RFID chips [LTO-CM] in LTO Ultrium 5 tapes

Xer0fire · 2015-10-31 00:09:27

Does anyone know if the proxmark can read these chips

This is what tag looks like, if that helps any:
http://upload.wikimedia.org/wikipedia/commons/f/f1/LTO-CM_top.jpg

Wikipedia:
https://en.wikipedia.org/wiki/Linear_Tape-Open

LTO cartridge memory
Every LTO cartridge has a cartridge memory chip inside it. It is made up of 256 (128 on LTO-1, 2 and 3) blocks of memory, where each block is 32 bytes for a total of 8 KB (4 KB on LTO-1, 2 and 3). This memory can be read or written, one block at a time, via a non-contacting passive 13.56 MHz RF interface. This memory is used to identify tapes, to help drives discriminate between different generations of the technology, and to store tape-use information.

marshmellow · 2015-10-31 23:19:37

If it is 13.56 MHz then the pm3 should at least be able to sniff the traffic between the reader and tag. Then with a bit of work and programming it might be able to do more.

Kevin · 2019-12-15 00:59:13

Left this message for posterity.

I attempted to read LTO-CM chip with Proxmark3 RDV4 Kit, however, it does not work.

I disassembled LTO-7 cartridge, took the tag from the cartridge shell and put the tag onto my device.
Since it sure is 13.56 MHz, I sent "HF search" command from pm3 terminal.
The result was "no known/supported 13.56 MHz tags found".
I have not tried "sniff" command yet because I have no reader.

FYI, I also found LTO CM electrical interface here.

Since I am a very beginner of Proxmark3, please leave a comment if there is anything that I can do further.

iceman · 2019-12-15 08:14:48

That is a excellent document.
Annex D has tag memory definitions. From page 95
Annex F has communication intefece. From page 119

The Operating Field characteristics as measured at the LTO CM antenna shall be 
− Frequency (fc)    13 560 kHz ± 7 kHz 
− Minimum field (Hmin)    5 A/m 
− Maximum field (Hmax)   15 A/m 
The LTO CM reader shall not generate a field higher than 25 A/m.

RD -> TAG: Modified Miller Encoding (Amplitude modulation)
TAG -> RD: Manchester / Manchester Biphase Encoding (Load modulation)

F.4 Communication from LTO CM reader to LTO CM 
− The LTO CM reader shall communicate to the LTO CM by amplitude modulating the Operating Field as  described  below. 
 The  bit  coding  for  commands  and  data  sent  from  the  LTO CM  reader  to  the LTO CM shall be Modified Miller encoding. 
 The bit period shall be 128 cycles of the Operating Field.

F.5 Communication from LTO CM to LTO CM reader  
- The LTO CM shall communicate to the LTO CM reader by load modulating the Operating Field with a subcarrier as described below. 
 The bit coding for commands and data  sent  from  the  LTO CM  to  the LTO CM reader shall be Manchester encoding of the subcarrier. 

The subcarrier frequency and the LTO CM to LTO CM reader bit period shall be 
  Subcarrier frequency: fc/16 Bit period:   128 cycles of the Operating Field

Two test commands  (7-bit)
 0x0E  
 0x6C

Some Commands defined:

 - 0x45  Request Standard,  (7-bit)
 - 0x4A Request All  (7-bit)
 - 0x93 Request Serial Number  (Select)
 - 0x    Read Serial Number
 - 0x4n  Read word
 - 0x30  Read block
 - 0x80  Read block continue
 - 0xBn  Write word
 - 0xA0  Write block
 - 0x50  Halt

It looks like this system is based upon ISO14443A.

16-bit CRC used:

generator polynomial

G(x) = x16 + x12 + x5 + 1

So maybe you should try some these commands with the 14a raw command in Proxmark client.

This should wake up the tag and get some kind of response. See page 132 in the document you linked.

hf 14a raw -b 7 45

Kevin · 2019-12-16 22:48:55

Thank you so much for your suggestion, iceman and I actually nailed it.

Reference.

Request Standard

[usb] pm3 --> hf 14a raw -p -a -b 7 45
received 2 bytes
00 03

Firstly, I sent Request Standard command. The returned values: 00 03 indicate type information of LTO-CM. See page 132. A state of the tag is changed from "INIT" to "PRESELECT" after the completion of the command. See page 128. Now the tag is prepared for transmitting its serial number information.

Request Serial Number

[usb] pm3 --> hf 14a raw -p 93 20
received 5 bytes
(AA) (BB) (CC) (DD) (EE)

5 bytes of serial number were received. Note that (AA),(BB),(CC), (DD) and (EE) are not the actual received hexs. The state of the tag remains the same - "PRESELECT". See page 129.

Select

[usb] pm3 --> hf 14a raw -c -p 93 70 (AA) (BB) (CC) (DD) (EE)
received 1 bytes
0A

Then, I sent Select command so that LTO CM can enter COMMAND state. The Select command starts from "93 70" and then received serial number at the previous step. Receiving 0A means that the tag successfully entered COMMAND state. Now the tag is ready to transmit data block to client.

Read Block

[usb] pm3 --> hf 14a raw -c -p 30 00
received 18 bytes
48 xx xx xx xx xx xx xx xx xx xx xx xx xx xx 00 A6 30

Read Block command allowed me to read D0 to D15 from specified block address. The command starts from 30 and then block address to be read (Block Address 0 in this case). The last two hexs (A6 and 30) are CRCs. See page 134. The remaining data from Block Address 0 should be read via Read Block Continue command.

Read Block Continue

[usb] pm3 --> hf 14a raw -p 80
received 18 bytes
4E xx xx xx xx xx xx xx xx xx xx xx xx xx xx 35 6E 3D

The Read Block Continue command allowed me to read data from D16 to D31. Again, the last two hexs (6E and 3D) are CRCs.

Maybe I should write some scripts to read whole data blocks... Note that these commands worked with LTO-7 cartridge. You do not need to take the tag from the cartridge - just put the cartridge onto the reader as it is.

iceman · 2019-12-17 06:39:20

Now that was interesting.

You should definitly create some lua scripts. If you have access to more tags, its possible to add native commands in the client.

Kevin · 2019-12-17 22:21:07

Here is a very preliminary script for LTO-CM. I know that it still needs a lot of works before it is safe to drive, however, I could confirm that it worked with LTO-4, LTO-5, LTO-6 and LTO-7 cartridges at least. This code also has a limitation. It can read data from block address of 00h to FEh. This is equal to 32byte/block * 255block = 8160byte in total. Since LTO-6, 7 and 8 has 16kB, a half of the contents can not be read by this script.

lto-cm.lua

local cmds = require('commands')
local lib14a = require('read14a')

local function oops(err)
    print('ERROR:', err)
    core.clearCommandBuffer()
    return nil, err
end

function sendRaw(rawdata, options)
    --print('>> ', rawdata)

    local flags = lib14a.ISO14A_COMMAND.ISO14A_NO_DISCONNECT + lib14a.ISO14A_COMMAND.ISO14A_RAW

    if options.topaz_mode then
        flags = flags + lib14a.ISO14A_COMMAND.ISO14A_TOPAZMODE
    end
    if options.append_crc then
        flags = flags + lib14a.ISO14A_COMMAND.ISO14A_APPEND_CRC
    end

    local command = Command:newMIX{cmd = cmds.CMD_HF_ISO14443A_READER,
                                arg1 = flags, -- Send raw
                                -- arg2 contains the length, which is half the length
                                -- of the ASCII-string rawdata
                                arg2 = string.len(rawdata)/2,
                                data = rawdata}
    return  command:sendMIX(options.ignore_response)
end

function showdata(usbpacket)
    local cmd_response = Command.parse(usbpacket)
    local len = tonumber(cmd_response.arg1) *2
    --print("data length:",len)
    local data = string.sub(tostring(cmd_response.data), 0, len);
    --print("<< ",data)
    return  data
end

function main(args)
    core.console("hf 14a raw -a -p -b 7 45")

    local payload = "9320"
    res, err = sendRaw(payload,{ignore_response = false, topaz_mode = false, append_crc = false})

    if err then
        lib14a.disconnect()
        return oops(err)
    end

    local serial_number = showdata(res)

    local cmd_select = string.format("hf 14a raw -c -p 9370%s", serial_number)
    core.console(cmd_select)

    for i = 0, 254 do
      local cmd_rd_blk = string.format("hf 14a raw -c -p 30 %02x", i)
      core.console(cmd_rd_blk)
      core.console("hf 14a raw -p 80")
    end

    core.console("hf 14a raw -r")

end

main(args)

iceman · 2019-12-18 06:16:21

a nice start. Look at the previous scripts and add the helptext?
lto_dump.lua ?
and make a PR

iceman · 2019-12-18 17:23:34

I did some rework on your script and added it to the repo. How about you test it out and see if you can get it to work
https://github.com/RfidResearchGroup/pr … o_dump.lua

Kevin · 2019-12-18 23:34:51

Thank you, iceman. I got the code in my repository. I will play with this for a week and report its result here. I may perform git push if necessary.

Kevin · 2019-12-19 20:38:42

I tried the script and it seemed like the following part in main() was something wrong:

-- Wakeup
    local payload = "45"
    local res, err = send(payload,{ignore_response = false, append_crc = false, bits7 = true})
    if err then return end

"res" shall return LTO-CM type (e.g., 00 03), but it was empty.

I substituted the following code for these. It worked and returned LTO-CM type without any issues.

core.console("hf 14a raw -a -p -b 7 45")

Note that I got the following flags after "send(payload,{ignore_response = false, append_crc = false, bits7 = true}".

flags:  0000000a
bit 7:  0007000a

Any information would be highly appreciated.

iceman · 2019-12-19 20:58:03

Don't worry. There is some bugs still.
I will push some fixes. you on signal or keybase? easier to chat.

Kevin · 2020-01-23 21:12:37

Now that LTO read block is supported, I have just started working on write block.
With 'hf 14a raw' command, it works fine so far.
Just wanted to share my preliminary result for future reference.

Note: Need to enter COMMAND state by select beforehand.

Write Block

[usb] pm3 --> hf 14a raw -c -p A0 80
received 1 bytes
0A

"A0" is a write block command and "80" is the block address to write. If "0A" is returned, LTO-CM accepts the first 8 data words and store them in a temporary location.

[usb] pm3 --> hf 14a raw -c -p 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16
received 1 bytes
0A

Then send 16-byte of data (01 02 .. 16 in this case) to be written. Again, returned "0A" means a success and LTO-CM is now ready to accept the next 8 data words.

[usb] pm3 --> hf 14a raw -c -p 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32
received 1 bytes
0A

Then send the next 16-byte of data to be written.

If you need to verify, issue read block command:

[usb] pm3 --> hf 14a raw -c -p 30 80
received 18 bytes
01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 0D 6F

[usb] pm3 --> hf 14a raw -p 80
received 18 bytes
17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 73 58

That's about it for write block. Working on C code and maybe issue pull request later some time.

iceman · 2020-01-24 18:07:21

Well done!

The document has a whole heap of configuration data about the tag and what was on it.
That should also be added to hf lto info

iceman · 2020-06-30 18:52:05

How to extract detailed information from a dump file. https://github.com/Kevin-Nakamoto/LTO-C … nalyzer.sh

Should be implemented in the client

0xDEADBEEF · 2024-04-17 21:51:45

Ultrium tapes (seems from LTO6 onwards) have more than 8k of data in the CM. The command to read/write the data from the ECMA standard allows only for reading up to 8k. LTO9 for instance advertises 32k in the block 0 of the tapes.

I saw that there is some commented code in the iceman fork:
/*
static int lto_rdbl_ext(uint16_t blk, uint8_t *block_response, uint8_t *block_cnt_response, bool verbose) {

if (blk && 0x) {
blk &= 0xFE;
}

uint16_t resp_len = 18;
uint8_t rdbl_ext_cmd[] = {0x21 , blk & 0xFF, (blk >> 8) & 0xFF};
uint8_t rdbl_cnt_cmd[] = {0x80};
...

If this is valid it would allow reading all of the 32k in LTO9 since now the block address is 16bit.
Is this command valid? {0x21,...} Does anyone know also the write equivalent with 16bit addressing? I have access to LTO9 tapes and I can test this out. If someone has the newer specs I could also implement the new commands test them and make a pull request..

iceman · 2024-04-17 22:10:51

Great questions,
and I have no answer. try it out if you have those tags available?

0xDEADBEEF · 2024-04-17 22:13:44

Ok, wiill do tomorrow and report results

0xDEADBEEF · 2024-04-18 07:23:19

I can confirm that the command 0x21 works:

Reading the block number 256:
[usb] pm3 --> hf 14a raw -c -k 21 00 01
[+] received 18 bytes
[+] 00 00 00 00 FF FF FF FF 00 00 00 00 00 00 00 00 [ 91 4A ]
[usb] pm3 --> hf 14a raw -k 80
[+] received 18 bytes
[+] 00 00 00 00 00 00 00 00 00 00 00 00 6C 50 EE E3 [ 18 62 ]

Reading block 0 with the "extended read" command:
[usb] pm3 --> hf 14a raw -c -k 21 00 00
[+] received 18 bytes
[+] 54 B6 13 40 B1 20 00 04 00 00 05 03 00 00 00 00 [ 1B C9 ]
[usb] pm3 --> hf 14a raw -k 80
[+] received 18 bytes
[+] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 37 49 ]

Confirming that that reading block 0 is the same when reading with the "normal" read command:
[usb] pm3 --> hf 14a raw -c -k 30 00
[+] received 18 bytes
[+] 54 B6 13 40 B1 20 00 04 00 00 05 03 00 00 00 00 [ 1B C9 ]
[usb] pm3 --> hf 14a raw -k 80
[+] received 18 bytes
[+] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 37 49 ]

Now I just need the "extended write" command
Does the person who wrote the commented out code with the "extended read" command know that?

0xDEADBEEF · 2024-04-19 12:35:40

Since commands are identified by 1 byte, I have bruteforced the "extended write" command which allows 16bit addressing, by simply sending all values from from 0x00 to 0xff as the first byte, followed by a known two byte address that can be written.

The command identifier byte is 0x2b with the block address in little endian order (same as "extended read")

[usb] pm3 --> hf 14a raw -c -k 2b fa 00
[+] 0A
[usb] pm3 --> hf 14a raw -c -k 01 00 00 00 FF FF FF FF 00 00 00 00 00 00 00 00
[+] 0A
[usb] pm3 --> hf 14a raw -c -k -t 2000 02 00 00 00 00 00 00 00 00 00 00 00 6C 50 EE E3
[+] 0A

Notice that the default timeout is too short after the second 16 byte batch. Looks like that the LTO-CM tag needs more time to actually perform the write.

Reading back the block confirms that the write actually happened:

[usb] pm3 --> hf lto rdbl --first 250 --last 250
[+] BLK 250: 01000000FFFFFFFF00000000000000000200000000000000000000006C50EEE3

I'll update the client code and make a pull request when I am happy with my implementation

Last edited by 0xDEADBEEF (2024-04-19 12:44:54)

Proxmark3 community

Announcement

#1 2015-10-31 00:09:27

RFID chips [LTO-CM] in LTO Ultrium 5 tapes

#2 2015-10-31 23:19:37

Re: RFID chips [LTO-CM] in LTO Ultrium 5 tapes

#3 2019-12-15 00:59:13

Re: RFID chips [LTO-CM] in LTO Ultrium 5 tapes

#4 2019-12-15 08:14:48

Re: RFID chips [LTO-CM] in LTO Ultrium 5 tapes

#5 2019-12-16 22:48:55

Re: RFID chips [LTO-CM] in LTO Ultrium 5 tapes

#6 2019-12-17 06:39:20

Re: RFID chips [LTO-CM] in LTO Ultrium 5 tapes

#7 2019-12-17 22:21:07

Re: RFID chips [LTO-CM] in LTO Ultrium 5 tapes

#8 2019-12-18 06:16:21

Re: RFID chips [LTO-CM] in LTO Ultrium 5 tapes

#9 2019-12-18 17:23:34

Re: RFID chips [LTO-CM] in LTO Ultrium 5 tapes

#10 2019-12-18 23:34:51

Re: RFID chips [LTO-CM] in LTO Ultrium 5 tapes

#11 2019-12-19 20:38:42

Re: RFID chips [LTO-CM] in LTO Ultrium 5 tapes

#12 2019-12-19 20:58:03

Re: RFID chips [LTO-CM] in LTO Ultrium 5 tapes

#13 2020-01-23 21:12:37

Re: RFID chips [LTO-CM] in LTO Ultrium 5 tapes

#14 2020-01-24 18:07:21

Re: RFID chips [LTO-CM] in LTO Ultrium 5 tapes

#15 2020-06-30 18:52:05

Re: RFID chips [LTO-CM] in LTO Ultrium 5 tapes

#16 2024-04-17 21:51:45

Re: RFID chips [LTO-CM] in LTO Ultrium 5 tapes

#17 2024-04-17 22:10:51

Re: RFID chips [LTO-CM] in LTO Ultrium 5 tapes

#18 2024-04-17 22:13:44

Re: RFID chips [LTO-CM] in LTO Ultrium 5 tapes

#19 2024-04-18 07:23:19

Re: RFID chips [LTO-CM] in LTO Ultrium 5 tapes

#20 2024-04-19 12:35:40

Re: RFID chips [LTO-CM] in LTO Ultrium 5 tapes

Board footer