JEFFREY's Log

This post contains mail written by me to the famous hacker Héctor Martín. The mail was regarding the basic steps in reverse engineering devices.

– MAIL BEGIN –
> 1) After opening a device, how do you understand which chip is the CPU ?

This is usually fairly obvious from the layout and the connectivity on the board. It really depends on the device, but it’s usually one of the larger chips, and may be connected to Flash memory, and/or to a quartz crystal. On larger devices it will have its own power supply, while on smaller ones the only telltale might be that it’s connected to most parts of the board. And of course, often you can just look up the part numbers and figure out what most chips are.

> 2) How are the firmwares extracted from the devices ? Is there a general principle ?

This depends heavily on the device. It can be as easy as connecting to a debug serial port and getting a text-based console into a bootloader that lets you dump the flash. Or it can be as hard as requiring a clock/power glitching setup in order to dump an internal mask ROM buried inside the CPU. Usually if the flash is external, you can remove it and dump it externally, or there might be a JTAG port through which you can read/write it. Microcontrollers with embedded flash usually have programming ports but the code is usually protected from readout; these are nearly impossible to dump unless you know of a specific vulnerability in the particular chip’s protection.

> 3) After getting a firmware dump how do you read it ?

If you know the CPU architecture in use, you run it through a disassembler and see if it makes sense. If you don’t know the architecture, you can try some educated guesses. After a while you learn to recognize some popular CPU architectures from a simple hex dump (e.g. ARM code sticks out like a sore thumb due to the condition code field, which means that every 32-bit word almost always starts with ‘E’). You can just use GNU binutils (objdump) to disassemble code (usually), but the IDA disassembler by Hex-Rays is quite popular in the reverse engineering community (albeit quite pricey). Sometimes the CPU architecture is unknown. I know some crazy people who can eventually make sense of an unknown binary and figure out what the opcodes mean, but I’m not one of them.

And sometimes if the firmware has very high entropy (it looks like “garbage” – no patterns, you learn to recognize this too) it usually means it’s either encrypted or compressed, so you might look to see whether you can find an offset after which there’s valid compressed data using a popular algorithm (zlib, LZMA, etc…). If it’s encrypted sometimes there are blockwise patterns (e.g. duplicated 16byte or 8byte blocks) that often mean it’s encrypted using a block cipher in ECB mode.

– MAIL END –

Tags: Reverse engineering

Below shown is my new LS-CH1.0TL LinkStation Live 1TB Buffalo-NAS purchased from MediaMarkt (Germany).

It supports one of my favourite feature – Its a hackable device! Flashing a new GNU/Linux firmware. Buffalo-NAS is based on GNU/Linux and also they provide its sourcecode in the downloads section webpage.

Also there is an dedicated hack portal for the Buffalo-NAS. Below is the link
Buffalo NAS-Central – http://buffalo.nas-central.org/wiki/Main_Page

I will post some hacks in my web log as I proceed.

Tags: hacking devices

Track every Watt(TEW) is one of the new Open Hardware based project which I am working on for the past few weeks. Track Every Watt is a pluggable device which can be used to measure power consumed by an electrical appliance. The device to be measured is connected to the TEW which has an LCD display which shows power consumed and also some additional information. TEW was inspired from Kill A Watt which is a device that can only measure devices with voltage rating  110V. TEW has a voltage rating of 230V and this is the reason why I started this project.

Track Every Watt can display additional information such as Voltage(V), Current(A), Watts(W), Volt-Amp(VA), Frequency(Hz), Power Factor(PF), Kilo Watt Hour(KWH), Time Elapsed. It uses an Analog Devices Energing Metering IC ADE7763. There is also an application note AN-564 for this IC.

Tags: Project, TrackEveryWatt

Two years before I had designed a mini development board for AT90USB162. There was a small mistake in that board. It didn’t have the 1MFD capacitor connected across the UCAP (PIN 27) and ground. Because of that the board was not detected while connected via USB. Last month I thought of repairing that board and do some USB projects. I ordered samples of ATMEGA32U2 from ATMEL. Thanks ATMEL for the samples.

Today I did a small hacking on the board. I added the capacitor as needed by USB. Now the board is working fine. There came the next problem. GCC-AVR version which I had, didn’t support ATMEGA32U2. Also for loading the hex into the controller, I used the dfu-programmer. Since I had installed it from the Ubuntu repository, dfu-programmer was of older version and it also didn’t support ATMEGA32U2.

After a few Google search, I found that if you compile for AT90USB162, the hex generated is supported by ATMEGA32U2. So I wrote the C code and compiled it for AT90USB162. Next task was to make the dfu-programmer to work. The only solution was to get the latest code and compile it. Below shown is the way to compile the dfu-programmer from source

$ mkdir dfu-programmer
$ svn co https://dfu-programmer.svn.sourceforge.net/svnroot/dfu-programmer/trunk/ dfu-programmer
$ cd dfu-programmer/dfu-programmer
$ ./bootstrap.sh
$ ./configure
$ make

Once installed, flashing the controller is very easy. First we have to bring the controller into USB bootloader mode. For that first press and hold the RESET button. Then press and hold the HWB button. Now release the RESET button and then release the HWB button. This will bring the controller into USB bootloader mode. Now we can issue the following instructions to flash the controller.

$ dfu-programmer atmega32u2 erase
$ dfu-programmer atmega32u2 flash blink.hex
$ dfu-programmer atmega32u2 reset

This is an Open Hardware project and I will soon post the schematic and PCB layout once adding the missing capacitor in the old design. Below shown is the snap shot of the board.

Tags: atmega32u2, atmel, USB

Please don’t forget to read this post before coming here.

For the newly developed Phoenix-MDK, I suggested few hardware modifications. Among them was the hardware modification for resetting the Phoenix-MDK through software i.e the user doesn’t have to press the reset button on the board to load a new program. I copied the design of software resetting from Arduino project.

The plan was to reset the controller using two pins i.e there was a pin (RTS) coming from the FTDI chip connected via a 100Kohm resistor to the reset pin of the ATMega32 and also a pin (DTR) from FTDI chip connected via a 100Kohm resistor to the PD2 pin of ATMega32. The two 100Kohm resistor was for current limit. So when the user wants to flash a software, he has to hold the PD2 down (because bootloader will wait for code from serial port only if this pin is low), send LOW pulse on RESET. Then Avrdude loads the code, take PD2 high and then send a Reset pulse again.

When I checked the Arduino design, they were only using the RESET pin to load the software using Avrdude. Arduino bootloader loaded the code in the following manner – Send a reset pulse. The bootloader will wait for the software from serial port . If the data is coming, then they will write the flash memory using that data or else they will jump to the main code. The greatest advantage over here was of using only one pin (DTR) of the FTDI chip to load the software.

I adapted the same design to the Phoenix-MDK. Now The other pin (RTS) need not be used i.e the DTR pin of FTDI chip was connected to the RESET pin of ATMega32 via 100nF capacitor. So we saved one pin (PD2) of ATMega32 which is not used in the new design.

The below python code can flash code to Phoenix-MDK (written by Pramode).
import serial, time
import os, sys
fd = serial.Serial(port='/dev/ttyUSB0', baudrate=19200)
print fd
fd.setDTR(1)
time.sleep(.1)
fd.setDTR(0)
cmd = 'avrdude -b 19200 -P /dev/ttyUSB0 -pm32 -c stk500v1 -U ' + sys.argv[1]
os.system(cmd)

Usage:
1) Save the above code as load.py
2) Write the code which you want to run on ATMega32 and Compile the code using avr-gcc.
avr-gcc -mmcu=atmega32 -Os filename.c
3) Convert a.out to hex file
avr-objcopy -j .text -j .data -O ihex a.out a.hex
4) Load the hex to Phoenix-MDK
python load.py a.hex

Update: I will soon upload the pics of newly developed Phoenix-MDK .

Tags: Arduino, atmega32, Phoenix