I'm developing an interface to a VeriFone VX terminal. Although, this is really a general EMV question. Our processor has a zero floor limit, so it will always be sent online. However, in case it ever changes, how do you know (what tags) if the transaction was approved or declined offline? Or, in other words, how do you know to go online or not?
how do you know (what tags) if the transaction was approved or declined offline? Or, in other words, how do you know to go online or not?
The terminal has to decides either to proceed the transaction offline, to go online or to reject the transaction. Here terminal send a command (AC) to the card and response of this command helps terminal to decide the action next followed.
Decision making is depend on three fields -
1) - Issuer Action Code
2) - Terminal Action Code
3) - TVR
IAC, TAC and TVR have the same structure. For more to know this data you can see EMV BOOK 3
IAC Usage Example-
suppose IAC-ONLINE (TAG - 9F0F) = 08 00 00 00 00 ,
here byte 1 bit 4 is on i.e. offline DDA Failed ,
Here Issuer want to go online if offline DDA Failed.
when terminal perform DDA and it fails, it set corresponding bit in TVR
that means TVR says- offline DDA is failed for this card.
now terminal check IAC online and found DDA_Failed bit is on and same on in TVR, here terminal decision would be to go online and then it send a Gen AC command to card with p1 = 80 ( ARQC - Online authorisation requested).
Coding of P1 as below
Ex- Gen AC command
C: 80 AE 80 00 other data
R: SW1/SW2=9000 (Normal processing: No error) Lr=32
77 1E 9F 27 01 80 9F 36 02 02 13 9F 26 08 2D F3
83 3C 61 85 5B EA 9F 10 07 06 84 23 00 31 02 08
.
Now decision is made by card, Terminal get card decision in the response of Gen AC command. Card return tag 9F27 - Cryptogram Information Data. here card return 80 i.e. cards wants transaction to go Online.
Really your question is important and you need to read more spec for clarity on this topic. Please checks EMV BOOKs, for more in this topic. also can read - Terminal action analysis or Card Action analysis
Assuming you're using VeriFone's VIPA API, then the first 'Continue Transaction' command (GenAC1) returns tags wrapped in a TLV template (or 'constructed' TLV tag). The value of this template determines the result:
E3: Locally authorized
E4: Requires online authorization
AFAIK (in vanilla EMV) the tag Cryptogram Information Data ('9F27') returned during 1st GENERATE AC should serve this purpose.
See EMV Book 3, Table 14.
Beware, that this tag contains the decision of the card, so you won't see the cryptogram type the kernel required.
Related
I am trying to read dtc codes using following procedure:
1 - send 0101 which means get the number of the dtc codes
receive - 41 01 82 07 61 01 which means I have 2 trouble codes
2 - send 0x03 to receive codes and
receive - 43 01 33 03 01 00 00 which are the 2 codes : P0133 and P0301
Using a diagnostic service tester I get 5 codes on the same car: P0133, P0301 (the ones I get also) and P0303, P0300 and C1513
How can I see the other 3 codes using my OBD?
Here are pictures with the tester:
You might have multiple OBD2-conform ECUs in your car. To access these, use broadcast addressing or query each and every one separately by adjusting your arbitration ids.
That said, some readers may also show pending (0x07) or permanent (0x0A) DTCs.
What would be the best way to determine the issuer of a contactless EMV card. I am trying to determine if a card was issued by Amex, Visa or Mastercard. Is that information available via a USB EMV reader? I don't need to pull any other information from the card..
I'm assuming that it could be done by some python, or C++ code interacting with the card. I'm looking for a good jumping off point.
You should be able to get this info from the successful response of SELECT. Store the list of RIDs ( AID = RID + PIX ), and do SELECT one by one. On success, it will return status bytes 90 00, otherwise 6A 82( file not found ).
The easiest option would be through SELECT command as mentioned
before. The list of AID:
https://www.eftlab.com/knowledge-base/211-emv-aid-rid-pix/
The other option would be getting it from the PAN. You can define issuer
based on first 6 digits or 8 digits of the PAN, which represents Issuer
Identification Number (IIN)/Bank Identification Number(BIN).
34, 37 - American Express
4 - Visa
51-55, 2221-2720 - MasterCard
https://en.wikipedia.org/wiki/Payment_card_number#Issuer_identification_number_(IIN)
You would have to send commands:
SELECT
GET PROCESSING OPTIONS
READ RECORD
You would look for 5A - PAN and extract first digits.
Good tool that you can just use to read data from contactless EMV card is:
https://www.javacardos.com/tools/pyresman
You can create your own scripts or just proceed with some basic commands like a SELECT command.
I am using Docklight Scripting to put together a VBScript that communicates with a device via RS232. All the commands are sent in Hex.
When I want to read from the device, I send a 32-bit address, a 16-bit read length, and an 8-bit checksum.
When I want to write to the device, I send a 16-bit data length, the data, followed by an 8-bit checksum.
In Hex, the data that is sent to the device is the following:
AA0001110200060013F81800104D
AA 00 01 11 02 0006 0013F818 0010 4D
(spaced for ease of reading)
AA000111020006 is the protocol header, where:
AA is the Protocol Byte
00 is the Source ID
01 is the Dest ID
11 is the Message Type
02 is the Command Byte
0006 is the Length Byte(s)
The remainder of the string is broken down as follows:
0013F818 is the 32-bit address
0010 is the 16 bit read length
4D is the 8-bit checksum
If the string is not correct, or the checksum is invalid the device replies back with an error string. However, I am not getting an error. The device replies back with the following hex string:
AA0100120200100001000000000100000000000001000029
AA 01 00 12 02 0010 00010000000001000000000000010000 29
(spaced for ease of reading)
Again, the first part of the string (AA00011102) is a part of the protocol header, where:
AA is the Protocol Byte
01 is the Source ID
00 is the Dest ID
12 is the Message Type
02 is the Command Byte
The difference between what is sent to the device, and what the device replies back with is that the length bytes is not a "static" part of the protocol header, and will change based of the request. The remainder of the string is broken down as follows:
0010 is the Length Byte(s)
00010000000001000000000000010000 is the data
29 is the 8-bit Check Sum
The goal is to read a timer that is stored in the NVM. The timer is stored in the upper halves of 60 4-byte NVM words.
The instructions specify that I need to read the first two bytes of each word, and then sum the results.
Verbatim, the instructions say:
Read the NVM elapsed timer. The timer is stored in the upper halves of 60 4-byte words.
Read the first two bytes of each word of the timer. Read the 16 bit values of these locations:
13F800H, 13F804H, 13808H, and continue to 13F8ECH.
Sum the results. Multiply the sum by 409.6 seconds, then divide by 3600 to get the results in hours.
My knowledge of bits, and bytes, and all other things is a bit cloudy. The first thing I need to confirm is that I am understanding the read protocol correctly.
I am assuming that when I specify 0010 as the 16 bit read length, that translates to the 16-bit values that the instructions want me to read.
The second thing I need to understand a little better is that when it tells me to read the first two bytes of each word, what exactly constitutes the first two bytes of each word?
I think what confuses me a little more is that the instructions say the timer is stored in the upper half of the 4 byte word (which to me seems like the first half).
I've sat with another colleague of mine for a day trying to figure out how to make this all work, and we haven't had any consistent results with our trials.
I have looked on the internet to find something that would explain this better in the context being used.
Another worry is that the technical data I am using to accomplish this project isn't 100% accurate in their instructions, and they have conflicting information or skipping information throughout their publication (which is probably close to 1000 pages long).
What I would really appreciate is someone who has a much better understanding of hex / binary to review the instructions I've posted, and provide some feedback on my interpretation of the instructions provided, and provide any information.
I was submitting a job application, after research and a well thought out reply that was made on multiple questions, I clicked submit. Then the page asked me to re-input my login data, I pray it would 1. remember my form data or 2. Allow the back button to work, but no. Fun times! God damn whoever developed that page.
I have spent some time reading about how to resurrect the form data from Chrome from here and here.
I was able to do my regex to pull out the hex from the cached file, but it says that it is corrupted when I go to decompress it.
So my questions is how should the hex be?
Here is the first line, should it have two whitespaces at the end?
1f 8b 08 00 00 00 00 00 04 00 ed bd 07 60 1c 49 <--- here?
And what about the end?
13 fe <-- what amount of whitespace should be here?
I found a post on here that stated what the file should end in and it was not the same. So I not sure where else I can go with this.
Any ideas?
I am new to reverse engineering, and I have been looking at a simple program:
char* a = "hello world";
printf(a);
However, when I open this in ollydbg, I am not taken right to the assembly as I would have been in gdb, there are many more instructions first. I was wondering why this was happening.
Thanks!
Depending how you attach to the program with olly, you'll be take to one of two places(if no errors occurred):
The module entry point (aka the system glue and CRT wrapper for main/WinMain/DllMain): this occurs when you start a program with olly.
NtUserBreakPoint: this is when you attach to an existing process.
To navigate to where you want you can use ctrl + e to bring up the modules window, from there, select the module you want. Then use crtl + n to bring up the symbols window for your current module (note: for non-exported symbols to be available, the pdb's need to be available or you need to perform an object scan of your obj's for that build).
if your taken to the ModuleEntryPoint you can also just spelunk down the call chain (generally you want the second call/jmp), this gets you to the crt entrypoint, from there just look for a call with 3/5/4 args, this will be main/WinMain/DllMain:
from here:
Blackene.<ModuleEntryPoint> 004029C3 E8 FC030000 CALL Blackene.__security_init_cookie
004029C8 ^ E9 D7FCFFFF JMP Blackene.__tmainCRTStartup
we goto here:
Blackene.__tmainCRTStartup 004026A4 6A 58 PUSH 58
004026A6 68 48474000 PUSH Blackene.00404748
004026AB E8 1C060000 CALL Blackene.__SEH_prolog4
004026B0 33DB XOR EBX,EBX
then scroll down here:
004027D3 6A 0A PUSH 0A
004027D5 58 POP EAX
004027D6 50 PUSH EAX
004027D7 56 PUSH ESI
004027D8 6A 00 PUSH 0
004027DA 68 00004000 PUSH Blackene.00400000
004027DF E8 2CF2FFFF CALL Blackene.WinMain
I'm assuming ollydbg 1.10 is being used.