[A83] Re: What is the problem with flash writes (in general)


[Prev][Next][Index][Thread]

[A83] Re: What is the problem with flash writes (in general)




Once and for all:
RSA in a nutshell:

Neccesary Information:
Modulo: (perhaps, it's a different word in english, so forgive me)

you take a fixed set of numbers, say 0 - 5.
if you add 1 to 5, you drop back at 0.
if you add 3 to 4, you get 1
so:
10 mod 5 = 0
11 mod 6 = 5

formula (pseudo-c):

int mod(number,mod_base){
   return frac(number/mod_base) * mod_base;
}
--
phi(M) is a function invented by Euler, no need to elaborate here.
--

Step one:
take 2 relly big prime numpers, P and Q.
(Really big is about 75-100 digits)

P and Q will be the (secret!) core of our keys.

Step two:
N = P*Q

calculate phi(N) through phi(N) = (P-1)*(Q-1)

find a nubmer B, so that the greatest common divisor of B and phi(N) = 1.
B has an inverse called A (mod phi(N)!).

N and B may become public

phi(N), A, P and Q are secret.

Mow decoding works through the secret numbers (actually phi(N) and A).
And encoding through the public numbers (N and B).
(I'm not going to elaborate on this.)

because of joining bytes together before encrypting, 
and most imporantly:
phi(N) is calculated from P and Q, and P and Q can only be 
calculated from N, when you have a few thousend computers and several months of
spare time.

This process can also be reversed, so you encode with the secret numbers
and decode with the public numbers.

SIGNING:
A message or file is being parsed through a Message Digest Algorithm
(generally MD5), which creates an almost unique checksum based on 
the file.

This checksum is encryped with the secret numbers, and added to 
the end of the file. This process is called signing.

The reader(most likely a computer) has the public numers and can decrypt the 
checksum, and compare it with is own MD5 checksum.
if it matches, the reader can be sure there were no changes between the time
of signing and reading, PLUS that the file was approved exclusively by the 
signer, since he's the only one who can encrypt the checksum in that way, 
it can be decrypted by his public numbers.

Thus no third party without the secret (private) key, can sign a file in name of another.

since the calculator has TI's 83Plus public key hard-coded into the boot-rom,
so only TI-approved rom's can be loaded into the calculator. (int uses the abovementioned algorothms.


--(Peter-Martijn)




> > From: "Hyperbyte" <hyper@hysoft-automation.com>
> >
> > > > From: "Hyperbyte" <hyper@hysoft-automation.com>
> > > >
> > > > Simply put, no user-program can do it.
> > > >
> > > > Explanation:
> > > > The flash chip has a "write enabled" line,
> > > > only if this line has specific signal, one can write to the flash
> > > >
> > > > Now one could simply set this signal, if TI hadn't prevented that,
> > > > they've somehow made it only possible for certain OS Rompages to
> > > > set that value.
> > > >
> > > > (I think it's kinda obsolete now, since TI's released the app signing
> key,
> > > > but I doubt they'll insert _FlashWE and _FlashWD romcalls in new
> OS'es)
> > > >
> > > > You could hardware hack that WE line, but then your program wouldn't
> be
> > > distributable...
> > >
> > > Or, you can make your own OS, I mean TI-OS, which implements a routine
> that
> > > enables writing to flash......
> >
> > How are you planning on signing that custom 'TI'-OS?
> >
> > AFAIK, OS'es need to be signed too, and I can't see how TI would be
> > as stupid as to sign it's OS'es with the freeware private key.
> 
> It's all theoreticaly of course, but when you attempt to send an OS to your
> calc, your calc checks if it's a valid OS right? So can't you check that
> code and see how that's done? It's also possible that the graph link
> software checks a few things, but writing your own PC program that sends
> data and doen't check anything shouldn't be that difficult.





References: