TLV String not working properly

[Jonathandelacruzp]

HI I have a problem with a particular Strigng Hex. I tested the Hex String on a thirdparty webpage and had result, but with the library had the next message error.

The TLV String:
78795C185F605F615F625F635F645F6A5F215F225F235F7D5F7B5F7C5F600834353936393633305F6101355F620556494C43415F63075A4150415441205F64114B4154484552494E452043594E544849415F6A01465F21063134303133325F22063035303438365F2304202409055F7D005F7B005F7C041900010100000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000

The app that I testestd the String:
http://www.emvlab.org/tlvutils/

The Exception:
Message = "Index was outside the bounds of the array."
StackTrace = " at BerTlv.Tlv.ParseTlv(Byte[] rawTlv, ICollection1 result)\r\n at BerTlv.Tlv.ParseTlv(Byte[] tlv)\r\n at BerTlv.Tlv.ParseTlv(String tlv)\r\n at PCSC.DNIe.Logic.DNIe.SetPersonalData(Response response) in D:\\TFS\\TFS_Outlook_jdp\\DNIe\\PCSC.DNIe\\... TargetSite = {Void ParseTlv(Byte[], System.Collections.Generic.ICollection1[BerTlv.Tlv])}
InvocationFlags = INVOCATION_FLAGS_INITIALIZED | INVOCATION_FLAGS_NEED_SECURITY

Thanks.

Greeting.

[kspearrin]

Thanks. I'll need to look into patching this.

[prasaathviki]

Failed to parse

This app reported there is an error at the end of the last tag
— Failed to parse
00

so still we need to decode them?

[kspearrin]

Unfortunately I don't really have the time to figure out the patch for this so I will have to leave it up to someone to submit a PR to address this issue.

[Jonathandelacruzp]

Hi, sorry about the time without response. Comment you that the Peruvian government (RENIEC) have a mistake writing the SmartCard, so I fixed with a simple try catch :D adding or decreasing the TLV array that I get from the card. I think is a writing issue. It works spectacularly well. Thanks for the response and the support. Greeting.

…

On Thu, Apr 20, 2017 at 9:00 AM, Kyle Spearrin ***@***.***> wrote: Unfortunately I don't really have the time to figure out the patch for this so I will have to leave it up to someone to submit a PR to address this issue. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#1 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AGZA3IVbYGS4xaE-n83OpnRHgvlpxoCuks5rx2TwgaJpZM4LUUxw> .

-- *Jonathan De La Cruz*

[prasaathviki]

I tried to figure out the reason behind the failure. And now supported padding bytes too in my branch.
According to Book 3 Annex B 1.1 Make sure that any data up to end-of - file is all 0x00 or 0xFF padding bytes. So i have created a solution for that.

MyFixForPaddingBytes

[bepursuant]

EMV Book 3 v4.3, page 172 states that 0x00 may exist as padding before, between, and after tags as well:

Before, between, or after TLV-coded data objects, '00' bytes without any meaning
may occur (for example, due to erased or modified TLV-coded data objects).
Note: It is strongly recommended that issuers do not use tags beginning with ‘FF’ for
proprietary purposes, as existing terminals may not recognise ‘FF’ as the beginning of a
constructed private class tag.

I submitted PR #3 that skips these 'null bytes' while parsing, which should address this issue, as well as an issue I was having when parsing application records with a truncated tag 57 value.