Omnimaga
Calculator Community => TI Calculators => General Calculator Help => Topic started by: northern_snow on July 10, 2013, 04:27:26 am
-
The new nsManager supports of switching the region code.
But in the program, the function of switching a CM to a CX is disabled. So Zweb recompiled the source code and changed his CM into a CX, and flashed the Boot2 with RS232.
So in theory the CM is a CX now (Also the link software detect it as a CX)
...However, he can install neither the CX OS nor the CM OS.
The installation of nLaunch caused a reboot and stuck at 60% of the bar.
The installation of a CX OS caused a "Missing ASIC user flag" error. After the 80E0 field of OS image was changed, which means the ASIC user flag matches, another error displayed...
The installation of a CM OS casued an "Invalid program ID" error.
Questions:
Is there a syscall of boot2 can modify the NAND? Or any other way to modify the NAND without an OS?
What's wrong with the nLaunch?
What does the Field ID in hackspire really mean? In fact the ASIC user flag found in the OS image is not at the 80E0 field.
ExtendeD, Lionel Debroux, Critor, Adriweb, nLaunch guy and others please help...
-
In this first post, I'll try to explain comprehensively what I understand of this critic problem for other readers.
Correct me if I'm wrong.
nsNandMgr doesn't work on the latest TI-Nspire emulator release in CM mode, although it works like a charm in classic or CX mode. So unfortunately, we have no way to simulate exactly what you did - so it's important to be very accurate.
nsNandMgr does forbid some hazardous/untested things, yes.
So if I understand well, correct me if I'm wrong, you (guys) did modify the source in order to bypass those securities.
You did then:
- use nsNandMgr to change the model ID in NAND-Manuf from 0x12 (TI-Nspire CM) to 0x10 (TI-Nspire CX)
- use RS232 to flash CX Boot2 3.1.0.16
Question: how did you use RS232 on a model which has no Dock/J01 connector? Did you use the internal J04 connector?
Note: you could have flashed the Boot2 from nsNandMgr, before or after modifying the NAND ID.
So now, you have:
- a TI-Nspire CM hardware
- model ID 0x10 (TI-Nspire CX) in NAND-Manuf
- the common TI-Nspire CX/CM Boot1 3.0.0.99
- the TI-Nspire CX Boot2 3.1.0.16
- User Flags 0b00010 (TI-Nspire CM) in ASIC
In that condition, it's normal for your calculator:
- to reject CAS and CM OSes with an "Invalid program ID" error because of the NAND-manuf model ID
- to reject CX OSes with a "Missing ASIC user flags" error because of the ASIC User Flags
Yes, your calculator is in a condition where it won't accept any 'normal' OS anymore.
Such calculators are usually referred as 'bricked' calculators.
Changing the 80E0 field in an OS file to match the ASIC user flags can't work because this field data belongs to the signed data.
-
Yes he used the J04.
Thanks for your explanation critor ;)
Here are two possible ways to solve the problem:
1 Find out a syscall under boot 2 which can modify either manuf or ASIC.
2 Make nLaunch work. (IMHO nLaunch bypasses all the check of manuf and ASIC)
-
If it was so easy to inject code and use Boot2 3.1 syscalls, we wouldn't have waited for Nlaunch CX.
Solving this critic problem means making Nlaunch (or a similar tool) work with the CX Boot2 on your CM hardware.
And we should first try to determine where it does crash and why.
The TI-Nspire CM hardware has only 32MB RAM instead of 64MB on a real TI-Nspire CX.
This might have some issues with overflow exploits for example...
To help us determining where Nlaunch does crash you might try to modify its source code by adding some ouputs to the top left-hand corner of the screen or to RS232.
-
After transmitting the nlaunch to the calculator,it will reboot.I'm pretty sure codes executed before reboot(in fact,reboot is generated by nlaunch),but after reboot,no code executed.
-
Do you have the time to see if some characters are outputted to the top left-hand corner of the screen before the reboot when sending nlaunch.tco ?
-
Yes,"YZ" displayed.
-
Ok, Y+Z+reset seems perfectly normal:
firstloader_cx.c:
void main(void) {
const char *preloader_path = "/documents/nlaunch/preloader.tns";
display_msg_to_screen(u"Y",0,0);
*(volatile unsigned*)0x90060C00 = 0x1ACCE551;
*(volatile unsigned*)0x90060008 = 0;
*(volatile unsigned*)0x90060C00 = 0;
mkdir("/phoenix/install/");
rename(preloader_path, (char *)0x118D9DA4);
display_msg_to_screen(u"Z",0,0);
boot2_HW_reset();
__builtin_unreachable();
}
What is not normal, is Nlaunch not being started upon reboot by the CX Boot2 3.1 on the CM hardware.
-
Ok, let's focus on what happens on the 1st reboot after sending Nlaunch.tco.
The Boot2 is supposed to start at 60%.
You're getting a freeze without any error message or anything printed in the top left-hand corner of the screen? Please confirm this. It would mean the Boot2 tries to launch Nlaunch, but crash for some reason.
If you press the reset button again, what do you get? The same thing?
Just a little idea: could you retry to install Nlaunch after using the maintenance menu to reformat your filesystem?
On TI-Nspire CX, filesystem starts at NAND page 0x800, but on TI-Nspire CM it does start at NAND page 0x7C0.
-
I confirm this.Nothing displayed but freezed at 60%
I reseted it,the same thing.
I tried all reformat,but the same thing.
-
Ok. I hope someone will have the time to dig into Nlaunch code.
But unfortunately, we're in the middle of the summer, and I got no reply from the Ndless team for now.
You might have to way a little, but please don't throw away your calculator.
There is no reason Nlaunch won't work on the TI-Nspire CM someday.
-
What *might* be possible if you can't wait, would be to recompile Nlaunch by including some NAND-fixing code in preloader.c.
You would nead to:
- read the 16 first NAND pages (each page is 2048-bytes) to a buffer (I've never tried to read/erase/write less than 16 pages at a time)
- modify the model ID from 0x10 to 0x12 in the buffer
- erase the 16 first NAND pages
- flash the 16 first NAND pages with the buffer content
Before trying on your calculator, check that such code works on the emulator in CX mode with CX Boot2 3.1.
Make the program as simple as possible in order to use as few syscalls as possible, as every syscall will have to be (re)defined with CX Boot2 3.1 addresses.
You'll need to find read_NAND, nand_erase_range and write_NAND syscalls addresses in the Boot2.
-
Triple-posting.
I finally got a reply from the Ndless team, which does confirm my main hypothesis.
The current nLaunch(y) CX code needs 64MB RAM in order to work.
The TI-Nspire CM has only 32MB RAM and this will have to be fixed.
The current nLaunch(y) for CX only work with 64mb of RAM.
Some adresses in memory are hard-coded and fall in the over 60 mb of the memory, which does not exists if you only have 32mb. One of these adresses is at the very beginning, before anything gets printed.
-
Ok, so we have to make nLaunch work on the TI-Nspire emulator in CX mode with only 32MB SDRAM.
I think this should do.
CX mode 32MB SDRAM: nspire_emu /MX
CX mode 64MB SDRAM: nspire_emu /MX /R
-
Holy quadrouble post Batman ! *.*
Seriously though, I hope that you guys will be able to fix this. ;)
-
Me too. I hope it's not just plain impossible to support those calcs. The Chinese Nspire userbase seems very large.
-
Yes he used the J04.
Thanks for your explanation critor ;)
Here are two possible ways to solve the problem:
1 Find out a syscall under boot 2 which can modify either manuf or ASIC.
2 Make nLaunch work. (IMHO nLaunch bypasses all the check of manuf and ASIC)
If nLaunch were to work, would the configuration outside of the nLaunch program still be in a 'bricked' state? Hopefully that would at least work as a temporary solution.
-
Judging the latest news, it seems they have made a port of nLaunch to the CM, and unbricked his calculator. However, he managed to brick it even more now; the boot1 refuses to boot. This means that the only solution would be to use JTAG..
-
the further bricking is not due to NLaunch, I hope?
And does NLaunch actually unbrick the calculator or just provide the means to launch the boot files for os?
-
the further bricking is not due to NLaunch, I hope?
The bricking is due to a careless user removing all protections purposefully added in nsNandMgr against dangerous operations, and proceeding anyway (despite prior warnings) on those dangerous operations. End result: one of the very few most interesting Nspire prototype calculators in the world is bricked, and extra special equipment, at significant cost, is needed to (possibly) bring it back to normal state...
I just hope, for the community's sake, that he won't screw up any further by simply putting the calculator to the trash bin, instead of making it possible for others to try and salvage it.
And does NLaunch actually unbrick the calculator or just provide the means to launch the boot files for os?
nLaunch is only the latter. If the calculator were still able to proceed to boot2, the abitrary code execution vulnerability leveraged by nLaunch could be used for other purposes... but the calculator doesn't even proceed to boot2 any longer...
-
There is one chance left.
Being a prototype, it may have the internal boot loader that the OMAP series has. [maybe...????]