Worthy thread to ask: is there such a thing as a white label IP camera (or similar) with a supported open firmware? Not asking for open source, but something close to plug and play that nonetheless has a way of stripping the rootfs as desired for bespoke use in a manufacturer-supported way.
I have looked around before but I only found genuinely dev-oriented kits that weren't even in a shell, and crazy priced.
Not exactly open firmware, but something like ONVIF on an isolated network is pretty close. An ONVIF camera should talk to basically any NVR (network video recorder), there are several open-source ones available.
There are tons of ONVIF-compliant and cheap PoE cameras, and with this setup you really don't care about the security of the manufacturer firmware since you aren't exposing them to the network publicly. However, you do need to be extra diligent when configuring your VLAN/network segmentation.
Getting this right is hard, speaking as someone who has ARP poisoned an exposed ethernet connected to some cheap switches to monitor cameras in whole buildings before. The problem is the endpoint itself, adding layers on top doesn't solve things. Ideally I'd like a device that could be connected to public wifi and still be robust. For example including padding any data it's transmitting to avoid observable compression side effects being usable as a proxy for motion detection (which is a cool trick you can try even without a working wifi key)
For anyone who wants a setup like this but the nice notifications and quality of life capabilities (recordings, easy remote access for family), and are ok being on Apple infra (end to end encrypted) -
ONVIF camera (or one compatible with Scrypted)
Block WAN (ideally, VLAN) on the cheap cameras
Home computer to run Scrypted
AppleTV (for Apple home bridge)
This is what I moved to after getting away from Ring and it works quite well. Reolink cams, old desktop, and an hour of setup.
There is also https://thingino.com/ which has a clear set of supported cameras. The installation is straight forward if you choose a cam with SD-Card flashing support. I upgraded two of the Sonoff Slim Gen2 without any issues.
I found Thingino to be very buggy and frustrating to use despite using 2 different supported cameras. The stream would constantly drop out, services would sometimes crash and wouldn't get automatically restarted. I tried tweaking all available parameters, resetting, updating but eventually I just gave up (a few months ago).
Not exactly what you have asked for, but ESP32 based M5Stack and Seeed Xiao modules might fit the bill. They are not so expensive, are Linux-free, and there's no report so far of secret ping home features in the SDK.
Would it be so difficult to include a simple plastic case? Having to find/design 3D printed cases adds time to getting these projects set up. I don’t have a 3D printer and have to go to the local maker space to make anything.
I was working with Raspberry Pis, starting with a college honors project, around 2018.
For a while, I thought about building a network of surveillance cameras around the interior of my home. The Raspberry Pi seemed like a tempting platform to hook up a bunch of cameras to it. Sadly, I could not find a backend surveillance app or system that was suitable for running such a network. The best one I found was some kind of modular Linux app that was for-pay, and actually seemed based in Russia or something, and personally I wasn't comfortable about handing over my domestic surveillance needs to Russia!
I also considered exterior sensors, such as a camera, or perhaps a nice little weather station, outside on my balcony, running on the little Raspberry Pi.
Then I recalled two things: I live in the Sonoran Desert, where the desert highs can go up around 115℉, and any plant on my balcony was guaranteed to wither and die, not to mention the blowing dust and thunderstorms we have.
I determined that there was basically no way to house or protect a Raspberry Pi, as well as supply it with connectivity and electric power, and keep it outside on the balcony in conditions where I'd benefit from those active sensors. Sad but true!
I so want these to be a viable solution but man my experience so far is that it can barely be made to work and only in the most favorable environments. Compare that to the blink cameras I used to run outside where it occasionally went below -20F and they still went over a year on a couple batteries.
I wish...
The best I've found is https://openipc.org/ which is a very manufacturer unsupported way of reflashing certain chips with open-source firmware. It seems very fiddly as only certain SoCs are supported and good luck finding out if a specific Chinese camera has one.
I do know of at least one company who has black-holed the entire DoD ip space and are using it for internal space, which is why I gave a speculation warning... it's really strange regardless.
I recently troubleshot an installation for someone where at some point in the past they'd picked 1.1.1.0/24 as their address range because "all that 192 stuff was silly and too complicated".
You know, I'm not sure I can explain how I feel about this properly without waving the shotgun around.
Interesting -- seems like the side effect would be to basically prevent use by the DoD but not really anyone else. Bonus points if they sell a "government" version for higher cost
I also know of a company who does this. The reason in their case is they act as a network concentrator, bridging hundreds of client IP spaces, so this helps them avoid conflicts with their own space without having to NAT constantly. There is still a lot of NAT for the more common ranges.
I don't remember which but one of the major US cellular networks was using the DoDs 7.0.0.0/8 internally. It was never an issue since the DoD kept that /8 offline but the IPs would show up in traceroutes. I had to tell many people to ignore it.
I used to work somewhere that did that. Several of us in Eng pointed out that it was likely impossible to sell anything to DoD personnel since the reply would route internally. But I don't know if it was _fixed_, was still an issue when I left.
there's a couple subnets I (ab)use in the DOD IP space for my home network knowing they'd never put them on the open internet. it's also fun to throw logging for a loop if someone digs.
n.b., it's the Department of Defense, just like the Kennedy Center doesn't have Trump's name attached, and the large body of water by Texas is the Gulf of Mexico.
just buy stuff you can put your own firmware/os on because it's either just the worst security in the world (aka anything not from china) or, well... china.
and while i currently don't hate china as much as i do US rn (because canadian; sorry) i can also say -- due to being an aforementioned leaflandian -- that due to very personal experience i have zero faith in anything from china that has the ability to connect to any type of network :')
And so yeah at this point if I can't at the very least get a whatever-wrt firmware (preferably a proper linux distro nowadays; not to say the *-wrt firmwares aren't a real OS but, y'know) on the device i just avoid them entirely since, well... it's all i can do at this point because even if there were baked in hardware-based backdoors i as an individual can't do much more than that.
Not surprised, many of these vendors are doing crazy things, insane defaults, broken security, hardcoded values. Security is not a priority, I get that, but at the very least some baseline check would be nice (no hardcoded credentials for starting)
There's also some irony in people happily ignoring that so many of these products live-stream the inside view of their homes and offices to some foreign corporate cloud - and in the case of suspiciously many Chinese security cameras, a state-backed corporation's cloud. Because, wow, it really is convenient.
I bought some ambient room lighting recently. You cannot control them without a proprietary app. This bugged me ... so I grabbed an APK from the Google store, unpacked it, and found essentially keys to the kingdom: api keys for the backend, api keys for shopify, etc. Haven't done anything with this knowledge yet.
> Anyone who cares about security will be using App Attest or the Google store equivalent.
Why? I rarely have security objectives where remote attention would help, and it has a huge impact on user freedom. For B2C attestation is just an evil captcha.
Have you actually tried to do anything with them though? The keys are in there, but may not grant you any real extra access beyond what your user is actually allowed to do via the app.
It is still pretty nice, you don't have to install yet another app to do something. People did this with Mazda app as it allowed them to start the car without subscription. They 'fixed' it.
Another rule of thumb - i know it's not always the best since some products are really nice aesthetically - is to buy only local smart stuff, for example, zigbee/zwave.
I live by this rule*. Being able to pick up stuff from IKEA that's well supported, well designed and really affordable is a huge advantage.
*almost, I have two things that need an app. My Vaillant boiler and my Yale alarm system. Both apps are terrible, but I have a 10 year warranty on the boiler and my alarm is up to scratch from a home insurance point of view.**
Ugh, that's a new low. I can't think of a single good reason a lighting app would need shopify api access.
That said, I've done some consulting work on shopify stores, and I wouldn't be shocked at all to see something like that at all. The bar for code quality that a lot of low end consultants/designers deliver is just abysmal.
In many cases it is bad to publish this info because they might come after you. There used to be a company who shielded the “researcher” from the legal consequences, can’t remember the name though.
buy any dongle that sells for under $100 on amazon. they all have the same mac, and come with 'bespoke' apps to let you do things to your car. those apps are all thin wrappers on code widely shared; they use the MAC of the dongle as the keystone for ID.
Short story: buy one cheap dongle on Amazon, dump the MAC (00:11:22:AA:BB:CC IIRC; it's been 15 years since I cared) and you have auth to all of the apps everywhere.
Reminder: the Bluetooth logo comes, mostly, from self-certification.
And it's worth considering that obfuscation only ever worked against casuals for whom tedious was a bridge too far. Nation state actors and criminal hacker groups, on the other hand, consider the tedious entirely worth it.
Entirely without LLMs, I'm imagining an office of North Korean compsci graduates doing astonishingly tedious tasks, for whom an office job on a basic Linux computer and slightly better diet and nice apartment put them in the top 1-2% of living standard in the country.
I'm 100% confident in hardware companies' ability to make infinitely incompetent software given infinitely smart agents. They do it because they don't care about software, not because they lack tools. No agent can turn them into software companies if they don't want it themselves.
Back in the mid-1990s, I was working at an ISP and also at a consulting firm. The consulting firm's #1 business at the time was to get businesses connected to the Internet, where these businesses already had significant LAN buildouts.
Now these were the days before IANA had officially assigned those "Private IP Network" numbers. Nobody had any private IPv4 space to work with! So the choices consisted of: make up some numbers and hope they don't conflict, or go ahead and register your IPv4 space and get public netblocks assigned, even if you're just using them privately.
So, needless to say, we encountered some bonkers configurations, and a lot of our job was undoing some really awful configurations in order to make them compliant with actual Internet connectivity, and so that different office LANs would interoperate properly.
We were also big advocates of security, firewalls, and the venerable "DMZ/Bastion" setups from back in the day, so those Private IP Network assignments would've been really useful, along with NAT, but we simply didn't have those tools at our disposal, and our clients were basically registering huge IPv4 blocks that they really didn't need to ever use.
The CSS selector they used (`a[href*="://"]::after`) is meant to only target only external links, but assumes any internal links will be using relative paths like `href="/about"`. The problem is that this site uses absolute URLs (`href="https://hhh.hn/about"`) for its nav links, so every link ends up with an icon.
You could fix this by adding an exception to the CSS rule so it skips links starting with your site's name:
It’s kind of interesting - I imported security cameras for a business roughly twenty hours ago. The security problems at the time were unbelievable to a point that any kind of wireless, IP or any type of service offering remote view was really scary. It was always stupid stuff - little oversights, things that were hard coded and shouldn’t have been or extremely old versions of insecure software running critical functions.
what a good blog to read. Have you found answer on why they use the same token across these bunch of files? Maybe they are tying to adopt the agentic code writing?
One interesting questions, what does that gh token give access to? It is only read from private repo, is not it? You said "admin" privileges earlier.
the same token copy-pasted into 30 files. not even a config file. they baked their github admin credentials into the firmware image like it was a version number.
> Why would Hanwha Vision need anything remotely related to the DoD? Is it possible that their CI is provided by some centralized team at their parent company Hanwha, where the needs of their sister company Hanwha Aerospace cause the shared platform to have these entries in the CI environment variables? Or maybe because of their other sister company, Hanwha Defense USA, where they make other large scary steel machines
Or... the Department of Warmongers (nee DoD) addresses on the device are evidence of a supply-side attack targeting the DoW and carried out using the aforementioned github admin token.
... I mean, while we're in here speculating about truffles and all.
My cameras are analog rather than PoE or IP based, but that's just because I set up the initial iteration of the system a long time ago. The standard now is to give your camera an IP address.
With many IoT type things I block access to the public internet. I think with cameras specifically a lot of people even set it up physically on a different network that can only talk to the NVR.
But tldr, basing the cameras on IP invites some of the things in this article. Anyone deploying these devices needs to think about securing them.
Why would you write like that? Not capitalizing the first word of a sentence makes the whole thing less readable. So that you can feel special? Really?
Abusing IP ranges which were assigned to an organization but aren't actually used on the public Internet as private addresses is pretty common. Sure, it's bad practice, but not a big deal.
I know you're a mastermind when it comes to security, but you should provide more context about the tools and methods you're using in your article so we can better understand what it's all about and not have to Google every single step you're taking.
I feel like every security blog (or even just tech blog) I've read recently has had paragraphs and paragraphs of largely LLM generated explainer waffle. This felt refreshingly focused and to the point.
i’m not a mastermind, and I agree it could be more accessible. I treat this blog as somewhere to just dump my thoughts as unfiltered as I can while still being useful or entertaining, maybe for some other posts I will go more into depth
Seemed perfectly reasonable to me. Not everything has to be written for a target audience that includes you, besides you were able to look up what you needed it seems. Another tactic is to feed the article to your favorite LLM and interrogate it about what you don't understand.
Worthy thread to ask: is there such a thing as a white label IP camera (or similar) with a supported open firmware? Not asking for open source, but something close to plug and play that nonetheless has a way of stripping the rootfs as desired for bespoke use in a manufacturer-supported way.
I have looked around before but I only found genuinely dev-oriented kits that weren't even in a shell, and crazy priced.
edit: seems there are some options now (or I missed them before), e.g. https://www.goodcam.io/#for-independent-developers
Not exactly open firmware, but something like ONVIF on an isolated network is pretty close. An ONVIF camera should talk to basically any NVR (network video recorder), there are several open-source ones available.
There are tons of ONVIF-compliant and cheap PoE cameras, and with this setup you really don't care about the security of the manufacturer firmware since you aren't exposing them to the network publicly. However, you do need to be extra diligent when configuring your VLAN/network segmentation.
Getting this right is hard, speaking as someone who has ARP poisoned an exposed ethernet connected to some cheap switches to monitor cameras in whole buildings before. The problem is the endpoint itself, adding layers on top doesn't solve things. Ideally I'd like a device that could be connected to public wifi and still be robust. For example including padding any data it's transmitting to avoid observable compression side effects being usable as a proxy for motion detection (which is a cool trick you can try even without a working wifi key)
For anyone who wants a setup like this but the nice notifications and quality of life capabilities (recordings, easy remote access for family), and are ok being on Apple infra (end to end encrypted) -
ONVIF camera (or one compatible with Scrypted) Block WAN (ideally, VLAN) on the cheap cameras Home computer to run Scrypted AppleTV (for Apple home bridge)
This is what I moved to after getting away from Ring and it works quite well. Reolink cams, old desktop, and an hour of setup.
There is also https://thingino.com/ which has a clear set of supported cameras. The installation is straight forward if you choose a cam with SD-Card flashing support. I upgraded two of the Sonoff Slim Gen2 without any issues.
I found Thingino to be very buggy and frustrating to use despite using 2 different supported cameras. The stream would constantly drop out, services would sometimes crash and wouldn't get automatically restarted. I tried tweaking all available parameters, resetting, updating but eventually I just gave up (a few months ago).
e.g. https://github.com/themactep/thingino-firmware/issues/640
I bought the cheapest PTZ camera they have listed and, as you say the install was easy. The interface is useful and it does what it says on the tin.
I also use thingino and it was very easy to use. It has wireguard support, but I just set up my firewall so cams are only accessible over tailscale.
You can get close.... I guess...
Some cameras do support thingino, so you can override their firmware. Then there's this: https://openipc.org/supported-hardware/featured
Seems like the shop is broken?
> Stránka nenalezena
> There's been a glitch...
> We're not quite sure what went wrong. You can go back, or try looking on our homepage.
Huh, it was working an hour ago. The outdoor 8MP variant was around the 85 euro mark.
Czech for 'page not found'
Not exactly what you have asked for, but ESP32 based M5Stack and Seeed Xiao modules might fit the bill. They are not so expensive, are Linux-free, and there's no report so far of secret ping home features in the SDK.
ESP32 are powerful enough to run realtime image processing?! Wtf.
1 reply →
Pinecube from pine64.
https://pine64.org/devices/pinecube/
Would it be so difficult to include a simple plastic case? Having to find/design 3D printed cases adds time to getting these projects set up. I don’t have a 3D printer and have to go to the local maker space to make anything.
1 reply →
You would be better served using a USB capable camera behind an RPi to have assurance that broken firmware isn't compromising your network.
I was working with Raspberry Pis, starting with a college honors project, around 2018.
For a while, I thought about building a network of surveillance cameras around the interior of my home. The Raspberry Pi seemed like a tempting platform to hook up a bunch of cameras to it. Sadly, I could not find a backend surveillance app or system that was suitable for running such a network. The best one I found was some kind of modular Linux app that was for-pay, and actually seemed based in Russia or something, and personally I wasn't comfortable about handing over my domestic surveillance needs to Russia!
I also considered exterior sensors, such as a camera, or perhaps a nice little weather station, outside on my balcony, running on the little Raspberry Pi.
Then I recalled two things: I live in the Sonoran Desert, where the desert highs can go up around 115℉, and any plant on my balcony was guaranteed to wither and die, not to mention the blowing dust and thunderstorms we have.
I determined that there was basically no way to house or protect a Raspberry Pi, as well as supply it with connectivity and electric power, and keep it outside on the balcony in conditions where I'd benefit from those active sensors. Sad but true!
9 replies →
ESP32-CAM
I so want these to be a viable solution but man my experience so far is that it can barely be made to work and only in the most favorable environments. Compare that to the blink cameras I used to run outside where it occasionally went below -20F and they still went over a year on a couple batteries.
Pine cube
https://pine64.org/devices/pinecube/
Thank you. Ordered one to play around and see if this is a viable alternative.
I wish... The best I've found is https://openipc.org/ which is a very manufacturer unsupported way of reflashing certain chips with open-source firmware. It seems very fiddly as only certain SoCs are supported and good luck finding out if a specific Chinese camera has one.
[dead]
The US Department of War IP adresses baked into the firmware is the bigger story here. Note to self: never buy a Korean security product.
I do know of at least one company who has black-holed the entire DoD ip space and are using it for internal space, which is why I gave a speculation warning... it's really strange regardless.
I recently troubleshot an installation for someone where at some point in the past they'd picked 1.1.1.0/24 as their address range because "all that 192 stuff was silly and too complicated".
You know, I'm not sure I can explain how I feel about this properly without waving the shotgun around.
80 replies →
Interesting -- seems like the side effect would be to basically prevent use by the DoD but not really anyone else. Bonus points if they sell a "government" version for higher cost
I also know of a company who does this. The reason in their case is they act as a network concentrator, bridging hundreds of client IP spaces, so this helps them avoid conflicts with their own space without having to NAT constantly. There is still a lot of NAT for the more common ranges.
5 replies →
This will trip up most SOC workflows in funny ways, and I like it.
IPs having a global distinction between public/private is a convention, but local routing can widely differ.
Same with the "China Cyberattacks" - the guys sitting on top of my outgoing fiber can simulate any IP address they want to me.
1 reply →
Yeah I wanted to do that at previous company. Got talked out of it, but it's nice have all those ips available.
I don't remember which but one of the major US cellular networks was using the DoDs 7.0.0.0/8 internally. It was never an issue since the DoD kept that /8 offline but the IPs would show up in traceroutes. I had to tell many people to ignore it.
I used to work somewhere that did that. Several of us in Eng pointed out that it was likely impossible to sell anything to DoD personnel since the reply would route internally. But I don't know if it was _fixed_, was still an issue when I left.
there's a couple subnets I (ab)use in the DOD IP space for my home network knowing they'd never put them on the open internet. it's also fun to throw logging for a loop if someone digs.
22.0.0.0/8 - it's basically free real estate!
8 replies →
> Note to self: never buy a Korean security product.
The Canadian Navy very recently made a major choice and agreed with you
https://www.google.com/search?client=firefox-b-d&q=hanwha+oc...
The DoWD owns such a large chunk of the IP space, it can very easily be a coincidence
That they used a public IP as an internal IP? That’s simply a mistake.
1 reply →
Or Korean IoT products. The ones I was working on had insane approach to security.
can you elaborate on that approach?
As if domestic products aren't a hot mess of security issues and sloppy engineering. Lol
> Department of War
n.b., it's the Department of Defense, just like the Kennedy Center doesn't have Trump's name attached, and the large body of water by Texas is the Gulf of Mexico.
100% correct
DoW is a nickname if anything. I'm surprised Hegseth hasn't requested 'Secretary' get nick-named to something more masculine sounding.
just buy stuff you can put your own firmware/os on because it's either just the worst security in the world (aka anything not from china) or, well... china.
and while i currently don't hate china as much as i do US rn (because canadian; sorry) i can also say -- due to being an aforementioned leaflandian -- that due to very personal experience i have zero faith in anything from china that has the ability to connect to any type of network :')
And so yeah at this point if I can't at the very least get a whatever-wrt firmware (preferably a proper linux distro nowadays; not to say the *-wrt firmwares aren't a real OS but, y'know) on the device i just avoid them entirely since, well... it's all i can do at this point because even if there were baked in hardware-based backdoors i as an individual can't do much more than that.
That sounds horrible. I got an old PI4, would it make for a decent router, if at all possible?
1 reply →
Note to self: never buy any Korean hardware or software product.
/S
Note to self, never buy any hardware product, move to a yurt in the woods, start an alpaca ranch, write a manifesto
1 reply →
Not surprised, many of these vendors are doing crazy things, insane defaults, broken security, hardcoded values. Security is not a priority, I get that, but at the very least some baseline check would be nice (no hardcoded credentials for starting)
As they say: in IoT the S stands for security.
ID-IoT-S
There’s some irony to security not being a priority for security cameras. Different kind of security I know, but still.
There's also some irony in people happily ignoring that so many of these products live-stream the inside view of their homes and offices to some foreign corporate cloud - and in the case of suspiciously many Chinese security cameras, a state-backed corporation's cloud. Because, wow, it really is convenient.
1 reply →
Especially these days there’s really no excuse
Add a skill to your repo that does some basic checks at least, not that hard
How can there be a baseline check when you operate by getting the most inexperienced cheapest person possible to do the work?
A rule of thumb, put your cameras on a separate VLAN and never give that vlan internet access.
Least you can do.
I bought some ambient room lighting recently. You cannot control them without a proprietary app. This bugged me ... so I grabbed an APK from the Google store, unpacked it, and found essentially keys to the kingdom: api keys for the backend, api keys for shopify, etc. Haven't done anything with this knowledge yet.
There's a lot of public keys that don't give you any special access, unless the dev is really bad.
Anyone who cares about security will be using App Attest or the Google store equivalent.
>Anyone who cares about security
I have something hilarious to tell you about IoT apps
7 replies →
> Anyone who cares about security will be using App Attest or the Google store equivalent.
Why? I rarely have security objectives where remote attention would help, and it has a huge impact on user freedom. For B2C attestation is just an evil captcha.
Have you actually tried to do anything with them though? The keys are in there, but may not grant you any real extra access beyond what your user is actually allowed to do via the app.
It is still pretty nice, you don't have to install yet another app to do something. People did this with Mazda app as it allowed them to start the car without subscription. They 'fixed' it.
Another rule of thumb - i know it's not always the best since some products are really nice aesthetically - is to buy only local smart stuff, for example, zigbee/zwave.
I live by this rule*. Being able to pick up stuff from IKEA that's well supported, well designed and really affordable is a huge advantage.
*almost, I have two things that need an app. My Vaillant boiler and my Yale alarm system. Both apps are terrible, but I have a 10 year warranty on the boiler and my alarm is up to scratch from a home insurance point of view.**
2 replies →
Ugh, that's a new low. I can't think of a single good reason a lighting app would need shopify api access.
That said, I've done some consulting work on shopify stores, and I wouldn't be shocked at all to see something like that at all. The bar for code quality that a lot of low end consultants/designers deliver is just abysmal.
In many cases it is bad to publish this info because they might come after you. There used to be a company who shielded the “researcher” from the legal consequences, can’t remember the name though.
@stake or L0pht?
What lights did you get? I have Oasis. Love them but same thing would rather control them through a central bot or something.
Everything can be controlled without a proprietary app. Hope you reverse engineer the protocol and publish how to do it.
Or claude/codex can.
[flagged]
When I cared, I found out that a lot of OBD-II dongles shipped with the same MAC, which gave you access to everything on a bunch of websites.
You can curse the storm, but the wind will come.
how did "same MAC" lead to "access to everything"?
Was the website's security based on MAC, which presumably is supplied by the client? If so, I guess.. typical IoT.
buy any dongle that sells for under $100 on amazon. they all have the same mac, and come with 'bespoke' apps to let you do things to your car. those apps are all thin wrappers on code widely shared; they use the MAC of the dongle as the keystone for ID.
Short story: buy one cheap dongle on Amazon, dump the MAC (00:11:22:AA:BB:CC IIRC; it's been 15 years since I cared) and you have auth to all of the apps everywhere.
Reminder: the Bluetooth logo comes, mostly, from self-certification.
6 replies →
How does this even work? A website doesn't know your MAC, that is only known in your local network.
LLMs have truly killed obfuscation. It only worked previously by making things extremely tedious but AI doesn't care about that.
And it's worth considering that obfuscation only ever worked against casuals for whom tedious was a bridge too far. Nation state actors and criminal hacker groups, on the other hand, consider the tedious entirely worth it.
Yes, obfuscation was always a matter of cost: how much money do you need to break the protection? LLM just decreased that amount by a lot.
(Yes ok, RSA4096 is technically a matter of cost, you just need an infinite amount of money)
2 replies →
Pirates checked Denuvo, once considered the king of DRM.
1 reply →
> consider the tedious entirely worth it.
Entirely without LLMs, I'm imagining an office of North Korean compsci graduates doing astonishingly tedious tasks, for whom an office job on a basic Linux computer and slightly better diet and nice apartment put them in the top 1-2% of living standard in the country.
On the bright side, even a small local LLM can easily improve garbage code like that.
I'm 100% confident in hardware companies' ability to make infinitely incompetent software given infinitely smart agents. They do it because they don't care about software, not because they lack tools. No agent can turn them into software companies if they don't want it themselves.
Perhaps they should just drop the 'security' from the name and simply call it a camera.
Back in the mid-1990s, I was working at an ISP and also at a consulting firm. The consulting firm's #1 business at the time was to get businesses connected to the Internet, where these businesses already had significant LAN buildouts.
Now these were the days before IANA had officially assigned those "Private IP Network" numbers. Nobody had any private IPv4 space to work with! So the choices consisted of: make up some numbers and hope they don't conflict, or go ahead and register your IPv4 space and get public netblocks assigned, even if you're just using them privately.
So, needless to say, we encountered some bonkers configurations, and a lot of our job was undoing some really awful configurations in order to make them compliant with actual Internet connectivity, and so that different office LANs would interoperate properly.
We were also big advocates of security, firewalls, and the venerable "DMZ/Bastion" setups from back in the day, so those Private IP Network assignments would've been really useful, along with NAT, but we simply didn't have those tools at our disposal, and our clients were basically registering huge IPv4 blocks that they really didn't need to ever use.
FYI, I have issued a correction to clarify that they were using the IP space for internal addressing.
This blog's misuse of the external link icon irks me.
The CSS selector they used (`a[href*="://"]::after`) is meant to only target only external links, but assumes any internal links will be using relative paths like `href="/about"`. The problem is that this site uses absolute URLs (`href="https://hhh.hn/about"`) for its nav links, so every link ends up with an icon.
You could fix this by adding an exception to the CSS rule so it skips links starting with your site's name:
rel="external" solves this.
will fix it tomorrow
It’s kind of interesting - I imported security cameras for a business roughly twenty hours ago. The security problems at the time were unbelievable to a point that any kind of wireless, IP or any type of service offering remote view was really scary. It was always stupid stuff - little oversights, things that were hard coded and shouldn’t have been or extremely old versions of insecure software running critical functions.
Apparently, nothing has changed in two decades.
I generally run security cameras on a separate VLAN and use something like frigate or other floss dvr tool for them to talk to.
Never let a cheap networked security camera touch the actual internet. %-/
what a good blog to read. Have you found answer on why they use the same token across these bunch of files? Maybe they are tying to adopt the agentic code writing? One interesting questions, what does that gh token give access to? It is only read from private repo, is not it? You said "admin" privileges earlier.
I've seen these systems at US defense industry tradeshows so I'm guessing they are in use somewhere.
the same token copy-pasted into 30 files. not even a config file. they baked their github admin credentials into the firmware image like it was a version number.
This kind of open source expands the world.
> Why would Hanwha Vision need anything remotely related to the DoD? Is it possible that their CI is provided by some centralized team at their parent company Hanwha, where the needs of their sister company Hanwha Aerospace cause the shared platform to have these entries in the CI environment variables? Or maybe because of their other sister company, Hanwha Defense USA, where they make other large scary steel machines
Or... the Department of Warmongers (nee DoD) addresses on the device are evidence of a supply-side attack targeting the DoW and carried out using the aforementioned github admin token.
... I mean, while we're in here speculating about truffles and all.
My cameras are analog rather than PoE or IP based, but that's just because I set up the initial iteration of the system a long time ago. The standard now is to give your camera an IP address.
With many IoT type things I block access to the public internet. I think with cameras specifically a lot of people even set it up physically on a different network that can only talk to the NVR.
But tldr, basing the cameras on IP invites some of the things in this article. Anyone deploying these devices needs to think about securing them.
Sorry to be that guy but if you can't even bother to capitalize your sentences then I won't bother to read your blog.
At least it's written by a human and not AI slop.
I have yet to find a pattern for when the author chooses to capitalize things.
true open source!
it's not a bug, it's a freebie!
Why would you write like that? Not capitalizing the first word of a sentence makes the whole thing less readable. So that you can feel special? Really?
Who hurt you? It's his own blog. Let him write the way he wants.
[flagged]
[dead]
[flagged]
[flagged]
[flagged]
[dead]
[flagged]
[dead]
I bet someone returned that security camera.
No, if you read the article the author was downloading firmware from their website and still found the token.
Department of War IP address? I feel this should be making headlines!
Abusing IP ranges which were assigned to an organization but aren't actually used on the public Internet as private addresses is pretty common. Sure, it's bad practice, but not a big deal.
Of course this looks entirely different when your corporate superstructure has a long and active history of developing military equipment.
I know you're a mastermind when it comes to security, but you should provide more context about the tools and methods you're using in your article so we can better understand what it's all about and not have to Google every single step you're taking.
Oh I thought exactly the opposite!
I feel like every security blog (or even just tech blog) I've read recently has had paragraphs and paragraphs of largely LLM generated explainer waffle. This felt refreshingly focused and to the point.
i’m not a mastermind, and I agree it could be more accessible. I treat this blog as somewhere to just dump my thoughts as unfiltered as I can while still being useful or entertaining, maybe for some other posts I will go more into depth
Seemed perfectly reasonable to me. Not everything has to be written for a target audience that includes you, besides you were able to look up what you needed it seems. Another tactic is to feed the article to your favorite LLM and interrogate it about what you don't understand.