Skip to content

RF430TAL152H

Travis Goodspeed edited this page Nov 12, 2019 · 2 revisions

The RF430TAL152H from Texas Instruments is a confidential part, which is not documented publicly by the manufacturer and is likely only sold for use in one product.

Its memory map and pinout are identical to the publicly documented RF430FRL152H chip. The ROM is related, but quite different, and FRAM applications written for one chip will require porting before they can run on the other.

See The Inner Guts of a Connected Glucose Sensor from BlackAlps 2019, presented by Axelle Apvrille and Travis Goodspeed, for more information on the medical sensor.

Commands

A number of vendor command extensions are enabled by a table in FRAM, with some of them being implemented in FRAM and others in ROM. But as the entire table is in FRAM, and none of these commands are enabled in the ROM by default, these commands might change between firmware versions and cannot be expected to be fixed.

A0 initializes the sensor and begins a one-hour countdown before the data is valid. It requires a password, which was been replaced here with deadbeef.

Sent 02a007deadbeef
Got  00dc000300

A1 returns some identifying bytes about the tag.

Sent 02a107
Got  00df0000080000

A2 locks all the blocks. It requires the vendor number and password.

A3 is a raw read command that allows memory to be extracted from the tag. Like A1, it requires a 32-bit password. This is how to read six 16-bit words from 0xFFF0.

Sent 02a307deadbeefF0FF06
Got  00...

A4 unlocks all blocks. It requires the vendor number and password.

There is also an E series of commands, which were formerly exposed to users but are now disabled at the factory. In the 2019 version of the FRAM firmware, you can restore them by overwriting the AB AB at 0xFFB8 with E0 00, so that the table of additional functions does not end but instead continues with three more entries. Be sure to unlock it first.

E0 seems to reset the tag, but this alone isn't enough to restore a failed tag.

E1 is not yet understood.

E2 is not yet understood.

JTAG

JTAG isn't directly supported in libmsp430.so and must be manually added to the CHIP ID database. Its ver_id is 81 e6 and other parameters are expected to be the same as the FRL152.

We are not yet sure how this device locks. The value at FFD0 would imply that our samples are not locked if the FRL152 convention were followed, but no JTAG ID is presented. This might be caused by a difference in wiring, a difference in locking, or physical damage.

ROM

The mask ROM of the TAL152 is quite different from the FRL152, but one probably forked off from the other at some point in history. We hope to document it when time allows.

Patch Table

Like the FRL152, the TAL152 supports a table of patches to add new ISO 15693 commands or perhaps to patch the ROM pointer table that is loaded to the beginning of SRAM. The table begins at FFCE and grows downward to lower addresses, first with a little endian command name (a0 00 for the A0 vendor command) and then a function handler address. Unlike the FRL152, the TAL152 uses ABAB as its key word, both starting and ending the table.

Here is a sample patch table from a TAL152, featuring overloaded commands for A0, A1, A2, A3, and A4. Note that only the A1 (status) and A3 (raw_read) handlers are in FRAM, and that the handlers for the other three commands are in mask ROM.

ffb8   ab ab         dw         ABABh       End of Table
ffba   2c 5a         addr       DAT_5a2c
ffbc   a4 00         dw         A4h
ffbe   ca fb         addr       fram_a3
ffc0   a3 00         dw         A3h
ffc2   56 5a         addr       DAT_5a56
ffc4   a2 00         dw         A2h
ffc6   ba f9         addr       fram_a1
ffc8   a1 00         dw         A1h
ffca   24 57         addr       DAT_5724
ffcc   a0 00         dw         A0h
ffce   ab ab         dw         ABABh       Start of Table

Patch Handlers

Patch handlers are much like the FRL152, except that on this chip the handler is responsible for checking the vendor number, where the FRL152 checks for the vendor number in the dispatch function before calling out to the handler.

Quoting again from a TAL152 FRAM dump, the comparison instruction at f9bc exists to check the vendor ID (0x07 Texas Instruments) in the command input. On an FRL152, there would be no such test in FRAM, as the comparison would have already been performed in ROM.

f9ba   21 83           DECD.W     SP
f9bc   f2 90           CMP.B      #0x7,&RF13MRXF
       07 00 06 08
f9c2   02 24           JEQ        LAB_f9c8
f9c4   0c 43           MOV.W      #0,R12
f9c6   17 3c           JMP        LAB_f9f6
Clone this wiki locally