Results 1 to 4 of 4

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

  1. #1
    Join Date
    May 07, 2012
    Posts
    78
    Thanks
    4
    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:
    http://www.taitradio.com/opensource/..._tmab2x_tpab1x

    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:
    https://www.crc.id.au/apco25/rs232.html

    Available SFE keys:
    I have documented the possible keys here:
    https://www.crc.id.au/apco25/sfe.html#3

    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:
    https://www.crc.id.au/apco25/get_keys

    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:
    f00XXXXXXXXXXXXXXXXYYZZZZZZZSS0CC

    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:
    https://www.crc.id.au/apco25/key_to_hex
    https://www.crc.id.au/apco25/hex_to_key

    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:
    https://www.crc.id.au/apco25/force

    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.


  2. #2
    PRC148 No Longer Registered

    Default

    like dog balls he says

  3. #3
    Join Date
    May 07, 2012
    Posts
    78
    Thanks
    4
    Thanked 2 Times in 2 Posts

    Default

    Firmware:
    The firmware is supplied in two versions. Crypto_Capable and Crypto_Denied. The latest (that I know of) for the TM9154 is v7.79.22. It can be downloaded here:
    https://www.crc.id.au/files/TM9154_F...to_Capable.zip

    The firmware consists of 3 x SREC files. SREC is defined here:
    http://en.wikipedia.org/wiki/SREC_%28file_format%29

    The three files are:
    QMA3F_A00_7.79.22.0001.Srec -- Radio firmware
    QCA4F_A00_7.79.22.0001.Srec -- Head firmware
    QMA3A_A00_7.79.22.0001.Srec -- Control Mic firmware?

    The firmware can be loaded into the radio via the FPP.

    Obtaining a binary firmware:
    The srecord project can convert srec files to binary. It is available for EL/Fedora in the epel repository.

    The conversion command is:
    srec_cat inputfile -Data_Only -Output -Binary > outputfile

    example:
    Code:
    $ srec_cat QMA3F_A00_7.79.22.0001.Srec -Data_Only -Output -Binary > QMA3F_A00_7.79.22.0001.Srec.bin
    $ srec_cat QMA3A_A00_7.79.22.0001.Srec -Data_Only -Output -Binary > QMA3A_A00_7.79.22.0001.Srec.bin
    $ srec_cat QCA4F_A00_7.79.22.0001.Srec -Data_Only -Output -Binary > QCA4F_A00_7.79.22.0001.Srec.bin
    I am not 100% certain that this binary file is complete and in the correct format, but things 'seem' to be right.

    Running the linux program 'strings' on the binary firmware (after conversion) seems to indicate that a lot of debug strings are still available in the binary. This includes some clues as to the SFE source code locations - such as:

    Code:
    $ strings QMA3F_A00_7.79.22.0001.Srec.bin | grep -i sfe
    SFE NOT VALID
    SFE1
    SFE2
    SFE3
    SFE4
    SFE5
    SFE6
    SFE7
    SFE8
    SFE20
    SFE21
    SFE22
    SFE23
    SFE24
    SFE25
    SFE26
    SFE27
    SFE28
    SFE29
    SFE30
    SFE31
    SFE32
    SFE33
    SFE34
    SFE35
    SFE36
    SFE37
    SFE38
    SFE39
    SFE40
    SFE41
    SFE42
    SFE43
    TaitTerm_Application/Torso/src/Personality/src/ConventionalMode/src/pscvcp/src/pscvcp_OutgoingTransfer.c
    TaitTerm_DataServices/Torso/FeatureEnabler/private/syften_Sfe.c
    TaitTerm_Application/Common/src/SerialInterface/src/sicmdt/src/sicmdt_DataTransferLayer.c
    This also seems to indicate the SFE codes possible in the radio. Some of these correspond with the Decimal code for SFE keys - but some are unknown.

  4. #4
    Join Date
    Jul 13, 2014
    Posts
    12
    Thanks
    24
    Thanked 6 Times in 3 Posts

    Default

    hows this project going any more updates?