Topic created on: July 6, 2005 07:23 CDT by JCRoberts .

Have you ever noticed the similarities between the engineering process and the reverse engineering process?

The reason I'm asking is simple: framework?

I get to do a lot of development work in the EDA tools world and work closely with the people engineering the latest and greatest hardware as well as all the muckety mucks selling EDA software tools. Whether EDA tool producer or consumer, everybody talks about "Flow" or more accurately the combination of tools and methods used to get the job of designing new hardware done in the most effective manner. In spite of the explicit abuse of the buzzword, flows are never really defined, documented or formalized and the required correct operation of interaction/interfacing/integration between various tools is basically a roll of the dice. It's a real mess because there is no solid way to manage the flow, know what tools/methods work with other tools/methods, know what has been done and know what still needs to be done.

I'm sure everyone here knows what it's like to have an idea and just start writing code. Some of the best programs start life that way but more often than not, you also waste a lot of time recoding a poorly thought out implementation. Documentation, if it ever gets written, is not much more than an after thought and it's seldom accurate. The short answer is you're making stuff up as you go along and it shows in the quality of your work. -Such is the model for poor software engineering and any one who can code is guilty of doing it at least once. ;-)

Reverse engineering often starts out just like the poor software development, with just an idea and a lot of determination. Often you get the one line dictate from the powers that be of "Can you make it work?" in the integration/compatibility field, or "Is it safe/secure?" in the vulnerability assement field, or "What damage has it done?" in the threat assement field.

Sure, there are how-to's, documented methodologies (ISECCOM/OSSTMM etc.) and similar things out there (both public and private) but as far as I know there really is no "Flow Management" program for the world of reverse engineering; a flexible framework of what should be done, how it should be done, along with the results of doing it and ways to pass such data from one part/tool in the flow to another. A place where you can load a default framework for doing a particular kind of work and then tweak it to include what ever you want.

Though my understanding of it is limited, I'll try to put it in terms of the related infosec reverse engineering fields; Have you ever been doing vunlerability analysis and forgotten something simple like failing to look for strcmp coding errors? race conditions? any of the other countless things that can be done wrong in coding?

Would it be nice to have a map that lets you know where you are, where you need to go and what you need to do to get there as well as a way to document your entire journey?

This is the reason why Ero's work on REML (Reverse Engineering Markup Language) sparked my interest. OK, I can admit I'm unabashedly biased in favor of Lisp S-Expressions over XML but that's besides the point. It seems Ero built REML mainly for interfacing with IDA. My thought is one step beyond; namely, defining tool/process/method flow, keeping documentation and providing a neutral interface between tools.

Maybe it's just a wild idea, but I think having the ability to organize your game plan and keeping the framework flexible enough to plug new tools/methods into the flow as they become available, seems like a lot better idea than keeping the whole thing in your head or in a static document and hoping you remembered everything.

If built in an agnostic fashion, a game plan manager could be used as the base for both engineering and reverse engineering. Do you think an open source game plan manager would be useful?