5 ms·

Reverse Engineering Wipeout

184 points by Donzo 12y ago

dmitrygr 12y ago
In "Silverstream - Rapier" the camera goes UNDER the road briefly in the beginning of the flyby, and then again a few seconds later.
- phoboslab 12y ago
  The camera path is a cheap hack, extracted from certain track faces and has a lot of damping to smoothen things out. Going through the track in certain parts was a tradeoff.
Keyframe 12y ago
I can't remember exactly if it was te first or the second wipeout for playstation 1. But, I remember poking around the CD in good old norton commander and I've stumbled upon those textures in compressed filea as well into which I have entered as if in normal zip file. I have also found NC batch files for compilation or something like that, meaning psygnosis also used NC and forgot to purge those files from final build.
mschuster91 12y ago
Heh, I might use this in EarthSiege 2 when I manage to crack the compression algorithm used there... thanks for the idea!
hayd 12y ago
"given the game's age, I expected the 3D format to be quite simple and straight forward." lolz :)
idunning 12y ago
Amazing, I've tried to do this for Wipeout 3 in the past (extract the tracks) and was defeated - this makes it seem fairly easy!
- fapjacks 12y ago
  Very interesting. I did this, as well. It was possible to put the Wipeout 3 CD into a CD player and play the tracks as though they were audio files. Realizing this, I used a simple audio ripper to extract the audio files. This was (I think) around 2001 or so.
  - phoboslab 12y ago
    I believe he meant the race tracks, not audio tracks. I read somewhere that WipEout XL used a similar data format as the original WipEout, but Wipeout 3 looked like it had a completely new game engine.
  - mattdotc 12y ago
    Storing background music as CD-Audio was par for the course with a lot of PSX games.
    - geon 12y ago
      And for PC games of the era. I know Descent did that.
- phoboslab 12y ago
  Not at all. At least not for me. It's only in hindsight that everything appears obvious. I spent a considerable amount of time trying to figure out the track textures. It was only when I looked at the game in an emulator again (psxemu[1], which comes with nice debugger that lets you record frames and single step through draw calls) that I noticed that the track faces are subdivided at run time. This gave me the clue to look for textures in different LOD levels. Still, it feels great once you get it working. Reverse Engineering is like solving really rewarding puzzle! [1] http://psxemulator.gazaxian.com/ http://psxemulator.gazaxian.com/
dezgeg 12y ago
Reverse engineering old games is always plenty of fun, there are so many different and unusual approaches available. One thing I've found particularly effective is to add custom hacks and patch to the emulator itself. For instance, when cracking the password algorithm of the original Crash Bandicoot, I came across a stack-based virtual machine for Naughty Dog's Lisp-based GOAL language. Since the game used a custom archive format for all its data and I really didn't want to start figuring that format out, so instead I patched the PCSX emulator to print out each executed virtual machine instruction and related state as they were executed: https://github.com/dezgeg/crash-bandicoot-password-cracking/blob/master/pcsx-1.9.92-vm-dump.patch https://github.com/dezgeg/crash-bandicoot-password-cracking/...
- dmbaggett 12y ago
  This is very cool; thanks for sharing. I wrote the GOOL code that you reverse engineered. It was probably only 8 lines of lisp code or so. The basis of the algorithm was simple modular exponentiation used to scramble the game state bits: h(x) = g^x mod p where x was the entire game state packed into 24 bits or so. I mapped the output bit pattern to a button sequence -- every two bits mapped to one of { circle, square, triangle, x } -- to produce the output "password". I don't remember the values for the generator g or the prime p, and no longer have the source code. This kind of construction is very common in cryptography, and was suggested to me by Carl de Marcken, who wrote much of the lisp code at ITA Software.
  - dezgeg 12y ago
    Wow, what a coincidence to hear from the original author! I never looked at (or even located) the actual password generation code, but only worked on the password verification code, as it's way easier to do it in that direction. What I initially did was to use the PCSX emulator's cheat finder feature to locate the memory address of the variable that holds the length of the entered password, then placed a memory breakpoint on that address in the NO$PSX emulator, which then lead to the discovery of the virtual machine. After some reverse engineering of the VM's instruction set and programming the VM tracer, as I knew the address of the VM instruction that incremented the password length counter, I could mash one button for 24 times, and then look at the differences in the instruction traces when the final password character was entered. The function `check()` in https://github.com/dezgeg/crash-bandicoot-password-cracking/blob/master/pwgen.js https://github.com/dezgeg/crash-bandicoot-password-cracking/... is a bit cleaned-up version of the verification function written in JavaScript, mentally translated from this trace dump: https://github.com/dezgeg/crash-bandicoot-password-cracking/blob/master/pass-checks.txt https://github.com/dezgeg/crash-bandicoot-password-cracking/... . All the cryptic variable names in the JS come directly from the virtual machine's "registers". The function make() in the JS is my implementation of the password generator, i.e. inverse of check(), which wasn't too hard to figure out. I never did bother to find a closed-form expression for the inverse of `mixAndPermute()` function, so maybe that's where the modular exponentiation hides, but I personally don't have enough number theory-fu to crack that.
agumonkey 12y ago
The webgl viewer works smoothly, very enjoyable to witness PS1 games in your browser just like that.
james_fairhurst 12y ago
Amazing work, brings back memories playing that track!
swang 12y ago
Wow this is pretty amazing! When I played the PSP version of Wipeout, I always wondered if I could extract the game, extract the track data and add my own tracks into the game.
lostgame 12y ago
Hey, this is very, very, cool. Reminds me a couple guys from the Sonic community who managed to get the old, unreleased Sonic X-Treme for the Sega Saturn to actually compile and run on real hardware. Massive thumbs up for old-school reverse engineering/old console love. http://forums.sonicretro.org/index.php?showtopic=34038&st=0 http://forums.sonicretro.org/index.php?showtopic=34038&st=0
twic 12y ago
Wipeout was the first thing i ever reverse engineered! Specifically, it was the files for cars - you could download more cars for it on the PC version, which had different stats, and a friend and i wanted to engineer a car where all the stats were maxed out. We got as far as being able to decode the files, but could never create a new one that the game would recognise. At least, i think it was Wipeout. Either that or some very similar antigravity racing game. EDIT: It wasn't Wipeout at all, it was POD: https://sites.google.com/site/nelsonspbr/games/pod https://sites.google.com/site/nelsonspbr/games/pod . The cars weren't even antigravity.
- exogen 12y ago
  Looking at the first few cars listed on that page – it looks like each has stats that sum to exactly 300, so this may have been a hardcoded limit preventing what you describe.
deleted 12y ago
[deleted]
huuu 12y ago
I always liked the music in Wipeout. It gives speed to the game. For those interested, check out Tim Wright (http://coldstorage.org.uk http://coldstorage.org.uk)
jojohack 12y ago
Awesome work! And I just realized it's the same guy who created ImpactJS. Awesome developer!
ahoge 12y ago
It's a shame that there was never a good PC version. If I remember correctly, Wipeout 1 had proper timing, but it only offered software rendering. There was one version with hardware acceleration, but it used some crappy proprietary 3D API (ATI CIF). Wipeout 2 used DirectX, but it used tick-based timing which was meant for 30 FPS. So, if you capped it at 60 FPS by using vsync and 60 Hz, it ran butter-smooth but twice as fast as intended.
- Aoyagi 12y ago
  2097/XL had a PC version which is relatively good and I still play it from time to time.
Aoyagi 12y ago
That's quite nice, although I imagine extracting the graphics is less demanding work than redoing the physics and stuff, heh.

184 points by Donzo 12y ago

In "Silverstream - Rapier" the camera goes UNDER the road briefly in the beginning of the flyby, and then again a few seconds later.

phoboslab 12y ago
The camera path is a cheap hack, extracted from certain track faces and has a lot of damping to smoothen things out. Going through the track in certain parts was a tradeoff.

Keyframe 12y ago

I can't remember exactly if it was te first or the second wipeout for playstation 1. But, I remember poking around the CD in good old norton commander and I've stumbled upon those textures in compressed filea as well into which I have entered as if in normal zip file. I have also found NC batch files for compilation or something like that, meaning psygnosis also used NC and forgot to purge those files from final build.

mschuster91 12y ago

Heh, I might use this in EarthSiege 2 when I manage to crack the compression algorithm used there... thanks for the idea!

hayd 12y ago

"given the game's age, I expected the 3D format to be quite simple and straight forward." lolz :)

idunning 12y ago

Amazing, I've tried to do this for Wipeout 3 in the past (extract the tracks) and was defeated - this makes it seem fairly easy!

fapjacks 12y ago
Very interesting. I did this, as well. It was possible to put the Wipeout 3 CD into a CD player and play the tracks as though they were audio files. Realizing this, I used a simple audio ripper to extract the audio files. This was (I think) around 2001 or so.
- phoboslab 12y ago
  I believe he meant the race tracks, not audio tracks. I read somewhere that WipEout XL used a similar data format as the original WipEout, but Wipeout 3 looked like it had a completely new game engine.
- mattdotc 12y ago
  Storing background music as CD-Audio was par for the course with a lot of PSX games.
  - geon 12y ago
    And for PC games of the era. I know Descent did that.
phoboslab 12y ago
Not at all. At least not for me. It's only in hindsight that everything appears obvious. I spent a considerable amount of time trying to figure out the track textures. It was only when I looked at the game in an emulator again (psxemu[1], which comes with nice debugger that lets you record frames and single step through draw calls) that I noticed that the track faces are subdivided at run time. This gave me the clue to look for textures in different LOD levels. Still, it feels great once you get it working. Reverse Engineering is like solving really rewarding puzzle! [1] http://psxemulator.gazaxian.com/ http://psxemulator.gazaxian.com/

dezgeg 12y ago

Reverse engineering old games is always plenty of fun, there are so many different and unusual approaches available. One thing I've found particularly effective is to add custom hacks and patch to the emulator itself. For instance, when cracking the password algorithm of the original Crash Bandicoot, I came across a stack-based virtual machine for Naughty Dog's Lisp-based GOAL language. Since the game used a custom archive format for all its data and I really didn't want to start figuring that format out, so instead I patched the PCSX emulator to print out each executed virtual machine instruction and related state as they were executed: https://github.com/dezgeg/crash-bandicoot-password-cracking/blob/master/pcsx-1.9.92-vm-dump.patch https://github.com/dezgeg/crash-bandicoot-password-cracking/...

dmbaggett 12y ago
This is very cool; thanks for sharing. I wrote the GOOL code that you reverse engineered. It was probably only 8 lines of lisp code or so. The basis of the algorithm was simple modular exponentiation used to scramble the game state bits: h(x) = g^x mod p where x was the entire game state packed into 24 bits or so. I mapped the output bit pattern to a button sequence -- every two bits mapped to one of { circle, square, triangle, x } -- to produce the output "password". I don't remember the values for the generator g or the prime p, and no longer have the source code. This kind of construction is very common in cryptography, and was suggested to me by Carl de Marcken, who wrote much of the lisp code at ITA Software.
- dezgeg 12y ago
  Wow, what a coincidence to hear from the original author! I never looked at (or even located) the actual password generation code, but only worked on the password verification code, as it's way easier to do it in that direction. What I initially did was to use the PCSX emulator's cheat finder feature to locate the memory address of the variable that holds the length of the entered password, then placed a memory breakpoint on that address in the NO$PSX emulator, which then lead to the discovery of the virtual machine. After some reverse engineering of the VM's instruction set and programming the VM tracer, as I knew the address of the VM instruction that incremented the password length counter, I could mash one button for 24 times, and then look at the differences in the instruction traces when the final password character was entered. The function `check()` in https://github.com/dezgeg/crash-bandicoot-password-cracking/blob/master/pwgen.js https://github.com/dezgeg/crash-bandicoot-password-cracking/... is a bit cleaned-up version of the verification function written in JavaScript, mentally translated from this trace dump: https://github.com/dezgeg/crash-bandicoot-password-cracking/blob/master/pass-checks.txt https://github.com/dezgeg/crash-bandicoot-password-cracking/... . All the cryptic variable names in the JS come directly from the virtual machine's "registers". The function make() in the JS is my implementation of the password generator, i.e. inverse of check(), which wasn't too hard to figure out. I never did bother to find a closed-form expression for the inverse of `mixAndPermute()` function, so maybe that's where the modular exponentiation hides, but I personally don't have enough number theory-fu to crack that.

agumonkey 12y ago

The webgl viewer works smoothly, very enjoyable to witness PS1 games in your browser just like that.

james_fairhurst 12y ago

Amazing work, brings back memories playing that track!

swang 12y ago

Wow this is pretty amazing! When I played the PSP version of Wipeout, I always wondered if I could extract the game, extract the track data and add my own tracks into the game.

lostgame 12y ago

Hey, this is very, very, cool. Reminds me a couple guys from the Sonic community who managed to get the old, unreleased Sonic X-Treme for the Sega Saturn to actually compile and run on real hardware. Massive thumbs up for old-school reverse engineering/old console love. http://forums.sonicretro.org/index.php?showtopic=34038&st=0 http://forums.sonicretro.org/index.php?showtopic=34038&st=0

twic 12y ago

Wipeout was the first thing i ever reverse engineered! Specifically, it was the files for cars - you could download more cars for it on the PC version, which had different stats, and a friend and i wanted to engineer a car where all the stats were maxed out. We got as far as being able to decode the files, but could never create a new one that the game would recognise. At least, i think it was Wipeout. Either that or some very similar antigravity racing game. EDIT: It wasn't Wipeout at all, it was POD: https://sites.google.com/site/nelsonspbr/games/pod https://sites.google.com/site/nelsonspbr/games/pod . The cars weren't even antigravity.

exogen 12y ago
Looking at the first few cars listed on that page – it looks like each has stats that sum to exactly 300, so this may have been a hardcoded limit preventing what you describe.

deleted 12y ago

[deleted]

huuu 12y ago

I always liked the music in Wipeout. It gives speed to the game. For those interested, check out Tim Wright (http://coldstorage.org.uk http://coldstorage.org.uk)

jojohack 12y ago

Awesome work! And I just realized it's the same guy who created ImpactJS. Awesome developer!

ahoge 12y ago

It's a shame that there was never a good PC version. If I remember correctly, Wipeout 1 had proper timing, but it only offered software rendering. There was one version with hardware acceleration, but it used some crappy proprietary 3D API (ATI CIF). Wipeout 2 used DirectX, but it used tick-based timing which was meant for 30 FPS. So, if you capped it at 60 FPS by using vsync and 60 Hz, it ran butter-smooth but twice as fast as intended.

Aoyagi 12y ago
2097/XL had a PC version which is relatively good and I still play it from time to time.

Aoyagi 12y ago

That's quite nice, although I imagine extracting the graphics is less demanding work than redoing the physics and stuff, heh.