Speaking as a hardware engineer, the moat did not vanish. You have simply assumed you were on the right side of the moat this whole time when in reality you dug half a trench and threw a glass of water in it.

If your firmware is open for someone to reverse engineer now, it has always been open. The real moat is firmware security, encryption, secure locked down hardware. Nobody, not even LLMs, can reverse your firmware if they can't obtain a cleartext copy of it.

You must use microcontrollers with security features, encrypted firmware, secure key stores. If you don't, you never had a moat in the first place. Your only security is the belief that it's too much effort to reverse your product. Security through obscurity is the moat that has vanished and everyone has been screaming for decades that this is not secure by any stretch of the imagination.

▲

rpcope1 3 hours ago | parent | next [-]

Maybe some of the newer stuff is better, but you're kind of overselling the hardware protection (lol). I'm sure everyone thought RDP1 on the STM32F1xx series was going to stop "bad guys" (or even RDP2, lol) but I was able to do better than Obermaier on firmware recovery of a F103 recently without going to the trouble of doing something like delidding a chip or even undersoldering it. The newer stuff is a little better, but a quarter in the Deepseek machine, some fairly common tools and patience, and even skids will be breaking into your invulnerable firmware fortress. I think the apocalyptic nature of all this just hasn't really sunk in for a lot of EEs or firmware developers.

	▲	ndiddy 23 minutes ago \| parent [-]
		RDP2 is barely any more secure than RDP1. When the processor boots, it reads the read-out protection value from flash. If it's one specific value, it's RDP2, if it's another specific value, it's RDP0, and if it's any other value, it's RDP1. This means that all you have to do to downgrade the chip to RDP1 is glitch it while it's reading that value, then you can use one of the RDP1 errata to read out the flash. In general read-out protection only prevents the most casual of hobbyists from getting your firmware. Anyone who thought otherwise even pre-AI doesn't know what they're doing. It's sort of like how blu-ray copy protection only prevents people who don't know about MakeMKV from copying their discs, or how HDCP only prevents people who can't find a $20 HDCP terminating HDMI splitter from capturing the protected video.

▲

true_religion 17 hours ago | parent | prev | next [-]

I think you are torturing the analogy.

A moat isn’t a perfect defense. It’s a delay tactic that keeps the enemy from coming right up to your wall and climbing it or breaking it down. While you defend your moat, you whittle down the attackers so even when they do cross it they can be more easily defeated.

Moats and high walls became obsolete when canon fire became common.

Claude isn’t just a faster way to cross the moat, it’s gunpowder, and with it the rules have fundamentally changed.

Firmware security is useless if your product can be bought tested and reverse engineered through multiple trials. So long as you have something that can be understood and used by humans, you have something that can be reverse engineered.

Having the code accessible makes it easier, but just having both input and output is sufficient.

▲

oblio 16 hours ago | parent [-]

> Moats and high walls became obsolete when canon fire became common.

Moats and high walls, sure. But to this day, the absolute best way to stop any attacker is to dig a trench (most minus water) and to build low parapets, primarily of dirt, sand, barbed wire and ideally some anti tank stuff.

The moat never really went away.

▲

AnthonyMouse 15 hours ago | parent | next [-]

How does your moat do against a B-52?

▲

oblio 10 hours ago | parent | next [-]

A lot better than expected, as Vietnam proved.

▲

iugtmkbdfil834 13 hours ago | parent | prev [-]

You may be missing the point, unsure if purposefully or not, but you can't just rent B-52 for $250 a month.

▲

thiisguy 11 hours ago | parent [-]

The B-52 analogy seems pretty spot on where the (relatively) sudden capabilities of Claude are similar to now having a B-52 where you can just fly around and find silly little moat/wall defenses and easily destroy them with your one-shot bomb-release button.

	▲	oblio 8 hours ago \| parent [-]
		Amusingly, if you know about the history of B-52, it's a bad analogy. B-52s biggest war was lost.

▲

NooneAtAll3 7 hours ago | parent | prev [-]

trenches aren't stopping the attackers, only protecting the defenders. You "men" the trenches to make them effective

▲

m3kw9 an hour ago | parent | prev | next [-]

They'll just "distil" your hardware from input/outputs.

▲

ranger_danger 20 hours ago | parent | prev [-]

Reverse engineering of audio effects can be done completely independently of the hardware that generates it.

▲

amelius 17 hours ago | parent [-]

What if the audio effect is:

Take an audio stream, apply STT, interpret the result as an algorithm, run the algorithm, take its output, apply TTS, then send that audio stream to the output.

▲

true_religion 17 hours ago | parent | next [-]

Sounds like it would be susceptible to how they’d reverse engineer LLMs using distillation.

	▲	tyromaniac 10 hours ago \| parent [-]
		Connect the dots for me, I'm not seeing it. Unless you are talking about building a function approximator for a bunch of measured transfer characteristics, in which case you could as easily do that well before AI.

▲

pjc50 15 hours ago | parent | prev | next [-]

The several seconds of latency would be fun.

	▲	11 hours ago \| parent [-]
		[deleted]

▲

wazoox 4 hours ago | parent | prev | next [-]

That's basically how convolution reverb has worked for 25 years.

▲

casey2 6 hours ago | parent | prev [-]

since human hearing is lossy you can get whatever sound you like. In the context of a moat there is none for a sfx