I've created a little program for the 84+, 84+SE, and (yes) 84+CSE to receive unsigned OSes -- any hardware revision, any boot code version, any OS version, any link cable type, any connectivity software, no questions asked.

It works by unlocking Flash, copying the boot code into RAM, patching it so it can run from there, removing the 2048-bit RSA signature check from the RAM copy, and then passing control to it.

It's at http://brandonw.net/calcstuff/uosrecv.zip

Obligatory picture:


I should've thought of it years ago -- as long as we can unlock Flash, this can work. I have a list of 12 exploits (which all work differently) queued up in case they actually fix something, so I think this is here to stay.

I'm hoping to create some sort of wiki/page to explain things like this that aren't really explained anywhere, such as 1) running unsigned OSes on any model, 2) recovering from a brick (no matter what kind), etc.

Nicely done. Running the boot code from RAM is an interesting concept.

I've occasionally wondered, though, if maybe we could do better, and design an OS installation protocol that would be faster and more reliable than TI's - allowing it to resume an interrupted transfer, for instance, or compressing the data. You could probably also speed things up a lot with an OS installer that runs entirely in RAM, so it can simultaneously be writing to Flash and receiving data from the link port. Still, I'm sure that skipping the absurdly slow validation is already a big improvement.

Cool! I kind of considered something like this but couldn't figure out how to do it.

out of curiosity:
1) can you remove ALL validation? (I could if I had time...)
2) does make103 work on CSE?
(Make103 being an automated, flexible version of http://brandonw.net/crap/84PlusOS2.43_Boot1.03Compatible.8xu)

1. Yes. I left the 512-bit one in there since we have all those signing keys, and it's a nice sanity check on the data.
2. I had no idea he studied that 8XU and created that tool, but yes, that does still work on the 84+CSE (I have an 84+CSE-only tool that does it).

EDIT: Since that tool already exists publicly, here's my color equivalent: http://brandonw.net/calcstuff/84PCSE_fakesign.zip

Very impressive. How long did it take you to do a complete analysis of the bootcode to identify where it needed to the patching? Was TI's code straightforward enough that sorting out data from code wasn't too difficult?

It just occurred to me one day how often the boot code assumes where it's returning to by writing 7Fh to port 6, and that that code can be scanned for and replaced in RAM.

On something like the 84+CSE, which has enough extra RAM to hold both boot pages, it's relatively easy to copy the data there and scan-and-replace large sections of code (the larger the block you look for, the less likely you'll replace data with code).

It took a few days of beating my head against the wall to get it to work on the 84+ and 84+SE, where you can only assume one extra RAM page. For those, it uses the extra RAM page for the first boot page, and then RAM page 0 for the second (USB) boot page (swapped into both the second and fourth banks). That means it shares that page with the hardware stack, so SP has to be shifted to the very end.

There's also the matter of the direct USB code using the extra RAM page for its packet buffer, but since that code's running in the same page, it ends up corrupting itself. To get around that, I patched the read/write-to-extra-RAM-page routines to add an arbitrary offset to get it to use the "empty"/0xFF'd area of the second boot page.

So the second boot page can contain the boot code, the hardware stack, AND the direct USB packet buffer. That made for some unusual bugs to track down. At more than one point I had to inject "di \ halt" and "label: jp label" at various places to see what was going wrong...and wait a long, long time between OS transfers.

Between both pages, though, there's more than enough free space to deal with any future changes.

Great BrandonW !

Let's patch the OS to make it faster now

Wow -- it's like jailbreak for TI-84 family! That's pretty cool...of course, if there were only a way to make it more user-friendly (then again, exploits are almost never user-friendly)...