Forum TI-Planet.org

[removed]

Interesting.

So we need a modified Boot1.5 image ?
How can this work on a real calculator, since Boot1 is checking Boot1.5 before launching it ?

critor wrote:Interesting.

So we need a modified Boot1.5 image ?
How can this work on a real calculator, since Boot1 is checking Boot1.5 before launching it ?

No, we are modifying the boot2 image after boot1.5. It is a bug in how boot1.5 loads boot2. Boot1.5 has a base address of 11200000. boot1.5 does not check the signature before copying the image to the base address, so If you make a boot2 image with 11200000 as a base address, it will overwrite boot1.5's code in RAM while it is running and run your code instead.

Ah, very interesting indeed.

So now, after Nlaunch* (HW<J) and nBoot+ControlX (HW<W), we've got to develop another Nspire boot loader, at least for recent hardware revisions.

I've checked your repository and the script files.

You've got a ControlX specially modified to work with this setup ?
Could you share it ?

critor wrote:I've checked your repository and the script files.

You've got a ControlX specially modified to work with this setup ?
Could you share it ?

No. It does not work, just crashes.
I only modified ldscript, to remove the header and change the base address. There are no other changes.
Maybe I am doing something wrong?

The find is interesting indeed, good idea

However, it's a shame that you publicly burned a potentially high-value vulnerability, in a place TI reads, before you got any kind of even somewhat working exploit for it
The nLaunch / nLaunch CX crew(s ?) didn't do that blunder: they came out of the blue with ready-made programs.

The occurrence of a crash when the code overwrote itself, which I didn't anticipate but was pretty obvious when I understood what was going on, was the reason why I switched one of the five core statements of OSLauncher's code from memcpy() to __builtin_memcpy(). You won't have this luxury here, so you'll have to find another way to reliably regain control.

Lionel Debroux wrote:The find is interesting indeed, good idea

However, it's a shame that you publicly burned a potentially high-value vulnerability, in a place TI reads, before you got any kind of even somewhat working exploit for it
The nLaunch / nLaunch CX crew(s ?) didn't do that blunder: they came out of the blue with ready-made programs.

The occurrence of a crash when the code overwrote itself, which I didn't anticipate but was pretty obvious when I understood what was going on, was the reason why I switched one of the five core statements of OSLauncher's code from memcpy() to __builtin_memcpy(). You won't have this luxury here, so you'll have to find another way to reliably regain control.

1) I don't think I really burned this vulnerability, because you can always downgrade boot2/boot1.5 as long as the hardware is compatible, even with only a serial cable. It took 2 years for new hardware to become incompatible with boot2 3.1. Also, it takes TI months to validate/release new OSes.

2) I posted it because I don't know enough about exploits to finish making it work and want help.

3) Thanks for the help. My new idea is to just overwrite the boot1.5 with a patched version of itself that jumps to a much higher address (like 11300000) instead of validating the signature, fill in the blank space at the end, and then put the rest of my payload at 11300000.

1) I don't think I really burned this vulnerability

You did (you got the clock ticking) by the mere fact of posting publicly

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

]It took 2 years for new hardware to become incompatible with boot2 3.1.

Yeah, and given that they're now much deeper in the Cost Reduction phases than they were previously, the chance of new, incompatible hardware is probably lower.

Also, it takes TI months to validate/release new OSes.

Yup. They usually fix high-impact vulnerabilities within about three days (for bounds checks or nullptr checks, it's a matter of fixing several lines of code, after all !), and the fixed versions start hitting brand-new calculators on the market 2-3 months later.

2) I posted it because I don't know enough about exploits to finish making it work and want help.

I understand that, but doing it privately wouldn't have got the clock ticking yet

Patching the boot1.5 to shift the addresses looks like a major chore. 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.

Lionel Debroux wrote:

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.