Final Fantasy Exploit Teaches 32-bit Integer Math

September 19, 2018 by Bryan Cockfield 18 Comments

One of the fun things about old video games, besides their obvious nostalgia, is that some of the more popular games have been pried apart and tinkered with for years, leading to a lot of new “development” within the games. This often uncovers some hidden gems that gamers might not have had any knowledge of during the game’s heyday, like this coding oddity found in Final Fantasy 7 that illustrates a lot about how 32-bit processors do math.

The original PlayStation used a 32-bit RISC processor, but the most significant bit could be used for integer signing. This means that if you have an integer that has a value of 2,147,483,647 (01111111111111111111111111111111 in binary) and you add one, the value is suddenly negative 2147483648 because the most significant digit is also an indicator of the integer’s sign. In this situation, the integer is said to “overflow”. In Final Fantasy 7, if you can somehow get a character to deal 262,144 damage in one hit (much less than two billion, due to the way the game does damage calculations), the game has a little bit of a meltdown.

[4-8Productions] had to do a lot of work to show how this glitch can be exploited in the game as well. Usually damage in this game is limited to 9,999 but under certain configurations (admittedly obtained by using other exploits and tools available for FF7 like a savegame editor) two of the characters can deal more damage than this critical value, exposing the 32-bit processor’s weak spot.

Even though integer signing is a pretty basic concept for most of us, the video is definitely worth a watch especially if you’re fans of the classic game. Of course, Final Fantasy 7 isn’t the only classic that has been exploited and reverse-engineered to the extreme. You can use a Super Mario World level to implement a calculator now, too.

Continue reading “Final Fantasy Exploit Teaches 32-bit Integer Math” →

Fail Of The Week (in 1996): The 7 Billion Dollar Overflow

June 30, 2016 by Gerrit Coetzee 50 Comments

The year was 1996, the European Space agency was poised for commercial supremacy in space. Their new Ariane 5 Rocket could launch two three-ton satellites into space. It had more power than anything that had come before.

The rocket rose up towards the heavens on a pillar of flame, carrying four very expensive and very uninsured satellites. Thirty-seven seconds later it self destructed. Seven billion dollars of RUD rained down on the local beaches near the Guiana Space Centre in ~~Southern~~ South America. A video of the failed launch is after the break.

The cause of all this was a single improper type cast in a bit of code that wasn’t even supposed to run during the actual launch. Talk about a fail.

There were two bits of code. One that measured the sideways velocity, and one that used it in the guidance system. The measurement side used a 64 bit variable, but the guidance side used a 16 bit variable. The code was borrowed from an earlier, slower rocket whose velocity would never grow large enough to exceed that 16 bits. The Ariane 5, however, could be described with a Daft Punk song, and quickly overflowed this value.

The code that caused the overflow was actually a bit of pre-launch software that aligned the rocket. It was supposed to be turned off before the rocket firing, but since the rocket launch got delayed so often, the engineers made it timeout 40 seconds into the launch so they didn’t have to keep restarting it.

The ESA never placed blame on a single contractor. The programmers had made assumptions. The engineers had made reasonable shortcuts to make their job easier. It had all made it through inspections, approvals, and finally the launch event.

They certainly learned from the event; the Ariane 5 rocket has flown 82 out of 86 missions successfully since then. It has at least five more launches contracted before it is retired in 2023 for the Ariane 6 rocket being developed now. This event also changed the way critical software and redundant systems were tested, bringing the dangers of code failure to the attention of the public for the first time.

If you want to read more, there is a great discussion on Reddit which tipped us off to this fail, a quite thorough Wikipedia article, and the original article that ran in the New York Times is mirrored here.

Continue reading “Fail Of The Week (in 1996): The 7 Billion Dollar Overflow” →

Keypad Input Scanning By A 555 Timer

March 3, 2011 by Mike Szczys 17 Comments

[R-B] designed a 555 timer circuit to scan a keypad. Keypads are common interfaces for small projects and require row and column scanning by a microcontroller. [R-B’s] setup allows you to reduce the number of pins used on the microcontroller to just two. One is an interrupt that is triggered when any of the buttons are pushed, the other reads the frequency from the 555 chip. Each button has its own resistance which alters the frequency of the 555. The microcontroller reads the frequency for 100ms using a timer. The number of timer overflows that occur during that period directly correspond to the button press (five overflows for the numeral 5, zero overflows for the numeral zero).

We usually debounce our button presses for 40 ms, this is more than twice that amount of time but still not a staggering difference. It does make us wonder if you will miss quick button presses? The only really way to know is to try this out yourself. Check out the video after the break and don’t forget to leave a comment with your own experiences in working with the circuit.

Continue reading “Keypad Input Scanning By A 555 Timer” →

Tool Tip: Microcontroller Timer Calculator

September 28, 2009 by Mike Szczys 11 Comments

uC_timer_calculator

In life and embedded systems timing is everything. Give [Frank’s] web-based timer calculator a try. Set your system clock resolution (in hertz making sure you account for any system clock divider), select your timer resolution and prescaler, then calculate based on desired ticks, overflows, or real time. He’s built this with the AVR chips in mind but it should be handy for any family of microcontrollers.

Of course none of this is rocket science, but if you’re trying to use one timer for two differently synchronized events this can save you a lot of trial and error time.