Have a look at what I've found today!
http://ti.bank.free.fr/index.php?mod=news&ac=commentaires&id=1112

What's your guess?

TI has just released the new 2.1.1 Nspire OS.


It's very similar to the 2.1.0 OS, but Ndless isn't compatible yet (although it seems it could be ported to that OS).

It includes the 1.4 boot2 and so is no more protected that the 2.1.0 OS.
It also means that unlike the 3.0.1 OS, installing it should not brick your calculator this time.


The 3.0 boot2 does reject the 2.1.1 OS. So you can't be saved (downgrade from the buggy/faulty/dangerous/evil 3.0 OS) by installing the 2.1.1 OS.


Well quite an uninteresting OS.

I really can't understand why TI felt the urge to release that now...


All tests/infos and links on TI-Bank:
http://ti.bank.free.fr/index.php?mod=news&ac=commentaires&id=1076

The Nspire 3.0 OS doesn't open unencrypted TNS files anymore: you get the "this document format is not supported" dialog box.

Some unofficial softwares (TI-Nspire Text Editor, TNIC web) were generating unencrypted TNS files with text and images.
Those files aren't usable anymore on OS 3.0.

They probably did it on purpose: to import text or images on your Nspire, you now have no other way than using the official software, if you have a valid licence.

Starting from OS 1.2, TNS files were stored encrypted.
In OS 1.1, TNS files were stored unencrypted as XML files, exactly like with TI-Nspire Text Editor and TNIC web.
I've just tested: TNS files generated by the 1.1 OS aren't usable on the 3.0 OS.

So, in order to bother us, TI even took the right to break their own advertised ascending compatibility.


To get back at TI, we should really break the TNS encryption as soon as possible.

Hi!


Just got another unknown TI-Nspire CAS prototype.
It's got the "TI-XXXXXXXXXXX" label, which had never been reported on the Internet up to now.

Could you help me saving the included OS/Boot1/Boot2?

It's running the oldest 1.1 Nspire OS we've ever heard off: 1.1.6925 CAS built on 2007-02-07.
Boot1 & Boot2 versions are 1.1.6818.
There is no included diagnostic software.

And of course, like the 1.1.7320 basic OS, no "full" USB support.
So I cannot use TI-Nspire Computer Link to access the filesystem, and I cannot exchange data with another TI-Nspire, and the "Send OS" menu is disabled anyway.


With the 1.1.73xx prototype, the main difference was that I had severall of them.
So I could:
- remove the OS on one of them to use the boot2 exploit at the "install OS" screen and dump boot1/boot2/diags
- flash a more recent boot2 on another one, as the older 1.1.73xx boot2 didn't want to run the more recent developer OSes I had as a test image


This time, I've only got 1 prototype of that kind, and that's the main poblem.
So if I remove the OS or update the boot2, it will be lost and probably forever.


I'm going to try:

- to get the full boot log through my RS232 adapter

- to run the more recent 1.1.8408/1.2.2344 developer CAS OSes as a test image through my RS232 adapter, but according to my previous experience with the 1.1.73xx pototype, I'm very doubtfull it will work...


Here's the 1st photo in the world for you:



Goplat, Bsl, everybody... if you have any idea which could help me fully dump the OS/Boot1/Boot2, please share it.

I've purchased 2 identical basic TI-Nspire prototypes.

They are very rare. Have a look there:
http://ti.bank.free.fr/index.php?mod=galerie&action=img&id_gal=9&id_img=129

They come with the oldest 1.1 OS/boot1/boot2/diags I've ever seen:

* OS 1.1.7320
* Boot1 1.1.7314
* Boot2 1.1.7314
* Diags 1.1.7387


They are detected as standard "TI-Nspire handheld" by Windows, but...

- None of the TI-Nspire Computer Link versions is listing them... Not even the 1.0 version, not even by updating/downdating the driver, not even by using the Computer Link 1.0 driver...

- The "Send OS" menu item is disabled.

- Unlike my other prototypes, they cannot exchange data with commercial TI-Nspire BAS/CAS, prototype TI-Nspire CAS/CAS+, and not even between themselves! The "Send" menu item simply returns immediatly, doing nothing.


If I'm guessing right, the USB link protocol had not been implemented yet in the 1.1.7320 OS. Seems it is going to be hard to dump anything without USB linking...

Any idea?

Here are the "programs" used when booting a Nspire:

• boot 1
• boot 2
• OS

Boot1 is checking boot2 signature, then launching it.
Boot2 is checking OS signature, then launching it.

Up to now, we were believing that boot2 could be updated by a software, but not boot1.


Then, if we ever managed to factor the OS key, TI just would have to use a different signing key for new OSes. This would force you to update your boot2 to a new version that would launch the new OSes signed with the new key, but not the old OSes signed with the old key.

Then, we just had to factor the boot2 key.
If boot1 couldn't be updated by a software, only new TI-Nspire could get a new boot1 using a new key and refusing to load boot2 signed with the old key.


The TI-Nspire diagnostic software 1.3 can update the NAND ROM code (boot2, diagnostic software, test program, OS). Here are the related messages:
The NandFlash has more than 20 bad blocks, please change it!!
Nand Flash Test
UpdatedNandFlash(528B)
NAND
Copy Nand  Data To SD Card
SDCard Update NandFlash Code
Search  Nand
Erasing the Nand
Copy Nand.bin to NandFlash
Search  Nand.Chk
Copy Nand.bin to RAM
Copy RAM to NandFlash
Verify SDCard Update NandFlash Code
NandIDFlashFailed
Nandflash Check
Please enter nandflash address
Nandflash Address
Please input nandflash address again
ST Micro NAND128R3A
ST Micro NAND128W3A
ST Micro NAND128R4A
ST Micro NAND128W4A
ST Micro NAND256R3A
ST Micro NAND256W3A
ST Micro NAND256R4A
ST Micro NAND256W4A
ST Micro NAND512R3A
ST Micro NAND512W3A
ST Micro NAND512R4A
ST Micro NAND512W4A
ST Micro NAND01GR3A
ST Micro NAND01GW3A
ST Micro NAND01GR4A
ST Micro NAND01GW4A
NAND_BI_RSN_READ
NAND_BI_RSN_ERASE
NAND_BI_RSN_WRITE
NAND_BI_RSN_ECC
NAND_BI_RSN_TEST
Nand Flash Test


But... it also seems the TI-Nspire diagnostic software 1.3 can update NOR ROM code (boot1), by looking for a "Nor.raw" file on the external SD card.
NOR
Verify SDCard Update NorFlash Code
Search  Nor.raw
Comparing  Nor.raw with Norflash
SDCard Update NorFlash Code
Search  Nor.Chk
Copy Nor.raw to RAM
Erasing the Norflash
Copy RAM to Norflash
NorFlash
NorFlash Test
NorFlash_ID

Then, as boot1 can be updated by a software, TI could make a new TI-Nspire OS which would update boot1 to a new version using a different key and boot2 to a new version signed with the new key. We wouldn't be able to load boot2 signed with the old key any more.


But... If I am right, boot1 is not signed.
Then, it means we would just have to disable the boot2 signature checking in boot1 in order to load a modified boot2 and then a modified OS...

Of course, TI could then release OSes that would update boot1 again (and maybe won't want to run with the hacked boot1) but we would just have to disable that security by modifying the new OSes before installing them.


Did I make a mistake somewhere?

Does anybody have the courage to try something like that on Goplat's emulator ? (for now...)
I can give the diagnostic software 1.3 dump, in order to look for the flashing code.

I'm opening a topic to list 1.x downgrade problems with TI-Nspire TouchPad, as I've had something frightening yesterday.

Feel free to contribute.


#1:
Calculator: TI-Nspire CAS TouchPad
OSes: 1.6 & 1.7
Problem: The OS doesn't start with any of the 4 available keypads (TouchPad, TouchPad CAS, ClickPad, and 84+). We either get a keyboard error dialog box, either continuous reboots.


#2:
Calculator: TI-Nspire TouchPad basic
OSes: 1.1-1.7
Problem: The OS doesn't start with the TouchPad keypad (continuous reboots).

#3:
Calculator:  TI-Nspire CAS TouchPad
OSes: 1.1-1.4
Problem: The TouchPad keypad keys are mixed and the arrow keys don't work at all.


#4:
Calculator: TI-Nspire CAS TouchPad
OS: 1.4
Problem: When plugging a mini-USB A plug into the Nspire (even if the cable is not connected to anything else) a dialog box is triggered saying that the connected USB peripheral is not working properly, asking to disconnect and reconnect the peripheral, and saying that the hardware might be faulty if the problem does persist.
When validated, the dialog box is triggered again allmost immediatly.
Moreover a strange alternative but regular noise could be heard from inside the USB connector; something like: noise for 1second, silence for 1 second, noise for 1 second...
It does not happen with a mini-USB B plug, and the TI-Nspire seems to be able to communicate properly with that plug.
A reboot didn't correct the problem.
After reupgrading to 2.0, the problem disappeared.

Hi!


I'd like to make a Ndless program able to control the LED present on the following models:
* TI-Nspire ClickPad
* TI-Nspire TouchPad
* TI-Nspire CAS TouchPad
(the TI-Nspire CAS ClickPad doesn't have that LED but has the circuit -> you might make a hole and solder it)

There are many uses for that LED.
It could be used in games as a won/lost or hit/missed indicator.
You might use it to indicate your mood of the day: red for "mad: don't speak to me today", yellow for "I'm in love", for example...
We might use it to communicate short answers: yes/no, little number...
We could also use it to communicate fully by using some king of Morse code.


The LED is documented on HackSpire and it looks quite easy:

90110000 - LED

    * 90110B00 (R/W): Control register
          o Bit 0: Set this bit to enable green light blink data. If green blink data iteration is not on, the green light state is read from bit 0 of green blink data.
          o Bit 1: Set this bit and bit 6 to enable green blink data iteration.
          o Bit 2: Set this bit to force green light off. Overrides bit 4.
          o Bit 3: Set this bit to force red light off. Overrides bits 5 and 13.
          o Bit 4: Set this bit to force green light on.
          o Bit 5: Set this bit to force red light on.
          o Bit 6: See this bit and bit 1 to enable green blink data iteration. Reset before modifying green blink data or delay.
          o Bit 9: Set this bit to enable red light blink data. If red blink data iteration is not on, the red light state is read from bit 0 of red blink data.
          o Bit 10: Set this bit and bit 12 to enable red blink data iteration.
          o Bit 12: Set this bit and bit 10 to enable red blink data iteration. Reset before modifying red blink data or delay.
          o Bit 13: Forces red light on if bit 4 is 0, or red light off if bit 4 is 1. (?)
    * 90110B04 (R/W): Green blink data. 32 bits of on and off state, represented by 1 and 0. Iteration is done from bit 31 to bit 0 repeatedly.
    * 90110B08 (R/W): Green blink delay (negative). OS sets this to -2048.
    * 90110B0C (R/W): Red blink data. 32 bits of on and off state, represented by 1 and 0. Iteration is done from bit 31 to bit 0 repeatedly.
    * 90110B10 (R/W): Red blink delay (negative). OS sets this to -2048.

Note: If red and green lights are on at the same time, the color becomes yellow.

I've made a simple program.

#include <os.h>
#include "console.h"
#include "screen.h"
#include "charmap.h"
#define LED_MODE_ADDR 0x90110B00

int getMem(int addr)
{ return *(volatile unsigned*) addr;
}

void setMem(int addr, int val)
{ *(volatile unsigned*) addr = val;
}

int main(int argc, char* argv[])
{ int mode_orig = getMem(LED_MODE_ADDR);
int mode_base = mode_orig&~0b01011001111111; //turn OFF + disable blink / iteration / force on-off
clrScr();
int mode_curr=mode_base;
int mode_last=mode_orig;
while(!isKeyPressed(KEY_NSPIRE_ESC))
{ mode_curr=mode_base;
if(isKeyPressed(KEY_NSPIRE_R) || isKeyPressed(KEY_NSPIRE_J) || isKeyPressed(KEY_NSPIRE_Y))
mode_curr |= 0b100000; // force RED on
if(isKeyPressed(KEY_NSPIRE_V) || isKeyPressed(KEY_NSPIRE_G) || isKeyPressed(KEY_NSPIRE_J) || isKeyPressed(KEY_NSPIRE_Y))
mode_curr |= 0b010000; // force GREEN on
if(mode_curr!=mode_last)
{ setMem(LED_MODE_ADDR,mode_curr);
mode_last = mode_curr;

disp("Written LED mode: ",0);
dispi(mode_curr,0);
displn("",0);

disp("Current LED mode: ",0);
dispi(getMem(LED_MODE_ADDR),0);
displn("",0);
}
}
setMem(LED_MODE_ADDR,mode_orig); // reset
return 0;
}
You need to press some keys to turn on the red or green colors.


And I'm getting very strange behaviours.

I've tested on 3 TI-Nspire ClickPad and 1 Ti-Nspire TouchPad.
On 2 of them, it worked the 1st time, but that's all... It never worked again!!!
On the 2 others, it never worked.

The LED just remains off...

Strangely, I've experienced many reboots, either when entering the program, either after exiting the program...
Very strange as I don't use any other pointer than the 0x90110B00 address. And it did reboot before I added the debug display.


Here's a sample log of the debug informations displayed on the screen (when it doesn't reboot):

Written LED mode: 0 // 1st loop
Current LED mode: 5699
Written LED mode: 32 // press 'R' key
Current LED mode: 5699
Written LED mode: 0 // release 'R' key
Current LED mode: 5699

You see?
I'm checking the LED mode just after writing it.
And it's allways 5699!
My values aren't written, or are modified immediatly...

How is this possible? I thought interrupts were disabled while running a Ndless program...


The fact that it worked 2 times (with dozens of tries) this evening, proves that this address is read/write, as stated on HackSpire.

But there seems to be some kind of checking/protection, whose reliability is strong, but not 100%.


Can you help me?
Do you have any idea what is going on?
Do you see some stupid things in my code?

Thanks.


Please find attached the last binary.

If you want to modify & recompile, you just have to get "screen.*", "console.*" and "charmap.h" files in the mViewer archive, and use them with the code above.
http://ti.bank.free.fr/index.php?mod=archives&ac=voir&id=2014