The Story of LLRP2HRP - Part 1

So, this brash American dude who ran a relay race event decided to go fancy. None of this using phones to manually scan NFC chips for race timing. He was going to have chips in bibs. He convinced another organisation that also ran races to chip in some funding ... and then went online.

He found an RFID reader system. The kind of ground mats that you run over, that connects to a box that goes beep. It was from China. It was insanely cheap. Like fall-off-the-back-of-a-truck cheap. It was delivered, hardware checks out.

It came with no software.


Commence epic yak shaving side project!

---

The reader is a Hopeland (previously Clou) CL7206C4. Basically an ARM9 box running (amazingly) Familiar Linux v0.8.3 with a 2 2-port UHF transceivers. The transceivers are based on the Impinj R2000 platform, which is a popular platform for race timing.

I pulled a venerable Thinkpad out of a draw and plugged it into the ethernet jack and fired up wireshark. No DHCP requests, but some documentation suggested the default IP was 192.168.100.116 so I configured an address in this range and watched as the reader helpfully started broadcasting a proprietary UDP protocol:

^tlì¡þ¶`Eó@lhÀ¨dtæt[ #ß·b^RFID_READER_INFORMATION:7206C,DHCP_SW:OFF,

IP:192.168.100.116,MASK:255.255.255.0,GATEWAY:192.168.100.1,

MAC:6c-ec-a1-fe-b6-60,PORT:9090,HOST_SERVER_IP:192.168.1.1,

HOST_SERVER_PORT:9090,MODE:SERVER,NET_STATE:INACTIVE$ 

Beautiful, and with telnet too:

$ nmap 192.168.100.116
Starting Nmap 7.60 ( https://nmap.org ) at 2019-12-04 17:08 CST
Nmap scan report for 192.168.100.116
Host is up (0.022s latency).
Not shown: 998 closed ports
PORT     STATE SERVICE
23/tcp   open  telnet
9090/tcp open  zeus-admin

I wonder what the password is ... no ... no, it can't be ...

$ telnet 192.168.100.116
Trying 192.168.100.116...
Connected to 192.168.100.116.
Escape character is '^]'.

Familiar Linux v0.8.3 (none)


(none) login: root
warning: cannot change to home directory
/ # 

The process list was typical for an embedded system - some hacky scripts that start a monolithic binary that has all the functionality.

  488 root       2916 SW  /bin/sh /bin/ping_gateway.sh 
  489 root       2920 SW  /bin/sh /bin/feeddog_auto.sh 
  491 root       2920 SW  /bin/sh /bin/auto_start_fifo.sh 
  492 root       2920 SW  /bin/sh /bin/auto_start.sh 
  523 root       1352 SW  /bin/fifo_read 
  524 root       1348 SW  /bin/feed_dog 
  525 root       9400 SW  CL7206C2 
  542 root       9400 SW  CL7206C2 
  543 root       9400 SW  CL7206C2 
  544 root       9400 SW  CL7206C2 
  545 root       9400 SW  CL7206C2 

With only TFTP to play with, I set up a TFTPD on the Thinkpad and started analysing the files. So, I could see that there was definitely a daemon listening on port 9090 looking for some kind of binary protocol - but it wouldn't talk without a specific instruction. I didn't have the instructions though. Then there are binary drivers for each of the RFID chips. Not a lot to go on.

I had a theory that this reader was an OEM model for Impinj. There are similar looking physical units, with the same chips online. Those speak Low Level Reader Protocol (LLRP), so perhaps if I fed some LLRP messages to port 9090 I could get something?

I wanted a quick and easy LLRP toolkit that I could fire up and used to send some messages. The leading options seemed to be from the Java-based "LLRP toolkit", which had a Eclipse plugin called LLRPCommander that seemed perfect. Only, it was hosted on SourceForge and didn't appear to have been updated in recent years. Not a good sign, and sure enough it didn't work with any recent version of Eclipse or Java even with a bit of hacking.

Back to the drawing board. So, Hopeland provided an "SDK" in C#. Not a language I'm familiar with, and the distribution was full of impenetrable binaries and no API documentation as such. It was also Windows-only and using a version of Visual Studio that was deprecated. I got out wine and tried to get it working in an older version, but to no avail.

Googling ensued. At one moment I was on the unofficial Hopeland YouTube channel (appears to be run by one of their employees, under their personal name). There they had screen captures of the SDK's test tool running. If you zoomed in just enough at just the right frame, you could see a debug window with the binary commands being passed to the machine. I copied down what I could:

## These sent when the app goes to advanced settings. getting settings?
AA02000000A803
AA020000002828
AA02000000A8F3
AA02000000A87B
AA0200000028A0
AA02000000A88B
# these are received after the above
AA0202000B010008080A070B060C050DE637
AA02080001FF24F1
AA020A00030000008E29
AA020A00030000006E2F

Then, I got out netcat and tried pasting them in. It worked!!

OK, so this definitely wasn't LLRP protocol ... but what was it? I definitely didn't want to try and completely reverse engineer what looked to be a complex proprietary binary protocol. I couldn't get packet captures to make progress, since the system didn't even respond unless the right packet was sent to it.

Then, after a very long and arduous Google session, I found the perfect solution, courtesy of the Bolivian government...