Jump to content
jimrandomh

Looking for arbitrary code execution through an Atari game

Recommended Posts

There are several published demonstrations of NES, SNES and GBC games where it's possible to trigger a bug in the game, corrupt memory, and get the console to execute arbitrary code. For example http://tasvideos.org/4961S.htmlwhich exploits a memory corruption glitch in Super Mario Bros. 3 to get the program counter into RAM, then starts loading programs in through the controller port. I'm looking to do something similar to an Atari 2600.

 

The Arcade Learning Environment (ALE) is a machine learning/artificial intelligence testbed based on an emulated Atari 2600. AIs have realtime read access to the Atari's screen and memory, and write access to the controller ports and reset switch. But what if, instead of a primitive AI, you connected the ALE to a master hacker? I want to achieve total control over an emulated Atari 2600 in the Arcade Learning Environment, preferably through a bug in a well known game. Then I want to load a custom program that triggers memory corruption in the emulator, Stella, and use this to break out of the emulator to the host system, and from there build a connection between the controller port and the internet. (The ultimate purpose is to publish the result in a paper and make a point about AI safety - that not giving an AI internet access explicitly doesn't mean it can't acquire internet access).

 

I have quite a bit of programming expertise including several assembly language variants, but have never programmed for the 6502. Before I dive deep into reverse-engineering Atari games, I'd like to sanity-check a few things with someone who knows the architecture well. In particular:

 

1. If the program counter points to RAM, will it actually execute, or will that crash the console?

2. In between the end of the ROM area of address space and RAM, are all the TIA read and write ports and some unallocated address space. Will attempting to execute these addresses crash the console or will it continue and execute $80?

3. Are there any already-known examples of game memory corruption bugs which might work?

4. How common are indirect jumps in Atari games?

 

Thanks!

Share this post


Link to post
Share on other sites

1. you can run code from RAM, but remember there's only 128 bytes of it.

2. Several of these locations probably do not have well defined behaviour as to what values you will "read" from, so are unlikely to reliably create runnable code that would allow you to execute from 0x80 through to 0x100

3. Not that I'm aware of, bugs in 2600 code are fairly rare, there isn't room for them :)

4. fairly common

 

you seem to be intending to rely on there being a code execution bug in Stella which can be accessed from 6502 code, seems unlikely.....

  • Like 1

Share this post


Link to post
Share on other sites

Typical guest-to-host escapes exploit bugs in a communication mechanism between guest and host, like accessing guest hardware via a driver, or sending signals to the host for a shared clipboard or similar things. These bugs rely on the fact that the host code has to parse some (complicated) structures the guest can construct, or that the guest can provide and fill a buffer of variable length.

 

You won't find something like that in Stella's VCS emulation. It's "only" parsing 6507 opcodes and emulating registers/output. You cannot via 6507 code signal anything to Stella, nor can you trigger some kind of buffer allocation or complex structure parsing in Stella from 6507 code.

 

I'm pretty sure Stella is full of bugs since security never was a concern when it was developed, but I'm also pretty sure you cannot trigger them with 6507 code in a controllable way, much less in a way that afterwards, the host's program counter points into the emulated VCS ROM/RAM.

 

Have you any experience with guest-to-host exploits in other environments?

Share this post


Link to post
Share on other sites

I'm pretty sure Stella is full of bugs since security never was a concern when it was developed...

Stephen has invested quite a lot of time into better code quality lately. He has eliminated a lot of potential errors that way.

 

If any attacks are even possible, then I would try to use an older version.

Share this post


Link to post
Share on other sites

There are several published demonstrations of NES, SNES and GBC games where it's possible to trigger a bug in the game, corrupt memory, and get the console to execute arbitrary code. For example http://tasvideos.org/4961S.htmlwhich exploits a memory corruption glitch in Super Mario Bros. 3 to get the program counter into RAM, then starts loading programs in through the controller port. I'm looking to do something similar to an Atari 2600.

 

The Arcade Learning Environment (ALE) is a machine learning/artificial intelligence testbed based on an emulated Atari 2600. AIs have realtime read access to the Atari's screen and memory, and write access to the controller ports and reset switch. But what if, instead of a primitive AI, you connected the ALE to a master hacker? I want to achieve total control over an emulated Atari 2600 in the Arcade Learning Environment, preferably through a bug in a well known game. Then I want to load a custom program that triggers memory corruption in the emulator, Stella, and use this to break out of the emulator to the host system, and from there build a connection between the controller port and the internet. (The ultimate purpose is to publish the result in a paper and make a point about AI safety - that not giving an AI internet access explicitly doesn't mean it can't acquire internet access).

 

I have quite a bit of programming expertise including several assembly language variants, but have never programmed for the 6502. Before I dive deep into reverse-engineering Atari games, I'd like to sanity-check a few things with someone who knows the architecture well. In particular:

 

1. If the program counter points to RAM, will it actually execute, or will that crash the console?

2. In between the end of the ROM area of address space and RAM, are all the TIA read and write ports and some unallocated address space. Will attempting to execute these addresses crash the console or will it continue and execute $80?

3. Are there any already-known examples of game memory corruption bugs which might work?

4. How common are indirect jumps in Atari games?

 

Thanks!

 

You would like the SuperCharger's Operating System. the SuperCharger is an Atari cart with 6k of RAM and an OS that loads program files from tape.

 

You could hack the 2K OS to load via the joystick port, and even without the supercharger RAM if 128 bytes is enough for you; the OS would be good to study because it's doing what you want already - loading and executing code on the VCS :)

Share this post


Link to post
Share on other sites

128 bytes of ram is usually more than enough for self-modifying routines...given that you'd probably only need them for display kernel purposes where code would already be as streamlined as you could make it before needing to take this route, and additional ram for all other aspects is already obtainable via Superchip, etc. Regarding (3), there are plenty of examples of existing ram-corrupting bugs for games on any console...but not so much for the effect you are after. Certainly not for any commercial games for the 2600 - where the majority of games were pretty small and programmed by a single person. On question (4), lots. Most often utilizing the PHA/RTS method rather than the actual JMP(ind) opcode, because code is shorter with the former.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...