3

I'm faced with finding a bug in a 10,000+ lines assembly program, and maintaining it in the future. It concerns assembler code for a PIC18 microchip microcontroller. The code was written by a former colleague who is no longer available, and he left no documentation and his code is very poorly commented.

The code also uses a number of direct goto's and bra's, and relative ones ($+0x06 for instance) so I'm very affraid to edit it.

I would rather decompile his assembly source code into 'new' C-code (or C++) and work from there. I would like to know:

  1. Is decompiled assembler -> C code 100% functional?
  2. What will happen to the direct and relative goto's?
  3. Are there any free or cheap tools available to decompile PIC18 code?
valki
  • 73
  • 2
  • 7
  • 1
    And exactly this is why you should comment your code properly. – poitroae Aug 30 '12 at 13:19
  • 2
    I don't think you'll be able to do this. Oh, and I like to think that there is a C compiler for everything, including PIC18. Have you googled for such? Start all over. 10000 LOC of assembly would probably be around 1000 LOC in C. – nullpotent Aug 30 '12 at 13:21
  • 2
    Decompilers have made some progress, but they still don't *really* work, especially not for code that doesn't look like "typical compiler output". What you usually get is "assembly but with C syntax" - that doesn't really clear things up a lot. – harold Aug 30 '12 at 13:23

3 Answers3

4

Here's how I see it:

  1. No, I would expect that to be possible, since there's no guarantee that C can exactly express everything a particular CPU can do at the assembly level in a way that is straight-forward enough to make implementable in a decompiler. Sure they're both Turin complete, but the devil is certainly in the details, here.
  2. That's one particular issue, for instance. It's certainly possible in assembly to jump e.g. into the middle of what would be a C statement, which makes it complicated to reverse.
  3. I don't think so, no.

For more information about the problem space, check out the Boomerang project's FAQ.

unwind
  • 391,730
  • 64
  • 469
  • 606
2

The non-mips pics are extremely compiler unfriendly, using C is slow and costly in terms of consuming limit resources.

gotos and branches are how processors work, nothing wrong with them.

I would start by removing the relative branches and replacing them with labels, it should be a trivial check that you have added no new bugs by comparing the binary of the pre-modified code and post modified code. Once the relative branches all use labels you can then add or remove code with less fear of breaking something else.

Decompilers dont work and cant work. It would be like trying to take the french fries you had for lunch out of your intestinal track and trying to restore the original potato (without the skin of course, unless they were skin-on fries). The original source has been cooked and processed a number of times before it becomes the asm that is fed to the assembler, then it is cooked (well...warmed up) another time if you use objects and a linker. Too much material is lost on the way that cannot be recovered.

It is very possible to do a static binary translation, and get something that is in the C language but is significantly harder to read and maintain than the asm, esp for architectures with flags. The translator is not going to be perfect removing all of the dead code. Every add instruction is going to be the add itself plus code to detect the overflow and if overflow set the flag, else clear, if result equals zero set the flag, else clear if msbit is set set the n bit else clear, if there is a v bit then if signed overflow then set the v bit else clear, one simple line of asm becomes 10 lines of C code unless the translator can automatically remove that dead code.

old_timer
  • 69,149
  • 8
  • 89
  • 168
  • "*Decompilers dont work and cant work.*" - that is to say that "You can't make an equivalent high-level code from assembly", which certainly is false as turning assembly to equivalent C code is a very common *reverse engineering* practice. Of course, there's no way to restore the *original* source code by decompiling, but there's nothing which would prevent one from turning assembly logic into C logic for example - it's up to the quality of decompiler if the produced code can be compiled or not though. Sure, decompiling is almost always only a tool at best, definitely not a final solution. – zxcdw Aug 30 '12 at 16:40
0

While decompiling itself is possible to some extent, whether it's applicable in your situation is another thing which depends on the available software. Personally I would start deciphering the code manually and roughly reconstructing the code with C. Of course, it's a tedious task and probably involves lots of errors and bugs, but if you are supposed to maintain the codebase then it would be obvious to try to make that task as easy as possible later on - and perhaps the future maintainers would appreciate your job too.

zxcdw
  • 1,629
  • 1
  • 10
  • 18