Reverse Engineering Reveals Hidden API In Abandonware Trail Camera

It sometimes seems like there are two kinds of cheap hardware devices: those dependent on proprietary software that is no longer available and those that are equally dependent but haven’t been abandoned just quite yet. But rest assured, abandonment is always on the table, and until then, you get to deal with poorly written apps that often suffer from a crippling lack of essential functionality.

Such was the case for the wireless game camera that [Chris Jones] scored on the cheap, but rather than suffering with the original software, he decided to reverse engineer the camera and turn it into something more useful. The eBay description was promising — Bluetooth LE! WiFi! — but the reality proved less so. To save the batteries, WiFi is off by default and can only be turned on by connecting to the camera via BLE using a janky and crash-prone Android app.

[Chris]’ first step in reverse engineering the camera was to snoop into the BLE by capturing the Bluetooth packets to a file and running them through Wireshark. This revealed a write command with the text “BT_KEY_ON” — very promising. After verifying that this command turned on the camera’s access point, [Chris] got to work capturing WiFi packets using PCAPDroid and analyzing the results, again with Wireshark. Using every function available in the OEM app eventually revealed the full API on the camera, which gives file system control, access to individual images, and even putting the camera into live video mode.

With the keys to the kingdom, [Chris] was able to do a proof-of-concept bridge to the camera using an ESP-32, which wakes up the camera’s WiFi with a BLE tickle and interacts with its API. Future plans include a full-blown bridge based on a single-board computer to unlock the full potential of the camera.

Sure, it might be cheaper, in the long run, to just build a trail cam from scratch, but where’s the sport in that?

12 thoughts on “Reverse Engineering Reveals Hidden API In Abandonware Trail Camera

  1. “Game” camera? It is a trail camera for capturing wildlife pictures.
    Same models seems to exist under at least one another brand: Campark.
    For iOS, there are several applications to control them, depending on the model. There are developed by “Ocean Wang” or “Shenzen Fuxin Electronics Co. Ltd”.
    In addition to indeed very clunky apps, there are also strange claims about there capacity.
    For example Campark TC06 or TC07 are advertised to be the best picture quality on the marker, with 4K video and 60MP photo, and use a 1/3” CMOS Sony IMX458 Starvis image sensor.
    But this sensor is only 13MP, far from the advertised 60MP !
    Also, in night mode, video is limited to 1296p 30fps, and photo to 8MP. It seems from the description that there are in fact 2 sensors, but there’s no details about the second one in the specifications.
    In 4K/High MP mode, the application is barely usable, because Wifi communication seems to be quite slow, so the lag is awful. Or maybe is the application poorly coded.

    1. “Game” – any non-domesticated animal hunted for food or sport. Although the camera will also faithfully capture pictures of grizzly bears, which will hunt *you* for food or sport.

    2. With a 1/3″ sensor you could get at best 2MP in night mode. To get a “usable” 13MP color image you need the sun to be in zenith and completely unobstructed.

  2. always glad to see a reverse engineering for usability succeed!

    i want to add a third kind of cheap hardware. well, i’d say the same categories apply to expensive hardware too. but the third kind is something using open standards. a decade ago, i got a camera that spoke http and trivially gave up a concatenated jpeg stream over http. to put it mildly, it is not without faults, but i am not concerned about support, and i would reject a firmware upgrade if it came knocking.

    the great thing about it is it really feels like it was something someone just hacked on for a week and then said “ship it”. like, they only used open standards because that was coincidentally the easiest thing to do. win!

  3. I have a white brick of camera made by D-Link. I’m not going down the rabbit hole of hacking it, but if somebody has I’d give it a try. The camera web-software died in ’19.

  4. This is most helpful for the details on spying on communications. Useful for things like my 24s BMS and/or cheapy smart watch (I’m not going to use a crappy app, either watch is smart or its not, Google needs a simple API native to Android.)

  5. Glad that the author managed to reverse engineer it, but for all others that’s just one of the many products doomed to end their life prematurely in a landfill because of crappy software and no will from the manufacturer to publish technical information so that better firmware, software and upgrades could be written by others. And of course cellphones are the 1st example of that coming to mind.
    Closed source isn’t just bad, it’s harmful plain and simple.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.