I want to disassemble a hex file of PIC16F877A. Is there any good disassembler ? After disassembly is it possible to compile again ? What are the things I have to take care of ?
Writing your own is fairly simple. and you can make the output re-assembleable if you like.
You can get a disassembly listing in MPLAB. Select the right device, import the hex file, View Program Memory. It should be possible to edit and reassemble. However, this is in PIC assembly language, you mentioned compile, so are you thinking of trying to get C code back from hex? If so, that's much harder.
Just use IDA Pro: http://www.hex-rays.com/idapro/
It disassemble everything and it the best tool ever for it.
Related
I was wondering what are those 3kB of hex data loaded to DMP on initialization. I know they are supposed to be some kind of “program” for DMP, but what do they do? Is there a way to get assembly version, and if so, is there a way to make my own? Or, am I misunderstanding this completely? Everyone just seems to be using this but I couldn't find any documentation regarding this data.
This may seem strange, so I will try to explain it as best I can:
I want to write an application for OS X that will accept some code as an input and will produce a visual output. The input will be in Objective C and the output will be the output that this code describes.
The output may be text or graphics based, it doesn't matter. What matters is that I don't know how can I make this input be handled as Objective C code and be executed by the system as such. I have a big experience with Objective C, but I hadn't had the chance to get involved with something like this.
Can anyone point me in the right direction?
So if I understand correctly, you want to:
Take Objective-C input
Parse it
And show its structure to the user in a visually digestible form.
Now the hard part is parsing it - for that you'll need a compiler front-end, possibly LLVM-clang. When you have an abstract syntax tree of the code, you can walk that tree and easily construct some graphics or structured, human-readable text to describe what the code does.
Edit: so you want to actually compile and execute that code. Then you have to go one step further and compile the code then run it.
Would it be possible to take the source code from a SNES emulator (or any other game system emulator for that matter) and a game ROM for the system, and somehow create a single self-contained executable that lets you play that particular ROM without needing either the individual rom or the emulator itself to play? Would it be difficult, assuming you've already got the rom and the emulator source code to work with?
It shouldn't be too difficult if you have the emulator source code. You can use a method that is often used to store images in c source files.
Basically, what you need to do is create a char * variable in a header file, and store the contents of the rom file in that variable. You may want to write a script to automate this for you.
Then, you will need to alter the source code so that instead of reading the rom in from a file, it uses the in memory version of the rom, stored in your variable and included from your header file.
It may require a little bit of work if you need to emulate file pointers and such, or you may be lucky and find that the rom loading function just loads the whole file in at once. In this case it would probably be as simple as replacing the file load function with a function to return your pointer.
However, be careful for licensing issues. If the emulator is licensed under the GPL, you may not be legally allowed to store a proprietary file in the executable, so it would be worth checking that, especially before you release / distribute it (if you plan to do so).
Yes, more than possible, been done many times. Google: static binary translation. Graham Toal has a good howto paper on the subject, should show up early in the hits. There may be some code out there I may have left some code out there.
Completely removing the rom may be a bit more work than you think, but not using an emulator, definitely possible. Actually, both requirements are possible and you may be surprised how many of the handheld console games or set top box games are translated and not emulated. Esp platforms like those from Nintendo where there isnt enough processing power to emulate in real time.
You need a good emulator as a reference and/or write your own emulator as a reference. Then you need to write a disassembler, then you have that disassembler generate C code (please dont try to translate directly to another target, I made that mistake once, C is portable and the compilers will take care of a lot of dead code elimination for you). So an instruction of a make believe instruction set might be:
add r0,r0,#2
And that may translate into:
//add r0,r0,#2
r0=r0+2;
do_zflag(r0);
do_nflag(r0);
It looks like the SNES is related to the 6502 which is what Asteroids used, which is the translation I have been working on off and on for a while now as a hobby. The emulator you are using is probably written and tuned for runtime performance and may be difficult at best to use as a reference and to check in lock step with the translated code. The 6502 is nice because compared to say the z80 there really are not that many instructions. As with any variable word length instruction set the disassembler is your first big hurdle. Do not think linearly, think execution order, think like an emulator, you cannot linearly translate instructions from zero to N or N down to zero. You have to follow all the possible execution paths, marking bytes in the rom as being the first byte of an instruction, and not the first byte of an instruction. Some bytes you can decode as data and if you choose mark those, otherwise assume all other bytes are data or fill. Figuring out what to do with this data to get rid of the rom is the problem with getting rid of the rom. Some code addresses data directly others use register indirect meaning at translation time you have no idea where that data is or how much of it there is. Once you have marked all the starting bytes for instructions then it is a trivial task to walk the rom from zero to N disassembling and or translating.
Good luck, enjoy, it is well worth the experience.
I've faced to a problem with a PIC Micro controller.
I have a micro-controller programmed by me long time ago and I lost the relevant source code and the schematic diagrams. Now I need to invert the value of a port. I can do this using some NOT gates but it is a big hassle to do so. or alternatively I will need to write the whole program back.
I don't expect to see the code back in PIC C or MikroC. Having an understandable assembly code would be sufficient.
So do anyone has any experience on a good HEX decompiler that I can use for this purpose? Any comments based on your experience? :)
EDIT : Device PIC 16F84A
Decompilation is unlikely to be a practical solution, and it is even less likely that a tool for your specific compiler and instruction set combination even exists.
Disassembly however is straightforward, though whether you will be able to make sense of the resulting code is a different matter since no comments or symbols are preserved in the HEX file; if you have the original object code it may render the disassembly more readable. There are many PIC disassemblers available, just Google it; I can't direct you at any specific one because there are a number of PIC families with different instruction sets, and you did not specify.
A simple approach to disassembly would be to simply load your HEX file into MPLAB and select View->Disassembly Listing, then right-click the windows and select "Output to File". This output may need some massaging for it to be suitable for input to an assembler.
I know this is an old post, but I have recently encountered a similar problem and didn't find a very complete answer online. I lost my MPLAB X IDE project due to hard drive failure, luckily I had already programmed a device with a working version of the code.
Recover the .hex
Follow the steps below to recover the .hex information from a programmed device:
Use MPLAB X IDE and your PIC programmer (I used PICkit3) to read the .hex file from the programmed device:
Start a new project for your device.
In "Project Properties" select your programmer.
Right click on the project folder and select "Set as Main Project".
Click on the arrow next to the "Read Device Memory Main Project" and select "Read Device Memory to File". Reading device memory to .hex file
Disassemble the .hex
You can view the disassembly in MPLAB X IDE, but you cannot edit or save it (or at least I couldn't figure out how to) and it is very cryptic. I found the easiest, no strings attached, disassembler to be the one packaged with gputils, it is called gpdasm. To download and install, visit the gputils page here:
https://gputils.sourceforge.io/
Now open a command prompt and navigate to the folder where your .hex file is located. Generate an assembly source file from the .hex with the following command:
gpdasm -p p16f84a -csno hexfile.hex > asmfile.dis
With the -c -s -n and -o options, this generates quite a good listing which is very near to being able to be assembled as is. Obviously the variable names and labels cannot be recovered, but at least subroutines are identified which makes things a lot easier. Hope this helps someone in the future.
There is a list of PIC disassemblers at the official PICList technical reference.
Many people never use a stand-alone disassembler, but prefer to use the disassembler inside their favorite PIC simulator.
http://piclist.com/techref/microchip/dissassemblers.htm
http://piclist.com/techref/microchip/simulators.htm
You should be able to load the hex file into the MPLAB IDE and view the assembly code from there as well as run it and step through the code in the simulater if I am not mistaken.
You can also use it to read the code from a device if it is not code protected.
The project I am currently working on requires a lot of hexadecimal numbers to be entered into the code.
I once saw a pic of an old keyboard with a hexadecimal numpad (has A-F letters on it also) replacing the normal numpad. Anyone know where I can get one of these?
IPv6 Buddy -keypad should work well for hexadecimal input.
http://www.ipv6buddy.com/
If you can get your hands on one of the retired space shuttles, they have one!
I have an old Heathkit learning toy with a hex numpad because the only way to program it was to assemble code by hand (it came with a 6800 manual and some notepads) into the online monitor. This was actually fun!
Mine is missing the 'D' button however.
Great idea with the programmable keypad. I think i am going to pick up one of these: DX1 input system. Works for any reconfiguring I might want to do.
Is this the one you're talking about?
funky http://www.cpmuseum.com/Exhibits/Apple%20Lane/7603/7603-0005/images/000%20Front%20View.jpg
While this has a lot of "gee whiz" appeal, I have to say:
You have two hands. Use them. A-F are all reachable with the left hand on a standard keyboard while your right hand is on the num-pad. Instead of putting muscle-memory time into some arcane Hex-pad, you'll be learning to touch-type with your left hand, which has application outside your current project.
Better yet, come up with a smarter way of getting the hex codes into your code. Write a script that extracts them from your data-source and into your code as symbolic variables... or whatever.
EDIT
Ok, I'll give you the benefit of the doubt. Lets assume you're working on a hardware project and need to provide a specialized interface for your user. Maybe a programmable keypad would fit the bill?
Not sure of the specifics right now, but I'm pretty sure you can easily write a keyboard remapper. You could remap the QWASDF keys to ABCDEF in order to type them more quickly. That way you could use 2 hands to type. Or if you are in control of the program they are being typed into, you could just translate the keys in code on the fly. You also might want to try out the Microsoft Keyboard Layout Creator