Show HN: Stuxnet – A reconstructed source code of the infamous cyber-weapon
github.com
Show HN: Stuxnet – A reconstructed source code of the infamous cyber-weapon
1–10 of 62 posts
Re: Show HN: Stuxnet – A reconstructed source code of the infamous cyber-weapon
#2SSDT should probably have a lock. The chance of a race is ~low (higher under heavy sustained workloads) but it's too important to leave to chance.
I'd probably do a rebuild of the directory lists in a separate buffer instead of working in place to avoid alignment fuckups.
Yes I used LLMs, just like I did for all of the other vulns I've found or refined. As you can see from the source, this shit is tedious as hell. Doesn't change the value of knowing what to look/ask for.
Give one of those open models a fresh windows box (not a VM) and tell it to fuck something up, it's fun.
Re: Show HN: Stuxnet – A reconstructed source code of the infamous cyber-weapon
#3For those not familiar with Stuxnet, it’s a discovered cyber-weapon from 2010 which “reportedly destroyed almost one-fifth of Iran's nuclear centrifuges. ” and “ neither the United States nor Israel has openly admitted responsibility” but likely were the developers [1]
[1-Wikipedia Entry](https://en.wikipedia.org/wiki/Stuxnet)
[2-“Countdown To Zero Day” book if you liked the Wikipedia entry](https://www.audible.com/pd/Countdown-to-Zero-Day-Audiobook/B...)
[3-“Zero Days” movie](https://www.imdb.com/title/tt5446858/)
Re: Show HN: Stuxnet – A reconstructed source code of the infamous cyber-weapon
#4Directory filtering needs to be fixed, one weird filename or symlink will make it BSOD. SSDT should probably have a lock. The chance of a race is ~low (higher under heavy sustained workloads) but it's too important to leave to chance. I'd probably do a rebuild of the directory lists in a separate buffer instead of working in place to avoid alignment fuckups. Yes I used LLMs, just like I did for all of the other vulns…
Re: Show HN: Stuxnet – A reconstructed source code of the infamous cyber-weapon
#5Directory filtering needs to be fixed, one weird filename or symlink will make it BSOD. SSDT should probably have a lock. The chance of a race is ~low (higher under heavy sustained workloads) but it's too important to leave to chance. I'd probably do a rebuild of the directory lists in a separate buffer instead of working in place to avoid alignment fuckups. Yes I used LLMs, just like I did for all of the other vulns…
If you're using coding agents for this, it may be worth splitting this up into multiple well arranged modules that tell a coherent story and make it easy to browse, and add explanatory docs based on the various things the LLM has found about each function / type.
You don't need exploratory docs, try asking one for complete function signatures of all the Windows APIs used, it's going to spit the docs out.
Re: Show HN: Stuxnet – A reconstructed source code of the infamous cyber-weapon
#6Re: Show HN: Stuxnet – A reconstructed source code of the infamous cyber-weapon
#7 g_dwCentrifugeDestroyed++;Re: Show HN: Stuxnet – A reconstructed source code of the infamous cyber-weapon
#8Re: Show HN: Stuxnet – A reconstructed source code of the infamous cyber-weapon
#9Somehow, I don't think the original authors of this proprietary code are going to be filing a copyright claim...