-> 5AF4013D
<- 00 /*Success*/
-> AA01
<- AFA8394ED57A5E83106B4EE72FD2BB0CC4
How to proceed from here?
I have been struggling about a week with this. I can select app from the card and get that first response with the 0xAA ("AFA8394ED57A5E83106B4EE72FD2BB0CC4" equivalent) but what to do after that?
Do i need to encrypt or decrypt the response with my App_auth_key (16bit) or what and then send it to the card?
Encryption which I use is AES.
Related
Please see the transaction post
VPSProtocol=4.00&TxType=PAYMENT&Vendor=Vendorname
&VendorTxCode=324234906133500
&Amount=20.00
&Currency=GBP
&Description=Payment
&BillingSurname=Jo
&BillingFirstnames=Test
&BillingAddress1=43
&BillingCity=Ash
&BillingPostCode=Asd234
&BillingCountry=GB
&BillingPhone=323-8412233
&CustomerEMail=test#test.com
&DeliverySurname=Jo
&DeliveryFirstnames=Test
&DeliveryAddress1=43
&DeliveryCity=Ash
&DeliveryPostCode=Asd234
&DeliveryCountry=GB
&DeliveryPhone=323-8412233
&AllowGiftAid=0
&ApplyAVSCV2=1
&Apply3DSecure=1
&Profile=LOW
&VendorData=Rent
&NotificationURL=https://testpage/notificationpage.aspx
Please see the Transaction Post Response below
Status: OK
VendorTxCode: 324234906133500
VPSTxId: {8652345E-5B25-49F1-DD23-1B9CCC2B6545}
Security Key: AZFE2KOSDS
VPSSignature: N135C007EF1643ABE44CAC12EBD9ED43
StatusDetail: 0000 : The Authorisation was Successful.
TxAuthNo: 34234532
AVSCV2: SECURITY CODE MATCH ONLY
AddressResult: NOTMATCHED
PostCodeResult: NOTMATCHED
CV2Result: MATCHED
GiftAid: 0
3DSecureStatus: OK
CAVV: Y2c2ZVVBeTRvTUVwVGtpaGVMdzk=
AddressStatus:
PayerStatus:
CardType: VISA
Last4Digits: 0006
DeclineCode: 00
ExpiryDate: 0123
BankAuthCode: 999777
Surcharge: 0.40
FraudResponse:
ACSTransID: 490ead88-8dc8-4ac4-b40a-fbe1f8a95182
DSTransID: 3f06865c-33c1-462c-956d-01f4c55114b5
SchemeTraceID: Wkv0Jq8QEYu4DupyW0gG}s2~}N2K~U+7LAMYCVU0vXt2uH0prPJCpY6
The Issue is VPSSignature is not matching after computing the MD5 signature
VPSTxId+VendorTxCode+Status+TxAuthNo+VendorName+AVSCV2+SecurityKey+AddressResult+ PostCodeResult+CV2Result+GiftAid+3DSecureStatus+CAVV+AddressStatus+PayerStatus+CardType+ Last4Digits+DeclineCode+ExpiryDate+FraudResponse+BankAuthCode+ACSTransID+DSTransID+SchemeTraceID
SERVER Integration POST URL: https://test.sagepay.com/gateway/service/vspserver-register.vsp
Have you validated your code that builds the signature to be compared against VPSSignature in the Post response? Are they salting the MD5? Are you feeding it the exact payload? I fed your Post into an MD5 generator and I got 79dda36adfdc796412ab0fa77ca67380 instead of N135C007EF1643ABE44CAC12EBD9ED43 .
I have been working in setting up multiple AE titles and configured two AE called CLIENT1 and CLIENT2.
Now I have send hl7 order for these two AEs but at modality end i could fetch all the worklist irrespective of AE.
Could anyone of you please tell how to configure AEs in hl7 orm message we send and also how we fetch worklist according to AE
Thanks
Neeraja
This problem I got resolved by MWL item coerce i.e.,c-find request by using a mwl-cfindrq.xsl on ...server/default/conf/dcm4chee-ae/ having Scheduled Station AE striclty in ORM message we send.
I'm writing an web server with Lisp to handler HTTPS request. I followed TLS 1.2 and already completed the handshake process. The Cipher Suite I chose is TLS_RSA_WITH_RC4_128_SHA. I already calculated client_write_MAC_secret, server_write_MAC_secret, client_write_key, server_write_key. These keys seems are correct, because I can decrypt "Finished" message from browser and validate the data inside. I also validate the HMAC of the record layer. Then I send a "Change Cipher Spec" and "Finished" from server. So far everything seems working fine.
Then I got the message from browser start with #(23 3 3 1 61 ...). 23 means it's an application data. #(3 3) means TLS 1.2. #(1 61) means length is 256+61=317 which is correct because the data left is really 317 bytes long. Here comes my question: I decrypted these 317 bytes with RC4 using the "client_write_key" then I got data like #(148 104 81 182 67 111 28 201 202 50 207 57 126 209 19 ...) which can't be converted to text. I thought I should get something like GET / HTTP/1.1. What do I get wrong?
Thanks.
RC4 is a stream cipher and, according to RFC 5246, section 6.2.3.1, "For stream ciphers that do not use a synchronization vector (such as RC4), the stream cipher state from the end of one record is simply used on the subsequent packet."
So, the first record you decrypt is the FINISHED message and the first application data you decrypt should be with the RC4 state as it was left after decrypting the FINISHED message.
when I send an API ND command to a remote endpoint I get ???
When I send an API ND command from a VB program using the following packet;
7E 00 05 08 01 4E 44 00 64
I get;
7E 05 3F 14 E4 41 3F
Its a response -- but not as I know it. Neither the checksum "3F" or command length "05" are comprehensible to me. On the other hand if I wait for more bytes by setting "Serialport1.ReceivedBytesThreshold" (threshold: 10 bytes in buffer > event is fired) to 10 the "SerialPort1.ReadExisting()" statement times out. Any suggestions for decoding? Both coordinator and endpoint are XBEE PRO S2Bs.
I don't think it makes sense to send ATND as a remote AT command, and it will probably be ignored on the remote node, or trigger node discovery at that node with the responses staying local.
It looks like your response is possibly dropping null bytes (0x00), like the MSB of length, and one more in the packet itself. I'm not familiar with a frame type of 0x3F though -- is it documented for that XBee module you're using?
After a node discovery, you should see multiple AT Response frames (type 0x88?) come back over some time (based on ATNT, I believe), until you get one with a short payload (indicating discovery is complete).
In the SSL client, I am receiving a serverHello message with tampered message length like below.
"16 03 00 00 35 02 00 08 00... "
Here, "00 08 00" is message length which is coming as 2048 bytes. But in the next record, it sends "serverCertificate & serverHelloDone" messages.
So, in the client side, it waits to read 2048 bytes. but messages "serverHello, serverCertificate, serverHelloDone" are not having 2048 bytes combinedly. So, still client waits to read pending message (socket is blocking socket). So, it just waits in recv and never comes out.
I would like to know how applications should handle this situation. Is there any way in SSL protocol, we can identify this. If not possible, how applications should handle this situation to come out ?
Thank you !
Regards
Satish.