Feasability of reverse engineering some embedded code

Question

All,

My company is in the situation where we are using an embedded control system from another company in another country. We do not have the source code or the schematics to this system, and the manufacturer doesn't want to release them, seemingly at any price or under any terms. We are thus stuck with a 6 month turn around to get even a small modification done, and they can basically charge any amount they want.

Legal aspects aside, would it be at all feasible to reverse engineer the embedded code back into C? Do any companies exist that could do this for us?

Thank you, Fred

Answer 1

There are plenty of companies that will re-implement the embedded control system without reverse engineering the one you are using now, as long as you know that system's requirements.

Answer 2

Assuming you are able to retrieve the binary code out of the system, disassembling and combing through it should be no problem. Actually turning the assembler code into maintainable C code poses a big problem. Depending on the size of the system, this will take a lot of time manually (re-)writing the code into something useable.

To my knowledge, in some countries, it is legal to reverse engineer a system to ensure compatibility with your software. But this may require clean-room reverse engineering.

Answer 3

Quite a big "it depends".

The mapping from source -> object code is (mathematically speaking) not reversible, so you can't recover the source code. But if you have the object code it's not all that hard to come up with some kind of source that compiles to the same object code, or at least which has the same effect - that's just disassembly/assembly.

Depending how creative your decompilation process is, though, the C code might come out looking a lot like assembler. So I'd question the quality of code I'd likely get back from a third-party - "C code" doesn't mean "C code that's easily maintainable by our C programmers", and it might be really quite hard to produce the latter.

Also note that an embedded controller "written in C" might actually have quite a lot of assembler in it in their source code. So either you allow assembler in your reverse-engineered version or you don't. If you don't it may be impossible to reproduce the functionality in C. If you do, then where do you draw the line - in the extreme you could just disassemble their source and not have any proper C code at all. You can't necessarily tell from examining the object code which bits were written in C and which weren't.

All this of course leaving aside the legal issues. It's probably unwise to leave aside the legal issues, especially as it seems you're buying this system as a physical object, and you possibly have no legal basis to separate the code from the hardware at all.

Answer 4

See answers to http://stackoverflow.com/questions/2272581/reverse-engineering-c-programs

In particular, see my answer referencing "Pigs to Sausages". The company behind that paper can do a quite good job of converting assembler back to C, if the assembler in question doesn't do things you can't state in C (such as, "Set the Stack Pointer Register...").

[I have nothing to do with the Pigs-to-Sausages guys except having met and having a great deal of respect for their technical lead.]

Answer 5

If you are looking for companies to help reverse engineer, you might want to sniff around who publishes in the Working Conference on Reverse Engineering. Find some work there that impresses you and ask those people whom to hire.

Answer 6

You might be better off starting an embedded team in house. In the same time it'd take you to do 4-5 software changes, with the right team you could have fully owned hardware and software designs, plus in-house expertise that can implement changes quickly.

... not to mention the amount of money you'd save on markup if the product has any considerable volume.