Continuing my growth in the realm of hardware hacking, IoT and embedded penetration testing, I have purchased too many devices to perform some (mostly light) reverse engineering.
Before going further, here are the required details for CVE references:
- CVE-2025-25727
- Affected Product and Version: IF740 – Firmware Versions: 11001.7078 & 11001.0000 (Confirmed) & System Versions: 6.25 & 6.00 (Confirmed). Likely <11001.7078 & < 6.25 (Not Confirmed). No version update that resolves the issues.
- Problem Type: Cleartext Communication Channel & Sensitive Information within URL – WiFi Update
- Description: Bosscomm IF740 Firmware versions:11001.7078 & v11001.0000 and System versions: 6.25 & 6.00 was discovered to send communications to the update API in plaintext, allowing attackers to access sensitive information via a man-in-the-middle attack.
- CVE-2025-25728
- Affected Product and Version: IF740 – Firmware Versions: 11001.7078 & 11001.0000 (Confirmed) & System Versions: 6.25 & 6.00 (Confirmed). Likely <11001.7078 & < 6.25 (Not Confirmed). No version update that resolves the issues.
- Problem Type: Sensitive Information Disclosure – Multiple
- Description: Bosscomm IF740 Firmware versions:11001.7078 & v11001.0000 and System versions: 6.25 & 6.00 was discovered to store sensitive information such as SSIDs and cleartext passwords, screenshots, logs and other information without the ability to proper delete it, while giving the impression that they can be deleted.
- CVE-2025-25729
- Affected Product and Version: IF740 – Firmware Versions: 11001.7078 & 11001.0000 (Confirmed) & System Versions: 6.25 & 6.00 (Confirmed). Likely <11001.7078 & < 6.25 (Not Confirmed). No version update that resolves the issues.
- Problem Type: Hardcoded Passwords
- Description: Bosscomm IF740 Firmware versions:11001.7078 & v11001.0000 and System versions: 6.25 & 6.00 was discovered to store passwords in cleartext.
One of these devices is the BossComm OBD2 Tablet (IF740)
Which I purchased secondhand ofc. My approach to gathering devices to do my research on is Used > New.
This device as one can imagine has a main pieces of functionality. Car Diagnostics, tests, or resets via OBDII. Additionally, it can update its firmware/car codes via WiFi or USB. If you want to see all of its functionality, you can view the instruction manual HERE
After spending a few hours I determined a few things, 1. This isn’t going to be as straight forward as other devices I’ve been poking at. 2. I’m having trouble determining what the pin holes are. 3. The micro SD card, the WiFi Update Functionality and the USB Updated Functionality are where I’m going to focus on first.
Here’s the top of the main board
Obviously there are plenty of pins/touch points and more that look interesting, including ones labeled debug.
I traced which of these are connected, which are ground.
I used my Saleae Logic Analyzer which had some interesting results which suggested there’s UART somewhere on the device but was showing a lot of errors. This post isn’t going going to cover anymore of that though, I will return to that and make a post upon then.
So let’s look at the issues I did report in this batch.
- Cleartext Communication Channel & Sensitive Information within URL – WiFi Update (CVE-2025-25727)
So turns out that communications to the BossComm update API are sent in cleartext. These include unique device serial numbers and download tokens which are sent as both POST data and URI parameters. I found this out, via using a man-in-the-middle (MiTM) router (I used a rpi which I can cover in another post but there’s a million tutorials/scripts to get that set up).
Reproduction steps are straightforward (as they are with all of the CVEs in this batch) just select WiFi Update, connect to the AP you are capturing traffic on, and view the traffic.
An example request sent to their API including serial number as a URI parameter and in cleartext:
And another showing the serial number and download token:
Note that I’m not sure of their input validation or anything beyond what was sent by the device itself as I didn’t have permission to fuzz their cloud environment. If you’re willing too, I’m sure you’ll find some interesting vulnerabilities though.
Next up was a handful of instances of hardcoded passwords (CVE-2025-25729). There were multiple locations where these were stored and disclosed. For example, a registration password is viewable within the settings of the tablet application but with no indication of what this is exactly for or a way to reset/generate a new one when selling the device in the aftermarket.
Most of the instances though were viewable when removing the microSD card from the board and viewing it in a Linux Machine. Note that b/c you’re accessing the microSD directly, you could modify these files but upon boot, they would be overwritten which is very standard for embedded devices.
Some files that contained hardcoded creds (didn’t include all of them):
/etc/wifi/wpa_supplicant.conf/
/etc/wifi/bootdefaultwifi.sh
/etc/app_back/Res/script/scr01
/etc/app_back/Res/script/scr05
/etc/app_back/Res/script/scr07
So there’s just a few. Wonder if it’s worth adding these SSIDs/Passwords to my Evil Core2 or other evil twin setup, I’m not sure how popular these devices are but would be cool to have it on a list so that if the time comes, it would auto connect to the evil twin…
FYI, I did attempt to scan the device while it was in WiFi update mode, but masscan+nmap weren’t seeing any open ports etc. I wonder if any of these hardcoded SSIDs are related to dev mode or connections or something.
Anyway, the largest issue I reported in this batch, is Sensitive Information Disclosure – Multiple (CVE-2025-25728)
So it turns out that anyone with physical access to the device, can view screenshots, OBDII logs and cleartext SSID + Passwords that the device connected to previously. Even if the tablet application shows that you successfully deleted screenshots, Logs and WiFi info from the device…
Here’s the device showing History/Logs as empty:
Well what I discovered was, if you plug in the tablet via USB for a Update it allows you to view some partitions of the microSD card. (Note there are some other very interesting files I’ll cover in a future post).
Within Log, as you can imagine, is the OBDII logs
pdf which contains the reports you can generate after running diagnostics via OBDII.
ScreenShot which contains, screenshots as you can imagine
(Those were on the MicroSD from the previous owner)
Lastly if you just removed the MicroSD completely and plug it in, you can access all partitions.
Which included the filesystem:
The kernel (logofail anyone?)
And my favorite,
Now within this partition was what I was most surprised and concerned with.
Because it turns out that all SSIDs + Passwords the device connects too are stored in this partition (among other places)
And yes, hiiot is my SSID when I was doing some testing in the beginning.
When I did find within my initial testing was running recovery on the tablet, (holding down the power and up on the pad) would reinstall the firmware and OS (it actually recovered to an older version then what was on it when I bought the device). This also actually deleted the logs, screenshots and PDFs from the device. However, it did NOT delete the Wifi Passwords.
Obviously there is SO much more testing to do and eventually I will continue and update y’all.
I also would like to say that BossComm responded immediately and we had multiple communications back and forth and seemed appreciative of my disclosure. They also gave me permission to request CVE #s and disclose this initial batch of issues.
END TRANSMISSION