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:
Beautiful, and with telnet too:
I wonder what the password is ... no ... no, it can't be ...
The process list was typical for an embedded system - some hacky scripts that start a monolithic binary that has all the functionality.
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:
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...
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...
Comments
Post a Comment