search

juks / iso-8583-socket-queue

ISO 8583 gateway
MIT License
194 stars 111 forks source link

PIN Block field 52 #44

Closed scalpovich closed 4 years ago

scalpovich commented 4 years ago

Hi Igor, HOpe you're doing. I get one question Is SQ support pin block (de52) encrypt and decrypt. If yes what is the method? How to form the pin block tosend to host

juks commented 4 years ago

Hi Noe!

No, it both doesn't come with such a specific logic and doesn't care about the pin block as this data is very sensitive. It is being encrypted by the POS terminal then checked on the bank side.

scalpovich commented 4 years ago

Thanks for your feedback.

Warms regards

scalpovich commented 4 years ago

Hi Juks, Get an little issue with value send in de52. i use an external crypto libs to format the secure pinblock but value send in de52 through SQ to the host is not formal well. image kindly assist

juks commented 4 years ago

This seems to be a display issue. What is field 52 format?

ll-bin-char should be displayed correct.

scalpovich commented 4 years ago

yes. Even i use ll-bin-char same issue image

Thats what client send 👍

curl -H "Content-Type: application/json" -X POST -d '{ "0": "1100", "3":"000000", "7": "1027160933", "11": "618160", "12": "191027130600", "24": "100", "25": "000", "33": 101010, "52": "0912AC251359B8D7" }' http://localhost:2017

also i remark that in httpcleintserver you declare hexfield value

// Todo: proper initialization with no hardcode var hexFields = [52,55];

kindly explain

juks commented 4 years ago

There was another hardcode, fixed it (forgot to mention this issue): https://github.com/juks/SocketQueue/commit/b5741ec819424732d0ed3e1cde689ca88dffe310

scalpovich commented 4 years ago

Hi Igor, Thank for your revert. After merge still get same issue, I definitly remove field52 from hexFields rray and the value sent well.

Therefor I get sam issue with field 55. Even i remove it fro hexFields array

juks commented 4 years ago

Hi! Could you please provide the entire case exaple, like curl command you are using or equivalent.

scalpovich commented 4 years ago

Hi, Kindly see below

{"0": "0100","2": "6367111201570495","3": "000000","4": "000000000500","7": "1910131642","11": "123456","12": "191013164212","14": "2001", "15": "191023","18": "7011","19": "562","21": "686", "22": "600030V05100","24": "100", "32": "950160","37": "123456789878","41": "00048048","42": "0400600048048 ","43": "SCALP","48": "P310041100P92003236P70045 940164 6860081002000 TEST 7011P6100210", "49": "952","53": "0099000000", "55":"9f2608571f1e10d4fa4aac9f2701809f100706010a03a4b8029f37045bb074729f3602000c950500800010009a031508189c01009f02060000000010005f2a02064382023c009f1a0206439f03060000000000009f3303e0f0c89f34034403029f3501229f1e0835313230323831358407a00000000310109f41030000565f340101","128": "00000000" } http://localhost:2017

juks commented 4 years ago

Thanks! But there is no field 52 here, or? What is your expectation?

scalpovich commented 4 years ago

For De52 after remove it from hexData array it's passed well. But for de55 send like thath, my host get it wrong like : image

scalpovich commented 4 years ago

Hi Igor any update

juks commented 4 years ago

Hi, i am really sorry for this inconvenience, but i don't have means for coding right now. Went for bicycle training.

What actually hexFields does it just treat given values as hex coded. So for example 20 will produce a 0x20 byte (space, code 32) and 2020 will be to spaces. If field is not listed in hexFields it will just pass as a string.

https://github.com/juks/SocketQueue/blob/dd83a83f2e998180dce0f5417fd4db95f3a5c11c/lib/socketServer/lib/clientHttpServer.js#L180

What you get on your host side does show an easy explination in a straight point of view: there should be no zeroes at any scenario. Could you please provide the whole message on the host side or what is being logged by SocketQueue before sending. There might be some other format expected rather than ll-bin-char that is: LLLLDATA, where LLLL is starting length counter (one byte for field length under 100, or two bytes for greater):

https://github.com/juks/SocketQueue/blob/dd83a83f2e998180dce0f5417fd4db95f3a5c11c/lib/iso8583/lib/packer/ll-bin-char.js#L27

The problem might be also related with the value length. You cat try tweaking field length to se if there will be any difference.

scalpovich commented 4 years ago

Hi, thank for your revert. The format expected for my host is LLLVAR b..255

juks commented 4 years ago

So, did you solve it?

scalpovich commented 4 years ago

Not yet. Is it possible to add lll-bin-char packer? Im trying tweaking field type and when i use LLLANS and remove it from hex array, the field 55 has been get on my host but the contain value is not correct., Host parse it as hex. Seems like some hardcode convert my string entry send by the http client.

juks commented 4 years ago

Probably your host expects ascii encoded length. So it is lllans format. According to your example above, you send the field value in HEX mode so need to leave it at hefFields or send in ascii.

I suggest you engineer the problem by producing the message payload in place then sending it to the host to see what happens. Just like this: cat ./test_payload.txt - | nc host port. You can copy the current message from SocketQueue debug output (run with --dangerous), then edit it with hex editor to understand whats wrong. There is not much options: first understand the way length is expected, then the message body (ascii or hex).