I have bought some GPS recieving equipment for my Pocket PC. It does most of what I want it to do, but there are some things that I just can’t get it to do. So, I would like to decompile the program, see what that program does, and then modify it to do what I want it to do.
If I could get it to a programming level, I could trace it and make the changes that I want. Anyone want to help me on this?
What you are asking is possible, but not practical. It usually takes a great deal of work to decompile a program, and the result does not have the original programmer’s comments that explain how the program works. It would be much cheaper to buy a product that does what you want out-of the-box.
Not just comments are missing, but the variable names will be totally arbitrary (non distcriptive in any sense)
The only time I’ve done this successfully is when I had a paper copy of the source code as a reference. In this case my customer had paid another developer to design a product, then developer decided they weren’t interested in production. 5 yrs later all electronic copies of source code have been lost.
Note that this was assembly code, so the output of the dis-assembler looked a lot like the source, structure wise. A de-compiler would be much worse.
Decompiling isn’t something that’s done much any more. mainly because processor architectures and compilers do such a good job of optimizing (read “mangling”) the code that post-compiled code is usually considerably more complicated than the original. Machine generated RISC code, for example, is often all-but-uninitelligible after compilation, as the order of instructions gets moved around to assist branch prediction, pipelining, and vectorization.
So mks57 is right - it’s not practical unless you’re an unbelievably good programmer in the specific architecture of the program.
However, all is not necessarily lost. “Open Source” is trendy these days, especially on embedded systems like GPS units. If the one you chose is based on open source code, you might be able to just download the original source code for the system. Check with the manufacturer of the system.
It is generally not possible to “translate” a runtime (executable) program back into source code, because of the different ways that different compilers apply optimizations. Different compilers (written by different people) place different priorities on different types of optimizations, and perform multiple optimization-passes, and so the end result is that there’s no way to really know how to backtrack and undo everything properly, in the reverse order it was done originally. If you compile the exact same source code in several different compilers for example, all their results will function, but they will very-probably not be the same exact file-sizes, and some will run faster than others, some will use less RAM than others, and so on.
…The most you can do is disassemble it into ASM and then edit it in a hex editor, but for most people that’s not much help, as there’s no comments contained therein and usefully doing complex revisions on uncommented asm is pretty baffling. Perhaps there is some human with the brains to do that sort of business, but it sure as heck ain’t me.
If you are capable of programming, you could look for any open-source projects on the equipment you have. I have read elsewhere that most GPS receivers can be accessed and polled with simple commands through a regular terminal window.
The problem is that the compiled code is built of extremely simple instructions. Move a byte from here to there. Test a condition and jump to a different address if it’s true, etc. Basic building block stuff. The software was generally written in a higher level language that has more complicated constructs like loops, subroutines, control blocks, and the compiler translates these complicated constructs into huge chains of really simple instructions. Translating back is simply not something you can do in an automated way. It takes an expert a lot of time of poring over low-level code to see patterns and try to discern what higher-level code led to the instructions he’s looking at.
Here’s an analogy. I’ll give you a sequence of basic arithmetic chores, and you have to figure out what was the ultimate task I wanted completed:
add 1 and 2
integer divide by 10, storing the remainder in A
add 6 to the result
add 9 to that result
integer divide by 10, adding 10 times the remainder to A
add 3 to the result
add 1 to the result
add 100 times the result to A
A is your answer
What did you just do?
you added 361 and 192 one digit at a time. Note that this isn’t really how computers do math, but it’s analogous to the simplistic instructions complex programs are reduced to when they get compiled.
If you bought it recently and it works with a PocketPC, the GPS most likely has a SiRF chip and can use the NMEA 0183 protocol; The software you recieved when you bought the GPS device is not the only solution, as all the programs support NMEA0183. If your GPS device has this format, you will probably be better served finding an off-the-shelf solution rather than trying to decompile the program you have.
No offence but if you don’t understand the basic principles of compilation, then it’s highly unlikely that you would have the skills to make whatever changes are neccesary, even if you had the source code.
Not necessarily. I won’t go off on a rant about CS education these days, but the basic principles of compilation are often omitted for modern programmers.
For one thing, Java, VB, and other bytecode languages–very popular for beginners–have a somewhat different set of rules altogether. The basic principles still apply, whether your target is bytecode or machine language, but knowing what’s happening is less important. (From a standpoint of successfully programming – I’d argue it’s still quite important.)
For another, an awful lot of this stuff is purely high-level nowadays. I’ve met professional programmers who couldn’t even READ assembly, much less write it. Doesn’t hold 'em back a bit; the tools are reliable enough that you can just assume the low level stuff works. Especially in the increasing number of places where you can overwhelm performance issues with hardware (or patience).
For comparison, when I went through school, they taught about the compiler, the linker, and the loader? Loader? When’s the last time you thought about that in any real sense? Or the whole issue of absolute vs. relocatable addressing? It just isn’t relevant. Virtual memory (as in, how it works)? Paging in general?
Please note that I’m not saying any of this is good. But the field of “computer knowledge” has grown enormously, to the point where you can’t know it all. You choose what’s important, and for many of today’s young’uns, the magic that happens when you hit “build” doesn’t make it past the “importance threshold.”
Yes, but unless you were purely a Perl or PHP or other interpreted language programmer, you must surely have the notion of “source files” which are plain, ASCII text files and “object files” which are filled with gibberish and are what the computer actually runs. It seems that this is basic enough that it would be hard to miss, no matter how spotty your education was.
TimeWinder, given that the result of dis-assembly is going to be some ugly assembly code that needs to get assembled after being modified, I have to agree with Shalmanese. It’s unlikely that a programmer would be un-aware of compilation, but would be comfortable with assembly language and running the assembler to produce machine code.