Difference between revisions of "83Plus:OS:Certificate/Headers"

From WikiTI
Jump to: navigation, search
(That was just all kinds of wrong.)
Line 38: Line 38:
  
 
=== App Valid Bitmap ===
 
=== App Valid Bitmap ===
The app valid bitmap is also located starting at 1FE0h. Each app page gets its own bit and the table was supposed to start at bit 6 of 1FE0h and work its way down. However, since TI doesn't know the difference between RRCA and RLCA, the table actually starts at bit 1 of 1FE0h and continues left through bit 7, before it jumps to 1FE1h.  
+
The app valid bitmap is also located starting at 1FE0h. Each app page gets its own bit and the table works its way down.
  
 
To sum it up, on a TI-84+SE:
 
To sum it up, on a TI-84+SE:
Line 52: Line 52:
  
 
The way the system works is that normally, the whole table is full of zeros. But when an app should be deleted, the OS sets its bit. The bit is also set while the app is being transferred so that you cannot pull the batteries during validation.
 
The way the system works is that normally, the whole table is full of zeros. But when an app should be deleted, the OS sets its bit. The bit is also set while the app is being transferred so that you cannot pull the batteries during validation.
 
Since TI didn't write their routine correctly, an astute observer will note that when an app is being received to page 63h, the OS is marked invalid.
 
  
 
=== App Trials Table ===
 
=== App Trials Table ===

Revision as of 15:31, 23 May 2013


Certificate

Each calculator has a certificate which is stored on the certification page. This is page 1E on the 83P, 3E on the 84P regular, and 7E on the 83P SE and 84P SE. The certification page is actually two physical sectors of the flash chip, each 8 KB in size. Only one sector is used for the certificate at a time, and new certificates are loaded into the currently unused sector.

Headers

Every signed calculator variable has a header; this includes both the OS and apps. The header always comes before the variable and tells important information like the size of the variable and also the developer key used to sign it. The reason that the certificate and headers are grouped together is because they are both made up of fields.

Format

Each field has the same general format. They all include the type of field, the size of the field, and usually, data.

The general format is: TT TS [SS] [SS] [SS] [SS] [SS] [DD] [DD] [DD] ... [DD]

Where T is the type, S is the size, D is data, and bracketed bytes are optional.

Type

These 12 bits are where the name of the field originates.

  • Certificate start with a 0, then the group number, and finally the field within that group.
  • OS and app header fields usually start with 80 and their specific type is the final nibble.

Size

The size bits indicate the number of bytes in the data field. The fist nibble can be any number from 0-F but D, E, and F are special case.

  • 0-C - This is the literal size of the data. If the nibble is 5, there are five data bytes following.
  • D - This means that there is a one byte size following.
  • E - This means that there are two size bytes following and the size of the data is stored in big endian.
  • F - F is rarely used. It is always the size byte of the initial field and indicates four size bytes following in big endian. There is really no reason to use F other than starting an OS or an app.

Data

The data for the field is purely data. It's format depends on the field type. All that is really important is that the amount of data is equal to the amount indicated by the size bits.

Fields

The certificate and header and nothing more than several fields nested within each other. Here is a list of the known fields.


Other Areas

OS Valid Flag

The OS valid flag is located at byte 1FE0h in the certificate at bit 7. Reset means the OS is valid.

App Valid Bitmap

The app valid bitmap is also located starting at 1FE0h. Each app page gets its own bit and the table works its way down.

To sum it up, on a TI-84+SE:

  • bit 1, 1FE0h = page 69h
  • bit 2, 1FE0h = page 68h
  • bit 3, 1FE0h = page 67h
  • bit 4, 1FE0h = page 66h
  • bit 5, 1FE0h = page 65h
  • bit 6, 1FE0h = page 64h
  • bit 7, 1FE0h = page 63h
  • bit 0, 1FE1h = page 62h

...

The way the system works is that normally, the whole table is full of zeros. But when an app should be deleted, the OS sets its bit. The bit is also set while the app is being transferred so that you cannot pull the batteries during validation.

App Trials Table

This table is stored at 1F18h on the 83+ and 1E50 on everything else. Each app page gets two bytes in this table. The numbering starts with the last app and continues on from there.

  • 80h 00h - the app is completely free
  • 00h 00h - the app has a time stamp after which it won't work
  • 00h XXh - XX is the number of times you can execute the app

1DEAh

This area is used to store important information during garbage collection.


Certificate / Header bcalls

Some entry points useful for working with certificates:


Calculator ID number

The calculator ID number is organized as follows: PPHSS-SSSSS-VVVV

  • P - product number
  • H - hardware revision
  • S - serial number
  • V - validation code


Product numbers are as follows:

  • 01 - TI-92 Plus
  • 02 - TI-73
  • 03 - TI-89
  • 04 - TI-83 Plus
  • 08 - Voyage 200
  • 09 - TI-89 Titanium
  • 0A - TI-84 Plus
  • 0E - TI-Nspire