The Case of the Hidden Camera: A Forensic Journey

David Tull
Dec 27, 2024
5 min read

Recently, I worked on an intriguing case involving a hidden camera cleverly disguised as a USB-C charger. At first glance, the device looked like any standard wall adapter—no markings, no clues. But hidden behind its magnetically attached front cover were a camera lens, IR lights, a selector switch for recording modes (continuous or motion-activated), and a microSD card slot. The camera also connected via Wi-Fi and worked with a companion app, making it a powerful yet inconspicuous surveillance tool.

Due to the nature of the case, I can’t delve into the specifics, but the popularity of such covert devices prompted me to share some insights from the investigation.

Device Identification:

The device turned out to be related to the Tuya application but it is still unknown what the actual band of the camera is. It appears that this camera is available under several names through various retailers, including Amazon and Newegg.

The Challenge: Extracting Usable Video

When we examined the microSD card, the folder structure and file formats presented an immediate hurdle. The video files had a .media extension and lacked a recognizable file header, making them unplayable in standard video players. Even specialized forensic tools failed to convert the files.

Here’s what I discovered about the folder and file naming conventions:

Folder Structure: Organized by date with names formatted as TIMESTAMP_DURATION. The timestamp was in Unix seconds, and the duration indicated the total length of the videos in seconds.
Files: Named using the epoch time of each 12-second video chunk (e.g., 0000.media, 0012.media, etc.).

Cracking the Code with FFMPEG

To make the files usable, I turned to FFMPEG, a powerful multimedia tool. After copying a single .media file, I used this command to convert it:

ffmpeg -i 0000.media -c copy output.mkv

Success! The resulting video played seamlessly in VLC. Building on this, I concatenated and converted multiple files:

find . -type f -name '*media' >> unsortedlist.txt cat $(cat unsortedlist.txt) > all.media 
ffmpeg -i all.media -c copy output.mkv

This script collected all .media files, combined them into one, and converted them into a continuous video. For daily folders, I refined the process:

find . -type f -name '*media' > "$(basename "$PWD").txt" cat $(cat "$(basename "$PWD").txt") > all.media ffmpeg -i all.media -c copy "$(basename "$PWD").mkv"

The output was a complete daily recording, neatly named and ready for review. Evidence found in the videos was critical to the case.

I refined the script a little more and made it a single line.

find . -type f -name '*media' > "$(basename "$PWD").txt" && cat $(cat "$(basename "$PWD").txt") > all.media && ffmpeg -i all.media -c copy ../"$(basename "$PWD").mkv"

Moving forward, this could be made into a Python script and executed once but by this time I had all of the videos converted so I did not want to spend any more time on it.

Digging Deeper: A Chip-Off Investigation

To explore the device itself, I performed a chip-off analysis. The camera’s flash memory was an 8MB BoyaMicro 25Q64AS SOP-8 chip. Using heat, I removed the chip, placed it in a SOP-8 adapter, and read it with an XGecu T-48 programmer, exporting the binary file for examination. Datasheet for the chip.

Green:
- Camera and IR Lights board
Yellow
- Exterior Housing
Red
- Back plate and power distribution board.
Blue
- Main circuit board

Green:
- Power cable coming in from the power distribution board
Blue:
- Power going to IR lights
Yellow:
- Power going to camera
Red
- 3x Test points
- Board ground

Blue:
- Flash memory chip
Red:
- Test points
Yellow:
- UFL connector for antenna

I used the software provided by the makers of the programmer, XGoPro, but I have always been cautious as to where I install this software. There is an open source project in the works which allows a Linux machine to run the programmers. It is called minipro and the Git is available here. Check it out if you do chip-offs. (In the screenshots, I did not have the chip in the readers).

Commands like strings and grep provided critical clues, including the Wi-Fi SSID and password:

strings BY25Q64AS@SOIC8.BIN | grep -iC 3 'SSID'

-i is for Case Insensitive and C 3 is to return the 3 lines prior and after the keyword.

Further analysis with binwalk revealed a JFFS2 filesystem:

binwalk BY25Q64AS@SOIC8.BIN

Above command was used to examine the binary.

binwalk -e BY25Q64AS@SOIC8.BIN

Above command is used to extract the files from the binary.

Among the extracted files, I found a configuration file (wifi.conf) containing Wi-Fi credentials, though no setup dates or user-specific data.

A Live Exam and Final Findings

Re-soldering the chip back onto the board allowed for a live exam. I identified test points for UART (Tx, Rx, and VCC) and had to find a ground on the board. I then connected them to a UART-USB device (FT232). After overcoming boot loop issues by reconnecting the camera and inserting a blank SD card, the device successfully booted and began searching for Wi-Fi.

Although noisy with network calls, I avoided installing the companion app to preserve the integrity of the evidence. While the live exam yielded limited new data, the earlier findings from the videos and Wi-Fi setup were pivotal.

Ground:
- Black wire soldered to the board and connected to GND via a Green wire clip
Rx:
- Yellow wire soldered to the Rx on the board and connected to the Tx on the receiver
TX:
- Blue wire soldered to the Tx on the board and connected to the Rx on the receiver.

Yellow Wire - Rx
Blue Wire - Tx
Pencil lead for size comparison.

For the live exam I used a Kali Linux machine. The tool I chose picocom as it is a great tool for live exams. You will need to know the baudrate and the location of your device. If you don't know the baudrate, you can find a listing of common rates and try them until you see readable code. I was lucky and found it listed in the .BIN file

strings BY25Q64AS@SOIC8.BIN | grep -iC 3 'baudrate'

picocom -b BAUDRATE LOCATION_OF_USB

You can also choose to output the information to a log file as the device loads. By using the tee command you will have an output file and see the information on the screen.

picocom -b 115200 /dev/ttyUSB0 | tee output.txt

Lessons Learned

This investigation showcased the versatility of open-source tools like FFMPEG and Binwalk in digital forensics. It also underscored the importance of understanding file structures and embedded device systems. Ultimately, the recovered videos provided the evidence needed, and the device’s connection to a password-protected Wi-Fi network significantly narrowed down potential suspects.

In an age where hidden cameras are increasingly accessible, these forensic techniques are vital for uncovering the truth.

What are your thoughts on handling covert surveillance devices? Let’s discuss!