Open sidohin-felix opened 7 months ago
I checked this point using another lib (https://www.npmjs.com/package/asn1js) using this method:
fromBER(buffer).result.valueBlock.value[1] (to pick up a only problem string)
where buffer is an hex code example above (30820c92020100031100890e6dada073475c839b216850c1...)
and saw this object:
{
"blockName": "BIT STRING",
"blockLength": 19,
"error": "",
"warnings": [],
"valueBeforeDecode": "031100890e6dada073475c839b216850c19f48",
"idBlock": {
"blockName": "identificationBlock",
"blockLength": 1,
"error": "",
"warnings": [],
"valueBeforeDecode": "",
"isHexOnly": false,
"valueHex": "",
"tagClass": 1,
"tagNumber": 3,
"isConstructed": false
},
"lenBlock": {
"blockName": "lengthBlock",
"blockLength": 1,
"error": "",
"warnings": [],
"valueBeforeDecode": "",
"isIndefiniteForm": false,
"longFormUsed": false,
"length": 17
},
"valueBlock": {
"blockName": "BitStringValueBlock",
"blockLength": 17,
"error": "",
"warnings": [],
"valueBeforeDecode": "",
"isIndefiniteForm": false,
"value": [
{
"blockName": "PRIMITIVE",
"blockLength": 16,
"error": "",
"warnings": [],
"valueBeforeDecode": "890e6dada073475c839b216850c19f48",
"idBlock": {
"blockName": "identificationBlock",
"blockLength": 1,
"error": "",
"warnings": [],
"valueBeforeDecode": "",
"isHexOnly": false,
"valueHex": "",
"tagClass": 3,
"tagNumber": 9,
"isConstructed": false
},
"lenBlock": {
"blockName": "lengthBlock",
"blockLength": 1,
"error": "",
"warnings": [],
"valueBeforeDecode": "",
"isIndefiniteForm": false,
"longFormUsed": false,
"length": 14
},
"valueBlock": {
"blockName": "PrimitiveValueBlock",
"blockLength": 14,
"error": "",
"warnings": [],
"valueBeforeDecode": "",
"isHexOnly": true,
"valueHex": "6dada073475c839b216850c19f48"
},
"name": "",
"optional": false
}
],
"isHexOnly": false,
"valueHex": "890e6dada073475c839b216850c19f48",
"unusedBits": 0,
"isConstructed": false
},
"name": "",
"optional": false
}
the most interesting thing is a field:
valueBlock.value.valueBlock.valueHex: "6dada073475c839b216850c19f48"
which is not valid for us
but, we also have another value from this object
"valueHex": "890e6dada073475c839b216850c19f48"
which is exactly what we need so, I would like to understand why this happened. there is a feeling that the line "890e6dada073475c839b216850c19f48 "has undergone additional processing
and of course I wouldn't want to use this library, because I need process each value and also this library works twice as slow
The problem is that unfortunately many "interesting" ASN.1 structures hide content inside either BIT STRINGs or OCTET STRINGs, and since asn1js has a "best effort" decoding approach it tries decoding the content of any of those and if it "just happens" to be valid ASN.1 it shows the content as "embedded" (instead of "constructed", which means it was done with proper ASN.1 structures).
As you can notice (while hovering the BIT STRING, not the content) is is made so:
03 11 00 89 0E 6D AD A0 73 47 5C 83 9B 21 68 50 C1 9F 48
Where 03
mean it's a BIT STRING, 11
means it is 17 bytes long, 00
is the number of unused bits (0 means the last byte is fully used), then the content which in this case is raw 89 0E 6D AD A0 73 47 5C 83 9B 21 68 50 C1 9F 48
.
Problem is, 89
means custom tag [9] and 0E
means 14 byte long, which actually match the rest of the content.
This is most probably a false positive, but it is unavoidable (while keeping the approach of decoding as much as possible for "hidden" internal structures, which are not rare).
You have the very same behavior that that other library you cite which I have no experience with, but they do basically the same I do in returnig you both the direct hex encoding of the current node, and a way to access inner structures with .value.valueBlock
.
there is a feeling that the line "890e6dada073475c839b216850c19f48 "has undergone additional processing
Actualyl this is the raw content of the BIT STRING, it's the "6dada073475c839b216850c19f48" that actually has undergone additional processing, in trying to decode as inner value.
If you are using asn1js and never want to go inside "encapsulated" structures, you can do that by checking for that explicitly, there is currently no way to disable recursion altogether.
Would you like a checkbox in the GUI to avoid any recursion? (this is not a great approach when you have big ASN.1 structures with both BIT STRINGs that use recursion and ones that should not, though)
Or maybe, when using as a library, I could make it more easy to understand when a node is an actual "encapsulation" (which might be a false positive).
Actually your very example contains both an example you say is a "false" content, and a node that, from its complexity, I'd say it's DEFINITELY a real encapsulated content:
I could make it more easy to understand when a node is an actual "encapsulation" (which might be a false positive).
Actually it's not very difficult (while not very documented), you could do it like this:
if (this.sub !== null) { // has inner structures
if (this.tag.tagConstructed)
// this is a constructed content (for sure)
else
// this is a (supposedly) encapsulated content
}
There are cases when an application specifically considers that the client should parse a BitString, however the recurse variable defined in Line 332:
BTW I'm not sure I understood this correctly, as the rest of you message seems (to me) to be about a structure which was erroneously decoded, not a structure that hasn't been decoded but should have been.
Can you clarify?
Hello!
Not necessarily a bug more of an issue when receiving messages from an application with specific rules
https://github.com/lapo-luchini/asn1js/blob/6fa69ff58a421794078f4f07358d3da17526808c/asn1.js#L442-L450
There are cases when an application specifically considers that the client should parse a BitString, however the recurse variable defined in Line 332:
is triggered. This cause the JS client to be unable to parse the correct value contained within it. It would be very nice to be able to force this variable to force under certain circumstances.
Example hex:
When decoding this, you can find the following data:
In this case the BitString should have just remained a BitString of length 128 but it gets decoded into an unknown type 9 with a length of 14 bytes.