teardown: Verifone vx570 card terminal

The following is a disassembly of a working Verifone Vx570 I scored off ebay for $20. The switch that sits behind the spring-loaded LCD display had already been tripped before I received it, meaning that it had switched into recovery mode.

The device has a large number of components, with roughly 28 IC’s and a number of physical ports as well:

  • USB
  • RS232
  • Ethernet
  • Modem
  • Pin Pad

The following IC’s can easily be identified:



teardown: Garmin Nuvi 2559LM

I’ve had a spare Garmin GPS unit kicking about that I had no particular use for, so decided to pull it apart and look at how it might be hackable. These are largely notes for my own future reference.

The core components are:

  • A 3.7v 930mAh rechargeable Li-ion battery (part # 361-00035-01)
  • A DFD050V1-PFLW 5″ LCD touch screen. These seem to be fairly common, available on ebay and other places.
  • A square ceramic device labeled g393 – presumably a gps antenna
  • A USB Mini socket
  • A speaker
  • A microphone
  • SNI2065850 BZCE 3BAQNYW – unidentified square BGA chip; I’d hazard a guess this is the main SoC, via process of elimination.
  • A winbond w971gg6jb25 1Gbit DDR2 SD RAM chip (datasheet)
  • An unidentified chip labeled SNA9033 A2 TI 3CI AHZJ G4
  • A TI AIC3120 Audio chip (datasheet)
  • A samsung klm8g1we4a-a001 8GB NAND flash memory
  • An unidentified NL5500L chip
  • A MicroSD slot

Select source code for this device has been released by Garmin as part of GPL obligations, and no real surprises it includes the linux kernel:

Having a look through the kernel patches, TCC9201 shows up. A quick google suggests this may be a Telechip ARMv11 processor that has indeed shown up in other garmin products. This is likely the unidentifiable BGA IC.

Circuit board notes:

  • There are quite a few test points, although none stand out as obvious UART or JTAG.
  • There is an PCB antenna, most likely for bluetooth.
  • There are a few unpopulated pads, in row formation as well as quad and DIP.

Attack surface:

  • Desoldering the BGA flash chip doesn’t appeal as it’d destroy the device.
  • I plan to look at each of the test points with a scope to see if we get lucky with any serial or other interfaces. Perhaps a JTAGulator against groups of TP’s as well.
  • Garmin have Windows & OSX applications for updating the firmwares and map information on these devices, which may be an interesting way to communicate or write a different flash image to the unit.
  • It may be worth interfacing via Bluetooth, although I’m not sure whether it is used for anything more than just as a handsfree audio device to a mobile.




swift overflow detection

The swift programming language takes a few steps forward for security in a number of areas over it’s predecessor Objective-C, which itself is a lot less of a footgun by design than C/C++.

One feature it has is by-default wrapping prevention for it’s Int values. The following code in Swift will cause an exception – you’ll break in a debugger or simply terminate the entire app if you’re running on iOS:

var i:Int8 = 100
i = i + 30

How does this work under the covers? The following screenshots from hopper show us a disassembly of the compiled binaries, in x64 and ARM.


In the above x64 disassembly, the constant 0x14 (20) is added to the low 8 bits of RAX (AL). The SETO instruction then sets the R8 register (R8B) conditionally if the previous ADD has caused an overflow. This value is then tested using TEST, and finally causes a conditional Jump to 0x100001532 if TEST showed R8 having been set (IE, there was an overflow).

The resulting jump if there has been an overflow is simply to UD2 – UnDefined instruction; raise an invalid opcode exception.


ARM follows a fairly similar path, with B.VS conditionally jumping based on overflow being set, branching out to a BRK; trigger a debug breakpoint.

Interestingly, both ARM and x64 in particular places use a full 64-bit register which is still capable of catching an overflow condition when the Swift data type is Int8 (IE triggers exception when incremented beyond 127) This likely is necessary to be synthesized on ARM due to a lack of access to lower 16 and 8 bits.

Defcon CTF Quals 2016: xkcd

After a friday at work, I took the subway home to have a nights rest before the weekend I intended to spend hacking on the defcon qualifier challenges. I got home and jumped on my laptop – the competition started at 8pm NYC time thanks to timezone differences, so thought I’d see what was likely to be lined up in terms of challenges.

Logging into the legitBS site, I noticed a few Baby’s First challenges available, so I clicked through each having a look at what they might entail. The last was named xkcd, and being a fan of the comic I took a look.



Might want to read that comic as well… 1354

The XKCD comic is this one: https://xkcd.com/1354/

So, the challenge likely has something to do with reading memory. I decided to take quick look at the binary to see what might be involved, and a while later I’d solved it.

First off, I ran file on the binary to see what it likely was:

rook:defcon_ctf tecnik$ file ~/Downloads/xkcd
/Users/tecnik/Downloads/xkcd: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), statically linked, for GNU/Linux 2.6.32, not stripped

Much to my happiness, not some less-common architecture or highly packed binary. Not even stripped. I decided to take a peek in IDA..

The program was very small, with only a few basic blocks in the main function.


In the above block of code we call setvbuf() for stdout and stdin, call bzero() on a buffer which points to a location in which we eventually read our flag (annotated here as ‘flag_buf’) to clear the memory, and then open a file whose name is ‘flag’. In the last line we test whether the open was a success or not.

I followed along to see what happens with the opened flag file.


If the fopen64() call succeeds, 0x100 bytes (256) is read from the ‘flag’ file into the .bss segment buffer pointed to by flag_buf. Nothing interesting happens if the fopen64() of the flag file fails.

Following the fread(), we drop into this block:


The first call is to fgetln() which reads data from stdin, with a pointer to the read data returning in the rax register. This is fed into strtok() to grab the first token leading up to the ‘?’ character.

A call to a function which (I confess I didn’t look at but made too much sense) looked like strcmp() checked that the first token from fgetln() matched “SERVER, ARE YOU STILL THERE”. If it’s not, we exit.

This is where I remembered the XKCD comic (https://xkcd.com/1354/). The comic repeatedly uses the following string to demonstrate a request to a remote server:


On to the next block of code:


Here, we perform another strtok(), sending in NULL as the buffer pointer, signifying we’re continuing along the string, but this time looking for a ” character as the end of token.

We strcmp() this against ” IF SO, REPLY “, which perfectly matches our xkcd cartoon. Again, if this string doesn’t match, the program sends back an error message (MALFORMED REQUEST) and bails out.

The program performs another strtok(), this time collecting all the data leading up to the ” character again. A pointer to this token string is put on the stack and we also run a strlen() across it to see how long it is.

The next call is to memcpy(), and we’re copying the tokenized string that existed between the two ” characters into a global buffer known in this binary as ‘globals’. The length we memcpy() is taken from the previous strlen.

The next call out is to strtok() again, this time we’re grabbing the string that exists leading up to the ( character. As you’ll see in the final screenshot, that string is discarded – we’re just moving along.

Final basic block:


The subsequent strtok() call reads everything up until a ) character is encountered. The call following this is to __isoc99_sscanf(), which is using our token value as input, a scanf string of ‘%d LETTERS’ as a format specifier, and a single pointer into our stack frame as the destination of integer read specified in the format string.

Or more simply, we’re grabbing the 6 from (6 LETTERS) as per the xkcd cartoon.

Whatever number value we send in as the LETTERS variable is then used to pop a NULL into the globals buffer to terminate the string.

Finally, we run a strlen of our globals buffer. If the length we’ve specified in the LETTERS variable is equal or less than the data we put in the globals buffer, we jump to a block which calls puts() to print out the globals buffer. If we’ve put a larger value in in LETTERS than the length of the data in globals, an error message ‘NICE TRY’ is printed.

At this point I start testing against the remote hostname we were given, sending the following payloads:


Interesting. Being such a small binary mean that the answer was likely pretty straight-forward.

— Burger and whiskey break —

Ok, so in order to hit the puts() call and print out data, we need to ensure the last jump is taken, meaning that the LETTERS value we send in cannot be more than the length of the globals buffer. We control where the NULL is written into the globals buffer, so as long as there are no other NULL values, we can read as long as we want.

The problem is, the buffer has 256 bytes of bzero()’d data. But what lies beyond?

Taking a look in IDA, we see that right after the globals buffer is the ‘flag_buf’ we read in earlier. Excellent.

If we send in enough data to fill up the globals buffer so that it flows directly on to the flag buffer, then request a length via the LETTERS variable that exceeds the data we sent, we should be able to over-read. I tried it using the following python code:

#!/usr/bin/env python
import socket
import sys
s1 = socket.socket(socket.AF_INET,socket.SOCK_STREAM)
resp = s1.recv(1024)
print resp[BUFLEN:]

And sure enough:

rook:defcon_ctf tecnik$ ./xkcd.py
The flag is: bl33ding h34rt5

I jumped back on the LegitBS panel and popped it in for the win.