What would cracking the nSpire RSA codes do? Aren't they simply used for the Certificate?

Oh, so cracking the code would make custom OS patches viable?

So all you would really need is the private key and the encrypted data, correct (it's been a little while since I've worked with RSA)?

Quote from: Qwerty.55 on October 09, 2010, 06:40:04 pm

Oh, so cracking the code would make custom OS patches viable?

So all you would really need is the private key and the encrypted data, correct (it's been a little while since I've worked with RSA)?

Yup.
The private key will let us resign the modified OS, making any changes possible. PLUS - it would also let us create better OSes (hint: Linux calc distro!!), and install them too.

Linux on-calc ... so it's really possible?

@Deep: ARM processors are fully capable of running Linux.

If all you need to find is the private key (I'm assuming someone's already located the encrypted data), why go to the trouble of number sieving? What you have is a situation any code cracker would dream of where you have access to the device itself. Instead of inefficiently using random numbers, use the bits in the memory itself as the random numbers. When you get a combination that works for the private key, then there's your answer. And since I'm fairly sure the nSpire's emulator can run 84+ ASM, just use an Assembly program to look at the bit level data in the memory. In fact, this is exactly what one of my current projects does.

If you know the approximate location in the memory, then the situation gets even better as you can narrow your search.

EDIT: Yep, you could probably get something like Tiny Core Linux to run on-calc.

FYI, the private key is not stored in the memory of the Nspire AT ALL, nor in the OS.
The public key verifies and decrypts it, that's all. Encrypting uses the private key.
Now, if you were saying that this method could find the private key from the PUBLIC key, then you might have a case.

I think I need to look at RSA again

You're right.

Basically, the ndless devs already decrypted the OS and boot2, which is how they can produce hacks to make ndless itself. But the major hurdle is that we can't write back to the OS, since it's encrypted, and writing anything breaks the signature, causing boot2 to reject it and not load it at all. When you turn off your calculator, the ndless portion is still "loaded" in a way. Now, if you pulled batteries or did a true reset, the jailbreak is gone, and you would need to rerun.

In iPod JB terms, it's a tethered jailbreak, but not as bad as an iPod Touch/iPhone tethered jailbreak, in which any reboot/power off (which happens a lot more than a calc) requires a computer to JB again. (Whereas the Nspire doesn't drain that fast, and can be JB via a TI-84+ )

I still like the "virus" idea, but I wouldn't make it a virus. I'd make it a easy, portable program that can be distributed easily, has a tray icon and simple dialog for progress, and can submit the final factored key to the internet (and spread to every flash drive and such) if it successfully finds it. People can give this to friends, and they can give to others. If we can build a large base with people doing this, the probability of finding the key goes up. It's hard and slow, but it's the best chance we have to knock TI down with a swift knife.

First an 84 jb's a ps3, now (possibly) an NSpire. Nice.  This is looking looking interesting.

Possibly? It's already done! http://www.ticalc.org/archives/files/fileinfo/426/42627.html

Anyway, I need to find that lovely C source and repost about it here.

And you double-posted

I wonder how many computers will be needed to crack the keys

If I understand correctly, there're 1.8×10³⁰⁸ (that's a googol cubed and then some) different combinations, so it's gonna take a while if we were to do it like that