This post is an introduces a series of “Deep Tech” articles on hacking (reverse engineering) trail camera firmware. The goal of this reverse engineering project has been to add new features to multiple Browning Trail camera models, as well as to debug and apply fixes to firmware bugs. For examples of results, see posts based on this work: IR to White Flash Trail Camera Conversion, Adding Features to Browning Elite HP5 Firmware, New Optional Features for Browning HP5 Trail Cameras, New Features for Browning Recon Force and SpecOps Cameras, and Deep Tech: Repairing EEPROM in Browning Trail Cameras, and Fixing Browning Edge, Elite HP4 and HP5 SD Card Corruption

In this series, I will give background and explanation of a set of tools I developed along the way. These tools are available on my GitHub site. I will also explain how I used Ghidra, a powerful open source reverse engineering tool, to disassemble, decompile, and annotate the firmware from several generations of cameras. Unfortunately, I am not able to provide open source access to this (albeit critical part) of the firmware reverse engineering solution in order to respect the copyright on camera source code. Still, with the overall process laid out, anyone interested can, in principle, independently reproduce this work.

In the rest of this post, I will introduce topics which will be covered in separate posts in the series.

Requirements

There are many possible goals for any hacking project. When I started this project, my goals were modest. I wanted to convert an IR flash camera to white flash so that it could take color photos at night. Based on some early experiments, I optimistically guessed that I might be able to accomplish my goal simply. Perhaps by modifying a single key instruction in the firmware — say the one which switched between daylight and night time mode — and I would achieve my goal. This guess turned out to be wildly optimistic. It quickly became clear that such a simple approach would not work. 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 somehow get it into a firmware image that I could load into the camera.

This upcoming post on Deep Tech: Trail Camera Firmware Hacking — Requirements will focus on the requirements. I will also list some “non-requirements” that help bound the problem.

Business Considerations

Readers of this blog sometimes comment, “I wish Browning would allow customization,” or “I wish Browning would support improvement XYZ”. In this upcoming post Deep Tech: Trail Camera Firmware Hacking — Business, I will speculate on the reasons that firmware customization is not typical in the trail camera market. I will also note exceptions. No one will be surprised that these reasons are grounded in the business models and financial interests of several companies (and types of companies) involved in making, marketing, selling, and supporting trail cameras.

Trail Camera Theory of Operation

To understand the details of a hacking project, it’s critical to understand the basics of how the target system works. In the Deep Tech: Trail Camera Firmware Hacking — Theory of Operation post, I will document what I found out to give readers a framework for understanding the technical context of the reverse engineering flow.

Reverse Engineering Tools

The key to any computer project is a set of tools tailored to solve specific aspects of the overall task. Because these tools are small projects in their own right, I dedicate a post to each.

Reverse Engineering Flow

As with any complex engineering project, it is important to break down a complicated process into a series of steps, or, a “recipe”, if you will. In the post Deep Tech: Trail Camera Firmware Hacking — Reverse Engineering Flow I will cover a set of steps I have used to reverse engineer the firmware in several models of Browning Trail cameras. With benefit of hindsight, I will focus on what has worked, and leave out a series of ultimately unproductive steps. This flow is largely laid out in a Colab worksheet, making it easy to pull together 3rd party and external tools, into cloud execution environment. See: “Deep Tech: Trail Camera Firmware Hacking — Tool Flow”

New Functions — Source Code Overview

In several past posts, I describe new functions that I have added to some Browning Trail camera models. See:Adding Features to Browning Elite HP5 Firmware, New Optional Features for Browning HP5 Trail Cameras. In this post, I will give an introduction to the source code I wrote to implement these features. See: “Deep Tech: Trail Camera Firmware Hacking — Source Code Overview”

Up Next

This post is a set of “coming attrractions” for more detailed posts to come. These posts will document the deep technology involved in reverse engineering and subsequently hacking of trail camera firmware.

I realize the audience for this particular series is small. Yet it seems worthwhile to share these learnings with the small set of possibly interested parties. These may include researchers, trail camera enthusiasts, and (perhaps even) trail camera manufacturers. As I have discovered, there is both an interest in customizing trail camera firmware on the part of consumers and researchers. There are also good reasons why trail camera companies themselves are unlikely to do this. Thus, this work may address a long term niche.

Feedback

The rate at which I make it through this series, and the amount of detail in each post will depend, to some extent, on feedback from readers. Please comment below if you’d like to see more faster.