EDA

The embedded disassembler.

Purpose

• Static disassembly misses a lot and requires you to keep a lot in your head.
• Debuggers require you have that sort of access to the target system
• Simulators are painful to set up and don't really behave like debuggers

EDA is a cross between these three; a static disassembler with support for things like breakpoints and quick system configuration (like a system designed to run one function). Also, it keeps all past states of the system allowing the memory and registers to be viewed from any point of code execution. Click an instruction or memory address, and see every access and the system state at that point. No more missing xref because of things like (MOV R0, #0x1004 ADD R0, PC). This is all within an IDA-like frontend.

And this is just phase one. There's planned support for differential paths (run twice and graphical compare), a version migrator and differ (compare iBoot 1.0 and 1.1, find exploits, and at worst not have to migrate the names), a built in patching engine based on a lot more than pattern matching, and collaboration.

History

EDA is a descendant of DBS (Disassembly by Simulation), an idea I had after coming home from a party at college and couldn't keep stuff straight in IDA. I used DBS to work out the bugs and verify nckbf. Unfortunately, like simulators, it was annoying to set up and the GUI I wrote used Microsoft CLR; arrays crapped out at like 5000 elements.

EDA alpha was the version I did at the end of August. It was designed without a clear plan in mind, basically I wrote a frontend, then bsed my way through a backend. It was written in C, with the frontend in Web (HTML, CSS, JS). It looked nice, and did function as both a disassembler and a simulator. But the code base became very unmanagable; I would add a button to the frontend then hack on the backend to make it work.

EDA

As of 12 April 2009, geohot got motivated to work on this again, and hopefully motivated posixninja and westbaer to help. This is too big a project to do alone. We discussed design and have a plan this time. The backend will be C++, running a web server that any webkit browser can run the front end in. It's fully cross platform. Initially, we plan only to support ARM, but it should be easily extendable to support more architechures.

I believe this is well within the reach of this community. Think of this as a meta-project, finish this and all your reversing tasks will be sped up 2-20x

Tasks

• Front-end coding: We are looking for skilled HTML/CSS/JS devs to write a front-end and help think up the protocol.
• Arch extensions: If we get someone on this now, it'll be easy later. I don't know how much ARM I assume.
• Skilled C++ developers: The whole EDA kernel is in C++, we need a web server and someone to deal with threads and messages.
• Good reversers: To tell me why IDA frustrates them

Sites

• http://code.google.com/p/eda-reversing/ -- Google code for the wiki and releases
• http://github.com/geohot/eda-reversing/tree/master -- github for the source in development
• If you join the project, we have an internal Google Doc too, viewable at http://docs.google.com/View?docid=dg49sn22_167kkh2vcn
• Youtube video about EDA by geohot