I worked for a company that used a TON of VeriFone credit card terminals. We used the Zon Jr., the Tranz 330, and eventually the Tranz 380x2.
Before I detail the cracking, let me describe the operation of the terminals. The terminals ran a custom language called TCL (Terminal Control Language). It has NOTHING to do with the Linux hosted language of the same name. The memory in the terminals was laid out with an address from 0-999. When you wrote code, you used specific memory locations. For instance, when you press the "1" key, the code in memory location 107 gets kicked off. We nicknamed the code "License Plate Language" for reasons that you'll soon see.
Let's say that you wanted to write some code to get a 5 digit number from the keypad, and store it in memory location 150. The code would look like this:
B5.5
G
P112
K1.5
U150
*K
Now, this code would select a buffer to use (buffer 5), clear it, display what's in memory location 112 (presumably a prompt that said "Enter 5 digits" or some such), then, accept 5 numeric characters from the keypad, store it in 150, and return to idle.
Now, on with the story. We used thousands of these terminals, so our VeriFone salesman was ALWAYS bringing us new stuff. He brought us a new Tranz 380. Nice terminal, it had lots of memory, but it was of the "batch storage" type, not the code storage type, so it was of virtually no use to us. Then, someone at VeriFone got smart, and decided to modify the firmware to take that big glob of memory, and split it. Thus making *2* distinct code banks, and making the terminal act like 2 terminals! (You could load a COMPLETE firmware image on both sides of the unit, and toggle back and forth). For us, this meant that we could do a TON more work on the terminals than previously. But, in the process of writing this new code, they also put in a small form of copy protection. We found this out as the salesman is in the conference room talking to the muckity mucks about this terminal, which was delivered to me. While he was talking to them about the terminal, my friend Mike (now my Co-Worker Mike), and I had opened the unit up (4 phillips head screws), removed the EPROM, and copied it. Put the unit back together, and had it waiting when they came to take it back.
When the firmware in this unit booted, it checked a memory location in the battery backed RAM area, and if a bit was set in it, it continued to boot like normal. BUT, if that bit was CLEAR, it would calculate a "Lock code", and ask you to enter the "Unlock code". When I threw our copied EPROM into my 380, and saw this, I was both shocked, AND delighted! :-)
The terminals ran a Z-80 variant, it MIGHT have been a Z-180. Anyway, so, I whipped out the disassembler, and ran it through the code. This new Lock/Unlock code was at the VERY END of the ROM. (As you could imagine new code was just tacked into the first free space, at the end of the existing code). I studied it, saw the checking of the bit in the memory location, so my quick fix was to made a "Load Chip" (which I had modified the Lock/Unlock code to WRITE that bit into memory), and the normal "Run Chip", which was the normal code which would now find it's bit set, and run like normal. This was a solution to get us going, but not one that really made me happy. So, I released this hack to shipping, who played with it for a while, while I worked on a better solution. I studied their algorithm, and as you'd expect from someone used to writing code to do communications over the modem, and parsing of packets, the protection was VERY simple. As it turns out, I took their verification routine, and re-ordered the instructions so that now, it asked for the LOCK code, and gave you back the unlock code.
I had made a VeriFone Tranz 380x2 Keygen, using their code, and running on THEIR hardware. I thought it was funny, and I had a good time doing it.
Monday, August 11, 2008
Subscribe to:
Post Comments (Atom)
2 comments:
nice. How did you communicate with the TRANZ 380X2? Did you use windows or the many tools within linux (i.e. z80, etc.). I'm trying to figure out how to connect the terminal to my IBM machine. Right now I have the phone line 1st RJ11 connected to a serial port w/ an adapter. I also have a plug for the first serial interface plug on the terminal machine, but I doubt converting that to USB would be any different. Let me know if you have any hings
The round DIN connector on the back is what we used. There's a cable with a DIN on one end, and a DB-25 on the other.
(Yeah, this is a year late, but I felt obliged to answer anyway).
Post a Comment