📷

JEEMAK Vision 4K - teardown and pwn

Photos of the boards

Other boards of the device

Bluetooth board

Buttons support

Trying to find debug / serial interface

One of the first thing I would like to find is a debug or a serial interface so I could interact with the ARM processor and maybe gain access to it. To do so, I looked at the main board and notices 4 pins that seems to be not in use but still present.

I soldered some cables to it and hoocked up the logic analyser to see if anything goes through it

Now, let’s fire the logic analyser software and plug the device to see if anything come out from one of those pins

Two other things that have to be determined is the frequency of the communication and the protocol they use (Serial, I2C) but I’m not sure if it would lead somewhere interesting since all the signals appear to be the same just played multiple times.

Let’s take a look at the EEPROM

After being unsuccessful at reading informations from the different pins that are on the board, I decided to take a new look at it at try another way to break in. That’s where I found the EEPROM on the board it appears to be a Winbond W25Q128FW.

I plugged it to the CH341A and red it through it’s software and it looks quite promising.

The complete binary file can be found at the following link

http://cyberwolf2077-vps.ddns.net:2077/BinaryFiles/W25Q128FW_dump.bin

Binary analysis

Now that I have the firmware in a bin file, I pushed it into a Kali linux VM to see what I could get from it.

Looking at the content of the .bin file

I first made a binwalk of the file to get an idea of what it contains using 

binwalk <file.bin>

Extracting the data

I then extracted all this to get a closer look at the files that could be interesting using

binwalk -e <file.bin>

One of the interesting things I saw while extracting the content of the bin file was this line 

151733 0x250B5 Android bootimg, kernel size: 1869570560 bytes, kernel addr: 0x203A6174, ramdisk size: 543449442 bytes, ramdisk addr: 0x746F6F62, product name: "a boot.img?"

This mean the device would be running under some kind of android ? that could be interesting to test, but first let’s try to see if we can find some informations

Browsing the data

Finding informations about the WiFi

In the path _W25Q128FW_dump.bin.extracted/squashfs-root/etc/wifi It is possible to find a file called p2p_supplicant.conf This file contains some informations like the Channel, SSID, BSSID, and the PSK of the network amongst other things

Get some information about the components of the camera

When looking at info.xml that is in _W25Q128FW_dump.bin.extracted/squashfs-root/etc it is possible to get some information about the screen that is used, but also the camera module and the firmware date of release

Looks like they reused some code from others manufacturers

In vold.fstab it is possible to see some references to HTC Passion. I took a look online as I had no idea of what it could be linked to. Turns out this is the code name of the HTC Nexus One

HTC Nexus One (htc-passion) - postmarketOS
https://wiki.postmarketos.org/wiki/HTC_Nexus_One_(htc-passion)

Turns out they also used some of the HTC Nexus One code for the WiFi part of their device

⚠️
After further researches and some discussions with a friend, these code elements could be from NixOS, which they probably use at it still provide support to it. These lines are present in a lot of IoT projects over GitHub so it must be some well known code.
https://github.com/search?q=%2BHTC-VHTcapable&type=code

It even is inside FreeBSD code

https://github.com/search?q=repo%3Afreebsd%2Ffreebsd-src%20HTC&type=code

Some functionnalities still available

More android structure

The idea that the device is actually running android seems interesting, the line I noticed earlier makes it really possible, the informations that can be found in the directory _W25Q128FW_dump.bin.extracted/squashfs-root/etc/firmware are also helping with this theory.


boot_xr819.bin could be the boot.img,
sdd_xr819.bin the uboot.img,
and fw_xr819.bin the system.img.

Let’s exploit the device as an Android device through ADB

Find the device

From what has been saw previously, this device seems to run under android. Let’s try some shenanigans using ADB to mess around with it !

I plugged it over the USB cable and nothing happened we I plugged the camera, I decided to plug back the screen to the logic board to see if any informations could be provided, it happens that I had to select the USB mode to get access to the camera over USB. And this is what it displayed in VMWare Workstation :

This make it more credible for an android powered device than ever before

I then started by listing the devices that are available with

adb devices

Dump the firmware

I can download the most interesting files with the following commande from ADB

adb pull /dev/block/mtdblock0 uboot.img         # uboot
adb pull /dev/block/mtdblock1 boot.img          # kernel
adb pull /dev/block/mtdblock2 system.img        # squahfs
adb pull /dev/block/mtdblock3 config.img        # /data
adb pull /dev/block/mtdblock4 boot-logo.jpg     # boot logo
adb pull /dev/block/mtdblock5 shutdown-logo.jpg # shutdown logo
adb pull /dev/block/mtdblock6 env.img           # uboot params

The content of the firmware can be found at the following link :

http://cyberwolf2077-vps.ddns.net:2077/FirmWare/firmware_JEEMAKVision4K.rar

Exploit the device

I can now join the shell of the device using 

adb shell

It gives a root shell, from here it could be possible to do anything on the device