Rendered at 11:53:57 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
BiraIgnacio 3 days ago [-]
> The contest was initially inspired by Daniel Horn’s Obfuscated V contest in the fall of 2004 (note: the original page is long gone, and this link goes to a snapshot from archive.org). The object of that contest was to write a simple program to count votes, that somehow miscounts the votes on election day. I was greatly impressed to see how even a short program to simply count characters in a text file can be made to fail, and fail only on one specific day, so that the bug isn't noticed in testing.
My favourite entry was the "leaky redaction" one, which created a "redacted" version of an image in the text-based ppm image format, but in such a manner that most of the redacted information could be restored directly from the file.
The trick was to redact by converting characters to zeroes, as opposed to words. So "8" would become "0", but "256" would become "000" rather than "0". In a black and white text document, distinguishing between "0" and "000" effectively faithfully recreates the original document! But even in color pictures, it was very interesting to see how much information is still retained going from 256bits per channel down to just 3.
The method was underhanded in that the code at that section was written in a seemingly very sensible manner, enough to convince an astute auditor that this was an honest and defensible bug.
silisili 3 days ago [-]
The original page actually loads fine, maybe was restored later?
I looked through a few trying not to read the short description and missed a lot of simple things, really makes you think...
Interesting that the case they were using was the Nuclear Threat Initiative and FP uncertainties, I've audited some, ah, nuclear-physics-related code that had an issue due to FP uncertainties...
ForOldHack 3 days ago [-]
Where you can encode an entire Command and Control server within rounding errors! You sneaky skunk!
aa-jv 3 days ago [-]
All software is, eventually, rounding error.
pseudohadamard 1 days ago [-]
It was actually due to the original developer assuming FP compares were exact. It was never an issue, the code went through huge amounts of auditing and testing, just an interesting coincidence that the underhanded contest used something so similar to its underhandedness.
https://underhanded-c.org/_page_id_7.html
The trick was to redact by converting characters to zeroes, as opposed to words. So "8" would become "0", but "256" would become "000" rather than "0". In a black and white text document, distinguishing between "0" and "000" effectively faithfully recreates the original document! But even in color pictures, it was very interesting to see how much information is still retained going from 256bits per channel down to just 3.
The method was underhanded in that the code at that section was written in a seemingly very sensible manner, enough to convince an astute auditor that this was an honest and defensible bug.
I looked through a few trying not to read the short description and missed a lot of simple things, really makes you think...
https://graphics.stanford.edu/~danielh/vote/vote.html
If I put my submission up on github, is that considered unethical in the days of LLMs?