Chaff Bugs: Deterring Attackers by Making Software Buggier (2018) | Hacker News Reader

Chaff Bugs: Deterring Attackers by Making Software Buggier (2018)

arxiv.org

26 pointsTomte15 comments

Back when I had to secure software using hardware dongles, I came up with my most evil idea.

For those who don't know, dongles are hardware tokens that represent your license to use the software, and the dongle had to be attached to the computer so the software could check for its presence. Using dongles required you to either add code to your program to test for the presence of the dongle, or you could encrypt the executable using a key stored on the dongle and a program launcher would retrieve the key from the dongle to decrypt your program. In either case, if the dongle wasn't present a dialog would appear telling you the software was unlicensed and then terminate the application.

My evil idea was to tell people up front that the dongle was required for the software to work, but rather than terminate the application when the dongle wasn't present I would introduce subtle errors into the data manipulated by the program.

  * CAD program missing the dongle?  Each second, a random vertex is moved by 1 pixel
  * Statistics program missing the dongle? Random numbers are added to data sets during aggregate calculations
  * Video game missing the dongle?  Game stutters at random intervals.

Oh sure you could use the software without the dongle, but it would be super-annoying to do so.

I never got the opportunity to implement this because people realized that dongles are dumb.

Many moons ago I came across an anti-theft device for a car that was designed on similar lines. The idea was that car alarms are easily defeated and are generally ignored anyway if they go off.

When armed, the circuit would cause the car to run but stall frequently, blow the horn and lights and misbehave in other ways. Eventually the thief would assume the car was in serious disrepair and abandon it.

I kinda like this idea, although I suspect that some may be willing to put up with the annoyance if they're aware its just a ruse?

It reminds me of some audio software, when there's no license registered, it injects a burst of noise every 30 seconds.

Or make them alpha testers

> I would introduce subtle errors into the data manipulated by the program

I no longer remember the games, but in the 80s copy protected games, I remember some where if the game detected it was a cracked copy it would still run fine but the game would be missing critical items so it became impossible to progress. Unless you knew this, you could go crazy trying to find the items that didn't exist.

New coping strategy for low-quality software just dropped.

I feel personally attacked! :D

Definitely works for games. AAA games are generally buggy messes upon release. Crackers dont bother cracking something that takes time and effort (eg. Denuvo) until the game has had the bugs patched (otherwise they would need to re-crack the updated versions each time) I would not be at all surprised if the bugs are left in on purpose to ensure the game remains uncracked for a certain period of time. The kind of company who would use DRM and Denuvo would have zero qualms about doing it imo. I think having buggy games also pushed people toward online DRM systems like Steam that autoatically download updates every time you run the game, rather than something like Itch.io or gog where you just download the game and play it like a sane person.

That's interesting, but it would have to be very carefully managed, because it would make it difficult to maintain high Quality, in general.

I could easily see people saying things like "I know my software is buggy, but that just makes it more secure, dude!"

So you would have to have a database of these bugs that would be available to testers (including unofficial testers, like end-user testers), so they wouldn't waste their time, tracking down deliberate bugs. If it were open enough to do that, then hackers would simply consult that list, before going much further.

Makes me think of those novice lockpickers who buy a bunch of cheap locks from some dollar-store, only to find these surprisingly difficult to pick because of poor machining tolerances.

Definitely picked the right day to post a paper like this one.

as part of a big project some years ago with pretty heavy security restrictions if we detected you were likely an attacker we did not shut you down, we let you get further into the system and then later we threw a randomized error so the attacker would try to focus on that section of the app and that error as an exploitation point.

Automatically generate thousands of bugs... what could possibly go wrong?

By an interesting parallel....

....some of the most difficult locks to pick can be those that are just 'buggy' and worn. The kind where you need to lift your key or rattle it in the lock just-so to get it to open :-)

Reply on news.ycombinator.com