Reverse Engineering Stack Exchange is a question and answer site for researchers and developers who explore the principles of a system through analysis of its structure, function, and operation. It only takes a minute to sign up.
Sign up to join this community
Let's assume I have a device with an FPGA on it, and I managed to extract the bitstream from its flash. How would I go about recovering its behavior?
One simple case is if it implements a soft processor - in that case there should be firmware for that processor somewhere and I can just disassemble that. But what if it's just a bunch of IP blocks and some additional logic?
While FPGA makers don't just throw their formats out there, there is extensive documentation at a low level. Xilinx devices are a good example.
To reverse engineer the bit stream you might generate test cases that implement simple logic and see how those translate to the bit stream, then move on to designs that exercise different portions of the chip.
At the basic level, you would want to know how a CLB is controlled then the IOBs and interconnects. the CLBs are the logic the IOBs the are connected to the pins and interconnects link up the CLBs and IOBs. This document should give you a lot of insight into how FPGAs are implemented and how you might go about reverse engineering the bit streams. Do note that newer FPGAs are moving to 6-input luts rather than 4-input as was common.
Just keep in mind that the bit stream isn't software - it is a hardware configuration image. So, it's actually very similar to how ENIAC must have been programmed - rewiring circuits and flipping switches to program it - except in this case you are setting up routes with interconnects and logic in the CLBs.
Also the guy behind the Ben NanoNote is writing a fpga-toolchain which I am following avidly. Since a secondary to my SparcStation collecting hobby is reimplementing sun4m, a SparcStation architecture, in FPGA. After all who wouldn't want to be able to configure an FPGA from an FPGA with your own processor design on it.
Update: It's worth noting that IceStorm (mostly ice40 chips) and NextPNR (Multi targeted at ice40/ECP5/Xilinx Series 7) are the current state of the art reverse engineered FPGA toolchains.
Xilinx Virtex II had an "open" bitstream, meaning that the bitstream format was documented and public. People could then manipulate the bitstream as they saw fit. Since then, the format has been closed (IMO) to keep people from (1) RE'ing the device which is a big concern for some interests and (2) to keep their technology a secret from competitors.
Newer technologies allow for the bitstream to be encrypted from within the FPGA toolchain and to do internal decryption before programming the FPGA. So, you'll need to make sure that the bitstream you've captured is decrypted before trying to analyze it.
Also, with the realization of Partial Reconfiguration (through Xilinx), RE attempts will become more complicated as you can no longer sit-and-watch behavior of devices.
RapidSmith does that for you. http://rapidsmith.sourceforge.net/
There is also a paper that you can read as the starting point: "Recent Advances in FPGA Reverse Engineering" Hoyoung Yu, Hansol Lee, Sangil Lee , Youngmin Kim and Hyung-Min Lee
"if it implements a soft processor - in that case there should be firmware for that".... but a soft processor isn't firmware (what processor would run that firmware?) It is a configuration of hardware elements on the FPGA.