ChargePoint / wireshark-v2g

Dissector for the V2G Protocols
Other
43 stars 18 forks source link

CertificateInstallationReq and -Res are not decoded #25

Closed adoebber closed 1 year ago

adoebber commented 1 year ago

The V2G messages CertificateInstallationReq and -Res (as well as CertificateUpdateReq/-Res) are not decoded by the plugin: image

In addition the Info field in the table view is empty for those messages.

chardin-cpi commented 1 year ago

@adoebber - thanks, do you know the version this was in - pretty certain the din and iso code both got updated but it could be a bug in the lower code

        if (body->CertificateInstallationReq_isUsed) {
                col_append_str(pinfo->cinfo, COL_INFO,
                        "CertificateInstallationReq");
                dissect_v2gdin_certificateinstallationreq(
                        &body->CertificateInstallationReq,
                        tvb, pinfo, body_tree,
                        ett_v2gdin_struct_dinCertificateInstallationReqType,
                        "CertificateInstallationReq");
        }
        if (body->CertificateInstallationRes_isUsed) {
                col_append_str(pinfo->cinfo, COL_INFO,
                        "CertificateInstallationRes");
                dissect_v2gdin_certificateinstallationres(
                        &body->CertificateInstallationRes,
                        tvb, pinfo, body_tree,
                        ett_v2gdin_struct_dinCertificateInstallationResType,
                        "CertificateInstallationRes");
        }

So, not sure what is missing yet - is there a sample pcap as well maybe? might be able to just trace the code with that.

cc: @jhart-cpi

adoebber commented 1 year ago

@chardin-cpi I tested this with the released version at that time, so v0.3.4 (https://github.com/ChargePoint/wireshark-v2g/releases/download/v0.3.4/v2g-v0.3.4-win64.tar). Here is a pcap file. Packets 70 and 79 are CertificateInstallationReq and -Res messages. CertificateInstallation.zip

chardin-cpi commented 1 year ago

@adoebber - so, those pcap frames are causing these errors in the decoder from openv2g

Frame 70: EXI_ERROR_OUT_OF_STRING_BUFFER (-101) Frame 79: EXI_ERROR_OUT_OF_BOUNDS (-100)

So examining the stream a bit shows that the decode is failing because of a bounds check

iso1EXIDatatypes.h:#define iso1X509IssuerSerialType_X509IssuerName_CHARACTERS_SIZE 50 + EXTRA_CHAR 

and when the certificate chain is being decoded - the issuer name decode gets triggers from DecoderChannel.c

int decodeCharacters(bitstream_t* stream, size_t len, exi_string_character_t* chars, size_t charsSize) {
        ... snip snip ...
        if ( (len + extraChar) > charsSize) {
                errn = EXI_ERROR_OUT_OF_STRING_BUFFER;
                return errn;
        }
        ... snip snip ...
}

It appears the issuer name is too long (89 chars) which exceeds the 50 and thus causes the bounds check to fail. So, I wouldn't there isn't a way to relay to decoder and thus that is why the data is returned instead of a decoded struct.

So, the openv2g code seems to set an artificial restriction on the side of the issuer for decode since I think the type in xmldsig is just a string type.

/* Complex type name='http://www.w3.org/2000/09/xmldsig#,X509IssuerSerialType',  base type name='anyType',  content type='ELEMENT',  isAbstract='false',  hasTypeId='false',  final='0',  block='0',  particle='("http://www.w3.org/2000/09/xmldsig#":X509IssuerName,"http://www.w3.org/2000/09/xmldsig#":X509SerialNumber)',  derivedBy='RESTRICTION'.  */

cc: @jhart-cpi