Reading LTO-CM tape RFID

Support
21

The LTO-CM tag holds a large amount of metadata about the cartridge itself, used by the tape drive (via an internal reader). Tape generation (LTO 7 in his case), model of tape, capacity, current usage, etc. are all stored on the cartridge memory. If that tag wasn’t working, it would definitely cause issues with the drive trying to read it.

Here’s an example dump (with blank data) of everything stored on an LTO-CM tag, after being ran through an analyzer (not sure what markup stuff is happening to make it occasionally red, but whatever):

Data dump

– LTO CM Manufacturer’s Information –
LTO CM Serial Number: xxxxxxxx
CM Serial Number Check Byte: xx
CM Size: xx
Type: xxxx
Manufacturer’s Information: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
– LTO CM Write-Inhibit –
Last Write-Inhibited Block Number: xx
Block 1 Protection Flag: xx
Reserved: xxxx
– Cartridge Manufacturer’s Information –
Page Id: xxxx
Page Length: xxxx
Cartridge Manufacturer: xxxxxx
Serial Number: xxxxxxxx
Cartridge Type: xxxx
Date of Manufacture: xxxxxxxx
Tape Length: xxxx
Tape Thickness: xxxx
Empty Reel Inertia: xxxx
Hub Radius: xxxx
Full Reel Pack Radius: xxxx
Maximum Media Speed: xxxx
License Code: xxxxxxxx
Cartridge Manufacturer’s Use: xxxxxxxxxxxxxxxxxxxxxxxx
CRC: xxxxxxxx
– Media Manufacturer’s Information –
Page Id: xxxx
Page Length: xxxx
Servowriter Manufacturer: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Reserved: xxxxxxxxxxxxxxxx
CRC: xxxxxxxx

1 Like
22

It turns red between r’ and r’ for whatever reason.

Eta: It seems to be the single quotes within the code snippet now. There is definitely a pattern to it, but I don’t know the cause…

2 Likes
23

Thats really interesting we must be talking about completely different things then i will stay quiet :shushing_face:

24

Yeah, I tried to edit it to remove the r’ by adding spaces between them. That removed the majority of the red, but not all of it. In the remaining sections, even deleting random characters didn’t seem to help.

25

Just delete these

Screenshot_20210411-212821_Chrome
Screenshot_20210411-212821_Chrome1079×617 106 KB

1 Like
26

I had considered doing that, but didn’t want a giant block of data. I went ahead and deleted those and put it under a spoiler block. Good enough.

2 Likes
27

Thanks. I did watch that vid.

I’ve taken the rfid out of a couple of working LTO tapes and actually placed them on the reader, with different orientations. Nada. So proximity is not the issue.

I’ve written to ACS’ technical support to ask if they’ve changed their ACR122U readers in some way.

28

No, no reaction from the reader whatsoever.

29

Yeah, the LTO specification was designed with a lot of “security” measures built in, which means if the drive detects any discrepancy between the tape and the LTO-CM it will refuse to read the tape.

For example, each tape has a unique serial number, encoded onto the tape media itself. If this doesn’t match the data in the LTO-CM, the drive will refuse even low-level commands to read the tape.

30

OK, this is interesting; I’d assumed nfc-list and pcsc_scan were just pulling the data off the RFID raw rather than attempting to “understand” it… like the difference between using dd in linux to pull data off a hard drive, rather than mount it as a file system.

If this is the case - do you know of a straightforward way to pull the data off the rfid on a byte-by-byte basis? Do nfc drivers create a /dev device that can be read raw?

I suppose I could delve into the SDK and try writing my own utilities in C but I was really hoping not to have to spend hours burrowing down that rabbit hole :slight_smile:

31

Here is the Veritas thread I was reading… There aren’t a lot of details in there to be honest but the discussion is interesting.

32

“nfc-ltocm” and “Proxmark3” are just pulling raw binary data from the chip. To make this file human-readable, you can use the software below, or you can use your owns.

33

Thanks Kevin. I know you have used an ACR122UA9 to read an LTO-CM with nfc-ltocm; but would you mind telling me whether nfc-list will even “register” an LTO-CM via your ACR122UA9?

Also… if you wanted to copy the data onto an RFID that would be readable by an LTO drive, what kind of rfid card or fob (or whatever) would you write the data to?

34

Sorry, I do not understand what you are trying to do.

35

OK, so my first priority is to read this particular LTO’s RFID chip, and see if there’s anything wrong with it.

But to do that I need to establish why I can’t read any LTO chips with my ACR122UA9; is it a hardware problem, or some issue with the way I compiled nfc-ltocm?

My hardware appears to work ok with nfc-list, as it detects various other RFIDs, but not LTO-CMs.

If nfc-list detects LTO-CMs on your ACR122UA9, then it strongly suggests the issue is with my ACR122UA9, and I either need to get hold of (yet) another one, or bite the bullet and buy a Proxmark3.

But if nfc-list does not detect LTO-CMs on your ACR122UA9, then the problem may still be with my nfc-ltocm compile, in which case I need to go back and do more work there.

Now, once I’ve actually managed to read this LTO-CM, if it turns out to be ok, then I know the problem with the tape lies elsewhere.

But if the LTO-CM is corrupted, I will need to clone another LTO-CM and then “present” it to the drive. My understanding is that the LTO-CM chips have read-only areas, so I will need to do this with another RFID rather than an actual LTO-CM… hence my question about what RFID I would need to clone the “bad” LTO-CM onto.

But… the 1st step in my troubleshooting is to determine whether my ACR122UA9 is the problem… hence my request that you see if your ACR122UA9 detects LTO-CM chips with nfc-list :slight_smile:

Sorry if that’s a bit long-winded, but you did ask :slight_smile:

36

Thanks for your clarification. I will check if my ACR122U can detect the chip on Tuesday, and get back to you.

37

Thanks Kevin, that would be great :slight_smile:

38

Yes, I confirmed my ACR122U detected my LTO-CM. I used Ubuntu (16.04), Libnfc (1.8.0) and nfc-ltocm (latest as of today - 4/20/2021).

39

Thanks Kevin, but did nfc-list detect it?

40

No, it did not. LTO cartridge memory chip (MAM) employs proprietary commands to communicate between the chip and reader. “nfc-list” only supports ISO14443[AB] and Felica and JewelIt. LTO-CM commands are completely different from those, and thus, it does not detect anything.