Microsoft-cto Russinovich vindt via Claude kwetsbaarheden in zijn antieke code

Cto Mark Russinovich van Microsoft Azure liet oude Apple II-software van zijn hand analyseren door Claude Opus 4.6. De AI-codetool vond meerdere kwetsbaarheden in de veertig jaar oude code. Claude moest die antieke software, geschreven in machinetaal, eerst decompileren.

De mogelijkheden van AI om kwetsbaarheden te vinden, zijn 'ongelofelijk' en de mogelijkheid om machinetaal te reverse-engineeren is 'schokkend'. Dit stelt cto Mark Russinovich van Microsofts clouddivisie, Azure, die ook bekend is als maker van de Windows-tools Sysinternals. Hij komt tot deze uitspraken na het loslaten van Claude Opus 4.6 op een tool die hij in 1986 schreef voor de Apple II-computer. Zijn oude software was geschreven in de machinetaal van de 8bit-6502-processor.

Tot zijn verbazing kon de AI-tool van Anthropic niet alleen die diepere legacyprogrammeertaal ontcijferen. Claude Opus reconstrueerde volgens hem ook de logica van zijn code 'met nauwkeurige labels en comments'. Russinovich stelt dat de AI-tool in wezen de intentie van de code las die hij veertig jaar geleden schreef.

'Nieuw tijdperk'

Vervolgens was hij nog meer onder de indruk van de securityaudit die Claude Opus uitvoerde. De AI identificeerde logische fouten in de code. Deze problemen kunnen leiden tot 'stil incorrect gedrag' van de software. Russinovich merkt op dat deze bugs niet direct neerkomen op kwetsbaarheden die gebruikers in gevaar brengen. Wel meent hij dat zijn experiment met AI een fundamentele verschuiving belicht.

Russinovich waarschuwt dat AI een nieuw tijdperk van softwarekwetsbaarheden inluidt. Het vinden van beveiligingsgaten in software wordt dankzij AI nog verder geautomatiseerd en daarbij ook versneld, schrijft hij op LinkedIn. Dit brengt fundamentele veranderingen met zich mee die zowel verdedigers als aanvallers benutten, aldus de technische topman bij Microsoft.

Claude. Bron: Anthropic

Reacties (48)

[DdeM]

Hoe weet hij zo zeker dat de kwetsbaarheden in de gedecompileerde "reverse-engineered" code óók in de originele code zaten? Leuk dat je de intentie van de code kan vergelijken met wat je zelf ooit bedoeld had, maar tenzij hij de originele niet gecompileerde code er naast heeft gehouden ter vergelijking is er 0 garantie dat die kwetsbaarheden er initieel gewoonweg niet in zaten.

[Prince]

Decompileren (machinecode naar assembler of C) is 100% identiek in wat de code doet.

De benamingen van de functies bepalen en veel "ontdoen van standaard optimalisaties van de compiler" is waar hier de magie zit. Maar dit betekent nog steeds niet dat hij zaken verzint.

Ook het feit dat hij comments kan achterhalen, betekent dat er debuginformatie in zat; als in deze comments uitleg zat en namen van gerelateerde functies, dan kan hij deze ook gebruiken.

[gixslayer]

Decompileren (machinecode naar assembler of C) is 100% identiek in wat de code doet.

Het "decompileren" naar assembly, i.e. disassembly, is in theorie 100% accuraat. In de praktijk kun je hier echter alsnog tegen problemen aanlopen. Zo is x86 bijvoorbeeld zo complex dat verschillende tools de binary blobs anders decoden, en zeker met Variable Length Instructions krijg je dan al snel totaal verschillende resultaten. Zie deze blog voor meer info. Ja natuurlijk is dit gewoon een bug in de tooling en/of ambigue specificaties, maar het geeft wel aan dat dit een serieus issue is waar een LLM ook last van kan hebben.

Als we het hebben over decompileren naar (pseudo) C, wat tools zoals IDA/Ghidra/Binja doen, dan nee. Dit is niet 100% accuraat. Er zijn scenarios waar de machine code/assembly gewoon niet goed naar C is te vertalen, of dat control flow een zooitje wordt. Een ander issue is het aanroepen van andere functies, die misschien niet de standaard calling convention volgen (bijvoorbeeld door compiler optimization voor niet externe functies). Dit was altijd erg duidelijk in bijvoorbeeld IDA. Je had soms wat code, en als je dan een functie bekeek die wordt aangeroepen, verandert je decompiled code opeens omdat er meer analyse had plaatsgevonden.

Je kan opnieuw zeggen, oh maar dat is een tooling issue. En wellicht valt er een decompiler te schrijven die altijd accuraat is door erg low-level C code uit te spugen vol met e.g. compiler intrinsics, maar dan verlies je ook een beetje het nut van een decompiler en heb je meer een iets fancier disassembler. Daarnaast hebben veel van deze decompilers allemaal hun eigen set bugs, omdat het erg complex is, en krijg je met 5 verschillende decompilers soms 5 verschillende resultaten, die allemaal al dan niet correct kunnen zijn.

Dit is opnieuw voor een LLM niet magisch op te lossen lijkt me, en als het dus op basis van 'decompiled' code naar vulnerabilities zoekt dan heb je daar gewoon een extra laag zitten waar fouten kunnen optreden waardoor de analyse niet meer klopt.

Vervolgens kan je ook nog problemen hebben met source code die wel veilig is, maar door compiler bugs machine code uitspuugt die niet veilig is, of andersom. Of dat het alleen voor bepaalde targets (x86 vs arm vs risc5 etc) onveilige machine code uitspuugt.

Kortom er zitten hier nogal wat valkuilen waar een LLM ook niet zomaar omheen kan. Ja in veel gevallen zal het vast goed gaan, maar ik zou er niet blind op gaan vertrouwen.

[Stijnvi]

Daarnaast staan LLMs er natuurlijk ook om bekend regelmatig te hallucineren. Wikipedia loopt er bijvoorbeeld al tegenaan dat vertalingen door LLMs in een keer informatie bevatten die niet in het originele artikelen stonden, of juist informatie uit het originele artikel weglaten, en dat bronnen uit het originele artikelen ontbreken, of dat er nieuwe bronnen bij zijn verzonnen.

https://www.pcworld.com/article/3079595/wikipedia-has-an-ai-translation-problem.html

Als het al zo erg fout gaat bij het vertalen van een simpel stuk tekst van Wikipedia, dan wil ik niet weten wat een LLM doet wanneer hij code moet "vertalen".

[robvanwijk]

Dat is niet hoe debuginformatie werkt. Daarin zitten namen van functies en variabelen en referenties naar files en regelnummers, maar (voor zover ik weet) geen comments. Degene die de extra informatie gebruikt heeft meestal gewoon toegang tot de oorspronkelijke source code, dus het zou ook volkomen overbodig zijn om comments mee te compileren.

Zoals ik het artikel lees zijn de comments gegenereerd door de AI, niet teruggehaald uit de code. Het klinkt alsof ook de functienamen en variabelenamen van de AI komen:

de mogelijkheid om machinetaal te reverse-engineeren is 'schokkend'

Ik denk niet dat het "schokkend" is als AI erin slaagt om een goed-gedocumenteerd dataformaat te parsen. En het lijkt me onwaarschijnlijk dat dit puur over het herleiden van de structuur van de code gaat, want dat kan (ook al is het niet perfect) al jaren.

[Olaf van der Spek]

óók in de originele code zaten?

Je kunt controleren of de bugs in de binary zitten en dat is waar het echt om gaat. Als ze dan niet in de originele code zaten, zou dat een compiler bug kunnen zijn, maar dat is weer een apart issue.

[ErnstvV]

Uiteindelijk maakt het voor een kwetsbaarheid ook niet echt uit of het in de sourcecode ook aanwezig is. Wat de processor uit voert is de machinecode, als daar een kwetsbaarheid in zit, is dat het probleem.

[yuckywucky]

Nee. Je gaat gewoon van machinecode naar leesbare assembly.
Decompileren is hier het foute woord, Eerder disassembleren.

Je weet honderd procent zeker dat de fout in je code zat.

[Olaf van der Spek]

Nee. Je gaat gewoon van machinecode naar leesbare assembly.

Je kunt dus ook naar leesbare C code..

[pietje63]

dat kun je toch testen op de gecompileerde code?

[Martinspire]

Niet heel raar. De bugs zijn gevonden in de tussentijd en dat is code waarop ze getraind zijn. Grote kans dat als er geen bug van is gemaakt, dat ook Claude niks gaat melden over code waar duidelijk nog bugs in zitten. Ze zijn geen analisten. Ze doen gewoonweg code herkennen waar ze op getraind zijn.

[bwerg]

Dan heb je weinig ervaring met deze toepassing, want Claude werkt prima om nog niet bekende bugs te vinden. Ik zie ook bug reports van de catagorie "volgens de naam van de functie moet die functie dit en dat valideren, maar hij vergeet een geval". Als je dat schaart onder de categorie "is hij op getraind" dan kun je dat ook wel extrapoleren naar menselijke developers die uiteindelijk ook maar getraind zijn op de miljoen regels code die ze intussen gezien hebben.

Zo'n AI vindt uiteraard niet alles, en niet alles wat die vindt is ook echt een bug, maar de ratio aan ruis versus daadwerkelijk nuttige bug-reports is goed genoeg om daadwerkelijk bruikbaar te zijn.

[Argantonis]

Nee dan onderschat je echt wat het kan. Ik zou er eerst eens ervaring mee opdoen voordat je zoiets zegt.

[onok]

Ik heb claude code ook al een keer losgelaten op een paar van mijn wat oudere projectjes. Ik was ook best onder de indruk waar die allemaal mee aan komt zetten. Niet alles klopt 100%, maar hij kan er toch echt dingen uithalen waar ik niet snel opgekomen was.

[gixslayer]

wat ik me dan wel afvraag is hoe de resultaten van Claude zich verhouden tot bestaande tooling zoals static analyzers en iets zoals Valgrind. Zijn er bugs die Claude wel vindt, maar de tools niet, of andersom? Hoe staat het met de false positives? Gebruikt Claude wellicht 'under the hood' niet gewoon dit soort tools?

Het laaghangend fruit zou dit soort tooling er redelijk betrouwbaar uit moeten kunnen halen. Wat ik me vooral afvraag is of iets als Claude ook complexe bugs kan vinden met een enigszins acceptabel false positive rate, zeker op grote en complexe code bases.

[RayNbow]

de mogelijkheid om machinetaal te reverse-engineeren is 'schokkend'.

Maar hoe schokkend is het daadwerkelijk? Als ik naar het oorspronkelijke artikel kijk, is het een BASIC-programma dat machine-instructies in het geheugen poket en een verwijzing naar deze code installeert op de ampersand-vector ($3F5). Als je een beetje rondzoekt kun je genoeg voorbeelden vinden op het internet (zowel sites als gescande boeken) die deze techniek beschrijven.

Wat wel een gemiste kans is, is dat bijv. het taalmodel met de volgende disassembly kwam:

LDA ($B8),Y ; A = token at TXTPTR

Mooier was geweest:

LDA (TXTPTR),Y

Dan was het commentaar overbodig geweest.

[claudibunsen]

De definitie "kwetsbaarheden" voelt wel een beetje aan als "marketing fluff" imo.

Persoonlijk zou een kop als "ai vind bug in 40 jaar oude code" een stuk beter klinken.

Zoals ook de in-depth pdf onder de LinkedIn post zelf al uitlegt

[dasiro]

De vraag is niet hoe indrukwekkend dit is, maar hoe relevant zulke oude code en de mogelijke exploits ervan nog zijn. In dat tijdperk was security van software die uitsluitend op lokale niet-geconnecteerde systemen draaide immers veel irrelevanter dan nu. Input validatition en garbage collection van je variabelen en memory (waar het in dit geval om gaat) waren eerder noodzakelijk omwille van hardware-beperkingen en "propere" code, omdat de taal waarin ze geschreven was met zulke scenario's geen rekening houdt.

[Marctraider]

Het blijft een token predictor, geen intelligentie. Handig? Wellicht. Een fout zit in een klein hoekje, ook bij een 'AI' audit.

[kuurtjes]

Wij van WC-eend


_{(Claude is beschikbaar via Github wat van Microsoft is)}

[brutus0]

Nu Microsoft A.I. gaat gebruiken wordt Windows mischien/hopelijk een betere OS

[henk717]

Dat lijkt wel anders, het aantal artiekelen over dramatische windows updates lijkt toegenomen. Misschien een leuk achtergrond artiekel voor tweakers om die tijdperken eens te vergelijken.

[adje123]

Wat is er precies mis Windows?
Ik vind Windows 11 heerlijk werken. Werk er dagelijks mee, zowel op de zaak als prive. Nooit problemen. Alles binnen handbereik en ook nog een snel.

[Standeman]

Ik vind het een vreselijk drama met wat Microsoft allemaal door je strot probeert te duwen plus de paranoia dat je constant in de gaten gehouden wordt.

Maar goed, ik kom dan ook van Linux af en wordt door de klant 'gedwongen' om windows te gebruiken. Kan er lekker over klagen met met mijn ex-MacOS collegae

Gelukkig hebben we wsl dat de pijn een beetje verzacht

edit:
en snel is het ook niet. Mijn spiksplinternieuwe HP zbook is ~30 seconden langzamer bij het compileren van projecten dan mijn 6 jaar oude xps met een kwart van het geheugen . :x

[Reactie gewijzigd door Standeman op 9 maart 2026 16:44]

[bzuidgeest]

Ik vraag mij af of het probleem niet de gebruiker is. Ja het is zeker waar dat microsoft overal copilot in propt. En wat al niet meer. Maar dat is ze hun goed recht als bedrijf. Moeten ze zelf weten. Met Notepad++ heb ik daar geen last van. Je hoef Edge niet te gebruiken. Search op de toolbar kan gewoon uit......

Waarom neem je de moeite om je er aan te ergeren? Configureer het zo je wil, eventueel met wat extra tooling. Niet anders dan op Linux (waar linux nog veel meer kan natuurlijk). En gebruik gewoon geen microsoft programma's er zijn heel veel windows programmas. Ergeren is verspilde moeite.

Windows is niet perfect. Maar het draait over het algemeen zonder problemen in de 10/11 generatie. Niet slechter dan window XP.

Ik ben blij dat je WSL ondekt heb. Dat is heel nuttige functionaliteit. Zeker voor een ontwikkelaar.

[zenlord]

Waarom neem je de moeite om je er aan te ergeren? Configureer het zo je wil, eventueel met wat extra tooling.

Wel, omdat (1) Windows mij niet alles laat configureren zoals ik het wil, en (2) mijn werkgever mij geen admin-rechten geeft om zomaar alles te installeren wat ik als gebruiker wil. Als policy zeer verdedigbaar, maar het gevolg is wel dat "configureer het dan zoals je het zelf wilt" niet van toepassing is en je vraag "of de gebruiker niet het probleem is" negatief moet beantwoord worden.

[bzuidgeest]

Tja, hoe hoog is de kans dat je werkgever veranderd en je geeft wat je wil?

Als het antwoord 0 is, dan is je ergeren verspilde energie. Want het veranderd toch niet en maakt wel je leven rotter. Circle of influence noemen ze dat. Je ergeren aan dingen die je niet kan veranderen is nutteloos. En dat is aan de gebruiker.

[Standeman]

Problemen die ik heb met MS:

• Doordrenkt met pogingen tot vendor-lockin
• Bewust onduidelijk over telemetrie
• Kapitalistisch bedrijf (Ja, ik ben een 'linkse rakker')
• Verplichte reboot na een update (why?)
• Hun enige motivatie is meer geld binnenharken voor de shareholder
• Houden hun sources strict voor zichzelf totdat er iemand met poen zwaait
• Verplichten mensen nieuwe hardware aan te schaffen terwijl hun machine prima voldoet. (Want ja, vendor-lockin)
• 'user comes last'-model dat je overal terugziet.

Buiten dat om is het nog een managed laptop ook met achterlijke policies

Maar dat ligt aan de klant..

[Reactie gewijzigd door Standeman op 9 maart 2026 17:22]

[bzuidgeest]

Maar kan je daar wat aan veranderen?

Als het antwoord nee is, omdat je werkgever het zo wil, dan is ergeren nutteloze energie verspilling. Circle of influence. Kan je het niet beïnvloeden dan niet verder bij stilstaan.

Mogelijk is er een optie om een andere werkgever te zoeken, maar dat is wel een ding met mogelijk impact in je leven. Of je gaat voor jezelf beginnen, dan mag je ook zelf bepalen

[Reactie gewijzigd door bzuidgeest op 9 maart 2026 17:21]

[Standeman]

Ik ben inderdaad druk bezig met het zoeken naar een nieuwe klant aangezien er niet geluisterd wordt naar ~80% van de werkvloer.

[robvanwijk]

Verplichte reboot na een update (why?)

Omdat een update code wijzigt. Daar heb je niets aan totdat die nieuwe code actief wordt (of, correcter, zodra de oude code niet meer actief is). Voor een fix in, bijvoorbeeld, Edge zou je tegen de gebruiker kunnen zeggen "sluit alle vensters en start Edge opnieuw op", maar voor een fix in de kernel of in een DDL, is dat een stuk lastiger. Dat betekent niet dat het volledig onmogelijk is ^*), maar het is zeker niet triviaal.
Als je er voorstander van bent dat ze de benodigde wijzigingen maken zodat dit in de toekomst niet langer nodig is, dan heb je het volste recht om dat te vinden. Maar doen alsof het een belachelijk idee is dat nergens vandaan komt, dat slaat nergens op.

*) Een externe partij zoals 0patch lijkt heel dicht in de buurt te komen van "nooit meer rebooten", dan moet MS het zelf ook kunnen.

[Standeman]

Het is belachelijk omdat Linux het al jaren doet. File replacement, geen centrale registry, modulairiteit, etc.

Ja, met kernel update heb je een reboot nodig. Maar ook dat is te verkomen met bijv kpatch.

Daarom zeg ik: Microsoft hanteert al 25 jaar het "user-last-stakeholder-first"-model.

[latka]

Ik moet ook windows gebruiken om programma's te starten die ik echt nodig heb (ontwikkelomgeving bijv.). Voor een programmalauncher is het nogal groot, traag en privacy invasief. Dat is het probleem van windows.

[Luchtbakker]

Wat is er precies mis Windows?
Ik vind Windows 11 heerlijk werken. Werk er dagelijks mee, zowel op de zaak als prive. Nooit problemen. Alles binnen handbereik en ook nog een snel.

Sinds Microsoft heeft aangegeven dat veel code met AI geschreven wordt hebben we best vaak releases, met name Windows 11 met best pittige bugs:

nieuws: Microsoft: 'Tot 30 procent van onze nieuwe code is door AI gegenereerd'

Ik ga hier niet een hele lijst met nieuwsartikelen van de laatste 12 maanden posten, maar bijna elke maand komen er wel artikelen voorbij met bugs die na het updaten zijn ontstaan, waarvan zulke knulligheden vroeger een stuk minder voorkwamen.

[Powerblast]

Onder AI generated code kun je vind ik ook veel verstaan. En Microsoft blijft er ook bewust stil over vermoedelijk.

Want code completion waarbij je zelf de eerste twee letters typed en dan in de dropdown je functie kiest, zou je daar ook kunnen onder zien. Dan is pakweg van een lijn code 20% zelf geschreven, 80% “AI generated”. Zo kom je snel aan hoge cijfers, die eigenlijk niet veel met AI te maken hebben .

Maar inderdaad, sinds ze meer met AI zijn gaan doen is de kwaliteit naar mijn gevoel heel wat achteruit. De toepassing van AI opzich is dus blijkbaar toch niet ideaal als ze doen uitschijnen.

[Schway]

het niet zo zeer iets dat precies mis is, maar meer een gevoel, een vibe, een geschiedenis, een traditie als het ware.

[hottestbrain]

Ik vind windows an sich best een fijn OS, maar uiteindelijk kies ik (vooral vanwege de CPU) voor een mac. Als ik op die machine native windows kon draaien was dat mijn eerste keus geweest

[Thc_Nbl]

Je moet eens monitoren wat jou pc aan data naar Microsoft stuurt..

Dat was voor mij de reden om prive on the stappen naar Linux.

Op YouTube staat er genoeg over.

[Simon Weel]

De beheerder komt er maar bekaaid af. Paar voorbeelden? Zwervende profielen en de 'nieuwe' apps. Hoe maak ik een 'default user profile'? Via GPO uitrollen van een aangepast Start-menu. Sysprep. Geen ondersteuning meer voor MDT. De grootste grap is Verkenner. Volgens mij heeft geen enkele applicatie nog moeite met lange (= meer dan 255 tekens) pad / bestandsnamen - behalve Verkenner. Grootste bron van ergernis is de manier waarop permissies worden ingesteld. Ik bedoel - een kolom met vinkjes voor 'Allow' en 'Deny'?!?!? Waarom niet gewoon 1 kolom 'Allow'; geen vinkje is 'deny'. En dan het tenenkrommende verhaal van overerven van permissies. Brrrrr. En zo zijn er nog wat zaakjes waarin Windows 'vroeger' een stuk beter was dan nu....

[Dutch_CroniC]

Las laatst al ergens dat er al enige tijd AI code is Win11 is gevonden. Als dat echt zo is dan zegt dat niet veel goeds.

[jrswgtr]

Wat is er precies mis met "AI code"?

Ik gebruik dagelijks AI om code te schrijven. Zeker sinds de laatste maanden zijn OpenAI Codex en Claude Code vele malen beter geworden. Ze schrijven sneller nettere en foutlozere code dan ik. Soms moet je een beetje bijsturen omdat het model aannames doet over je intenties. Maar dat betekent meestal dat je oorspronkelijke prompt niet duidelijk genoeg was.

Het belangrijkste is dat de maker van de prompts de output kan begrijpen en de resultaten daarvan kan overzien.

AI-code is de toekomst en ik vind dat geen slecht ding. Het geeft mij als programmeur meer tijd om na te denken over de problemen die ik probeer op te lossen met code, in plaats van voornamelijk code kloppen.

[Powerblast]

De updates die ze de laatste maanden uitbrengen doen echter het omgekeerde vermoeden. Nog meer AI generated slop. Dit artikel klinkt langs alle kanten als we moeten de AI hype opgeblazen houden want de aandacht valt stil.

[Standeman]

Volgens mij was dat een hoax en ontkracht door MS.

Maar het zou me niet verbazen als ze een subscription based, AI powered OS willen releasen.

[jpsch]

Zou een slechte zet zijn nu je voor 700 euro een Mac hebt. Maar goed, ze doen wel meer vreemde dingen.

[zalazar]

Dat bericht over Windows 12 bleek niet te kloppen, PC Welt heeft het weer ingetrokken. Nadella laat er niets over los en heeft iedereen verboden er iets over te zeggen, want die is op moment verblind door AI en stopt al zijn geld liever daarin.