Forum TI-Planet.org

Posté: **18 Jan 2018, 17:12**

Lionel Debroux a écrit: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.

Posté: **18 Jan 2018, 17:15**

critor a écrit:
Lionel Debroux a écrit:
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.

Posté: **18 Jan 2018, 19:35**

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

Posté: **18 Jan 2018, 19:56**

@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.

Posté: **19 Jan 2018, 07:54**

@critor @Lionel Debroux

I have working code execution.

All of this code is on my github.

Posté: **19 Jan 2018, 11:57**

That's wonderful !

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

Posté: **19 Jan 2018, 16:30**

critor a écrit: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.

Posté: **19 Jan 2018, 16:39**

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.

Posté: **19 Jan 2018, 17:18**

critor a écrit: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.

Posté: **19 Jan 2018, 17:26**

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.

Forum TI-Planet.org

[removed]

Re: I found an exploit in boot1.5 4.4.0.8!

Re: I found an exploit in boot1.5 4.4.0.8!

Re: I found an exploit in boot1.5 4.4.0.8!

Re: I found an exploit in boot1.5 4.4.0.8!

Re: I found an exploit in boot1.5 4.4.0.8!

Re: I found an exploit in boot1.5 4.4.0.8!

Re: I found an exploit in boot1.5 4.4.0.8!

Re: I found an exploit in boot1.5 4.4.0.8!

Re: I found an exploit in boot1.5 4.4.0.8!

Re: I found an exploit in boot1.5 4.4.0.8!