Tales of a Reverse Engineering project

Some reached out about the reverse engineering project ..

So here are more details on the project. Why it started, what I found along the way and how far I got until now.

It became an article; my first, due to the limitation of "Posts" ..

Up front: the details are kept to a minimum hiding the manufacturer because I do NOT wish to generate bad publicity. I really like their product and they are aware of my endeavor.

Some context

A couple of months a I bought a “device” which has a built-in web-server. The only issue it has is that it frequently; as in minutes to hours after reboot, looses its WiFi connectivity.

The manufacturer was kind enough to send me a new controller; even if I voided warranty by opening the device. Yet the problem persisted. Wired both work fine. On WiFi both go offline.

The controller essentially manages two components via a serial UART interfaces. Activating them after a successful RFID identification and keeping track of both usage and consumption. It also allows to configure the device remotely.

The Reverse Engineering Project

Since I now had two controllers, one was taken apart. Turns out it spurs an H3-based SoC with an HDMI interface. A single board arm-based computer similar to a Raspberry Pi. Having experience with various Pi's and Arduino's the nerd fun could begin.

The controller is running an Ubuntu Bionic based Armbian on the embedded eMMC. This OS has known “network-manager” issues. Initially I didn’t have root access to further investigate. A problem easily resolved by booting of an SD-card, mounting the eMMC partition, issuing a passwd command referencing and the eMMC as root path.

Armed with a Debian Buster based SD-card and full access I was able to locate their software components and replicate the setup. This allowed me to copy the required files from the internal partition to the SD-card. It is always handy to be able to peek around a running system as root for forensic purposes.

The Road-block

After managing the replication of the setup on the new OS I hit a roadblock.

The software is Java based and requires access to the internal UARTs to manage and monitor the components. This module is not part of the standard setup and thus generates an expected error "java.lang.UnsatisfiedLinkError: no rxtxSerial in java.library.path: [/usr/lib/jni] thrown while loading gnu.io.RXTXCommDriver".

Installing the default "librxtx-java" module as could be found on the original setup did not resolve the problem. Instead it threw "java.lang.NullPointerException thrown while loading gnu.io.RXTXCommDriver".

And Yes, I activated access to the UARTs hardware using armbion-config.

Further investigating the syslog unearthed another candiate module "io.netty.channel.rxtx.RxtxDeviceAddress". Searching the Internet, the rxtx and netty source-code was quickly located and downloaded to the target host.

Alas both failed to compile ..

A glimmer of hope

After the compilation failed I started going through the various "pom.xml" files that make up the maven configuration which revealed a startling comment.

Straight from the armhf pom.xml it reads

<AlwaysFail>

<message>Sorry, the rxtx binary for the linux/armhf platform can be build on the following systems only: * linux/x86 * linux/x86_64 If you know about a working cross-platform build procedure for other platforms, please bring this up at the rxtx mailing list.</message>

</AlwaysFail>

To cross-compile or not to cross-compile

Since cross-compilation on an x86/64 system is suggested this will be the next step. For that I will need to setup an x64 Linux machine for cross compilation. On the up-side I will also be able to use this machine for a "Linux from Scratch" effort. Again extending my expertise and re-awaking old skills.

So far it has been an rewarding and fun endeavor.

Hope this gave some insights 😉

To be continued ..