in reply to help needed badly parsing ASN.1 data

Umm... well, there are standard CPAN routines for standard ASN.1 encoding and decoding, such as Convert::ASN1 but I see telltale signs that your data may not be quite the same format as the ASN.1 BER (see for example http://www.columbia.edu/~ariel/ssleay/layman.html for a description of how "real" ASN.1 works.)

You say there are many TLV's in the data files, but the beginning of your decoding example decodes 0d, a1, 0b... as de1, comp1, era1... indicating that these are entities that code as single individual bytes and not as TLV's. (If the 0d started a TLV the a1 after it would have to be the length field... except that its high order bit is set, so in ASN.1 BER it would really be just the first byte of a multibyte length field...)

So, as best as I can tell from your description, there seems to be a field missing in the data files that would tell you whether a particular value in the first byte indicates a single-byte entity, like 0d, or whether it is is the first byte of a multiple byte TLV, like 02. And it makes no sense for the entry "01 opcode length" to appear in the data file; any small integer can be a length. (Unless it means that if the opcode tag is 02, then the only possible length is 01...?)

I think your biggest single problem is that when you say "01 stands for 'abcd' and also in some other place it stands for 'cdfv' also" you need to be able to put into words exactly how that decision needs to be made, and you need to be able to locate all the information used to make that decision. Actually, formulas or tables might work better than words, but all the details need to be fully fleshed out.

You shouldn't be worrying too much about how to express the algorithm in Perl until you get that far. From that point, most of it should be fairly straightforward array manipulation.

  • Comment on Re: help needed badly parsing ASN.1 data