Archive of https://www.reddit.com/r/evercade/comments/1rqco2c/serious_unaddressed_concerns_about_the_evercade/

Hello,

(regarding rule 10, skip to the end of the post)

I bought an Evercade EXP-R a few weeks ago, my sole purpose of buying one was to simply run my stuff on it. The pack-in Tomb Raider cart was cool, I guess, but I wanted to run my stuff on it the day it arrived. I knew that previous devices by Blaze used Rockchip CPUs, so I was ready with some Rockchip development tools on my Linux laptop.

I was trying the simplest stuff possible at first, found out that you can put an Evercade EXP-R into "Loader" mode by holding down VOL+ on a turned off unit and connecting it to a PC.

I dumped the flash, copied it to my Windows box for analysis, but realized that all the bytes past 32MiB offset were filled with 0xCC. Apparently, that's an intentional quirk of the rkusb read sector function in Rockchip's stock Das U-boot source code - it won't let you read past 32MiB and fills the rest with 0xCC instead of returning an error, this is a Rockchip bug that Blaze simply didn't notice.

Okay, no big deal, happens all the time. Rockchip devices have a MaskROM mode which is even more low-level, even the RAM isn't initialized properly in that mode. So I tried using a command to reboot the device into Maskrom from Loader, then push Rockchip's stock miniloader bin that I merged from rkbin stuff on their GitHub, then dump the flash that way! But... it hung. This kept me awake up all night. I even found out the exact versions of CPU and DDR init blobs evercade are using, but still nothing.

Then I tried to use the "read chip capabilities" command and realized that the device has Secure Read enabled.

Secure Read is a very dangerous to set up security feature that lets manufacturers put hashes of their encryption public keys into a CPU's OTP (One Time Programmable ROM). When the CPU executes code, it will verify the signature of the binary against the code, then verify the signature against the hashes of the public keys stored in OTP, if they don't match, the CPU either hangs or resets. There's no way Blaze Ent. could've set this up themselves in a garage, they must've had support from an OEM. Judging by GitHub guides - this thing is very difficult and dangerous to set up, as you only have one chance to burn your (hopefully securely generated) keys into the OTP ROM. If you flash incorrect keys - you have to get an another CPU. If you accidentally flash an unsigned (or improperly signed) binary onto the flash - the device won't boot anymore until you fix it with Maskrom by pushing a signed miniloader, which only Blaze Ent has.

This means that, ultimately, you cannot (easily) self-repair Evercade units in case of a flash chip failure, which can also happen all the time. Blaze Ent willingly and intentionally does not provide even signed firmware blobs, nor do they mention that they use Secure Read.

They only provide an updater for the legacy Evercade Handheld, only and only because it has no Wi-Fi, all other units with internet connectivity require a Wi-Fi connection to update, no other way.

That is also a huge problem! I live in Russia, and our government is cracking down on CDNs hard, I literally cannot update my EXP-R from my home Wi-Fi, I have to use a trick to share VPN'd internet from my phone just so I can update the thing I bought with my own money! Apparently the CDN they use for firmware distribution is either blocked, or partially blocked (aka degraded / slowed down) so the .bin gets stuck at 16KiB and doesn't download any further.

I am more than willing to prove everything I've just said with screenshots and references, but just in case:

sha256sum 0.uboot.img - 9a27337f053966399b7437990ca1a46ff105bcba (4194304 bytes)

sha256sum 1.trust.img - e6564357ef1ab5e46332a01227ad6128930dee9d (4194304 bytes)

Latest firmware kernel:

4.4.194 #1 SMP PREEMPT Sun Jan 25 22:12:53 UTC 2026 (root@runner-dpmzfssdz-project-54202388-concurrent-1) ((no: ee6c28406a20d8847b41c293dce5e47f6f5067ed)

Rockchip loader blobs used by Blaze:

GitHub rkbin commit b0e2c9b112989d6d662e61be57060c1f68f9c944, ddr bin V2.08 20220817, rk3326_loader_v2.08.135.bin.

Anyone with an EXP-R and even slight knowledge of Rockchip internals can independently verify this.

So, the questions:

a) Why did Blaze Entertainment set up secure boot for Wi-Fiable Evercade devices? What's the use case? Who are they protecting from? So far I haven't found any reasons for this other than, perhaps, greed(??) If I were them I wouldn't bother.

b) Why can't I self-repair a device I bought with my own money for myself? What if the flash chip just drops dead? I can't do anything then, because Blaze Ent. willingly does NOT provide any firmware files or emergency recovery tools.

c) Even Nintendo didn't do anything to lock down the FEL mode on the Allwinner CPU. They even put a warm greeting in /etc/nineties, so people have a smile and have fun I guess. Does this imply that Blaze Entertainment is somehow worse than Nintendo at anti-consumer practices?

d) What's up with the CDN they use? Why there are no HTTP proxy settings in the Wi-Fi options? Can't even change the DNS server, what about customers with restricted or heavily censored internet access? How are we supposed to set up our units, that do kindly ask for an update on first run?

I feel like I just wasted my money. I bought a thing that's very well-built, feels nice in hands, but also very useless and can't be modified only because of whatever business decisions of the manufacturer. I just wish I could have fun with this device, that's all.

Regarding Rule 10:

I don't even want to touch any of the intellectual property that's on cartridges, if there was some kind of homebrew firmware that intentionally bricks the cartridge slot, voids your warranty and support, and lets you run your own stuff, I'd accept that offer in a heartbeat.