Retrieve code from PIC Controller

Hi all.
I have developed a product for my client using PIC16F883 Microcontroller around 1 year back. Now today my client needs some alterations in the same program. but the thing is i have my original Code file. so is it possible for me using any programmer or some other gadgets to retrieve the code from the controller, so that alterations can be made as per my clients requirement.

I think you can retrieve the bitfile from the micro. But if you have source, as you say, why do you need to read the bitfile from the micro? You should also have that. Further, what good is the bit file if you need to modify the code?

barry said:

I think you can retrieve the bitfile from the micro. But if you have source, as you say, why do you need to read the bitfile from the micro? You should also have that. Further, what good is the bit file if you need to modify the code?

Click to expand...

I am extrememly sorry...
it was just a typing error. i mean to say i dont have any source file.

Then you've got a problem. The bit file from the micro isn't going to do you any good.

It cant ,You cant recover .
But one option you can recover the project file from your hard disk from recovery software option if you are using the same pc

thannara123 said:

It cant ,You cant recover .
But one option you can recover the project file from your hard disk from recovery software option if you are using the same pc

Click to expand...

No i am not even using the same PC...
but there should be some possiblilties to recover the hex file and then convert it to source code...

If my memory serves me, it is possible to read the hex file from the micro using a pickit programmer. However I do not believe that this will work if you enabled code protection.

The file that you get back will be a hex file, which is assembly. So you can pass it into a disassembler fairly easily. All the variable names and stuff will be stripped. You may be able to decompile it back to C, but I am not sure of decompiler for the PIC16.

One thing you could do is reverse engineer your code back to C. Not fun, but it is an option.

IF it isn't code protected you can retrieve the binary data from the memory by simply reading it back from the PIC.

What happens next depends on the language you used to write the program. If it was in assembly language you can use a disassembler (reverse assembler) to recover the original instructions but not the program structure or any meaningful symbols or comments. You would also have to manually decide what was code and what was data if they were mixed in the original program. However, given time, you stand a reasonable chance of recovering something useful you can work on.

If it was written in a high level language like 'C' or BASIC, I would give up now as the PIC would contain a mixture of your instructions and library routines, trying to unravel them would be almost impossible. There are tools to do it (codevisual2flowchart for example) but they are not free and you might have to spend weeks configuring them to recognize the bit patterns used in the original coding tools.

Brian.

bluelasers said:

One thing you could do is reverse engineer your code back to C. Not fun, but it is an option.

Click to expand...

It is in general the most feasible option; Seeing the working system as a black box, you can extract by inspection how it behaves and then make another code from scratch.

andre_teprom said:

It is in general the most feasible option; Seeing the working system as a black box, you can extract by inspection how it behaves and then make another code from scratch.

Click to expand...

Yes, function reverse engineering from specification or observation of function for all various input is an approach. However I was thinking more along the lines of reversing the code directly back to C. This is a PIC16 so the architecture is a RISC with only about 49 instructions, if my memory serves me. It is also reality small in terms of program storage. So one could disable the entire program and convert the assembly back to C with a little effort. I think this would be more accurate than functional analysis, especially since he wants to modify an existing product. Part of me wonders why he would not just modify the assembly. C makes an attempt to be pretty good at keeping the assembly close the C code. (However this assumes a lot about various compilers and optimization is not at play. C was primarily written to mask away the details of assembly.) The instructions are documented so one could do this without a disassembler too, just need to be really patient!

What happens next depends on the language you used to write the program. If it was in assembly language you can use a disassembler (reverse assembler) to recover the original instructions but not the program structure or any meaningful symbols or comments. You would also have to manually decide what was code and what was data if they were mixed in the original program. However, given time, you stand a reasonable chance of recovering something useful you can work on.

If it was written in a high level language like 'C' or BASIC, I would give up now as the PIC would contain a mixture of your instructions and library routines, trying to unravel them would be almost impossible. There are tools to do it (codevisual2flowchart for example) but they are not free and you might have to spend weeks configuring them to recognize the bit patterns used in the original coding tools.

Click to expand...

Those are all fair comments, however I still say that regardless of all that you could still take it back to C. He is not getting his source back, but he can get it to a more manageable forum. This is probably the best we can do at this point and should be the goal. One could take it back to other languages too. C++ has a pretty distinct memory footprint/layout. Libraries should be identifiable due to the fact that they are common. So one could use of other programs to identify sections of common code and match them back the library calls. If you remember the compiler you could also write code to see if the code starts to match. However this puts a lot of trust in the compiler to not optimize or behave in a non-deterministic way.

Also once you have the C code one could port that back to other languages. The result of this may not match the code, but you will have the logic so to speak. The reason I am recommending taking it to C first is because of the relationship of C to assembly.

The code running on your PIC is a binary file even if you manage to retrieve it all you will see is 0s and 1s. Won't make any meaning at all. I suggest you rewrite the program and find a way to upload the code to the machine(PIC) again.

you will see is 0s and 1s. Won't make any meaning at all.

Click to expand...

That's an ignorant view. bluelasers gives a brief description in post #7 and post #10 how things work.

The real interesting question is if the considerable effort of complete reverse engineering pays for a project. Making small modifications is often possible after analyzing the overall code structure and only particular details, then patching the binary code directly.

Needless to say that you need much better understanding of a microcontrollers instruction set, assembly language and what C constructs are compiled to than for regular C programming.

Libraries should be identifiable due to the fact that they are common.

Click to expand...

That's only true under two conditions:
1. The original compiler is known.
2. The original compiler footprint is known and all the libraries are the same version as originally used.

Try reverse engineering pointers into a structure from binary when you don't know the structure size or elements!
I would say assembly is most recognizable and certainly easiest to disassemble.

Brian.

betwixt said:

That's only true under two conditions:
1. The original compiler is known.
2. The original compiler footprint is known and all the libraries are the same version as originally used.

Try reverse engineering pointers into a structure from binary when you don't know the structure size or elements!
I would say assembly is most recognizable and certainly easiest to disassemble.

Brian.

Click to expand...

Well that is what I said, but I still say that it is possible. memcpy for example is going to be really easy to spot on just about any compiler or architecture. (Not exactly a practical example seeing how simple it is.) Plus you could just brute force with trial and error on several compilers and/or libraries. However that is not really needed as you can just read the code and see if it is generally doing the same thing as the assembly. It does not need to match exactly. We are just trying to revert to a higher level of representation of the logic. Compilers are more likely to change the code than libraries. (However I think one could make the argument for both.) Libraries usually are not complete rewrites so I would say you just need to get pretty close. Once you get into the area of which library methods are being called. You can start to use the knowledge of how the library would be used to help you narrow down the search.

My point was that you have the source code of libraries to match it to. So you know the size from the assembly when they are allocated and source where they are defined. You can compare them. You can derive the elements based on the offsets and where/how they are used. You can find this since the processor starts at the same place. So you can just follow its execution. I know this could be time consuming but it is definitely possible. I would be tempted to just modify in assembly and call it done. It has not needed to be modified in last year so I am not sure it is worth the effort of converting back if you are not likely to need to work with it too much.