Hacking the Tomlov DM-9 taught me my microscope prefers to identify as a dashcam.

Three personalities, two of them lies

USB was the obvious first move. Plug it in and it enumerates differently depending on which mode you pick, and i figured at least one of those would tell me who made it.

Mass storage   1b3f:8301  Generalplus       MSC + a live vendor command channel
PC camera      05e3:f12b  "GENERAL - UVC"   UVC only, no extension unit
Charging       does not enumerate           nothing at all

05e3 is Genesys Logic. That is a bridge chip's vendor ID, not the manufacturer's, and searching on it in camera mode walks you straight into a completely unrelated product. I did that first, obviously.

Three fingerprints, all pointing the same way

The first one came out of the microscope's own recordings. Every AVI it writes is stamped by whatever code muxed it, and the stamp is sitting there in clear text:

RIFF....AVI LIST....hdrl....avih ....strl....strf....JUNK
GP$322 Generalplus AviPackerV3 20140916....movi

In every captured .avi, and later found at 0x05d8e4 in the firmware too. Generalplus is a Taiwanese SoC vendor. Nothing there says Tomlov and nothing says microscope.

GENPLUS  USB-MSDC DISK A  1.00GP-PROD.

Months later i found the reference implementation's SCSIInquiryData[] array and it matches this byte for byte. Nobody ever edited it.

Third one is the good one. There is a private SCSI extension in there, gated behind two signature bytes — 'G' and 'P' at fixed offsets in the command block. The same command succeeds with them and gets rejected without them, which i confirmed on the actual device rather than reading it somewhere.

Three independent identifiers, one answer: this is a Generalplus part. And that is exactly where the whole thing forked, because of what you find when you go looking for Generalplus source.

There is basically one public Generalplus codebase

It is a GitHub repo called ZTKVR, and it is a complete SDK for a product line its own headers call 326B_CVR. CVR. Car Video Recorder.

It is a dashcam SDK. Nobody has published a microscope SDK, and at that point it looked like nobody had ever written one that got published.

Everything i knew for the next several weeks came out of that repository: the resource container format, how the splash gets loaded, how a firmware update works, what the vendor command table looks like. All of it read out of code written for something that bolts to a windscreen.

This meant every finding there was a guess, until i got my hands on the firmware. The update path this SDK describes has no signature, no checksum, no magic number and no version check. It erases and rewrites SPI flash from offset zero with whatever bytes it finds in a file on the SD card. If the dashcam assumption was wrong anywhere that mattered, my first write would also be my last one.

So i split my notes into two columns — verified on the device, and inferred from the SDK — and refused to write anything to flash while the second column still held anything important. That discipline is the only reason this story does not end with a paperweight.

What the wrong map cost me

Reasoning off a sibling product gives you confident, plausible, wrong answers. Each of these ate real hours before it fell over.

Four emails

The other route was just to ask. Tomlov does not publish there firmwares on their webpage, and i could not find it anywhere else either. So wrote a few lines to their support and ask for a copy of the firmware that is already running on the device i already own. Turns out this is much harder to communicate than it sounds.

Deflected twice. First reply: there are no firmware updates available for this model. Second reply: something about warranty and return terms that had nothing to do with what i asked. Front‑line support simply could not parse “a backup copy of the firmware i already have” as a different thing from “a firmware update”.

What finally worked was killing the newer‑version framing outright:

"I am not looking for a newer version. I would just like the version
 I paid for, should it ever experience issues."

Plus the point that being unable to reflash once the warranty is up costs the customer money. Support acknowledged the misunderstanding and escalated it to the factory.

The file arrives and the microscope stops pretending

First thing i checked was whether it is even the right build. At 0x01ae8c sits the ASCII string 20220905 V1.0, a byte‑for‑byte match for what the device's own menu reports. Right firmware, right device.

Then i parsed the resource container, and the dashcam stopped being an inference.

0x004b82   C:\gp_cardvr_upgrade.bin
0x023ea2   C:\gp_cardvr_upgrade.bin

cardvr. Car video recorder. The SDK documents this filename as a per‑customer compile‑time constant that gets changed for every brand licensing the platform. It was not changed. Which is handy, because it also tells me exactly where to put my file.

26 KB, and my first idea did not fit in it

The original splash is 26,178 bytes in a slot that spans 26,624. Since i can no longer prove which of those two numbers the firmware cares about, i aimed at the smaller one and let the packer pad the rest with 0xFF, which is what the vendor's own packer does to every short slot in the container.

26 KB at 800×480 is about 0.55 bits per pixel. That is tight, and how tight depends entirely on what you feed it.

I really wanted the crayon one. I tried edge‑preserving smoothing, i tried downscaling and letting the firmware rescale it back up at decode time, i tried denoise passes. All of it bought maybe 10–20% and made the picture visibly worse, and i still had a 5× gap to close. In the end the lesson is just: if it will not fit, redraw it as flat art instead of crushing the quality of the wrong source.

One more trap worth writing down, because it will bite anyone doing this. Progressive JPEG is the default in a lot of editors and the firmware simply will not decode it. Baseline only. -interlace none in ImageMagick, or uncheck “progressive” in a GUI, and check the result with file x.jpg — it will say baseline or progressive right there.

Writing to it

With a recovery baseline finally in my hands, i could actually do the thing i set out to do six weeks earlier. Five steps and one very long pause.

The pause is the interesting bit

The progress counter climbs to 100% and then the device just stops. Nothing moves. Minutes go by. On a write path with no signature and no checksum, sitting in front of a frozen screen that a moment ago said do not power off now is not a nice place to be, and i sat there for a while doing nothing.

It is not frozen. It is finished. The upgrade routine deliberately never returns:

DBG_PRINT("system hold ...");

i = 0;
while (1) {                              /* never exits */
    if (gpio_read_io(PW_KEY)) i++; else i = 0;
    if (i >= 3) { gpio_write_io(POWER_EN, 0); }   /* power key only */
    OSTimeDly(5);
}

Which reframes the message on the screen completely. “Remove SD card and restart now” is not a status line, it is an instruction to me. The device has no intention of restarting itself.

Two details made pulling the power provably safe rather than a gamble, and i worked them out before touching it rather than after. The progress value only ever gets set to 100 inside the branch taken when the written total has met the file size, so a displayed 100% is proof the write loop drained and not a rounding artifact. And the only thing that could still have been running at that point is the read‑back verify — interrupting a read cannot corrupt flash. There was no story in which power‑cycling was risky.

Failure would have looked completely different and completely unambiguous: Upgrade fail, drawn only when the retry counter runs out.

I pulled the card, pushed the button, and it came back up with my picture on it. First attempt, no bricks.

While i was in there anyway

That is the job done. But by this point i had the whole image open in front of me and 1.7 MB is a lot of place to poke around in, so i kept going. Everything below is stuff nobody at Tomlov bothered to take out.

A sound pack with nothing to play it

The container ships POWERON_AUDIO.WAV and the startup code genuinely calls it. Unlike the lane departure prompts, that one is not dead code. And it never plays.

I had a lovely theory about this. It is the only sound in the pack recorded at 16 kHz, while every other file is 11025 Hz, so obviously the audio path rejects the odd one out. Very neat. Completely wrong — no sample rate is hardcoded anywhere in the code region, every hit for either value is inside a WAV header rather than an instruction.

The real answer took one sentence from someone who had actually held the thing: it makes no sound at all. No menu clicks, no shutter, no beep, ever. There is no speaker in it. A day of clever theory beaten by looking at the device.

While confirming that, the sound table gave up one more thing. It declares nine effects. The container ships seven.

[0] CAMERA.WAV          present
[1] CLICK.WAV           present
[2] POWERON_AUDIO.WAV   present
[3] POWEROFF_AUDIO.WAV  missing from container
[4] GOTIT.WAV           missing from container
[5] BEEP.WAV            present
[6] LDW_TURNON.WAV      present
[7] LDW_TURNOFF.WAV     present
[8] LDW_ALARM.WAV       present

Two effects the code can ask for and the firmware cannot supply. A latent bug shipped in a retail product, on a device where you could not have heard it even if it worked.

It is ready for a crash

Not one accelerometer driver but two, next to the whole parking surveillance state machine — the feature that wakes a dashcam up when something hits the parked car.

G_Sensor_DA380_Init
G_Sensor_SC7A30E_Init
G_Sensor_park_mode_init
G sensor on time over restart recording!
G sensor on NO SDC Power off!
G sensor Who am I = %02X

DA380 and SC7A30E are real, specific accelerometer parts. This is driver code for named silicon, not a stub someone forgot to delete.

It is ready for a second camera

The dual‑channel recording path is fully built out. Front and rear each get their own JPEG buffers, scalers, AVI working memory, index writers and timestamp queues, and the firmware sits there watching for a rear camera being plugged in and out. In a product sold with one lens.

Every file this device has ever written is named for camera A of two, as well — DCIMA\MOVA0001.avi, DCIMA\PICA0000.jpg. The entire DCIMB tree exists in the code and will never be written to. There is also a LOC* naming scheme in there, which is the locked‑clip mechanism: the files a dashcam protects from loop‑record overwrite after an impact.

It can be a USB host

This is my favourite one. On top of the mass storage and webcam modes it advertises, there is an entire additional state dedicated to being a USB host — enumerating an external UVC camera, negotiating isochronous transfers, pulling frames off it.

state_usbh_uvc_entry
Host: do uvc_host_enum_device
Host: Enum UVC device successfully reinit_flag[%d]cmd[%d]
Host: MSG_USB_HOST_UVC_PLUG_IN
Alloc ITD1 buffer for USBH UVC failed
[ERROR]USBH iso in trans fail

A microscope carrying the machinery to record video from a camera you plug into it. Whether any of it survives to runtime i genuinely do not know yet — but it is compiled in and it is not small.

Reading the code, which needed one trick

I wanted to check whether any of that vestigial stuff is actually reachable, and for that i needed to read the binary properly rather than grep it. That went badly for a while.

The code region is plain uncompressed ARM32 and radare2 finds about 2,092 functions in it without complaining. What i could not do was connect any of those functions to the strings they print. I hunted for a load base for days: voting literal‑pool constants against string offsets, demanding that the five strings the upgrade routine provably uses cluster in one pool, running radare2's own reference analysis. All negative. A brute‑force base hunt is worse than useless here, by the way — with 87,700 distinct aligned words, about 5,000 candidate bases pass any five‑pointer test purely by chance, and raw scans keep surfacing ARM opcodes that look exactly like plausible addresses.

The reason none of it worked is that the image stores no absolute pointers to its strings at all. They are computed at runtime with ADD Rd, PC, #imm and never stored anywhere. I was searching for a thing that does not exist.

Decode those instead and the binary opens right up:

0x023a94   e0008fe2   add r0, pc, 0xe0    ; string address, computed
0x023a44   ec009fe5   ldr r0, [0x23b38]   ; =0xdfc5c, a BSS variable

1,388 PC-relative address computations found
1,223 (88%) resolve to printable strings
2,158 string <-> code references mapped

Watch the instruction mask if you ever do this. Matching ADD/SUB Rd, PC, #imm needs 0xffff0000. Use 0xfff0f000 and you zero the Rn nibble, so it can never equal PC, so you get zero hits — which looks exactly like a real negative result. That one cost me a wrong conclusion for a day.

And one thing that is not funny

Remember the private SCSI channel behind the 'G' 'P' signature. The SDK documents four subcommands. This build has nine. And this is what one of the handlers does:

add  r0, sp, 4
ldr  r1, [r4, 0x18]        ; length
bl   0x4b338               ; RECEIVE bytes from the host
ldrb r0,[sp,4] ; ldrb r1,[sp,5] ; ldrb [sp,6] ; ldrb [sp,7]
lsl/orr  ->  r2 = big-endian u32 assembled from 4 HOST-SUPPLIED bytes
ldr  r0, [r5, 0x14]        ; target ADDRESS from the control block
str  r2, [r0]              ; *** write ***

That is not “a register write”. That is a host writing an arbitrary 32‑bit value to an address, over USB, on a device you can buy for a hundred euros.

And there is no read counterpart anywhere in the image. I looked properly, with the string map, not by grepping hopefully. The two handlers that return data send fixed buffers of one and two bytes and nothing else.

Which is the worst possible combination. A register read would have been the single most useful thing an investigation like this could ask for — a way to dump the device over USB without opening it up. What actually shipped is only the half that can destroy. Four of those nine subcommands are also gated behind a state check i have not worked out yet, and i am not going to find out what they do by sweeping them on my only device.

So what is it, then

A dashcam that was told it was a microscope.

The categories were never really separate. Underneath it is one Generalplus reference platform. A brand licenses it, swaps a splash screen, ships it into a completely different market, and the economics never once justify removing the parts the new product does not use.

So my microscope carries three and a half seconds of spoken lane departure warnings it cannot play, a date‑stamp overlay picker for footage it will never record, an update mechanism named after a car video recorder, two sound effects that exist only as names in a table, drivers for two named accelerometers, a parking mode waiting for an impact that will never come, a second video pipeline for a camera that was never fitted, and the machinery to act as a USB host for one you might plug in. None of it removed, because removing it would have cost somebody a day and left the device working exactly as well.

The bit that deserves more attention than the joke: that update mechanism takes any file with the right name off the SD card root and writes it straight to flash. No signature, no checksum, no version check. That is not one brand's sloppy build — it is the reference implementation, which makes it the behaviour of every device on this platform.

Which is also the only reason i got my picture on the screen. The exact missing safety check that makes this thing trivially modifiable is the one that makes it trivially destroyable. And the manufacturer spent four emails telling me there was no firmware to give.

xecaz

26,178 bytes · 4 emails · 1 flash · 0 bricks