[alg/.net] code obfuscation dmv code morphing

[wacco]

Nadat /. de site pbs.org rapporteerde, leek het me mooi punt van discussie voor P&W. Even kort waar het over gaat:

.NET is almost exclusively Just-In-Time compiled. JIT'ing means, "I was just about to interpret this, but I'll compile it at the very last minute instead." In effect, the .NET code remains in interpretation-intended form right up until the end.
...
One area of research is called "Program State Code Protection,” or PSCP, which means changing the code AS IT RUNS to make it harder for a cracker to know what is actually happening. Dotfuscator and DashO, for example, right now change all variable names to the same name. But what if all variable names were changed not just to the same name, but were changed continuously to a wide variety of names?

Het idee is dus hetzelfde als vroege virussen, het wijzigen van de code zelf. Daarnaast gaat het artikel dieper in op het aanbrengen van een 'watermerk' in een stuk programmatuur, zodat het op een 'onzichtbare' manier uit elkaar gehouden kan worden. Met dus in het achterhoofd dat elk stuk programma op een andere manier z'n code morphed.

Nu is dit allemaal wel leuk, maar hoe willen ze dit realiseren? De kunst van morphende (is dat een woord? ) virussen schrijven duurt meestal wel even, en nu gaat een programma 'even' code die normaal helemaal niet wild in het rond springt morphen? Apart. Zeker omdat ze stellen dat:

We no longer let a hacker reverse-engineer a program on paper, we force them to reverse-engineer as the program runs.

Hmm ja, dus we gooien het door een gdb-windows versie, en lopen de stappen door. Als de code al morphed, dan zal het waarschijnlijk het programma zijn dat morphed, en welke dan in verscheidene states een stuk van het eigenlijke programma uitvoert. En om het watermerk principe te realiseren zal het op meerdere fietsen kunnen morphen, welke onderscheiden worden door een key.

Om even af te ronden, dus, hebben we het morphing programma tool in handen, en reverse engineren we de morph mogelijkheden in combinatie met de keys, dan ligt er een breed aantal programma's (straks) die met deze code juist zijn beveiligd compleet open. En omdat de eigenlijke code helemaal gestript is van overbodige variabelen ed, wordt het alleen maar makkelijker.

Ik vind dit toch weer een jammerlijke manier van de ontwikkeling van beveiligingstechnieken. Wat ik zo vreemd vind is dat ze in deze tijden, waar beveiliging tot een enorm marketinginstrument is uitgegroeid, toch .net (een interpretatie framework) proberen door te zetten.

My two cents, now give me yours Denken jullie dat het zo uit de hand zal lopen? Zijn er andere methoden om deze 'morphing' techniek te implementeren? En in hoeverre zullen deze 'watermerken' echt onzichtbaar zijn?

[Remco]

Laat me eerst even beginnen te zeggen dat ik niet alles begrijp wat er geschreven stond, inhoudelijk dan. Het principe is me wel duidelijk.

Maar ik kan mij haast niet indenken dat een bedrijf als microsoft zo zal omgaan met de security van (toekomstige) broncode.

Er vanuit gaande dat het wel zo is, lijkt me dat een groot gevaar.
Ik denk niet dat een morph key snel gevonden zal worden, maar je weet het nooit.
Als deze inderdaad gevonden word, dan ligt inderdaad de complete wereld open.

Ik denk eerder dat de vraag moet zijn, hoe je een veilig stukje code kan laten executen zonder dat daar iets tussen kan komen (virussen) of is te reverse engineren.
Of pscp een goed alternatief hiervoor is zal denk ik alleen uit de toekomst moeten blijken.
Verstandiger lijkt het mij om op zoek te gaan naar een betere methode dan de "onveiligheid" van deze methode proberen aan te tonen.

Denk maar eens na over een methode om code "veilig" te laten executen met daarin gebouwd een soort watermerk.
Ik heb hier even over na zitten denken, maar ik kom nog geeneens tot een globale methode.

Ik hoop niet dat deze discussie aan zal zetten tot de al eeuwig durende discussie tussen microsoft en de rest van de wereld.

[wacco]

Ik snap het idee achter compileren op het laatste moment wel, het heeft namelijk z'n voordelen. Voordelen die de grafische industrie al een tijdje uitbuit; nieuwe drivers (compilers dus) zorgen voor een performance boost bij alle programma's. Vandaar dat er trouwens ook geen linker is voor .net.
Beetje jammer alleen dat de code dus op straat ligt daardoor. Een manier om dat tegen te werken is weer de code obfusceren, maar deze obfuscatie moet plaatsvinden bij de distributie van het programma (dus vóór eigenlijke compilatie). Resultaat: de morphing code, en key, zijn ook op een geinterpreteerde manier aanwezig.
Zou dit niet zo zijn, dan is het dus gecompiled, en kan het hele idee van compilen op het laatste moment weer overboord. Deze beveiliging kan dus het hele principe / voordeel van JITting om zeep helpen. En veilig is het nog steeds niet.

Zowiezo heb ik nog niet heel veel gehoord over .net en makkelijk te reverse engineren. Het voelt allemaal aan als een beetje een marketing praatje enerzijds, en fanatieke nieuwsposters anderzijds. Het grootte probleem ligt natuurlijk op het punt dat men volledig vertrouwd op deze beveiliging, en daarmee de code langzamer en juist minder veilig maakt.

Hoe het beter zou kunnen. Tsja, dat weet ik ook even zo snel niet. Aan de ene kant wilt men code optimalisaties kunnen doorvoeren via een driver/compiler model, aan de andere kant wil men niet geintepreteerde code distributeren...

[Korben]

Ik snap alleen niet waarom ze dit alleen bij .NET zouden willen doen. Want naar mijn idee is goede obfuscated code net zo 'makkelijk' te lezen als een programma dat gedecompiled is door een goede decompiler. Daar zie je in principe ook de goede code, alleen met onbekende variabelenamen. Om zeg maar echt code te beschermen zou 'gewone code' ook runtime morphing moeten zijn, en geen enkel commercieel programma is dat.

[Verwijderd]

Het is misschien een domme vraag, maar hoezo is de mogelijkheid tot het decompileren van CIL/MSIL een security issue? Het is niet wenselijk voor software bedrijven waarschijnlijk, maar in het gelinkte artikel wordt het als groot veiligheids probleem bestempeld, dat zie ik persoonlijk niet echt.