|
| 1 | +8Xp Files |
| 2 | +========== |
| 3 | +The 8Xp files are fairly easy to decompile since they're basically only byte-compiled and fairly simple. |
| 4 | +The program works with them by running through and matching up bytes to what they represent in plaintext. |
| 5 | +After that, it cuts 72 bytes off the top of the file, which appears to be metadata and doesn't need |
| 6 | +to be decoded to plaintext (it holds no benefit) and cuts 3 bytes off the bottom of the file. Those |
| 7 | +3 bytes don't appear to hold much importance because the file is still recognized without them. |
| 8 | + |
| 9 | +The metadata is a little bit more interesting and the Internet doesn't hold much information about it. |
| 10 | +The first 9 bytes are the same for every program and declare the type of file. Easy enough, it's: |
| 11 | + |
| 12 | + `**TI83F*[SUB][NEWLINE]` |
| 13 | + |
| 14 | +The next line holds a comment. The TI calculator uses this to datestamp the (creation?) of the file. The comment is |
| 15 | +40 characters (bytes) long, preceded by and ending with a NUL character. Another NUL character follows then a hexadecimal |
| 16 | +value. The hexadecimal value doesn't seem to be extremely important as changing it arbitrarily in my test |
| 17 | +programs doesn't seem to have any effect on their being decompiled (online software doing the decoding since |
| 18 | +it's much pickier than mine). The byte after it however is a little more important and changing it does some weird |
| 19 | +things that I don't understand given my knowledge of the files. It appears to denote something regarding |
| 20 | +the size or length of the code since it stays the same for programs of the same relative size. Given that, the line |
| 21 | +looks something like: |
| 22 | + |
| 23 | + [NUL]40 character comment[NUL][NUL]hex value[NUL or STX looking at my program collection][NEWLINE] |
| 24 | + |
| 25 | +The next and final line is a little more interesting and much more crucial to the file actually being usable. |
| 26 | +It starts with a NUL character, followed by the size of the code (excluding the size of the metadata and footer). |
| 27 | +If this value is invalid it causes some bigger problems, as the decompiler used to confirm results will stop |
| 28 | +interpreting anything past the number of bytes the file claims to be. This is followed by a byte that functions |
| 29 | +as a carry bit. Since the maximum value a single byte can hold is 255, if the size of the program is over 255 bytes |
| 30 | +then the next byte is set. The next section of the line is the name of the program, starting |
| 31 | +with a [ENQ] character. The name is limited to 8 bytes, and therein capital letters. Any unused bytes are filled |
| 32 | +with [NUL] characters. The two bytes after this are [NUL] characters as well which might suggest that the file |
| 33 | +itself could permit longer names although the 8 characters is all that fits on the calculator screen's place |
| 34 | +for it. This is followed by the size again and a carry byte, like the second two characters of the line. |
| 35 | +After this is what appears to be the size - 2, and a carry byte for the size-2. So, put together |
| 36 | +the line ends up looking like this: |
| 37 | + |
| 38 | + [NUL]program size, carry byte[ENQ]prgmname[NUL][NUL]program size, carry byte, prgm size - 2, carry byte |
| 39 | + |
| 40 | +Then the compiled code for the program follows |
0 commit comments