Results 1 to 4 of 4

Thread: Complete info in attempting to hack the Tait series of radios

Threaded View

Previous Post Previous Post   Next Post Next Post
  1. #1
    Join Date
    May 07, 2012
    Thanked 2 Times in 2 Posts

    Default Complete info in attempting to hack the Tait series of radios

    So I'm now creating this thread to bring together EVERYTHING I have found out about these radios and their codes over the year that I've been prodding and probing.

    The Hardware:
    At the root of these radios is a rather advanced FPGA. Tait do publish their CPU definition used in the FPGA on their open source web site:

    The CPU core is called a 'Leon' processor core from Gaisler Research. A debugger that understands this type of core may be helpful in stepping through the binary firmware looking for the JMP instructions to the disable subroutine. It will however require a debugger that understands the instruction set of a 'Leon Processor Core'.

    The OS is called eCos and is also available on the same web page.

    Radio bootup:
    The radios boot with all features enabled. The startup routine will then go through and check the installed SFE keys and disable features as required. I believe this would be a single routine that would stand out like dogs balls. Changing the JMP to a NOOP/NUL that points to the disable subroutine would effectively stop this feature from being disabled. The FPP however would still need to get an ODD SEQ number to recognise that the feature is enabled.

    Talking to the radio via RS232:
    I have documented the RS232 protocol used here:

    Available SFE keys:
    I have documented the possible keys here:

    Retrieving SFE keys:
    I have written a perl script that will put the radio in programming mode, then print out the list of SFE keys in the radio in both hex and 'SFE format'. It can be downloaded here:

    SFE Key format:
    The SFE Keys are all in the format: AAAA.AAAA.AAAA.ABBC.CCCC.XX

    The C's are the same between all keys in the radio and enabled or disabled features. As such, I believe these are tied to the hardware. This is further proved by the following info from the Tait manual:

    What is Board Swapping?
    When the internal PCB assembly inside the product is removed and is replaced with another PCB assembly. This repair method is done because the original PCB assembly is deemed irreparable or the customer requires a very quick repair turn around.
    When this method of product repair is used, it is imperative that the CSO is notified of this repair. The following details need to be provided:
    - Radio Chassis Serial Number
    - New board Serial Number (7 digit number on the PCB assembly label)
    The CSO is required to enter this information into the SFE database.
    Further on:
    Why does the SFE database need to be updated when a Board Swap is performed?

    With products such as the TM8000 and TB8000 series, it is becoming more and more apparent that board swapping will soon become the most economical repair for a product. However, along with this comes a need to have better traceability of what board is actually inside the product. The SFE requirement compounds this as the SFE key is partly based on information supplied by the internal serial number of each individual board, not the chassis serial number.
    When a board is swapped, the SFE keys (if features are enabled) will need to be re-generated for the new boards, as the old keys will not function on a new board.
    This means that the serial part of the key is tied to some kind of serial number on the board. Thankfully, we don't really care about this as we can read the keys from the radio and use them in keys we sent TO the radio.

    SFE keys in HEX:
    This is where the magic happens. The actual communication with the radio is done in HEX. The FPP decodes the SFE string and outputs hex to the radio. This is in the format of:

    This translates roughly to:
    X = Authentication code??
    Y = feature code (in HEX!)
    Z = serial number? ESN? Encoded somehow? Is the same across all keys in a radio - enabled or disabled.
    S = Sequence number (0 = disabled, 1 = enabled, 2 = disabled, 3 = enabled etc)
    C = Checksum

    I have written two perl scripts that convert SFE Key format to HEX and back. They can be downloaded here:

    Brute forcing SFE keys:
    I have written a proof of concept brute force perl script that will send attempts to the radio covering the ENTIRE key range. This is impractical to use as there at 2^16 keys and the radio induces a 3-5 second delay between key verification. You'd be well and truely dead, buried and decomposed by the time it covers the entire key space. Then you'd have to do it again for the next SFE key.

    The proof of concept can be found here:

    More info to come over time as I get time to process it all.
    Last edited by CRCinAU; Nov 28, 2013 at 06:54 AM.