The process by which an engineer reveals the identity of the mysterious IoT device that was in the room he moved into



Nikita Lapkov, a low-layer Rust engineer, posted on his blog the process of finding out what the mysterious IoT device was installed in the room he was moving into.

What's that touchscreen in my room? | Nikita Lapkov

https://laplab.me/posts/whats-that-touchscreen-in-my-room/

When Mr. Lapkov moved into an apartment built in 2015, he discovered the device shown below on the wall. It was definitely a touchscreen of some kind, but the homeowner had no idea about the device. There were no buttons or labels on the main body, and there was only a light to notify the power on/off.



When I looked into a binder containing manuals for various home appliances in my apartment, I found the pamphlet shown below. After finding this pamphlet, it turned out that IoT devices notify the amount of energy consumed.



The pamphlet also describes the device to be attached to the electricity meter, and when Mr. Lapkov actually went to look at the electricity meter, the device shown below was installed. At first glance, it wasn't clear what it was, but because it had the same brand name as the pamphlet, ``NetThings,'' Mr. Lapkov determined that this device was a meter-side device.



A sticker with 'SSID' and 'Pwd' is attached to the pamphlet, and it seems that the meter side device and the display touch screen are connected via Wi-Fi. Lapkov was horrified by the 'unnecessary complexity' of using Wi-Fi instead of running cables, as they were only a few meters apart and only had a few walls between them. He said he held her.

However, according to a friend of Mr. Lapkov who is familiar with IoT devices, using Wi-Fi even at such short distances is common in the field of IoT devices. 'The 'C' in IoT must stand for cost efficiency,' writes Lapkov.

If you look closely at the touch screen, there is a small hole on the side.



When I kept pressing this hole with a pin, the Android tablet started up. It was quite old, and some interesting apps were installed, such as Google Talk, whose service ended in 2013, and Adobe Flash, whose development ended in 2020. Mr. Lapkov found an app called ``NetThings'' and when he started it, a Wi-Fi selection screen was displayed. However, even after entering the SSID and password listed in the pamphlet, I was unable to connect.



When I checked the devices on the meter side again, I found that while the devices in other rooms were powered on, the device in Mr. Lapkov's room was not.



Mr. Lapkov lives in the UK, where all power supplies have fuses. When I opened the fuse box of this device, there was no fuse in it. When Mr. Lapkov purchased and installed a 3A fuse, the device on the meter side turned on.



This time, I was able to select the Wi-Fi listed in the pamphlet using the Android tablet app, and when connected, the screen below appeared.



When you tap it, a menu will appear. In addition to power monitoring, there are other menu options such as water supply and heating, but in reality only electricity worked.



The main screen of the power monitoring monitor looks like this. Mr. Lapkov criticizes this screen, calling it ``the most disappointing screen in the history of UX design.'' First of all, it is unclear what the indicator on the right side represents, and even if it is power consumption, I do not know how much it is consuming in which position. Of the five numbers displayed on the left, only the 'current energy consumption in kW' is actually correct; the other four numbers vary depending on the power company. According to the pamphlet, it is possible to set the amount to be paid and the value of CO2 per kW only in the initial settings, but there is no information on how to reset the system so that the initial settings can be re-configured. It was.



What's more, the pamphlet stated, ``⏰The date and time are always correct , so there is no need to adjust them at all.'' However, since this device was not connected to the Internet, it could not be corrected, and there was a lag of approximately 15 minutes. Mr. Lapkov complains, ``I don't know why I wrote this description.''



Mr. Lapkov said, ``Everything is very disappointing,'' but he thought that if he could connect directly to the Wi-Fi network of the device on the meter side and extract the kW consumption, he could display it on the

Grafana instance at the correct rate. I performed an IP scan from my laptop to determine the IP of the meter-side device, and when I accessed it with a browser, the content familiar to me on an Android tablet was displayed.



Mr. Lapkov thought, ``If it's just being displayed on the web, you can see the API in one go by looking at the communication content with developer tools,'' and when he checked the communication, he found that

Socket.IO was being used. In this case, the client only receives 5 numbers from the server, so Socket.IO is completely overkill. The client code also has complex behavior that would be unimaginable given its simplicity, with six RequireJS modules being dynamically loaded for different requests.



At this point, Mr. Lapkov realized that ``If Socket.IO is running, the device on the meter side must be running JavaScript,'' and decided to hack the device on the meter side. Since IoT does not have the initial 'S' for security, he was skeptical that it would be possible to do it quickly.

However, when running SSH directly, the connection was refused, so Mr. Lapkov decided to first find out which ports were available. The result is shown in the figure below, and port 41142 was prepared for SSH. In addition to the DHCP server and Node.js server, we also see that a mysterious service is using port 1534.



Although the SSH connection was not refused, root was password protected, and simple combinations such as 'admin/admin' and 'root/root' would not pass, so Mr. Lapkov decided to use 'micromuse' using port 1534. -lm' and found

the post shown below. According to this post, something called 'tcf-agent' seems to be involved.



The investigation into tcf-agent was said to be laborious. The pieces of the puzzle were scattered across various sites, so I had to read across the sites and put them together myself, and I couldn't grasp the information on the site without understanding the terminology. As a result of this investigation, Mr. Lapkov discovered the true identity of 'tcf-agent' as follows.

TCF, short for Target Communication Framework, is a text protocol that allows a target system to read file systems, start new processes, and send signals to processes. TCF is closely tied to the Eclipse ecosystem, and

the guide suggests plugins for Eclipse to interact with tcf-agent. However, when Mr. Lapkov tried to install the plug-in into Eclipse, the dependencies conflicted with other dependencies and he could not install it.

The TCF project has a Python SDK. Of course, like everything else in this research, I had to follow links on various websites three times to discover this SDK.



tcf-agent provides services that expose various parts of the system. For example, the command to obtain the information of the user currently accessing the site is as shown below. This command led Lapkov to discover that tcf-agent runs as the root user, writing, ``I just don't understand why anyone would bother setting a password for SSH while leaving such root access intact.'' Masu.



Since it became possible to obtain files with root privileges through tcf-agent, Mr. Lapkov first tried to decode the SSH password. However, after trying to decipher it for about seven hours, he was unable to decipher it, so Lapkov decided to try another method.



When I searched on Google, I found that I could empty the root user's password by simply changing '/etc/shadow'. However, even after following these steps, SSH login was refused, so Mr. Lapkov decided to check the sshd configuration file. Then, the setting 'PermitRootLogin no' was set to deny root login through SSH connection. 'It's a very sensible security measure, provided you don't provide full disk access over the network,' Lapkov commented.

Finally, Mr. Lapkov was able to log in as root using SSH.



The device is running Linux 3.10, released in mid-2013, a fairly new version considering the device was developed in 2014-2015. Since it is an embedded device, an ARM chip is used for the CPU.



The detailed information of the CPU is like this. It is equipped with an

ARM9 family chip , which is also used in the Wii . It has the feature of being able to directly execute Java bytecode.



The RAM capacity was 118MB. Mr. Lapkov wrote, ``I'm not a Linux expert, but I think it's a significant amount.''



Mr. Lapkov avoided publishing the source code because he did not want to risk litigation, but he did disclose the state of the directory. There are two main apps running on the device, one is an app called 'Pulse' that reads data from

the GPIO pin and writes it to a CSV file.



The other is a Node.js server app that reads data from CSV files and displays it on the web UI.



At the end, Mr. Lapkov decided to leave a small note in his home directory. ``I think I'm probably the only person who will read this text directly,'' he wrote, but added, ``Maybe in the distant future, another software engineer will live in this apartment and discover this text.'' It is written down.



As a later story, Mr. Lapkov reported on mastodon that even if the device's time setting is incorrect, the correct time is displayed when the web UI is opened. When I investigated this phenomenon, I found that when I opened the web UI in the browser, I was redirected to '/set-time/+Date.now()', and this redirect caused Node.js, which is in charge of 'current' The time information will be saved as a global variable in the app. Mr. Lapkov described this mechanism, which corrects the time using the time data of the accessing PC, as ``a unique and innovative time synchronization mechanism.''

in Software,   Hardware, Posted by log1d_ts