Attributed metadata history

Unpacking VStarcam firmware for fun and profit

One important player in the PPPP protocol business is VStarcam. At the very least they’ve already accumulated an impressive portfolio of security issues. Like exposing system configuration including access password unprotected in the Web UI (discovered by multiple people independently from the look of it). Or the open telnet port accepting hardcoded credentials (definitely discovered by lots of people independently). In fact, these cameras have been seen used as part of a botnet, likely thanks to some documented vulnerabilities in their user interface. Is that a thing of the past? Are there updates fixing these issues? Which devices can be updated? These questions are surprisingly hard to answer. I found zero information on VStarcam firmware versions, available updates or security fixes. In fact, it doesn’t look like they ever even acknowledged learning about the existence of these vulnerabilities. No way around downloading these firmware updates and having a look for myself. With surprising results. First of all: there are lots of firmware updates. It seems that VStarcam accumulated a huge number of firmware branches. And even though not all of them even have an active or downloadable update, the number of currently available updates goes into hundreds. And the other aspect: the variety of update formats is staggering, and often enough standard tools like binwalk aren’t too useful. It took some time figuring out how to unpack some of the more obscure variants, so I’m documenting it all here. Warning: Lots of quick-and-dirty Python code ahead. Minimal error checking, use at your own risk! Contents ZIP-packed incremental updates VStarcam pack system VeePai updates Ingenic updates LZO-compressed partitions Ingenic’s jzlzma compression Exotic Ingenic update But what about these security issues? ZIP-packed incremental updates These incremental updates don’t contain an image of the entire system, only the files that need updating. They always contain the main application however, which is what matters. Recognizing this format is easy, the files start with the 32 bytes www.object-camera.com.by.hongzx. or www.veepai.com/design.rock-peng. (the old and the new variant respectively). The files end with the same string in reverse order. Everything in between is a sequence of ZIP files, with each file packed in its own ZIP file. Each ZIP file is preceded by a 140 byte header: 64 byte directory name, 64 byte file name, 4 byte ZIP file size, 4 byte timestamp of some kind and 4 zero bytes. While binwalk can handle this format, having each file extracted into a separate directory structure isn’t optimal. A simple Python script can do better: #!/usr/bin/env python3 import datetime import io import struct import os import sys import zipfile def unpack_zip_stream(input: io.BytesIO, targetdir: str) -> None: targetdir = os.path.normpath(targetdir) while True: header = input.read(0x8c) if len(header) < 0x8c: break _, _, size, _, _ = struct.unpack('<64s64sLLL', header) data = input.read(size) with zipfile.ZipFile(io.BytesIO(data)) as archive: for member in archive.infolist(): path = os.path.normpath( os.path.join(targetdir, member.filename) ) if os.path.commonprefix((path, targetdir)) != targetdir: raise Exception('Invalid target path', path) try: os.makedirs(os.path.dirname(path)) except FileExistsError: pass with archive.open(member) as member_input: data = member_input.read() with open(path, 'wb') as output: output.write(data) time = datetime.datetime(*member.date_time).timestamp() os.ut

This record contains metadata and attribution only. It does not host, download, unpack, render, or execute malware samples.