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.
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 :)
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. :)
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 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 ;)
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
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.
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.
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.?
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.
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).
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.
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.
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.
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...
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.
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.
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