Issue while parsing DE 52 (PIN BLOCK) for mastercard

1,184 views
Skip to first unread message

Radhakrishna Venketeshwaran

unread,
Aug 23, 2010, 1:08:38 PM8/23/10
to jpos-...@googlegroups.com
Dear Mark

I have been trying to parse the Pin Block field 52.

I am using EuroPackager with PostChannel.

Initially i used the IFA_BINARY (4, PIN DATA) configuration (default). The field packager converts the 16 digit pinblock sent by mastercard "3FB5856E8EA7E797" (seen from the bit map) into 8 bytes "F577F777". However, what i need is the exact value "3FB5856E8EA7E797" to be read.

To help this cause i changed it to IF_CHAR, but it gave a unpacking error as it was expecting 30 for 0, 33 for 3 etc

Please let me know a field packager which can read the exact 16 digit pinblock sent by mastercard as is.

Note: Also i tried to convert "F577F777" back to hex using ISOUtil.hexString(), however the resulting string was 16 digit hex but did not match the original pinblock and as a result i am not able to decrypt it.

Kindly help me to read the exact 16 digit or convert back the 8 digit read using IFA_BINARY back to the original 16 digit.

Santhosh Venketeshwaran

Mark Salter

unread,
Aug 23, 2010, 1:21:49 PM8/23/10
to jpos-...@googlegroups.com
On 23/08/2010 18:08, Radhakrishna Venketeshwaran wrote:
> Dear Mark
And everyone else too 8)

>
> I have been trying to parse the Pin Block field 52.
>
> I am using EuroPackager with PostChannel.
>
> Initially i used the IFA_BINARY (4, PIN DATA) configuration (default).
> The field packager converts the 16 digit pinblock sent by mastercard
> "3FB5856E8EA7E797" (seen from the bit map) into 8 bytes "F577F777".
This seems an unlikely 'conversion', perhaps you have a previous field
that is mis-defined and your packager alignment is out?

How long is the field 52 on your interface, what form should it come in as?

> However, what i need is the exact value "3FB5856E8EA7E797" to be read.
>

Of course this is desirable 8), but is field supplied as character hex
or binary or something else?

> To help this cause i changed it to IF_CHAR, but it gave a unpacking
> error as it was expecting 30 for 0, 33 for 3 etc

IF_CHAR would work if the field was characters, but you would need the
right length (16?). You would need to convert to binary (perhaps)
yourself though.

>
> Please let me know a field packager which can read the exact 16 digit
> pinblock sent by mastercard as is.

MasterCard International or MasterCard Europe - this might be a loaded
question...

... have your checked your interface documentation?

8)


>
> Note: Also i tried to convert "F577F777" back to hex using
> ISOUtil.hexString(), however the resulting string was 16 digit hex but
> did not match the original pinblock and as a result i am not able to
> decrypt it.

As I said, I think you are misaligned, please check all of the fields
up to 52 match the specification?

Adding a Logger to you Channel and Packager will help you see how the
data is being parsed too.

--
Mark

Santhosh

unread,
Aug 23, 2010, 2:16:52 PM8/23/10
to jPOS Users
Thanks for your prompt reply. My packager alignment is correct, all
other fields are as expected.

Yes, it is for Mastercard international and the DE 52 element is 16
digits Hexadecimal encoded

I tried IF_CHAR (8). I am able to read the characters now.

Right value in the BITMAP: 5E818656488B9348
unpacked Value : ^??VH??H
After hexString : 5E3F3F56483F3F48

Value read is slightly different from what i can see from the bitmap.

This is what i did to read it back:
ISOComponent pinBlk = iso.getComponent (52);
byte[] bytePinBlk = pinBlk.getBytes();
bean.pinblock = ISOUtil.hexString(bytePinBlk);

As i said before the BITMAP shows the correct pinblock and i have
successfully decrypted it too. However, the issue is after unpacking
the value is slightly altered and thereby decryption fails.

After packing and unpacking the value has got altered.
> > did not matchthe originalpinblock and as a result i am not able to

Santhosh

unread,
Aug 23, 2010, 2:31:10 PM8/23/10
to jPOS Users
Just to add:

The value
^ ? ? V H ? ? H i decoded the value to 5E
3F 3F 56 48 3F 3F 48 which is what is there in the BITMAP. However,
hexString gives me 5E 3F 3F 56 48 3F 3F 48

I think i am doing a stupid mistake somewhere :-(.

Mark Salter

unread,
Aug 23, 2010, 3:46:40 PM8/23/10
to jpos-...@googlegroups.com
On 23/08/2010 19:16, Santhosh wrote:

> Yes, it is for Mastercard international and the DE 52 element is 16
> digits Hexadecimal encoded

This feels wrong from memory GAI is binary?

>
> I tried IF_CHAR (8). I am able to read the characters now.

But you said hexadecimal which would mean 16 characters for 8 bytes of
binary bitmap?

If this is what you are doing, you are placing binary data inside a
CHARacter representation.

Please try:-

<isofield
id="52"
length="8"
name="PIN Data"
class="org.jpos.iso.IFB_BINARY"/>

As you Packager definition?

>
> Right value in the BITMAP: 5E818656488B9348

Is the above the raw value you see in a dump/trace of the entire
message? The 'dumper' is presenting the binary data in hex for you.

> unpacked Value : ^??VH??H
This is the ASCII representation of the binary data with ? marking non
ASCII characters? This is where you are 'loosing' the resolution/data.

> After hexString : 5E3F3F56483F3F48
This is the hexadecimal character representation of the ASCII characters
you 'printed' above and have passed to hexString. Please check
http://www.asciitable.com/ for a manual breakdown.


>
> Value read is slightly different from what i can see from the bitmap.
>
> This is what i did to read it back:
> ISOComponent pinBlk = iso.getComponent (52);

Try iso.getString(52) with the field definition above instead.

> byte[] bytePinBlk = pinBlk.getBytes();
This is one problem, you are asking java to present the binary data
placed in CHARacter field as byte[], the default encoding on your
platform might play tricks and is I think introducing some mangling of
your data.

> bean.pinblock = ISOUtil.hexString(bytePinBlk);
This is doing exactly what you ask, converting "^??VH??H" ASCII
characters in their hex form.

>
> As i said before the BITMAP shows the correct pinblock and i have
> successfully decrypted it too. However, the issue is after unpacking
> the value is slightly altered and thereby decryption fails.
>

So manually works, after seeing the code you have the problem is more
obvious as indicated above.

--
Mark

Mark Salter

unread,
Aug 23, 2010, 3:49:49 PM8/23/10
to jpos-...@googlegroups.com
On 23/08/2010 19:31, Santhosh wrote:
> Just to add:
>
> The value
> ^ ? ? V H ? ? H i decoded the value to 5E
> 3F 3F 56 48 3F 3F 48 which is what is there in the BITMAP. However,
> hexString gives me 5E 3F 3F 56 48 3F 3F 48

I think you have pasted the wrong values into this message, those two
strings look the same to me.

>
> I think i am doing a stupid mistake somewhere :-(.

You will get there, you are close, please see my reply to your last posting.

I hope all will become clear for you.

--
Mark

Santhosh

unread,
Aug 24, 2010, 3:42:29 AM8/24/10
to jPOS Users
Hey Mark

As you said, ALL IS WELL NOW :-)

After changing it to IFB_BINARY (8)

I am able to translate the pinblock successfully. Thanks a tonn for
your help.

It was amazing how little changes i have made to the default packager
(jpos 1.6.4 - EuroPackager/PostChannel) to get certified for
mastercard issuing and acquiring. One change i can recommend is the
above IFB_BINARY(8) which was defaulted to IFA_BINARY(4) for PIN DATA
(DE52)

Will get back to you on parsing DE 48 PDS fields.

Also just a question, do you have a standard packager for IPM clearing
(ASCII and EBCEDIC). Not that i have an issue, it is working well for
me, but not sure what changes i had made to it (long ago) from the
default configurations.

Mark Salter

unread,
Aug 24, 2010, 4:31:06 AM8/24/10
to jpos-...@googlegroups.com
On 24/08/2010 08:42, Santhosh wrote:

> As you said, ALL IS WELL NOW :-)
>
> After changing it to IFB_BINARY (8)
>

Good.


> I am able to translate the pinblock successfully. Thanks a tonn for
> your help.

No problem.

>
> It was amazing how little changes i have made to the default packager
> (jpos 1.6.4 - EuroPackager/PostChannel) to get certified for
> mastercard issuing and acquiring. One change i can recommend is the
> above IFB_BINARY(8) which was defaulted to IFA_BINARY(4) for PIN DATA
> (DE52)

jpos6/modules/jpos/cfg/packager/europay.xml is the genericPackager
definition and already uses IFB_BINARY for field 52, so perhaps an
alignment is needed.

>
> Will get back to you on parsing DE 48 PDS fields.

On a nice new thread would be great 8).

You will hopefully find you only need to set the length value on the
subfields of 48 that you want to see/use.

>
> Also just a question, do you have a standard packager for IPM clearing
> (ASCII and EBCEDIC). Not that i have an issue, it is working well for
> me, but not sure what changes i had made to it (long ago) from the
> default configurations.

Not in the repository. I have often wondered if anyone would/could
contribute; Clearings are not my 'thing', although I would like to see
support for the file format added via a Packager.

I think the MasterCard files hold ISO8583 format records, but am not
certain.

--
Mark

Santhosh

unread,
Aug 24, 2010, 8:38:58 AM8/24/10
to jPOS Users
You are right it supports ISO 8583. I internally use JPOS to parse the
IPM records :-). Sure, will share my packager shortly.

akshay...@rupeepower.com

unread,
Jan 2, 2019, 12:51:55 PM1/2/19
to jPOS Users
Hii all,
I am new to jpos so I want to know to generate  ISO DE52.

please help me.

Alejandro Revilla

unread,
Jan 2, 2019, 2:37:21 PM1/2/19
to jPOS Users

Check ANS X9.24

Once you’ve got the binary image of your pinblock, you just need to call set(52, byte[]) on your ISOMsg object.




chhil

unread,
Jan 2, 2019, 7:09:39 PM1/2/19
to jpos-...@googlegroups.com
I assume your DE 52 is an encrypted pin block.

You start of with a pin, create a pinblock (see how it can be done here using the algorithm that needs to be supported. Once you have this pinblock you encrypt it with an encryption key. Encryption is usually DES.

Keys have a procedure in itself, key generations ,key exchanges and key management (thats what the ANS X9.24 is about) so that person sending and receiving use the same key. [Search for JCESecuritModule in the user group]. 
Jpos provides a software HSM that you can use for test (JCESecurityModule). 
It's great for testing as all the keys and pins can be seen in the clear, which is a big NO in PCI compliant production systems.


-chhil


--
--
jPOS is licensed under AGPL - free for community usage for your open-source project. Licenses are also available for commercial usage. Please support jPOS, contact: sa...@jpos.org
---
You received this message because you are subscribed to the Google Groups "jPOS Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jpos-users+...@googlegroups.com.
To post to this group, send email to jpos-...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jpos-users/CAAgSK%3D%3Dxa-q1QoWio%2BTKuV2XOmj-rLrMRiH4WmjhZpT5HAksNQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply all
Reply to author
Forward
0 new messages