Slashdot Mirror
Reverse-Engineering Consoles
shpoffo writes "In relation to the recent /. article i thought i'd give people a heads-up on some more console info. For those of you with the time, interest and know-how there are a few really good resources around for reverse engineering most of the major video game consoles such as Jeff Frohwein's site for the Gameboy. There's others for the N64 here and here, Dreamcast, Playstation, TurboGraphix, Genesis, and the Nintendo."
You can pick up RPMs for GCC at
http://n64dev.50megs.com/
Then all you need is a transfer device to copy your code to the N64 but Nintendo has sued Bung so they have stopped selling them.
>How come if I undercut software sales by making and selling software copies, I am called a pirate?
:-) So I, like a lot of consumers, choose to avoid this possiblilty by not buying Macintosh. This leads to less market share, and less exposure for the company. Less sales. Bad. If Macintosh were still allowing clones, well, I'd have a Mac, NOW (once the clones force the prices back down to earth).
Your copy is identical. You would be breaking the law if you made a Nintendo(tm) that used the identical parts and identical shape and identical trademarked name on the front of it.
>Yet if I undercut hardware sales by making and selling software copies of the console, I am called a emulator who "reverse engineered" this console, or other words that legitimizes what I did.
Reverse engineering implies that your "copy" is similar, not the same. You certainly CAN do this with software.
For example:
When the IBM PC was released, it was $3000 (or so). Much more expensive than IBM should be charging. So Compaq decided that they could make money by selling a compatible (read: clone, copy) machine. But they were stuck: To make it compatible, they needed to use the IBM BIOS (which IBM wasn't going to license to them). But, ahhh, why not do to the BIOS what they had done to the hardware? Make it compatible, but not identical.
They hired engineers without a clue of how the IBM BIOS was programmed, stuck them in a room, and had them reverse engineer the IBM BIOS, without looking at the code. Just by trial and error, and scientific hypothesis. They then created their Compaq BIOS, which provided the same services, but using their own ideas. And, there you have it, a 100% compatible BIOS not using any IBM code. Totally legal, since NO copyrights had been broken. And, this is an example of "copying" software.
Now, if you wanted to, you could do the same with Office 2000, if you had the time and money and wish to do so. You wouldn't be breaking any laws (except, perhaps, "look and feel", which could be worked around). You would end up with Office 2000, using your own personal code set. In essence, a copy, or clone of the software. But NOT a pirated copy.
That's how a console is legally reverse engineered any copied.
>Either way, my actions hurt sales by copying someone else's product and not producing anything new.
You produced something new. You produced a new console that works like the old one, or a new software that works like the old one.
>How is that good?
Because it provides the consumer with protection should the original company go out of business, or choose not to continue the product. Imagine if there were no IBM clones, but IBM had become popular. What if, somehow, IBM suddenly went out of business? Ohoh... now there's trouble. But, now with clones abounding, the world won't come to a standstill today if IBM dives.
Also, for example, those of us who still use Nintendo (original) (like me) like the fact that clones are avaliable since Nintendo has dumped this console. See how the world benefits from this? When my Nintendo original sets on fire, I can buy a clone, and still legally use my cartridges.
And, amazingly, it benefits the original company. What happens if/when Apple goes out business? Yes, you Macintosh users, you are ROYALLY screwed. You can join the Amiga lot looking in garage sales for parts.
>Now either BOTH activities must be evil or they must BOTH be allowed
No. One is illegal, and bad. The other legal, and good.
Verbatim copying is illegal because you add nothing of value. Making _similar_, _compatible_ things is not, because you add the value of protection to the consumer. Why? Because a reverse-engineered copy proves you understand how the original works. You can therefore improve upon it. A verbatim copy shows you have no understanding of the device/software, and therefore cannot sustain the life of the device.
Oh, here's another few examples of copied, but NOT pirated software: Freedos. Linux. DR-DOS. OpenDOS.
Freedos and DR-DOS and OpenDOS are compatible with MS-DOS (reverse engineered). Would you tell me that Freedos, DR-DOS, and OpenDOS add no value to MS-DOS whatsoever?
Would you tell me that Linux adds no value to Unix whatsoever?
The fact is, the law, and morals in general, are designed to protect the citizens as a group, and not some single company. It's a free market. If your company can't stand some legal competition, then pack up and go.
If you could be told what you can see or read, then it follows that you could be told what to say or think - BoC
A company wanted to allow its own movie production management product interoperate with a motion picture project management database. It was like a regular project management tool that had specialization for things of interest to the movie industry, for example there was a specific category for scheduling potted plants to be present on the set as well as manage the expenses involved with these things.
I think it was called Movie Magic Scheduling.
The publishers of movie magic were very protective about thier product and didn't want to cooperate with my clients, so they hired me to reverse engineer the product.
The initial agreement was that I would do this in a week for $1500. It took three weeks and I was working long days, but in the end I was able to take the whole production schedule for an actual full-lenth motion picture and run it through a parser I wrote that dumped it out into an intelligently interpreted text file.
I started by doing this: I created a new, blank document. Then I created a second document with one of the fields containing only the letter "A". Then I made hex dumps and used a comparison tool to compare the hex dumps.
I quickly found that there was lots of unexplained junk in the files so I wrote two tools that I would run before launching Movie Magic to create each document. This was on a Macintosh. One tool would allocate all available memory, set it to zero, then free it and quit. The other tool would create a large file set it to zero and quit.
Note that on Unix systems writing a page full of zeroes to a file is optimized to not write any data at all; however on a properly written system virtual memory pages and disk sectors are zeroed before being allocated to prevent leaking of confidential information.
Then basically I would note what change in the file and make a hypothesis as to what the cause of the change was, and test out my hypothesis by trying to predict what a further change in the file would do.
I wrote two things to document this, one a file format spec in a word processor, second a C program to parse the file. As my knowledge of the structure got more complex, I could implement the knowledge in the file parser and start dumping files through it until an error occurred. Then I could look more closely at what caused the exception.
The key to being able to do this I got from Robert Ward's book Debugging C (I think it is out of print). That is simply to use the scientific method when debugging software (or reverse engineering it).
The scientific method is simple in principle but it takes some discipline and creativity to use it effectively.
- Observe something
- Make a hypothesis as to why that was observed
- Design an experiment that will test that hypothesis. It is important that your experiment tests the hypothesis that you have made, and not something different.
- Carry out the experiment to see if it confirms your hypothesis.
- If it does, you have learned something
- If it doesn't, you have to make a new hypothesis
All the while you keep watching out of the corner of your eye for weird things to happen.One thing that helped a lot with this is that I'd spent a lot of time working with word processor file formats while maintaining a spellchecker, and I'd designed a binary graphics format. So I knew what were the common things to do in a file format, and a lot of things could be guessed directly.
It would have been a lot harder if the format was designed to be hard to reverse engineer, but the information has to go somewhere. Even with encrypted data, with a situation like mine you can do what is called "chosen plaintext cryptanalysis".
For another example of that, during World War II we'd cracked the Japanese cipher, but in addition to the cipher the Japanese used code words. To crack the code words, when we suspected that the Japanese used a certain code (call it "FOO") to refer to midway island, naval intelligence sent a command to Midway via secure channels asking them to report that their water desalinator was broken down - through insecure channels.
After Midway sent the request for a new desalinator, we intercepted a japanese transmission saying that "FOO" had a broken desalinator. Because they had also said they were preparing a major attack on "FOO", we knew to meet them with our aircraft carriers.
The choice of hypothesis is a problem here. Robert Pirsig talks about this in Zen and the Art of Motorcycle Maintainance. For any given observation, there are a large number, possibly infinite number of hypotheses that would fit the observed facts.
Choosing which one is worth taking the trouble to test calls for scientific creativity; ultimately the choice is based on scientific quality, and one mark of a good scientist is that they have a sense of what is right - and the flexibility to recognize that their sense can be wrong.
-- Could you use my software consulting serv