These are a few of my favorite little reverse engineering puzzles to show people when they express interest in the craft. They are also 2 sample functions I thought I would use when prototyping the BFRE program.
Monthly Archives: March 2005
Thou Shalt Not Create Independent Tests
And software companies wonder why we users have trouble taking software end-user license agreements seriously. Roberto Togni actually read the license that accompanies On2’s VP7 Decoder. It contains this clause:
You may NOT:
4.publish or provide any results of tests, including without limitation benchmark tests, run on the Software to any third party without On2’s prior written consent
In fairness to On2, this is not an uncommon clause in EULAs. However, it presents some very curious scenarios. Am I allowed to publish something like this?
I looked at a VP7 sample and it did not look as good as WMV9, H.264, or even On2’s own VP6.
Maybe I should write and ask permission. A colleague brought up another point: Since this “no benchmark tests” is such a common EULA clause, it should stand to reason that Microsoft’s Windows Media Encoder carries the same license. It is extremely unlikely that Microsoft would have granted written permission for this whitepaper exercise.
Update: Again, to be fair, the decoder license (On2’s Truecast Player) does not appear to mention anything about publishing benchmark tests. That is on the limited trial codec license.
VP7: On2 Just Won’t Quit
I was just thinking the other day about whether On2 would release VP7. This is the organization that brought us TrueMotion 1, TrueMotion 2, VP 3.0, VP 3.1, VP 4.0, VP 5.0, VP 6.0, and VP 6.1, not to mention VP 6.2. VP70 just seems like a natural progression.
What does ‘VP’ stand for anyway? I have never read any definitive answer. However, if On2’s technology focus is any clue, it stands for “Video Predictor”, owing to On2’s almost religious devotion to prediction-based compression algorithms.
Michael Roitzsch tipped me off that On2 has, indeed, unleashed their VP7 codec upon the world. True to form, their literature asserts that VP7 “rUleZ!!1!” and that “MicRo$$oFt is teh suck!1!!!” (slightly paraphrased, they state their points using graphs).
Brute-Force Reverse Engineering
Many have postulated on a program that can take the machine code of a binary program and automatically translate it to C. I am not talking about elegant C, with proper indentation and control loop structures. I mean C that looks like it was directly translated from ASM, GOTO statements and all. When you start reverse engineering i386 code and extracting algorithms from it, you very quickly notice the tight ASM-C relationship. It’s no wonder that C is sometimes referred to as “portable assembly language”. ASM constructs map quite cleanly into the C language (or is it the other way around?).
Based on that, why can’t we write a program that automatically converts those low-level ASM instructions into a series of C statements? Then it could be compiled for any CPU architecture. Personally, I have traditionally been opposed to this idea, simply on the grounds that one of my overriding goals is actually understanding the underlying technology that I am reverse engineering.
However, I also realize that intelligence-gathering is an essential component of reverse engineering activity. To that end, this type of program could be another tool in the RE toolbox, another way to look at the problem. I would call this approach brute-force reverse engineering since it might– just might– be workable, but not elegant by any stretch of the imagination. Let’s call this hypothetical program “BFRE”.