This looks sweet, so we can access that menu, which I never heard of, in other times rather than when booting :)What RSA algorithm? Are you talking about solving the RSA problem? If so, I know of no algorithm to solve it.
It also seems like we're closer from getting the RSA algorithm :)
This looks sweet, so we can access that menu, which I never heard of, in other times rather than when booting :)What RSA algorithm? Are you talking about solving the RSA problem? If so, I know of no algorithm to solve it.
It also seems like we're closer from getting the RSA algorithm :)
It's probably what the (never released) RunOS was using.
And how do you run 2.1 on 2.0.1? O.OSame way I do all these hacks - modified nspire_emu.
And how do you run 2.1 on 2.0.1? O.O
Nice. I wish somehow it was possible to just launch an Ndless program that overwrites the entire OS content and bypass the protections...Overwriting the OS in memory is easy. What do you mean by "bypass the protections"?
Nice. I wish somehow it was possible to just launch an Ndless program that overwrites the entire OS content and bypass the protections...
Trying to load an nspire CAS image on a regular nspire just locked it up(both were OS 2.1). Does it work the other way around?
Trying to load an nspire CAS image on a regular nspire just locked it up(both were OS 2.1). Does it work the other way around?
It depends upon the way you're trying to load the OS.
If you're using the original boot2, of course it's checking the model type and won't load a CAS OS on a basic Nspire.
It could be nice to be able to run significantly different versions, like have 2.x installed for Ndless but run 3.0 for the additional math features (e.g. 3d graphing), but this doesn't work too well because you get mixed-up text that basically makes everything incomprehensible (see below for an example - 2.1 running on a 2.0.1 installation).
It could be nice to be able to run significantly different versions, like have 2.x installed for Ndless but run 3.0 for the additional math features (e.g. 3d graphing), but this doesn't work too well because you get mixed-up text that basically makes everything incomprehensible (see below for an example - 2.1 running on a 2.0.1 installation).
What about patching the filesystem functions of the OS loaded to "chroot" (http://en.wikipedia.org/wiki/Chroot) the OS?
Anyway RunOS was not released to avoid giving TI good reasons (such as being able to run the CAS OS on a non-CAS TI-Nspire) for enabling the downgrade protection. This is really something none of us want.
Anyway RunOS was not released to avoid giving TI good reasons (such as being able to run the CAS OS on a non-CAS TI-Nspire) for enabling the downgrade protection.
Anyway RunOS was not released to avoid giving TI good reasons (such as being able to run the CAS OS on a non-CAS TI-Nspire) for enabling the downgrade protection.
Which they did anyway, starting from OS 2.0.0 on TouchPad models, and from OS 2.1.0 on all models...
If you want to modify the OS, it would be far easier and quicker to just do it in-memory.
Be careful with boot2launcher .
If you launch a developer boot2 on a production OS (or vice versa)it will delete that OS.
It also means that, if you have room, you could launch a 3rd party OS from the regular OS.But why would you want to have to go through this process:
Maybe with a modified boot2, we could also run production OSes on Ndlessed basic & CAS TI-Nspire prototypes.But isn't RunOS launching the OS files directly? without boot2? I think that way would be easier..
I agree. Using ndless directly is much easier.It also means that, if you have room, you could launch a 3rd party OS from the regular OS.But why would you want to have to go through this process:
TI's OS → Ndless → boot2launcher → modified boot2 → your OS (as a .tno file)
when you could just go through this one:
TI's OS → Ndless → your OS (as an Ndless program)
But, you had to get a decrypted OS image first, which is not easy at all for the end user.A Ndless program running on the calculator could perform the Blowfish decryption of the .tnc/.tno downloaded from TI or other sources :)
Why are the boot2 images so large in this video?
http://ti.bank.free.fr/index.php?mod=news&ac=commentaires&id=1026
It looks like they are ~300kb more than what TNOC removes from a standard tno/tnc.
data abort exception, lr=101f9ddcWell make sure to not post any copyrighted stuff like code, that's for sure. I unfortunately do not know about that stuff, though, so whatever you would post, I wouldn't even know what is it. X.x. At least avoid describing completely how to perform things like running a CAS OS on Nspires it isn't supposed to run on, though, so TI won't get mad.Of course I won't post copyrighted material and I can't describe how to run the CAS because I don't know how to do this.
I have decrypted the OS now using a method described on yAronet and modified boot2launcher's source (instead of 0x1180000 0x10000000 + size changed) but it seems that this method would be too easy. The emulator reboots withCode: [Select]data abort exception, lr=101f9ddc
So, is anybody gonna help me or does nobody want to talk about this because they don't want to upset TI?
So this has to be done in asm?
I have never used it. :(
What do you mean by hot reboot code?
This one line of assembly in boot2-/diagslauncher that loads the OS base address into r15/pc?
So would the asm code for fread from boot2 help you?
If someone could manage to write some fopen/fread/fwrite for the TI-Nspire's proprietary filesystem, that would certainly be a huge help to any sort of Linux port.
If someone could manage to write some fopen/fread/fwrite for the TI-Nspire's proprietary filesystem, that would certainly be a huge help to any sort of Linux port.
I'm not sure what you mean by this.
Out of curiosity, has anyone taken a look at the filesystem formats yet?Not yet, but it's on my list.
TI didn't use a standard filesystem like FAT, instead they used a proprietary filesystem called Datalight Reliance. This basically means we have to rely on TI's OS code to do file access (making ports of other OS's, such as Linux, somewhat difficult)
TI didn't use a standard filesystem like FAT, instead they used a proprietary filesystem called Datalight Reliance. This basically means we have to rely on TI's OS code to do file access (making ports of other OS's, such as Linux, somewhat difficult)
Out of curiosity, has anyone taken a look at the filesystem formats yet?I looked into it a little bit a while back.
The best thing would be to have an image with the linux rootfs, and just point the kernel to the raw location of the file on the nand. This way you would not need to know how the filesystem works.The problem with this is the filesystem won't keep your image file contiguous.
Sorry if this a stupid question. But couldn't we just reformat a section of the flash memory(or whatever the correct term is)?The vast majority of the flash memory is used by the filesystem. If you reformat part of that, you'll screw up the filesystem, and boot2 will just reformat it back.
I suppose in theory if you could replace the flash chip with a larger one, then you could use the space beyond the filesystem (current boot2's and OSes have hard-coded the filesystem area to end at 32MB, although this may change when OS 3.0 comes out because the CX will have a 128MB flash chip). I don't think there are many of us who could do that, though :p
Wild ideas, probably unworkable (though nobody has yet explained why to me):Does this subroutine load a TNO/C into RAM without installing it? O.O
* fiddling with the boot2's load_os_image and subroutines, in such a way as to make the boot2 load a TNS file containing the raw TNO/TNC for the same or the other calculator model. For example, proceeding forward no matter what the result of checks performed by some subroutines is. However, judging by the RunOS video, that's not what it did - but it looks like that in order to replicate RunOS perfectly, the tricks would have to be independently rediscovered...
* using launch_os_image after loading the OS image at 10000000 (in such a way as not to trigger the errors mentioned by critorI haven't gotten this far yet.
- perhaps by using the boot2 stdio/POSIX file functions ?).I was also thinking about this, I'm not sure if you could call the function in C though.
http://www.vimeo.com/21776371 :PNow add another intermediate step - patch Ndless hooks into it before launching :)
Indeed, it's so far beyond the state of the art. TF could yield something, but with hopelessly remote chances of success.
However, don't forget that we do have arbitrary code execution on OS 1.1 to 2.1, which enables launching other OS without installing them ("RunOS") :)
Correct me if I'm wrong, but I think that the size of the RSA signature doesn't make that you can't bypass it...Completely correct. It's not any less possible for us to crack 2048-bit then it is for us to crack 1024-bit RSA. It's more likely to rain frogs then it is for us to factor even the 1024-bit RSA keys. That's the beauty of RunOS/OSLauncher, it bypasses RSA completely.(well, except for installing and then rebooting)
Bypassing the RSA signature makes that you don't need the RSA signature to run code.
(I hope I'm not making a fool from myself)