Post #3976997

2026-07-15 18:16 UTC

@muddle@infosec.exchange cute! I'm currently serving a .gz bomb (at least from various .php endpoints), but I was more thinking source code that was deliberately bad, like "Matt's Script Archive" bad, so that as these things get incorporated into coding tools there's a lot of "oh god no".

Replies (2)

@muddle@infosec.exchange 2026-07-21 04:30

@danlyke@researchbuzz.masto.host Fair play to Matt, though... he acknowledged his ignorance of best practices wrt security... just thinking that he shouldn't go down in history as a synonym/trope namer for "bad" https://en.wikipedia.org/wiki/Matt's_Script_Archive

Open ##3976996
@muddle@infosec.exchange 2026-07-15 18:29

@danlyke@researchbuzz.masto.host Yeah, I answered before reading the thread. I get that now. There's a thing called (thinks) The Underhanded C Code Competition, I think. That's deliberately bad code that hides backdoors and stuff like that. For junk code, there's always Markov generation. Some of the existing anti-scanning tools work like that. You can usually feed them sample texts, which could be a bunch of valid Perl/C code and docs. Or give it (or something similar, anyway) a whirl in emacs with M-X dissociated-press. I'm also thinking that bug-fixed code could be a source. Make up a new repo that disapplies the patches that fixed major bugs. Or just expose old, buggy code from any publicly-available software? I hear you on the non-prepared sql queries. In a similar vein, you could hard code stuff to example.com (although probably best not), local IP/host names or other random sites? It depends on how much mischief/effort you're into, I guess. Technically, what this is is a honeypot. You can go to a lot of effort to make it look real, but simple generative things are much easier to implement.

Open ##4235109