Provided by: rabbitsign_2.1+dmca1-1build1_amd64 
NAME
rabbitsign - sign applications for TI graphing calculators
SYNOPSIS
rabbitsign [ options ] [ -o appfile ] [ -k keyfile ] hexfile ...
rabbitsign [ options ] [ -k keyfile ] -c hexfile ...
DESCRIPTION
rabbitsign is an implementation of Texas Instruments' Rabin and RSA signing algorithms, as
used on the TI-73, TI-83 Plus, TI-84 Plus, TI-89, and TI-92 Plus graphing calculators.
These algorithms are used to sign Flash applications and operating systems so that the
calculator can recognize them as valid.
rabbitsign, like Texas Instruments' official signing programs, needs a private key (a pair
of large prime numbers) to sign apps. In order for the app to be accepted, the
corresponding public key (their product) must be present on the calculator. As of this
writing, the ``shareware'' private key number 0104, used for signing applications for the
TI-83 Plus and TI-84 Plus, is available through TI's SDK. Unfortunately, the OS signing
keys, as well as the app signing keys for the TI-73, TI-89, and TI-92 Plus, have not been
released, which means that only TI can sign apps and OSes for those calculators.
OPTIONS
-a Attempt to match the output of Peter-Martijn Kuipers' appsign program, for testing
purposes. The resulting output file will have Unix-style line termination, and
hence will not be compatible with all programs. This option is not recommended for
ordinary use.
-b Assume input files are raw binary files. If this option is not given, the file
type is detected automatically.
-c Do not sign apps; instead, check that the signatures of the specified apps are
valid. Exit status is 0 if all apps are valid, 1 if one or more apps fail, or 2 if
there is a non-mathematical error.
-f Ignore non-fatal errors, and force the application to be signed if possible. (All
of these messages are there for a reason, though, and chances are that if your app
generates any of them, it will also either fail validation or crash the calculator.
You have been warned.)
-g Write the output file in GraphLink ``TIFL'' format. (By default and for historical
reasons, apps and OSes for the TI-73 and TI-83 Plus are written in plain TI Hex
format instead; you can use packxxk(1) to convert these files into TIFL format.)
Apps and OSes for the TI-89 and TI-92 Plus are always written in TIFL format. See
APPLICATION FILE FORMATS below for more information.
-k keyfile
Read signing and/or validation keys from the given file. This file must be in one
of the formats used by TI's SDK tools. (See KEY FILE FORMATS below.) By default,
rabbitsign searches for the key named in the app header (for example, 0104.key for
``shareware'' TI-83 Plus apps.)
-K id Search for the key with the given id (a small hexadecimal number) rather than the
ID specified in the app header.
-n Attempt to sign the program as-is, without modifying the header. (This option may
not produce a file that the calculator will actually accept; it is intended for
testing and special-purpose signatures, not for ordinary app signing.)
-o outfile
Specify the output file. By default, output files are named by taking the name of
the input file, removing any suffix, and adding a `.app' or `.8xk' suffix depending
on whether -g is specified. (If the input file already has a `.app' or `.8xk'
suffix, `-signed' is inserted, so `myapp.8xk' becomes `myapp-signed.8xk'.)
If `-' is specified as an input file, that indicates the standard input, and the
signed result is written by default to the standard output.
-p Fix the app pages header. This is not done by default because an incorrect pages
header is generally a sign of a much more serious problem.
-P If the application ends close to a page boundary, add an additional page to hold
the signature. (Application signatures on the TI-73 and TI-83 Plus are not allowed
to span a page boundary.) Keep in mind that this is extremely wasteful, as it
consumes 16384 bytes of Flash to hold approximately 69 bytes of data; if your
application is in this situation, you should consider trying to reduce its size
slightly, or alternatively, adding more data to take advantage of the extra Flash
page.
-q Do not print non-fatal warning messages.
-r Re-sign a previously signed app (i.e., discard the previous signature before
signing.)
-R n For signing TI-73 and TI-83 Plus applications, use root number n (0 ≤ n ≤ 3) rather
than the default, root number 0. All four roots are valid, though distinct,
signatures, so this option is mainly for debugging.
Root 0 is computed so as to be congruent to m^[(p+1)/4] modulo p and m^[(q+1)/4]
modulo q. Root 1 is the negation of root 0 modulo p, root 2 the negation modulo q,
and root 3 the negation both modulo p and modulo q.
This option has no effect when signing OSes or TI-89/92 Plus applications, which
use the RSA algorithm rather than Rabin.
-t type
Explicitly specify the type of program (e.g., `8xk' for a TI-83 Plus application,
or `73u' for a TI-73 operating system.) The default behavior is to infer the
program type from the name of the input file. (If the input file does not have a
recognized suffix, the type is guessed based on the contents of the program
header.)
-u Disable automatic page detection, and assume input files are unsorted. This means
that page boundaries must be defined explicitly. (See APPLICATION FILE FORMATS
below.) This option has no effect in binary (-b) mode.
-v Be verbose; print out the names of apps and their signatures as they are signed.
Use -vv for more detailed information about the computation.
--help Print out a summary of options.
--version
Print out version information.
APPLICATION FILE FORMATS
Intel Hex
Intel hex is a standard ASCII file format used by many PROM programmers, and a common
assembler output format. Each line (or ``record'') consists of the following:
:NNAAAATTDDDDDD...CC
: The first character of the line is a colon; this is just used to identify the
format.
NN The next two characters are the number of data bytes on this line, written in
uppercase ASCII hexadecimal.
AAAA The next four digits are the address of the data on this line. rabbitsign only
looks at the low 14 bits of this value.
TT These two digits identify the ``type'' of the record. Intel hex defines several
record types for various addressing models; the only types which are meaningful for
TI calculators are types 00 (ordinary data) and 01 (end of file.)
DD... 2*NN hex digits follow, the actual data.
CC Finally, the inverted checksum is added, so that adding up all the bytes on the
line gives a total of zero modulo 256. (As an extension, rabbitsign permits you to
use two uppercase `X's in place of a checksum.)
Since the address is only 16 bits, this format cannot unambiguously represent applications
larger than 64 kilobytes. To enable multi-page applications to be created, rabbitsign
attempts to detect page boundaries automatically, starting a new page for each field with
a zero address. Thus to create a multi-page app, you can simply concatenate several Intel
Hex files, e.g.
cat page0.hex page1.hex | rabbitsign - -o complete.app
This will only work if the records are correctly sorted within each page. (If the
assembler does not generate records in order, you can sort the fields yourself using a
command such as `sort -k1.8,1.9 -k1.4,1.7'.)
To turn off this automatic page detection, use the -u option. In this case, you must
define page boundaries explicitly using the TI Hex format.
TI Hex
``TI'' hex is an extension to Intel hex which provides unambiguous representation of
multi-page apps. It adds records of the form
:0200000200NNCC
which indicate that subsequent data is placed on relative page number NN. (Keep in mind
that the TI-83 and 84 Plus install applications ``backwards,'' so if relative page 0 is
stored on absolute page 69, relative page 1 will be stored on absolute page 68, and so
forth.)
Some assemblers can generate multi-page data using type 4 records instead of type 2;
rabbitsign treats these as equivalent to type 2.
For compatibility with other software which makes certain assumptions about the format,
rabbitsign will write 32 bytes per line, and will end lines with a DOS-style carriage
return and line feed.
GraphLink TIFL
The standard (newer) GraphLink format consists of a 78-byte binary header which is added
to the start of a hex or binary file. The contents of this header are as follows:
0x00-07
The string `**TIFL**'.
0x08 The major version number (``App ID'') of the application.
0x09 The minor version number (``App Build'') of the application.
0x0A Flags; apparently intended to indicate whether the contents of the file are binary
(0) or TI Hex (1). This value is not, however, set consistently by other software.
0x0B ``Object Type'' field; apparently indicates something about the type of data. Set
to 0x88 in most TI-73 and TI-83 Plus files; set to 0 in TI-89 and TI-92 Plus files.
0x0C-0F
Binary-coded decimal month (one byte), day (one byte), and year (two bytes, big
endian) when the app was signed.
0x10 Length of the app's name.
0x11-18
Name of the app.
0x19-2F
Reserved, always set to zero.
0x30 Calculator type (0x73 = TI-83 Plus, 0x74 = TI-73, 0x88 = TI-92 Plus, 0x98 = TI-89.)
0x31 Type of data (0x23 = OS upgrade, 0x24 = application, 0x25 = certificate.)
0x32-49
Reserved, always set to zero.
0x4A-4D
Little endian length of the following data (the length of the hex file, not the on-
calculator size of the application.)
There also exist multi-part TIFL files, which simply consist of two or more TIFL files
concatentated together. (For instance, a software license agreement or a certificate file
can be attached to an application.) rabbitsign handles these files in a limited way: it
will read only the first section with a recognized data type, ignoring any other data in
the file. rabbitsign cannot create multi-part TIFL files, but they can be created using
packxxk(1) (or simply using cat(1).)
Binary
rabbitsign can also read binary app files; they are assumed to be contiguous, so when
signing a multi-page app, each page except the last must be filled to a full 16k.
KEY FILE FORMATS
Key files contain the data needed for signing and validating applications. (The portion
of the key file used for validating is known as the ``public'' key; the portion used for
signing is the ``private'' key. Only the public key is stored on the calculator itself.)
Official key files from TI come in two varieties, known as ``Rabin'' and ``RSA'' formats.
Note that rabbitsign currently supports using Rabin-type key files to generate RSA
signatures, but not the other way around.
Rabin key format
The Rabin key file format is typically used for TI-73 and TI-83 Plus application signing
keys. It consists of three lines, each containing a big integer. The first line is the
public key, n; the second and third are its two factors, p and q.
Each line begins with two hexadecimal digits, giving the length of the number in bytes,
followed by the bytes themselves, written in hexadecimal in little-endian order.
RSA key format
The RSA key file format is typically used for TI-89 and TI-92 Plus application signing
keys. It consists of three lines: the key ID, the public key n, and the signing exponent
d. (d is the inverse of the validation exponent, 17, modulo ϕ(n), and thus calculating d
is computationally equivalent to factoring n.)
The key ID is a short hexadecimal number, which should match the contents of the 811x
header field. The numbers n and d are written as big integers, as in the Rabin key
format.
FILES
/usr/local/share/rabbitsign/*.key
Private key files which will be used if the requested key is not found in the
current directory.
BUGS
Who needs them?
rabbitsign accepts keys, applications, and even file names which cause TI's programs to
crash or generate invalid signatures.
Some apps which come very close to filling the last page may not be usable with TI-
Connect. This is a bug in TI-Connect. Try TiLP.
rabbitsign does not always generate the same signature as do TI's programs. This is not a
bug; it is simply due to the differences in implementation. There are in fact four valid
signatures for every application hash; all four are accepted by the calculator.
If you encounter a valid app which rabbitsign is unable to sign, or worse, generates an
invalid signature, this is a serious bug, and I would like to know about it.
SEE ALSO
packxxk(1), rskeygen(1)
AUTHOR
Benjamin Moody <floppusmaximus@users.sf.net>