Installing CAS OS 3.6.0.546 on nLaunch(y) Problems

→ **MyCalcs** profile · by **Lionel Debroux** » 14 Sep 2014, 07:39

Isn't the model number stored in the NAND memory?

Nope, the main information about the model number is elsewhere: http://hackspire.unsads.com/wiki/index. ... cellaneous

Why don't we just have a patch to change that to match the CAS version?

Because it can't be changed ?

None of the trivial ideas can work, otherwise they'd have been implemented for a long time (and if they had ever done the mistake, from their POV and threat model, of storing the model number [EDIT: I should have written "exclusively" here] in NAND Flash memory at first, TI would have implemented countermeasures as soon as their silliness would have been pointed out).

The third-party Nspire emulator is called nspire_emu, it's open source, and it works well under Linux, through Wine.

→ **MyCalcs** profile · by **pacificfils** » 14 Sep 2014, 07:42

http://hackspire.unsads.com/wiki/index. ... ory_Layout

Offset 804-805 apparently has that.

→ **MyCalcs** profile · by **Lionel Debroux** » 14 Sep 2014, 07:45

Don't you think that the calculator's software (in some parts we can't easily rewrite, at that) contains some protections against discrepancies between the content of ports 900A0028-900A002C and the content of manuf.dat ?

I repeat:

None of the trivial ideas can work, otherwise they'd have been implemented for a long time (and if they had ever done the mistake, from their POV and threat model, of storing the model number [EDIT: I should have written "exclusively" here] in NAND Flash memory at first, TI would have implemented countermeasures as soon as their silliness would have been pointed out).

→ **MyCalcs** profile · by **critor** » 14 Sep 2014, 07:46

pacificfils wrote:Isn't the model number stored in the NAND memory?

Why don't we just have a patch to change that to match the CAS version?

Yes, the model ID (0x0F for CX CAS and 0x10 for a CX) is stored in NAND and we can reflash it.
But, a CAS flag is also stored in the ASIC, and we know of no way to reflash it.

Having a CAS NAND with a non-CAS ASIC will make you unable to install any OS, as all OSes will be rejected, either because of the NAND check, either because of the ASIC check.

→ **MyCalcs** profile · by **pacificfils** » 14 Sep 2014, 07:50

I hate unwritable stuff.

Can't we just emulate the ASIC data value? (It seems to be too practical to be possible).

The ASIC might use NAND byte flash memory (meaning once you write a byte, it is set forever). Maybe we can find some way to set the bytes properly? Maybe even for the debug mode?

→ **MyCalcs** profile · by **pacificfils** » 14 Sep 2014, 07:52

On an unrelated note, is there a good program for fixing stuck pixels?

→ **MyCalcs** profile · by **Lionel Debroux** » 14 Sep 2014, 07:59

I hate unwritable stuff.

So do we

But let's face it, TI did attempt to protect their business model of selling severely outdated calculators at high price tags with some standardized exam testing restriction capabilities, and they could have done a worse job at it. Their best protection is, in fact, that people do (did ?) not try to destroy their platform's exam acceptance.

Can't we just emulate the ASIC data value? (It seems to be too practical to be possible)

On nspire_emu, yup... but how to do that on real hardware ?

On an unrelated note, is there a good program for fixing stuck pixels?

Programs are unlikely to help. If pixels appear stuck even in the diags software, than there's a hardware defect.

PS: instrumenting the code of nspire_emu with debugging output at select places can give lots of information, e.g. for finding where to automatically overclock the processor and thereby fight against the ever increasing weight of the OS. Maybe it could be used for gaining information relevant to this topic. Just saying.

→ **MyCalcs** profile · by **pacificfils** » 14 Sep 2014, 08:05

Lionel Debroux wrote:On nspire_emu, yup... but how to do that on real hardware ?

Fake the data value with a program like nLaunchy.

Also, I edited my post with an idea.

→ **MyCalcs** profile · by **Lionel Debroux** » 14 Sep 2014, 08:29

Fake the data value with a program like nLaunchy.

In itself, nLaunchy could not fake direct memory reads of memory-mapped hardware ports. It could, however, change comparison and branch instructions in the OS, as I mentioned above. nLaunchy does precisely patch branches in the RAM copy of the boot2, to kill all protections.
The only thing which was never published (assuming it was ever found because somebody bothered ?) is the list of addresses which need to be patched in the OS for running OS 3.6.0.546/550 CAS on the CAS-capable model sold as non-CAS. The code might even be similar to the code patched in boot2, and use hardware ports whose usage could be traced by modified nspire_emu.

The ASIC might use NAND byte flash memory (meaning once you write a byte, it is set forever).

The Nspire's NAND Flash is not OTP memory, even in the manuf.dat range. The serial number is OTP, and on CX / CM, the boot1 might be, we don't know.

→ **MyCalcs** profile · by **pacificfils** » 14 Sep 2014, 08:38

Lionel Debroux wrote:The only thing which was never published (assuming it was ever found because somebody bothered ?) is the list of addresses which need to be patched in the OS for running OS 3.6.0.546/550 CAS on the CAS-capable model sold as non-CAS. The code might even be similar to the code patched in boot2, and use hardware ports whose usage could be traced by modified nspire_emu

How would one who is interested in finding this address list and make the patch go around doing that? Not specifics, but what is the general method? (It's not me.) (It is me.)

Also, how on earth do I stop nLaunchy from deleting the Phoenix and `tns` file? I want to keep it between boots!