This post will focus on the requirements on developing tools and a tool flow for reverse engineering and hacking trail camera firmware. It is part of a multi-part series. See Deep Tech: Hacking Trail Camera Firmware 1 — Overview for context and pointer to other posts in this series.

Background

When I started this project, my goals were modest: I wanted to be able to convert an IR flash camera to use a white flash so that it could take color photos at night. See: IR to White Flash Trail Camera Conversion and DIY: Converting BTC-7A from IR to White Flash. Based on some early experiments with my target camera, I optimistically guessed that I might be able to accomplish this by modifying a key instruction in the firmware — say the one which switched between daylight and night time mode. This guess turned out to be wildly optimistic. It soon became clear that even if such a single instruction existed, I would need to be able to figure out where it was in the overall firmware image. As importantly, I would need to figure out how to get it into a firmware image that I could load into the camera.

Even as I made progress on these challenges, my goals for the project expanded. If, I reasoned, I could change the code in the firmware, then I could insert new or replacement function calls, which would allow me to make arbitrary and fairly complex additions to the trail camera firmware. Since new trail camera models are introduced on a regular basis, it also became clear that I would need to support mutliple generations of trail cameras, and different models. This, in turn, places a requirement of an automated build process.

Which leads to the final statement of requirements

Requirements

Support a Single Vendor

There are a lot of camera vendors out there, but I quickly determined to stick with the one. We typically use Browning trail cameras because of their high build quality, reliability in the field, and image and sound quality. So that’s what I chose.

Support a Limited Number of Models

Browning has a quite diverse offering of Trail Cameras models. Somewhat selfishly, I decided to focus on a limited number of models that we actually use. We tend to use the SpecOps and ReconForce models, which share most of the firmware and software. They differ primarily in the type of IR Flash.

For whatever reason, these models have some features which made reverse engineering them much easier. In particular, a internal serial port which can help in debugging firmware modifications. I did look at lower end models, but found that they were missing this port. Debugging firmware without a terminal is like flying a plane in zero visibility and no instruments. You can tell whether you’re flying, or whether you’ve crashed, but not much in between.

Add New and Modify Existing Features

I wanted to modify existing features, for example, creating an “off” selection for the IR flash power. I also wanted to be able to add completely new features, such as a coulomb-counting battery meter. This requirement meant that I would need to understand the key functional interfaces I was interested in, as well as their calling conventions.

Selectable Functions via Menu System Interface

Some of the features I prototyped early-on were generally useful. For example, displaying the time and date of the photo or video on the playback screen to make easier to review the timing of photos and videos in the field. Other features, such as the selection of time or date format, would need to be set differently for different users. I considered developing different firmware images for different features, but as the feature list expanded, it became clear this would be a support nightmare.

Instead, I determined that I would need to integrate the use of some features into the existing menu system.

Do as Much Software Development as Possible in C

I started this project by imagining that it might only be necessary to tweak a couple of instructions, or data values. However, as I got deeper into the project, I realized I wanted to build some fairly complex additions. The key to writing and maintaining such code is to use a high level language. I chose C because it matches the decompiled code produced by Ghidra. I’m also familiar with it, and it is well-suited for embedded application development.

Support multiple Generations of Trail Cameras

I started this project with our favorite trail camera at the time — the Browning Recon Force Advantage series cameras. Unfortunately, this camera was well past its release date when I started. By the time I got the first version of my tools working, the Advantage was no longer available. The cameras we were buying, and the requests coming in, were all for newer models. This all made it clear that it would be important to track the current product releases.

This requirement resulted in my spending more time in my toolset developing multi-target-camera automation. Ideally, once a camera is “added” to the suite, it can incorporate all the enhancements developed to date.

Non Requirements

As with most engineering projects, it is important to limit the requirements in order to reduce complexity and/or reduce the work and time required to produce a result. Here is a short list of critical “non-requirements”. Readers who find their own wishes in this list of “non-requirements” will need to go beyond the tools and and processes I document in this series.

Multi-Vendor Support

There are many trail camera vendors. From what I could tell looking at the user interfaces and SOCs used by these different companies, it seems clear that the application software is different. On the other hand, it also seems clear that much of the low-level firmware may be shared by multiple vendors. I did not explore this boundary. It may be relatively simple to add multi-vendor support to a set of tools. But I suspect not.

Full Open Source

I decided against a full open source software model because it would have required a complete, grounds up replacement of the camera’s application and OS stack. This is a lot of code and it is very difficult to replicate from the “outside.” This because I have no access to the SOC documentation, software libraries, or build tools. These are made available by the SOC supplier iCatchTek to registered developers only, and are themselves, probably not open source. Given the complexity of the hardware interfaces in the SOC, developing and independent software stack would be many 10’s of engineer-years.

I also considered a model whereby I might define an architected software interface which could cleanly separate the proprietary factory firmware from a public, full-function, open source software modules. Unfortunately, as I prototyped some of the most common features and functions suggested on our Facebook page, it became clear that implementing these functions would only really be possible with an intimate knowledge of the underlying factory source code. I.e. that no interface, short of one which exposed the whole proprietary software stack, would really enable a broad set of possible additions.

Comments and Coming Attractions

Please let me know if you can think of major requirements that I’ve missed.

In the next installment, I’ll speculate on why trail camera vendors, and the whole trail camera ecosystem, don’t generally provide this type of firmware customization.