Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - calcforth

Pages: 1 ... 3 4 [5]
61
Axe / Re: Working with Large Numbers?
« on: November 15, 2010, 12:46:55 pm »
Hmm I would like to know more about how to use that... It might be handy in the future if I ever work with RPGs with numbers that goes beyond the 2 byte range. Is it very large?
You can take a look on Learn TI-83 Plus Assembly In 28 Days. It explains how to do this effeciently in ASM and Axe is a thin wrapper thus the same principle apply. Of course all this will not help the topic starter: addition/subtraction of long integers are trivial, multiplication is harder but division is a bitch to write correctly. What is relatively easy to write is division of long integer by small (less then 16bit) integer - and it's MUCH faster too. Stay away from long divisions if it all possible!

62
Other Calc-Related Projects and Ideas / Re: Nspire OS Risk/Weakness
« on: November 14, 2010, 07:43:29 pm »
Is it just me or is everyone here deaf? I'm not talking about cracking a current key, I'm talking about the possibility of the boot2 and boot1 allowing for other keys than the current one.
Sorry, my fault. Finally wrapped the mind around the question: the answer is so obvious to me that I never imagined that it's not obvious to everyone.

Here is the part I missed:
My point was that the Boot2 has another option for what key it uses than the default. The question lies in what accomplishes this change. It can't be the boot1, since it's read-only, and it can't be the boot2, since it is the boot2 whose actions change.

Sorry to disappoint you but there are probably just one key in boot1 and boot2 loaders (unless someone did huge mistake while building them). And the to change it you indeed must change boot1. And indeed it can only be done on factory which build these things.

The message about "Production Keys" is not for end user - it's for service center. If the Nspire does not say these messages then most probably someone took MB from prototype and put it in regular Nspire: service center is not supposed to repair such devices.

WTF? Who will need all this crap? Well, the hardware is not developed in a day, you know. And original TI-Nspire hardware was different from what you can buy today in stores. Take a look. These prototype devices are sold on ebay from time to time (there are couple of them right now) - and since they require different signature they are sold for cheap: you can not install a production OS on them (different key prevents it and even if you'll manage to overcome this limitation it still will not work because hardware is different). I don't know how boot log looks on these devices, but most likely it does not say "Using Production Keys".

Since this approach is pretty typical in hardware development I was sure it was discussed to death already... but now looking back I see that indeed it was never explicitly explained... at least not in this thread.

As for breaking the key...

So how hard would it actually be? Would it involve doing 2^256 trials, or is there a faster way?
Well, the fastest known way involves 2^253.5 trials which still makes it totally impossible. Better to find some other kind of weakness... perhaps something similar to what Nintendo did (they used strncmp to compare sha1sums so the attack become 2^8 trials, not 2^70+ trials).

63
Other Calc-Related Projects and Ideas / Re: Nspire OS Risk/Weakness
« on: November 13, 2010, 07:19:06 pm »
Since the Boot2 is upgradeable, this means you could change the OS license key, and it appears you don't even need to go that far. The Boot1 is most likely capable (or maybe even some file in the system :D) of forcing the boot2 to use a different key when loading the OS. That means two things:

1. If we discover the RSA key to the OS, TI could change it on us with a boot2 v2.5
2. If we can figure out how to force our own key, we could easily install our own OS!

Thoughts?
Well, the scheme is not unique for TI, it's used everywhere: PSP, Wii, XBox360, some phones, etc. The idea is that "recovery menu" is already non-trivial piece of code and so it's not a good idea to store it in ROM. ROM only contains boot1 which checks RSA signature of boot2 and then jumps to it - nothing else. So yes, if the RSA key of boot1 will not be broken TI can easily make it impossible to change anything by upgrading boot2 (this is what Nintendo does with Wii - not very successfully). The problem here is the fact that brute force will not work: you'll need a lot of power (US$100,000 prize was left unclaimed). There are a lot of research in this area and the general consensus says that we'll have some new clever algorythm capable of cracking 1024 bit key in the next 10 years or so (that's why serious cryptographers recommend to start switching to 2048 bit keys), but it's probably not a good idea to wait for it :)

64
Ndless / Re: Fail.
« on: November 11, 2010, 02:40:26 pm »
Yeah, I wonder why it picked 2004. Maybe it got confused with one of the early version of the site :P
Well, it found lots of different dates on page and needed to determine which one is the correct one. One date in particular was mentioned lots of times: Aug 12th 2004. Five times here, four times here. And it precedes other dates. Obviously it's the date of document creation! Check the pages yourself: the "Aug 12th 2004" is still there - and in many copies, too!

Pages: 1 ... 3 4 [5]