Reverse engineering a camera protocol for fun and profit | Hacker News Reader

Reverse engineering a camera protocol for fun and profit

thirtythreeforty.net

479 pointswilsonfiifi89 comments

I must say, out of all the things to happen on a Thursday night I wouldn't have expected to read an article where someone referenced my own code that I wrote when I was 15. (5 years ago now... time flies) Here's the file I presumed he looked at; https://github.com/nvella/sdvr/blob/master/pk.c

I was trying to reverse-engineer my parent's network CCTV DVR so I could hopefully integrate it with Home Assistant - as far as I'm aware the sluggish smartphone apps are still the only way to access those boxes. I wasn't ever able to get as far as George did with his IP cameras; I hit a snag on trying to correctly reassemble the H264 streams, so all I ever got out of it was mostly corrupt still frames.

If you're reading this George, well done! :D

I love these “it’s a small world” interactions on news.yc.

Amen! It's really touching when someone finds a bit of code that you thought would never be interesting and uses it! I've actually started a few friendships by asking questions, reporting bugs, writing random thank you notes on little code things. It's special to be reminded that you're part of the general network of humanity doing neat things, even if many things go unnoticed. :)

Also very impressive code OP!

lol, and then hacker celebrity Cliff Stoll chimes in with some nice words. This website truly is kinda special.

Hi! Author here. You saved me a good day of figuring out what all the header fields meant. I definitely appreciated finding your code!

Also... When you were 15? Geez, I think I knew what GWBASIC was at that age. Kudos again.

Cheers :) Yeah, I was one of those kids that spent most of their free time programming or otherwise tinkering with computers. I started with simple systems scripting languages before moving to Ruby and getting a proper grip on basic OOP stuff, C then shortly followed.

I don't really have any use for C today, but it definitely taught me a lot. It was intimidating at first, but when the concept of pointers finally clicked I felt like I had a sense of control in the language, and things were relatively deterministic and predictable.

I did most of my projects in C for a few years, but eventually got sucked into the JS ecosystem like pretty much everyone else at the time. These days I mostly work in .NET - C# is constantly evolving, and with .NET Core it's seemed to strike a good balance between powerful tooling, cross-platform support, performance, and just fun language features. I'm pretty content for now :)

"Your definition of fun may vary" ... happily, my idea of fun is homeomorphic to yours.

Well done!

That was a super fun read! I was super impressed with the content! It seems like the "mastering embedded Linux" is extremely rich too [1]!

[1] https://www.thirtythreeforty.net/posts/2019/08/mastering-emb...

These articles always make me feel two conflicting emotions at the same time: "I feel so inadequate because I couldn't do this reverse engineering myself" and "it feels good knowing that I'd do a better job than Charlie even though I don't even work in that industry". Poor Charlie.

charlie is a double agent who intentionally made the security weak so it could be hacked and opened. i salute you charlie, fight the power!

Charlie apparently also works at a large US car manufacturer as they do some bit mashing as well as a form of "encryption" in their software tooling (though only for the key as they then decrypt everything with the unmashed key with salted 3DES so no xor there at least).

I would love to understand the software process breakdowns that allow that "Charlie" code to make it into production! Almost everywhere I've worked, this would have been instantly caught during code review and Charlie would have had to answer to at least his peers for his crimes! Or, it would have been caught during the integration phase, as there had to be some other team consuming the byte stream and implementing the reverse to "decrypt" it. How on earth does this make it through all the gates and out into the field??

1. Were the requirements just vague? e.g. PRD just says "Encrypt the payload somehow, lol" and junior engineer Charlie, not being a crypto expert, just made something up? If so, that should have been caught and corrected by a code review. More eyes than Charlie would have at least looked at it and should have raised an alarm.

2. Did the requirements actually say "The payload shall be XOR'ed with the string 'Charlie is the designer of P2P!!' and then the bytes shuffled around as such: [...]" and everyone agreed this would be great? Where is engineering/security leadership push-back during the design phase, in that case?

3. Did the requirements call for proper encryption, and Charlie just ran out of time and cobbled this together? Again--code review, maybe insufficient project planning?

I mean, bugs slip in to code all the time, but this seems like something deliberately done this way and deliberately ignored through the entire design, development, test, and deploy process!

Non-software companies hiring a "hacker" who is cheap and can either write firmware and make firmware talk to hardware.

These types of companies don't really have things like code reviews and teams of engineers.

I used to work on embedded systems. The entire software team in the company consisted of myself and one other software developer. The only code review at that time consisted of "can you take a look at this funny bug that is occuring?"

I suspect the entire system was developed by Charlie. I've been that Charlie person. We all make mistakes, and we all need to "just get it done." There is a difference between "harden something so it cannot be exploited" and "make it so the customer cannot take one of our devices and plug it in to a competitor's device."

In my experience, anything written by/for hardware manufacturers is done under the management pressure of "Did it meet the minimum requirements? Ok good, now any extra second you spend looking at the code again is time theft from the organization. It WORKS, stop."

> I would love to understand the software process breakdowns that allow that "Charlie" code to make it into production!

In embedded systems FW-space is at a premium.

If you can avoid embedding a full crypto-stack in your firmware and replace it with 5 lines of C, which provides at least some safety, more often than not (depending on the use-case), that might be the right decision.

I mean, even if the encryption used here was proper RSA, the method discussed in this article might lead to disclosing the key and cracking the protocol anyway.

Except this thing runs a full-blown Linux! It's hardly the kind of severely space-constrained system you're talking about.

I’ve worked with firmware’s where individual megabytes matter, and they’ve been Linux-based too.

Just because it runs “full blown Linux” doesn’t mean you get more than 16MB to play with.

And if we're talking megabytes, there's no excuse not to do proper crypto. MbedTLS, for example, gives you a basic TLS stack in 64kB ROM + 64kB RAM, and a pretty splurgy one in 200kB.

Of course this can be way too much for small embedded systems, but if you can afford to run Linux and use phrases like "individual megabytes matter", you can definitely do proper crypto.

>"The only thing that jumped out to me was the appearance of a sync word at the beginning of each packet, 0xf0debc0a. (In little endian, this is 0x0abcdef0.) On a lark, I Googled this, and actually found a project on GitHub from 2015..."

That is some excellent Google-Fu!

I had never thought about Googling the reversed-endian versions of hexadecimal constants -- until you wrote about doing this; I think it's a brilliant idea, so I'm adding it to my search engine technique toolbox.

In summation, it's a great idea!

It's both simple and elegant!

What surprises me is that there aren't more users of this constant...

I usually see constants that are easier to read like 0xdeadbeef, 0x0c0ffee0 or 0xcafecafe

Also works with function names: I regularly read assembly for which I don't have the source, only debug info. If the routine I'm interested in looks like a library or framework, there is some chance it's open source - so I'll throw it into Google and see what it brings up. Even if I don't get the exact same source (e.g. don't know the exact libc version), I get an idea what the routine should do, which tremendously cuts the time I need to understand what's going on.

This is a story after my own heart.

I have written a lot of ONVIF stuff, and have done pretty similar stuff with WireShark and Cocoa Packet Analyzer.

Video is still surprisingly proprietary, even after all this time.

I got the ONVIF stuff sorted, but the challenges I deal with, these days, is providing the video in a realtime streaming format that can be interpreted by as many clients as possible (especially Apple). RT[S]P doesn’t really cut it.

Make Youtube or twitch live feed...

Now its someone elses problem transcoding the data into millions of formats for every device under the sun...

Not for internal surveillance stuff. I'm working on a platform to commoditize IP cameras and NVRs.

What prevents you from simply using Kurento with the Playerendpoint and broadcasting the stream via WebRTC?

There is even a nice sample application that you can try out without having to write any code.

https://github.com/Kurento/kurento-tutorial-java/tree/master...

Well...this is for Apple systems.

As you probably know, Apple is not just badly supported in the surveillance industry, it is actively hated.

As I was working on the ONVIF stuff, I encountered this quite often. As soon as people found out I was working on Apple stuff, the relationship would go belly-up.

I ended up not bothering to renew my ONVIF membership, because it didn’t really buy me anything.

I created a “breadboard” streaming server for ffmpeg[0], but I’ve put my ONVIF stuff aside for a while, as I work on Bluetooth projects.

[0] https://github.com/RiftValleySoftware/RVS_MediaServer

Have you looked for inspiration in Red5 or Wowza?

I had used Wowza to take multiple rtsp streams (from cctv cameras) and properly stream to multiple clients (Flash h.264 player and iOS streaming).

Yeah, I'm trying to work on-device with Apple devices (Mac and iOS, principally).

That's not-so-simple. The VLAN folks have written some excellent SDKs for their VLCKit engine, but it is quite "heavy." I've also messed around with ffmpeg, but that's not much lighter, and doesn't easily work on iOS.

Another consideration for iOS is battery use. Video tends to be a bit "piggy," when it comes to power usage.

I am sort of waiting to see who comes out of the scrum. Video is just too damn important to be allowed to remain the rather chaotic mess it's in now.

I've been in the ONVIF world. Neat standard, but most of it is never implemented.

I ended up reverse engineering a bunch of the hikvision protocol for the bits that I could not do with ONVIF.

It's a really klunky standard. It's based on SOAP/WSDL, so a lot of "modern" folks don't like it. That's not really too much of an issue in my driver. I just licensed SOAPEngine, and that layer is sorted.

I think that one of the reasons that its uptake has been slow, is because manufacturers like to keep everything "in-house," and aren't too happy to allow devices they don't make to access their equipment.

I understand that. I really do. I worked for a manufacturer like that for ages. All kinds of hell can break loose, when you move from proprietary to open. It's not a simple transition.

The people that do like it, though, are the integrators. They are the ones that buy cameras in lots of a thousand, so there is definitely a case to be made in its favor.

even old folks don't like SOAP or WSDL. They were turkeys when they were released, and now they're just old turkeys.

(I developed pyGridware, which was based on SOAP and WSDL. It took hundreds of lines of code just to build Echo Hello World.

Yup. I am quite grateful for SOAPEngine[0]. Even then, I had to do a bit of hackery (using the proper callbacks)[1], to make auth work properly.

[0] https://github.com/priore/SOAPEngine

[1] https://github.com/RiftValleySoftware/RVS_ONVIF/blob/master/...

I have a SWANN camera (some do rtsp, others not) only has port 900 open, wonder if this would work on all these "proprietary" cameras.

The camera industry is shady AF with everything listed as call-for-price. I hate trying to source anything for it.

To the author: This site has major scrolling issues on Mac Safari in certain dimensions. For example, my window width is at 1347px and when I scroll quickly the layout goes crazy and everything flashes in different locations until the scrolling or overscroll stops. Occurs on any page on this site and in many other dimensions. Doesn't happen in Chrome though.

I had weird similar-sounding issues with Firefox ESR on Linux. I didn't try to narrow it down to the exact conditions though.

Author here. How bizarre. Thanks for the report. I'll see if I can reproduce the behavior (I don't normally use Macs so I have to test ad-hoc).

On Android (Chrome/SM-T719 tablet in portrait) the sidebar occupies over half the screen.

Oh wow, what a great read. When you thought it was over, there was another entire level deeper in the rabbit hole. Fascinating post. HN at its best.

Huh, this gives me the same kind of frisson that a middle school football-crazy boy must experience when his dad takes him to a football game when Tom Brady is in town.

Or you do not know who is tom Brady and American football or even the rule, but still enjoy it very much the whole analysts. Would read the embedded one. Great work. Great read.

It's nice work. I always thought it would be a pain to implement a Wireshark decoder but I was wrong!

One other approach that could have been taken: to add the desired protocols into the camera directly. I assume you're just adding a control channel and the video stream encapsulation would be minimal.

> As a quick aside, it’s natural to wonder why this camera doesn’t support RTSP and/or ONVIF. After all, plenty of other Reolink cameras do. Because I’d like to give them the benefit of the doubt, I’ll propose the possibility that Reolink ran out of storage on this camera and had to axe some features. After all, a 16MB flash chip would cost a whole 20 cents extra. This is just a cost-saving measure and definitely not vendor lock-in, hmmm?

Don't underestimate the licensing cost of the software. Afaik most camera vendors use http://www.live555.com/mediaServer/ for the RTSP server software. There's a licensing cost for commercial use.

FWIW, Wyze manages to offer RTSP firmware (not pre-installed, but freely available on their website) for their $25 cameras.

I tried using their RTSP for my own motion detection logic (python, opencv, pointing at my birdfeeder) but the stream is too glitchy. So far the Amcrest IP2M-841 is working best for me.

8Mpix is their top of the line "premium" product. Forcing bundle with own NAS is a no brainer.

btw I wouldnt be surprised if they didnt even pay HEVC royalties.

Poor Charlie. Does anyone know of a wireshark dissector tutorial similar to the one in the article, but for proper C?

How do you have motivation to do this kind of stuff in your free time?

For me it was that I stopped reading the news, and generally 'consuming' the media. Not only did it clear out several hours in the day, but it also generally allowed me to focus on being productive instead of being outraged or saddened by whatever was being peddled that day.

"To begin, begin."

― William Wordsworth

One thing that I'd like to mention is that the author of this post attended Mississippi State University. I mention this because there is a widespread stereotype of the Deep South as a place teeming with racists, rubes, the willfully uneducated, etc... and I want to draw attention to the fact that there are also technology geniuses that come from there too.

Many great people have come from Mississippi, or passed through on their journey in life. Sadly, I think most of these great people end up leaving, thus re-enforcing some of the problems the area faces.

I was thrilled to see a rigorous reverse engineering article. It's exactly the sort of thing I always hope to find when I browse HN. But I have to admit, it was a special delight to get to the end and find that the author was a fellow MSU alum. :)

I think addressing the perception gap is part of this. No doubt that a lot of people equate "Southern accent" with "stupid." I've seen many lists of "Top 20 black engineers" or "Rising female executives in tech" but haven't seen something similar for Southerners, although I'd guess that in a typical FAANG interview the Southerner is starting out with more unconscious bias against them.

I'm a retired software dev. Before the pandemic I hadn't coded in 4 years, but somehow got the itch. One of the things I've been playing with is pointing a security camera at my birdfeeder, but I'm not so interested in clips of boring brown sparrows. Instead I want clips of bright red cardinals and bright yellow goldfinches. So I wrote some python opencv code that reacts to color changes: https://github.com/ctrager/opencv_py/blob/master/red_yellow_...

This is working for me with an Amcrest camera, but I also got a Reolink E1 thinking it supported RTSP and felt cheated when I learned it didn't. I'll be playing with Neolink the rest of the day. Thanks.

"Charlie is the designer of P2P!!" should be on a shirt.

Ha - sort of a shitty version of the DeCSS T-shirts, huh? I love it. Pity nobody would know why it's funny... Or maybe that's part of the appeal. I can't decide.

You’d be surprised how many people would get it. This thread has some legs.

Hey, I'm in the market for some ONVIF/RTSP IPcams and saw Reolink highly recommended time and time again. Upon seeing how their 8MP cams don't have ONVIF but <=5MP do, I found this write-up just a week or two ago. Really cool work! I hate to say it with the author in the room, but I pretty quickly decided on 5MP to have everything work natively without also running bleeding edge middleware ;)

I wonder did the Great Scrambler Charlie read this post. Proper encryption takes time, just XOR it, XOR it all he always says :)

Great job and realy well written post.

Things I have reverse engineered in recent memory, that perhaps deserve a write-up.

Nextwave Piranha CNC protocol -- easy, about three days of work Virtucache for VMWare ESXi -- easy-ish, about five days of work to completey take apart SONY camera firmware -- quite hard, about two weeks of work Loc8tor tracking tags - easy once I understood how active RFID works

Fantastic read. I feel very stupid now though xD

These reverse engineering posts always do that. I'm pretty good at developing software but I see people pull off insane reverse engineering efforts like extracting encryption keys from a chip with 1000 security measures and I wonder if I know anything.

Same here! Then I remember that problem to solution only takes a sentence or two in the article, but might be few days of dead ends irl.

Absolutely.

I found myself wondering while reading the article what the guys notes look like. Does he screenshot everything and bullet point as he goes along? Or does he hit a logical stopping point and write up what worked from A-B, B-C etc.?

It's massively inspiring though.

These blogs kinda downplay the problem being broken down little by little.

Forensics work is the same... you don't naturally get a report that says the person did something, it's basically a list of things you try that lead to other things that lead to dead ends or an answer.

I'd like to know this too. Lately when I've been getting into something new or trying to solve a non-trivial bug/problem I've tried to keep notes as I go along in the hope of finally creating some blog content. I keep finding this extra step really slows me down and I forget to keep doing it at some points so what I end up with isn't even very good. I think this is just another skill I have not mastered (or even fundamentally grasped).

My other wonder was how long it took to go from "i've got this camera" to "i've written this software". I imagine it's on the order of weeks.

Which means you could probably do a daily journalling exercise. What you tried, what worked etc.

It's interesting to wonder about, but i imagine the dead ends, looking up docs, writing debugging tools is too boring to put in a blog

Oh for sure, it would have to be heavily edited from that complete set of notes. Although, even if my blog is so boring that I'm the only reader, I'd still be happy to have written it as that writing process will massively increase my chance of remembering what I learned.

Yeah, and the only way to get better at writing stuff up, is to write stuff up.

The screenshots were definitely taken near the end of the project, while I still had it all in my head but before I started writing.

In general, the process looked like:

- Brainstorm and reverse engineer first. Have in the back of my mind that I'm writing this up, and releasing a tool, at the end. This guides my search: no your reader won't want to desolder something to use their camera, so yes you need to speak the stock Baichuan protocol.

- As I hit interesting things (like the Charlie Scrambler) start filling out a Google Keep note with keywords that will remind me of them when I'm writing.

- Take screenshots and produce other media, giving me a rough layout of waypoints that the article has to hit.

- Write the article, editorializing optional but recommended.

For me, my "writing mindset" is very different from my "engineering mindset." Some days, I can pound out a new piece of code and sometimes it will even be a decent design. Other days, I can write clear documentation. Very seldom can I do both on the same day.

Just like the Wireshark dissector takes only a few sentences in the article, the author himself says it's more like a few hours to write one

It's just about poking at it and being persistent, until you figure everything necessary out. I've done similar reverse engineering efforts with a PoS terminal and an e-book reader/eInk display protocols. You don't know much at the beginning. Reverse engineering is mostly about persistence.

It may not always get you to the finish line, but without any documentation, persistence and some tools is all you have anyway. Knowledge is acquired during the process.

Where can I purchase one of those SOIC sockets?

https://www.adafruit.com/product/1284

Looks like this is not the drop in solution that the article used. Apparently the mentioned white small drop-in socket is from TaoBao but I couldnt find it there, neither on ebay...

I found someone selling them on AliExpress, though at a high price point: https://www.aliexpress.com/item/4000990317952.html

If you don't mind a different style (clam shell), you can get them for significantly less: https://www.aliexpress.com/item/33025755888.html

I suspect both AliExpress listings are an order of magnitude more expensive than they can be purchased on Taobao, but then you have to A) find it on Taobao, and B) use a shipping agent in China to export it.

Found a US-based seller who has them for $3/each (min quantity 10): http://siliconkit.com/ocart/index.php?route=product/product&...

Ah, the model number is listed on the flashrom wiki: https://www.flashrom.org/Technology#SO8.2FSOIC8:_Small-Outli...

Edit: Here's the Taobao link: https://item.taobao.com/item.htm?id=576521466919

Thank you, I've been drooling over them on Dediprog for a while: https://www.dediprog.com/category/smt-sockets but their MOQ is slightly offputting; I'd like just a few of each style to have on-hand.

It's a "Wieson IC socket" - I originally got them here on Taobao for $1.50:

https://item.taobao.com/item.htm?id=529625834683

and looks like others have pointed out various resellers.

How can I get started doing something like this? Maybe there is an ASK HN about this. Can someone point me to that?

I bombed digital systems classes (I didn't actually fail, but I really suck at it) and I want to get better. I give out this info just to relay my feeble grasp at what is happening here.

Super cool! I've never done any embedded device work but have an interest.

Seeing the layout of the flash in a straight forward image like this is pretty inspirational honestly. Definitely will be checking out more of his work.

For those of us interested in beginning to do RE, what does everyone suggest?

Definitely a blog I'll have to keep track of.

Great job!!! open some eyes on video world. Would start to hack my video camera.

I don't really understand the busybox step. Can someone expand on what is happening there?

I don't really understand the busybox step? Can someone expand on what is happening there?

Using binwalk you can unpack existing firmware and later you can build some exec for same architecture (can be MIPS or ARM) and repack in new firmware.

Nice work dude!!

Brilliant.

Reply on news.ycombinator.com