EOSHD BACKROM hack: Mario 64 on the Canon EOS R8

What if in-between waiting for your diva actors to rehearse the emotionally charged post apocalyptic scene, you can hit the delete key on your Canon EOS R8 and have a bit of Nintendo action? Well readers, that day is finally here and that's not all, as you will find out in this article (grab a cup of tea and enjoy). I will let you know how I did it, what's next, and what the R8 is ultimately capable of...

I've been working on a series of apps for cameras but it never entered by head to try with my Canon R8. Earlier this year, I worked with a nice chap at the BBC on a portrait and landscape video app for news journalists, tested in-house and this led to an NLE for Mac OS to take the fight to Adobe, which I'm going to release soon.

The iPhone stuff has been interesting, but to say the market is flooded is an understatement. My iPhone camera apps will be out eventually but most of my time is now spent on the Mac OS video editor, a Formula One simulator for PC, and a film-look hack for the 5D classic and 5D Mark II, which should be ready this week.

Anyway, that R8...

Something the Japanese camera companies never embraced in their business model for cameras was an app store - they missed the memo about it being worth $1.4 trillion in revenue for Apple alone in one year (2025). This was a bit of an oversight by corporate Japan in the 2010s, which ushered in an era of tepid experiment such as the harebrained "Play Memories" feature on early Sony mirrorless cameras. Even the master of Flappy Birdware Samsung didn't seem to put more than a toe in the water with their first full-fat Android APS-C mirrorless camera, the swiftly abandoned Galaxy NX. For the last decade and a half, Canon users have had some fun with Magic Lantern for additional features (most famously raw video) but anything official is left to firmware updates like it's still 2006.

Canon cameras have a factory service and engineering mode. In the 5D Mark II days, to enable it Magic Lantern made a small payload which runs via the camera's official firmware updater system. The job of this payload was to flick a switch in the ROM to enable booting code from a Compact Flash card. This is the origin of the famous autoexec.bin which made so much more possible on older DSLRs.

These cameras had no mandatory public key signing of firmware update (.fir) files. The newer format used by the R5 and R8 has ECDSA P-256 signatures covering the header/updater and, separately, the firmware payload. Successfully decrypting this or recalculating a checksum isn't enough. Verification uses a public key, recovering that public key (or the separate encryption key) doesn't give us the private key needed to sign modified updates, and that private key is property of Canon.

At this moment in time, I can't document or open source publicly how I run my code on my R8. I don't go via the firmware updater route, and I don't do decryption or firmware signing. There are good reasons I shouldn't yet disclose how BACKROM works in detail though. Rather than beat around the bush I'll level with you on the reasons:

• I don't want to rush out things that aren't ready or 100% reliable
• I don't want Canon to immediately rush out firmware updates to block it
• I don't want to upset Canon. They have a very large cripple hammer.
• The fine details of confirming legality needs to be verified pro-bono by legal professionals (I'm on a search for people who can help)

Keep in mind this is the very early days - the very start of something and a special thing that needs plenty of care, consideration and time in the oven - and maybe even a dialogue with Canon.

If they are reading this, I am happy to open up that dialogue.

The hack#

The humble EOS R8 has an ARM Cortex CPU plus a bunch of very customised bespoke hardware. To code for this camera, you need an intimate understanding of this CPU, the way it manages memory and the overall systems architecture of the camera.

The R8 is a big step up from the old DSLRs. It has protected memory, multiple CPU cores with a controller, a memory manager, a lot of bouncers at the door which you need to negotiate with to get anything done.

After Magic Lantern's legendary lead developer a1ex left in 2020, the project went on a bit of a hiatus and the new cameras are much more complex to code for..

The Canon EOS R8 also has it's own programming language - Canon BASIC. I prefer C. Once code was executing on the camera I began scaling up from a simple exploratory prototype app (aka a coloured box with text) to a spinning, shaded cube to test software 3D rendering.

My code runs from the card. Take out the card, and the camera returns to normal.

To understand how the camera works you need to understand the ROM and operating system (DryOS). For a human to do a static recompile of a binary app to C, you are talking something in the region of 48,000 functions that need to be understood by the idiot behind the keyboard plus the relationships between these (also with the hardware), and the recompile produces upward of 8 million lines of C code. That's around 6 years work for an expert team. Claude (AI tool) compressed that work down to a single weekend.

It is clear there are people now working at machine speed and they will have a big advantage over those still working at human speed, like it or not. An interesting finding was OpenAI's frontier model (GPT 6 Astra) has MUCH looser guardrails for reverse engineering than Claude (albeit not quite as stunningly good). If Canon want to improve their security they should seriously consider getting in touch as I've seen some quite concerning things with Astra.

Back to the R8, and after the spinning 3D cube I worked through a number of more simple app prototypes all in C and tested Mac-side on an ARM emulator until being in the position to do Mario 64 after developing a very broad research base and live test results from the camera. These other prototypes (including DOOM with original music and SFX!) will be shown soon on EOSHD.

When Mario 64 first booted successfully and showed a picture, the frame rate was an absolute slide show. I had in the region of 3-6fps and now it's at the 30fps cap like the original N64 version.

One of the breakthroughs was to understand how the R8 uses the second ARM core, which gives us another 660 million CPU cycles to play with. This second core hosts some camera tasks: AeWbIneg (white balance), DAFPath (autofocus), GlobalVector (exposure) and ColorSPCS. Canon also has a naming scheme for their highly regarded colour science processing: Lucky, and Angel.

In playback mode, these tasks are idle so the CPU has more time to deal with my gaming sessions. That's why, in the video I run it in playback mode. Later in the video you see it running in live-view too, but the frame rate is around 5 or 6fps better in playback with less overhead from the camera processing. The camera can even run Mario 64 in movie mode, but the CPU has even more work to do here in the background so cuts the frames per second to around 17-20.

How much is it capable of?#

The R8's hardware is geared towards fast memory, fast card writes, very fast sensor data processing, and hardware accelerated image encoding, but it's not like a PC with a very fast general purpose CPU and GPU.

The biggest thing missing for modern games on the EOS R8 is any sort of GPU, like a smartphone has. A smartphone has a very good one, R8 has literally none. This means, all of Mario 64's 3D rendering is done by a software renderer running on the two ARM CPU cores. More advanced stuff like PS3 era onwards would need a GPU.

Even with this limitation however, so, so much is possible and I intend to fully explore this on my camera.

If you have seen the recent 'film camera' hacks for the Canon 5D Classic (I'm developing one myself, out this week), these show a lot is possible even on the 2005 vintage DSLRs with their ARM2 CPUs.

Clearly, the R8 will take this even further.

Canon's hardware is for a very bespoke job, it's very good at certain hardware accelerated tasks like JPEG encoding. Once you start running custom scripts and C code on it, all of that runs on the general purpose CPU as software. When it comes to hardware chips you can't simply plugin another hardware accelerator chip to speed up stuff like 3D rendering, which the camera hardware was never designed around!

I would rate the EOS R8 as incredibly capable for a camera - to run a native, static recompile of an N64 game at 30fps with a software renderer is far beyond the two dimensional camera menus and orchestration of specialised hardware the R8's CPU was designed for. This bodes well for fast processing of film emulation, halation, grain, custom LUTs, open gate and uncompressed Cinema DNG 4K RAW video.

Now what remains is for me to see how far I can push it, and whether it's safe for me to release what I make with BACKROM. (At no point will I be distributing any copyright Canon code, flashing custom firmware, bricking cameras, or breaking encryption. This is not what this project is about).

The next target is my Canon EOS R5, the infamous spinning cube is already running on it. Can we reach 60fps in Mario 64 on the pro camera?

Stay tuned to EOSHD and the EOSHD Forum to find out.

Psst. Like the music? Check out my song-writing collaboration with Titan Rain here