You purchased a Smart IP Camera and use it just as a simple consumer device. Assuming you are a security enthusiast and think like an attacker, you'll know about the hidden layered stack of hardware, bootloaders, filesystems, services, and often years-old third-party code.
In this talk, we'll walk through a real-world firmware reverse engineering workflow for smart IP cameras, starting from PCB inspection to analyze and identify all the components, and then moving into UART probing, SPI flash extraction, firmware carving, filesystem mapping, and binary analysis.
The talk begins with the physical layer: identifying the SoC (System-on-Chip), SPI NOR flash, motor driver ICs, transistors and diodes, and other support components on the PCB. We'll then explain UART as the first communication surface we try to discover, how to identify VCC, TX, RX, and GND, and how vendors intentionally disable console access to stop people like us from accessing it. From there, we'll move on to how firmware can actually be dumped using the CH341A programmer, SOIC8 clips, and flashrom, including when desoldering becomes necessary and how to avoid damaging the board during extraction.
Once the dump is obtained, we'll move on to mapping the firmware using binwalk, interpreting magic numbers and compression markers, and distinguishing between readable and encrypted partitions. We'll talk about certain case studies to explain why some devices yield standard JFFS2, SquashFS, or MiniFS filesystems that are easy to unpack, whereas proprietary platforms like Anyka often customize them and add much more friction.
The final stage is to analyze and triage ELF binaries using tools like Ghidra, IDA Pro, Radare2, etc., search for risky patterns, and reason about vulnerability exposure in embedded services. Case studies will contain examples such as exposed root MD5crypt password hashes and vulnerable C programming functions like strcpy(), strcat(), sprintf(), etc., which can lead to buffer overflows, command injections, and all the way up to RCEs (Remote Code Executions).
The talk will close with the practical challenges of reassembling the hardware: keeping the device functional after desoldering, dumping, and analysis, while preserving the board and making sure the extraction process itself doesn't become the reason for our device getting completely fried.
This session is aimed at beginner-to-intermediate-level students, researchers, hobbyists, and practitioners who want a grounded introduction to firmware reverse engineering from the hardware side up. It's not a "magic exploit" talk; it's a guide to understanding the security posture of embedded systems, where each layer leaves a clue about the next.
