Reverse engineering a PIC program
Recently, one of my old PIC program was returned, unfortunately I have lost its source code. It should be not a trouble, but it came with a request for a modification, which might be impossible in this case. There are tools like gputils and mplab capable to do disassembly, but I think no need to describe their featureless functionality. So, after goggling around for a while, I have found a quite promising workpiece.
unPIC.pl
One able hungarian programmer (Tamás Rudnai) has adopted into Perl, an unmaintained program (by Timo Rossi), so it became platform independent. Its output is quite user friendly, the structure and the operation of the reversed program can be easily known and commented. It has one additional benefit: the reversed program after changing its functionality can be immediately recompiled.
Usage (under linux)
Insall it possibly under your home, e.g. into the /home/our_name/bin subdirectory, and give it an executable right. After the latter, we can use it easily in every directory.
On the other hand, we might copy it beside the program needs to be reversed, and give it executable right, and issue the command. Only one thing should be kept in mind, this way we need to start our command with these characters: "./"
So, issue the command: unPic.pl p18F819.inc program_to_reverse.hex > source.asm or issue ./unPic.pl p18F819.inc program_to_reverse.hex > source.asm. After the name of the program, we need to define the include filename for the target processor (this information is not included in the .hex file, so the program cannot guess it successfully), this file needs to be on the path as well. If it wouldn't, just find it and copy it beside.
After we get back the prompt, we will find the file source.asm in the current folder. This might be immediately recompiled, verifying the functionality of the perl script.
After the recompilation, the comparison of the old and new .hex file is proposed.
We might be frightened, because the two .hex files are not identical. Don't worry, they will be the same in a rare case only. There might be differences, between the read-out from the chip and the compiled version. For example there is the instruction representing the not programmed locations: 0x3fff = addlw 0xff, but this changes to: 0x3eff after recompilation.
So, the comparison should be handled with criticism.
The program can be downloaded from its hompage or from here.
Screenshots about the quality of the produced source code
Header
Subrutine
EEPROM datas
Symbol definitions