Hacking a hack: disassembly and sniffing of IM-ME binary

It’s fun to pick apart code, but it gets more difficult when you’re talking about binaries. [Joby Taffey] opened up the secrets to one of [Travis Goodspeed's] hacks by disassembling and sniffing the data from a Zombie Gotcha game binary.

We looked in on [Travis'] work yesterday at creating a game using sprites on the IM-ME. He challenged readers to extract the 1-bit sprites from an iHex binary and that’s what got [Joby] started. He first tried to sniff the LCD data traces using a Bus Pirate but soon found the clock signal was much too fast for the device to reliably capture the signals. After looking into available source code from other IM-ME hacks [Joby] found how the SPI baud rate is set, then went to work searching for that in a disassembly of [Travis'] binary. Once found, he worked through the math necessary to slow down communication from 2.7 Mbit/s to 2400 bps and altered the binary data to match that change. This slower speed is more amenable to the Bus Pirate’s capabilities and allowed him to dump the sprite data as it was sent to the LCD screen.

[Thanks Travis]

Comments

  1. andrew says:

    #corrections “SPI baud rate” should be “SPI bit rate”

  2. andrew says:

    That’s pretty ninja

  3. Zilluss says:

    Was it part of the challenge to extract it via bus sniffing? Otherwise he could have just applied some reverse engineering et voilá

  4. Cybergibbons says:

    Nice work – a very clean way of doing this. It’s quite often fairly easy to identify the registers used to setup clocks, dividers, I/O etc. in a bin file and play with them.

    It’s also sometimes possible to change the onboard crystal for a slower one, or on some microprocessors, remove it altogether as it will fall back to the internal oscillator.

    On the other hand, it’s possible to buy a faster logic analyzer, but where is the fun in that?

  5. mungewell says:

    just to note that the BusPirate should work up to around 10Mbit/s in it’s raw SPI mode.

    There are PC utilities to configure it into this mode and record/display the data.

  6. Peter says:

    @andrew
    Baud rate is just symbols per second. Since SPI uses binary levels, bit rate = baud rate

  7. Joby Taffey says:

    @mungewell The Bus Pirate may capture faster signals, but it can’t get them out over the FTDI chip any quicker

  8. mungewell says:

    @Toby – the total usable rate depends on the SPI clock and the rate which the processor sends out the bytes. There is a ring buffer on the BP which provides for a little slack.

    To get maximum baud rate out of the BP use the ‘b + 9′ command to manual set a Raw baud-rate (460800 baud is ‘8’, 921600 baud is ‘3’) and then start the Raw utility at this higher rate.

    Not having a IM-ME I can’t say whether this would actually be fast enough… so I appologise if you have already tried this. Good hack anyhow!

  9. Anil says:

    Hi,

    I have a task to develop a device it will sniff or emulate HD44780 LCD communication with another device and it will send the screen content to PC.

    My first choice is to develop an emulator. It will emulate LCD and communicate with the LCD driver (host) and sends the screen content to PC through its serial port.
    Another choice is to sniff data line and control line. It will sniff the LCD communication between host and LCD and it will send the screen content to PC through its serial port.

    I can not change the program of the device (host) that drives LCD. LCD driver runs with 8 MHz crystal.

    I have a STK600 development board to sniff or emulate and I am using ATMEGA1280 with 16MHz crystal on it.

    I tried to develop an emulator first, but I saw that I can not answer LCD driver’s commands. It wants to check the busy flag on LCD, I can not response fast enough. I have only 8 cycle time (500 ns @16MHz) to answer the busy flag check, but in my interrupt vector code, there are many push and pop instructions at the beginning. Because of I can not answer on time, it causes too much delay in communication. I have to answer at the right time it asks.

    Did someone try to develop a hardware LCD emulator? Do you have any suggestions about this kind of project? Is the hardware I am using for development enough for me? My opinion is, I should use a faster device for this kind of project to emulate an LCD. Although I use assembly programming for development, 16 MHz is not enough for me I think. Is there anyone has an experience about this subject?

    If anyone is interested and willing to help me with their suggestions, I will give more information about what I did and I will put my source code here in C.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 94,528 other followers