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]

9 thoughts on “Hacking a hack: disassembly and sniffing of IM-ME binary

  1. 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?

  2. @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!

  3. 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

This site uses Akismet to reduce spam. Learn how your comment data is processed.