[removed]

[parrotgeek1]

Maybe you don't have to do that, if the boot1.5 loads the image in boot1.5/boot2 compressed format before checking its signature ?
The return address of the memcpy()-type function which copies the boot2 to the target area would be a natural target to gain control of the execution flow. You can probably overwrite the code there with your own.

It doesn't. It decompresses it directly to the base address. (my exploit runs when the progress gets to about 9%).

I'm going to try to overwrite the code at the return address of the nand read function, good idea.

[parrotgeek1]

because you can always downgrade boot2/boot1.5 as long as the hardware is compatible, even with only a serial cable.

Right, but you know that hardly anybody ever uses a serial cable to downgrade Nspire calculators

A serial cable shouldn't be needed as long as we have Ndless to downgrade, and boot loaders patching the OS to prevent the Boot2 partition (Boot2+Boot1.5 images) from being altered (available in both Nlaunch* and nBoot+ControlX).


For the rest, indeed, TI thoroughly reads TI-Planet and probably some other english-speaking places, and usually fixes major flaws before they get released and sometimes even before they get exploited :

• Nlaunch* Boot2 1.4 exploit was released on 2013 January 1st -> viewtopic.php?t=11014
  But it was already fixed in Boot2 3.0.1 from 2011 February 23th
• Nlaunch CX Boot2 3.1 exploit was released on 2013 April 1st -> viewtopic.php?f=20&t=11483
  But it was already fixed in Boot2 3.2.4 from 2013 January 14th, and preinstalled on HW-J+ from March 2013 which were also made incompatible with the older version.
• nBoot Boot1 3.0 exploit was released on 2016 May 21st -> viewtopic.php?t=18437&p=202317#p202297
  But it was already fixed in Boot1 4.0 from 2015 July 20th, and preinstalled on HW-W+ from October 2015 which were also made incompatible with the older version.

If you've got the impression that TI is fixing flaws after they get exploited, it's just because it takes several months for the new hardware revisions to reach our local shops.

So, in the best case, if your exploit can be useful, you can consider it fixed before the end of the month.

Your reasoning is wrong. The exploits for nLaunch, nLaunch CX, and nBoot were discovered *because* they were fixed by TI. When people were looking through the differences between the code in the 2 versions, they found some code that looked like a vulnerability had been fixed and then tried to exploit it. I know for a fact this is true of nBoot.

[Lionel Debroux]

nLaunch wasn't the first usage of that vulnerability, and I'm not sure the vulnerability was found by differential code analysis.

[critor]

@parrotgeek1 Regarding nBoot, I'm not sure.

First CX HW-W have been assembled in October 2015.
Which means that they appeared in shops months later.

We discovered HW-W / CX CR4 / Boot1 4.0 in February 2016 : viewtopic.php?t=17934&p=196612
No Boot1 4.0 could have been dumped/shared before, since Ndless had to be fixed for the new hardware too.

Was this enough to start developing nBoot and release it on 2016 May 21st ? I'm not sure.

[parrotgeek1]

@critor @Lionel Debroux

I have working code execution.

All of this code is on my github.

[critor]

That's wonderful !

Let's start adapting ControlX for CR4+ / HW-W+ now.

[parrotgeek1]

That's wonderful !

Let's start adapting ControlX for CR4+ / HW-W+ now.

The first problem is that you can't use any of the boot1 functions like read_nand because boot1 isn't running. We need to either find or write nand related functions.

[critor]

Argh... that's adding quite a challenge.

I know these kind of functions are also available in Boot2.
I suppose they're available in Boot1.5 too, since Boot1.5 is loading Boot2 from the NAND.

[parrotgeek1]

Argh... that's adding quite a challenge.

I know these kind of functions are also available in Boot2.
I suppose they're available in Boot1.5 too, since Boot1.5 is loading Boot2 from the NAND.

The copy of Boot1.5 in RAM is corrupted by the exploit.

I figured out a way to load boot2 though. I'll add it.

The only big problem is that without nand access you can't get rid of the downgrade protection, or save settings.

[Lionel Debroux]

With reliable code execution, you can change the contents of the virtual memory translation table to map the boot1, if it's not mapped at the suitable place (0 or A4000000, back in the day) when the boot1.5 executes.