I am using a FEZ Cobra module for a traffic counting university research project. Unfortunately the last version of our software was saved only on one laptop that failed. So we lost 2 weeks of work due to carelessness
Is there any way to obtain/rebuild the source code from the code loaded on the Cobra?
I can get a .bin file with âFEZ Configâ that has some promising lines, but I believe it contains not only our code (not sure if it contains it anyway). Can the âFlash Sector Mapâ help me to locate the code sections of this binary or I am on a totally wrong track?
Thank you guys for your answers. Iâve heard about GitHub, I should definetly get familiar with it.
I have another question, so I can learn some more from this case:
I believed that my c# code was compiled to some intermediate code ( like CIL?), which was then loaded on the Cobra, where it was compiled to native code by a jitter. If it is the case - I thought - I should be able to locate the intermediate code on the FEZ, and after downloading it, with some luck and by the use of âReflectorâ (or something similar) I can recover at least some of my source code.
What am I missing here?
@ kisfa - For windows .NET Applications there are multiple possibilities to create C# code from any assembly, which also only contains IL code.
There is a free tool from JetBrains for that (Dot Peek I guess). The code might not look too nice, specially local variables have only generic names, and all comments will be gone.
Theoretically this is also possible with the NETMF binary file, which is a container for all the assemblies of your application and SDK and Framework.
So the 1st step for you would be to âextractâ the assemblies" from the hex or bin file.
After that there is a not too bad chance to use a tool which create C# from IL.
Also theoretically the NETMF SDK sources should contain all information (in source code) on how the hex/files are structured, but it does not contain a tool to extract it.
[quote=âkisfaâ]I believed that my c# code was compiled to some intermediate code ( like CIL?), which was then loaded on the Cobra,
[/quote]
Yes.
[quote=âkisfaâ]where it was compiled to native code by a jitter.
[/quote]
No - the current implementation of .NET Micro Framework does not have JIT, the CIL instructions are interpreted.
[quote=âkisfaâ] If it is the case - I thought - I should be able to locate the intermediate code on the FEZ, and after downloading it, with some luck and by the use of âReflectorâ (or something similar) I can recover at least some of my source code.
[/quote]
Technically, you can do that, but it would take a considerable effort:
If you donât have a hardware debugger (JTAG or similar) or the board does not expose debugging interface, youâd have to write a custom application do download the contents of the flash memory. It is possible to do it it .NET, have a look at Microsoft.SPOT.Debugger.Engine.ReadMemory() method in Microsoft.SPOT.Debugger.dll and how MFDeploy.exe uses it.
Then you would need to identify the assemblies in the flash memory - after compilation, the assemblies (.dll) are processed by a special NETMF tool MetaDataProcessor.exe, which optimizes the dlls for deployment: most of the identifier names are removed, strings are placed into special tables and the result is written into .pe file (*), which is then deployed into the flash memory area dedicated for âapplication deploymentâ (as you can see in the flash memory map). During deployment, all referenced libraries that are not part of the firmware are written too, then the application. Unfortunately, the NETMF PE format is not documented, youâd need to learn about it from the source code (have a look at files in CLR\Tools\Parser directory).
(*) PE is rather unfortunate name, it is NOT the Portable Executable format.
Then youâd most likely need to create a proper .NET assembly .dll from the .pe file, so you could use one of the existing .NET de-compilers. Alternatively, you could extract just CIL bytecode and use ILdasm.
Then youâd stare at the (at that time rather old) code, scratching your head and trying to understand what was it meant to do, and which stupid developer could write code like that
Personal note: I know from my own experience how unpleasant it is to lose days or even weeks of development time, especially in a team. However, in most cases we never really needed to recover the lost code - we were able to write it again in surprisingly short time and usually in a better way, as we could learn from the mistakes we made earlierâŚ
I absolutely agree with @ CW2.
Use your time to rewrite your code instead of trying the reclaim the old one.
For 2 weeks of initial work to create the code you might be faster rewriting it than decompiling and reformatting it.
Also you should see the good thing at this: You learned your lesson, and if youâre smart, this wont happen to you again.
Which means the IL going in is not going to be the same as the IL comming back out. So it will be even harder for the reflector applications to get back the code.
@ kisfa, youâre screwed dude. I know the feeling too. I lost all the data on my desktop last year with 3 months of work on a CNC project. On the upside the rewrite of that code took less time and worked better than the original. Sometimes you just need to hit Shift + Delete.
I know the feeling too. I lost all the data on my desktop last year with 3 months of work on a CNC project. On the upside the rewrite of that code took less time and worked better than the original. Sometimes you just need to hit Shift + Delete.