Why does it have to be signed? (I've never understood the whole signing thing with apps)

If it is only checked on the recieving end, it might also have to do with checksum validation (to check whether the app made it to the other side unscathed, since that's a lot of bytes to transfer).

TI pretty much gave up on paid apps though

And just a point of clarification for the original question: Remember that code can be executed from any location between $0000 and $BFFF (but not $C000 and beyond, which cause a RAM clear for security purposes). Flash pages are usually switched in to the area between $4000 and $7FFF, so it runs fine. You could even switch it into $8000-$BFFF (instead of the usual RAM page that's there) and it would still run. Pointers would get messed up though, of course.

I'm just curious about what these "security reasons" are that I keep hearing about...

Security, as in keeping programs under 8 KB so no one can release awesome games

I think it's to protect the VAT/stack, but IMO it's really unnecessary.

Quote from: ZippyDee on March 24, 2011, 01:24:23 am

Why does it have to be signed? (I've never understood the whole signing thing with apps)

If they are signed (I have no idea if they are) it would be to control who could make programs.

It has to be signed to make sure it's a "valid" source.  Before, when TI made paid apps, those required a special key.  The free key 0104 was released, and so, we use that to make apps.

Yeesh. So is it possible to sign an app on calc, or does it have to be done on a computer?

It's quite possible to be done on-calc, it would just take forever and ever.  There was a program made to sign axe apps.  It takes like 10 minutes, IIRC.  You're dealing with 256 and 512 bit numbers here, though.

Yeah, I don't see the necessity, either. Is it hardware that does that? I know there is a memory map mode that doesn't do this...

I believe it mostly has to do with how the chip is set up for flash and ram.  In one memory map mode, you have page 0 in 0000-3FFF, some flash page in 4000-7FFF, a ram page (82 I think) in 8000-BFFF, and ram page 0 (81 or 80, I can't remember) in C000-FFFF.

You know, I have a question. Why is it that the filesize of an App on the computer is always several times bigger that what it will actually be on the calc?

Because there's more stuff on the computer than there is on the calc.  There's header stuff for the app and more.  I don't know why it would be several times bigger, though.

not as big as 65536 bit numbers

Quote from: Xeda112358 on March 24, 2011, 12:11:05 pm

Yeah, I don't see the necessity, either. Is it hardware that does that? I know there is a memory map mode that doesn't do this...

I believe it mostly has to do with how the chip is set up for flash and ram.  In one memory map mode, you have page 0 in 0000-3FFF, some flash page in 4000-7FFF, a ram page (82 I think) in 8000-BFFF, and ram page 0 (81 or 80, I can't remember) in C000-FFFF.

Yeah, in the second memory map mode, page 0 is in 0000-3FFF and if page x is in 4000-7FFF, then x+1 is in 8000-BFFF and then whatever other page you load goes into C000-FFFF (at least I believe that is how it works... I haven't experimented with it yet )

Quote from: Compynerd255 on March 24, 2011, 06:31:47 pm

You know, I have a question. Why is it that the filesize of an App on the computer is always several times bigger that what it will actually be on the calc?

Because there's more stuff on the computer than there is on the calc.  There's header stuff for the app and more.  I don't know why it would be several times bigger, though.

It is because the data in the App is stored as hexadecimal instead of bytes, so it should be over twice the size of the actual code. There are about 9 or 10 bytes (I forget) before the actual hex data and then I think there are either 16 or 32 bytes of code following (32 or 64 hex digits).

I don't really even understand how the signing works, so I don't really get what would have to be done to sign an app on calc. Why would anything ever need to use 512 bit numbers except for high decimal precision?

For security reasons.  The object of cracking the the signature is finding the private key from the public key.  I think I do pretty well in documenting it here. Note, TL;DR: Factoring larger integers is exponentially harder.