[Alg] Ervaringen met obfuscation software

[Sebazzz]

Ervaringen met obfuscation software

Naar bytecode gecompileerde talen zoals Microsoft C# en Visual Basic en Sun Java kennen het probleem dat ze erg makkelijk te reverse engineeren zijn met allerlei programma's. In de .NET SDK biedt Microsoft er zelf eentje aan, de IL Disassembler (ildasm.exe).

Nu zijn er wel wat dingen over reverse engineering te zeggen. Behalve dat het niet mag maar toch zeer makkelijk kan zijn er ook softwarebedrijven die hier tools voor gemaakt hebben. Deze tools veranderen de bytecode of de CIL van je stukje software zodat:
• Functienamen veranderen, soms zelfs naar unprintable UTF-8 karakters;
• De flow van de code veranderen, waardoor het een soort moeilijk te begrijpen spaghetti wordt;
• Dependencies samenvoegen met je uitvoerbare bestanden;
• Door middel van overloading meerdere functies in één functie laten samenvallen;
• Fields in classes door middel van een soort overloading samennemen;
• Door ongeldige metadata toe te voegen decompilers en disassemblers laten crashen.
Dit alles zonder dat de werking van je software wordt aangetast, als het goed is.

Soms bieden deze programma's ook extra features:
• Pruning, het verwijderen van niet gebruikte functies en classes;
• Automatisch signing met een sleutel, waardoor veranderingen in de bytecode of CIL opgemerkt worden;
• Onopgevangen exceptions afvangen en naar een server versturen als foutrapport;
• Bericht sturen naar een server als is gedetecteerd dat er geknoeid is met de bytecode of CIL.
• Debug informatie genereren.

Met dit topic heb ik het doel om ervaringen deze obfuscation software te bediscussiëren. Wat maakt obfuscation software goed, welke obfuscation software werkt goed, en hoe integreert het met je ontwikkelomgeving?

Wat obfuscation software waar ik ervaring mee hebt of ken:

Dotfuscator

Talen:	.NET assembly's.
Versies:	Dotfuscator community edition (gratis);
	Dotfuscator community edition plus (gratis met registratie);
	Dotfuscator Professional (betaald).
IDE integratie:	Ja, bij Professional.
Extra features:	Herkenning als er gerommeld is aan de CIL.
Opmerkingen:	Zit standaard bij Visual Studio 2008 meegeleverd, (XML) serialization wordt niet ondersteunt in niet-Pro versies. String encoding alleen bij Professional.

{smartassembly}

Talen:	.NET assembly's.
Versies:	Enterprise (betaald).
IDE integratie:	Niet direct, wel via commandline post-build.
Extra features:	• Memory optimizer
	• Exception reporting
	• Resource compression;
	• Code pruner;
	• PDB generation.
Opmerkingen:	Geen.

Opmerkingen over de TS?

Iets toe te voegen, te veranderen, suggesties? Direct Message

Op het moment ben ik erg tevreden over {smartassembly}. Hij compileert niet zo snel als Dotfuscator, maar heeft een stuk meer opties en in beter te integreren.

[RobIII]

Sebazzz schreef op donderdag 12 februari 2009 @ 21:29:
Nu zijn er wel wat dingen over reverse engineering te zeggen. Behalve dat het niet mag

Says who?

Sebazzz schreef op donderdag 12 februari 2009 @ 21:29:
Iets toe te voegen, te veranderen, suggesties? Direct Message

Waarom zou dat via DM moeten en wat is het nut van een forum dan?

[ Voor 35% gewijzigd door RobIII op 12-02-2009 21:40 ]

[Sebazzz]

RobIII schreef op donderdag 12 februari 2009 @ 21:37:
[...]

Says who?

Wet? Maar je hebt gelijk. Niet direct, maar wel als ik jouw executable terug zou toveren in C# en zelf weer compileer en dan lekker als eigen product gaat verkopen

[...]

Waarom zou dat via DM moeten en wat is het nut van een forum dan?

Niet qua programma's, maar spelfouten en dergelijke wel Forum of topicvervuiling enzo.

[ Voor 15% gewijzigd door Sebazzz op 13-02-2009 21:55 ]

[Verwijderd]

Probeer er maar niet aan te beginnen Reverse Engineering tegen te houden. Je maakt het enkel leuker voor de Reverse Engineers. Niet dat ik het weet, want ik ben er zelf niet erg goed in, maar ik heb er wel al wat over gelezen.

[farlane]

Geen ervaring met die software, ik heb echter wel een stelling:

Als jouw software interessant genoeg is om in aanmerking te komen voor reverse engineering ben je vroeg of laat toch aan de beurt, ergo deze tools hebben weinig nut ( behalve het spekken van de kas van de makers )

[ZaZ]

farlane schreef op vrijdag 13 februari 2009 @ 23:57:
Geen ervaring met die software, ik heb echter wel een stelling:

Als jouw software interessant genoeg is om in aanmerking te komen voor reverse engineering ben je vroeg of laat toch aan de beurt, ergo deze tools hebben weinig nut ( behalve het spekken van de kas van de makers )

Mee eens, maar voor .NET software is het een tikkeltje anders vind ik. Je kan je prog door zo'n tool heen gooien om ervoor te zorgen dat niet iedereen met een of ander tooltje je 'hele' source tevoorschijn tovert. Daarin zou best het ene pakket zich van het andere kunnen onderscheiden.
Kan er zelf alleen niet veel zinnigs over zeggen omdat ik nauwelijks .NET schrijf.

[Verwijderd]

Het is ook wel handig om dan meteen de reverse-engineering tools te bespreken. Als je dat in hetzelfde topic doet krijg je een beetje een idee wat beide kanten doen.

[Sebazzz]

Verwijderd schreef op zaterdag 14 februari 2009 @ 02:23:
Het is ook wel handig om dan meteen de reverse-engineering tools te bespreken. Als je dat in hetzelfde topic doet krijg je een beetje een idee wat beide kanten doen.

Ik zou dit best willen, maar ik weet niet zeker of zoiets policy proof is.

[Woy]

Ik heb wel wat ervaringen met een Obfuscator voor .NET ( Ik kan de naam even niet herinneren ), maar dat waren niet echt goede ervaringen.

Bij het bedrijf waar ik toen werkte werd er bij de releas versies inderdaad ook een obfuscator overheen gehaald, het enige probleem was dat deze blijkbaar niet helemaal correct werkte en op sommige punten de Assembly corrupt maakte, of optimalisaties doorvoerde die de werking van de code veranderde. ( De obfuscator had blijkbaar niet echt goede ondersteuning voor Generics )

Ik kan me heel goed voorstellen dat bedrijven hun intelectuele eigendom willen beschermen, maar ik heb niet het idee dat een obfuscator er echt een goede oplossing voor is. Tuurlijk het maakt het iets moeilijker maar zeker niet onmogenlijk om de werking van de code te zien.

[ Voor 5% gewijzigd door Woy op 14-02-2009 11:14 ]

[roy-t]

Woy schreef op zaterdag 14 februari 2009 @ 11:13:
Ik heb wel wat ervaringen met een Obfuscator voor .NET ( Ik kan de naam even niet herinneren ), maar dat waren niet echt goede ervaringen.

Niet toevallig Dotfuscator, daar heb ik vaker dit soort problemen over gehoord (zelf nooit een obf. tool gebruikt btw, dus 2e hands ervaring )

edit: ik zie net dat niet elke versie om kan gaan met generics, misschien lag daar het probleem: Wikipedia: Dotfuscator

[ Voor 15% gewijzigd door roy-t op 14-02-2009 11:20 ]

[Zoijar]

Sebazzz schreef op vrijdag 13 februari 2009 @ 21:54:
[...]
Wet?

Artikel 45l

Hij die bevoegd is tot het verrichten van de in artikel 45i bedoelde handelingen, is mede bevoegd tijdens deze handelingen de werking van dat werk waar te nemen, te bestuderen en te testen teneinde de daaraan ten grondslag liggende ideeën en beginselen te achterhalen.

Aan de andere kant is het de vraag tot in hoeverre dit opgaat:

Artikel 29a

1. Voor de toepassing van dit artikel wordt onder «technische voorzieningen» verstaan technologie, inrichtingen of onderdelen die in het kader van hun normale werking dienen voor het voorkomen of beperken van handelingen ten aanzien van werken, die door de maker of zijn rechtverkrijgenden niet zijn toegestaan. Technische voorzieningen worden geacht «doeltreffend» te zijn indien het gebruik van een beschermd werk door de maker of zijn rechtverkrijgenden wordt beheerst door middel van toegangscontrole of door toepassing van een beschermingsprocédé zoals encryptie, vervorming of andere transformatie van het werk of een kopieerbeveiliging die de beoogde bescherming bereikt.

2. Degene, die doeltreffende technische voorzieningen omzeilt en dat weet of redelijkerwijs behoort te weten, handelt onrechtmatig.

Denk het niet, omdat een obfuscator het gebruik niet aanpast. Dus dan mag je gewoon reverse engineeren. Maar dat terzijde...

[ Voor 57% gewijzigd door Zoijar op 14-02-2009 11:28 ]

[RobIII]

Zoijar schreef op zaterdag 14 februari 2009 @ 11:22:

Mijn punt was min-of-meer dat het (AFAIK) nog steeds een discussie is die keer-op-keer gevoerd wordt maar waarin nog steeds niet duidelijk is of het nou (wettelijk gezien) wel mag (en dan is het ook nog eens afhankelijk van welk land etc.). Punt was dus dat je niet zo zwart/wit kunt stellen dat het niet mag.

[Woy]

roy-t schreef op zaterdag 14 februari 2009 @ 11:19:
[...]

Niet toevallig Dotfuscator, daar heb ik vaker dit soort problemen over gehoord (zelf nooit een obf. tool gebruikt btw, dus 2e hands ervaring )

edit: ik zie net dat niet elke versie om kan gaan met generics, misschien lag daar het probleem: Wikipedia: Dotfuscator

Nee ik weet zeker dat het niet Dotfuscator was. Ik zal eens kijken of ik nog kan vinden welke het was.

[Confusion]

Sebazzz schreef op donderdag 12 februari 2009 @ 21:29:
Wat maakt obfuscation software goed,

Dat hangt van je doel af. De eerste vraag die beantwoord moet worden is: waarom wil je je code eigenlijk obfuscaten? Ik denk dat het grootste deel van de mensen en bedrijven die zijn code obfuscate dat alleen maar doet wegens een ongefundeerde angst dat iemand 'de code steelt' of 'omdat het kan'.

[Sebazzz]

Confusion schreef op zaterdag 14 februari 2009 @ 18:53:
[...]

Ik denk dat het grootste deel van de mensen en bedrijven die zijn code obfuscate dat alleen maar doet wegens een ongefundeerde angst dat iemand 'de code steelt' of 'omdat het kan'.

Die reden lijkt mij goed genoeg. Als ik iemand een redelijk groot project zoals Werkmanager zou zien stelen en onder eigen naam etc op het net al dan niet tegen betaling zou zien aanbieden zou ik op zijn zachtst gezegd niet vrolijk worden. Je kan natuurlijk de host van de website schrijven etcetera, maar niet iedere host is even blij om die bestanden of die website offline te halen, en voorkomen is altijd beter dan genezen.

[Confusion]

Als iemand jouw code kopieert, dan is dat gemakkelijk aan te tonen. Een rechtzaak win je op je sloffen. Bovendien zal je meestal een licentieregeling hebben met activatiesleutels o.i.d. en die kan de dief niet leveren. Als hij dat dan wil, zal hij aan je code moeten gaan sleutelen. Is het geloofwaardig dat iemand die moeite gaat nemen?

[remmelt]

Met of zonder obfusciation is je code te reverse-engineeren. Als iemand de boel wil kopieren, er z'n eigen naam in wil plakken en het dan opnieuw wil uitbrengen, dan helpt er niets aan. Wat wil je precies voorkomen? Verder vind ik de discussie nogal zinloos. Software is niet te beveiligen, punt. Alle beveiliging wordt vroeg of laat gekraakt, en dan met name de security through obscurity beveiliging. Maak je software zo goed en je services eromheen zo onmisbaar dat je klanten naar jou toe komen. Als ze net zo goed een gekopieerde versie van het net kunnen trekken, doe je iets verkeerd.

[roy-t]

remmelt schreef op zondag 15 februari 2009 @ 00:43:
Met of zonder obfusciation is je code te reverse-engineeren. Als iemand de boel wil kopieren, er z'n eigen naam in wil plakken en het dan opnieuw wil uitbrengen, dan helpt er niets aan. Wat wil je precies voorkomen? Verder vind ik de discussie nogal zinloos. Software is niet te beveiligen, punt. Alle beveiliging wordt vroeg of laat gekraakt, en dan met name de security through obscurity beveiliging. Maak je software zo goed en je services eromheen zo onmisbaar dat je klanten naar jou toe komen. Als ze net zo goed een gekopieerde versie van het net kunnen trekken, doe je iets verkeerd.

Wel leuk en aardig, maar ik heb toch liever dat mijn wachtwoorden opgeslagen worden in SHA1 dan in plain text. Alles is te kraken, het kost slechts tijd. En als iemand door obf. software erg lang bezig is met achterhalen hoe je programma werkt, dan is de kans groter dat iemand afhaakt, alleen de echt serieuze rakkers houd je zo over, die zijn nauwelijks te stoppen, maar je hebt iig een stuk minder snel je software open liggen.

[remmelt]

Ik vraag me gewoon af wat de toegevoegde waarde is van dit soort bescherming. Tegen wie wil je wat beschermen? Wat wil je precies beschermen?

Ik heb altijd het idee dat er door bedrijven die dit soort software verkopen wordt ingespeeld op angsten van programmeurs. De "bescherming" die dan wordt geboden is ook maar halfslachtig en niet eens gegarandeerd werkend.

Waarom tijd en geld besteden aan iets wat geen toegevoegde waarde biedt voor je klanten? Wat in sommige gevallen zelfs vervelend is voor je klanten, bijvoorbeeld wanneer er een bug in de obfuscator zit?

Piraten hou je hoe dan ook, daar helpt niks aan. Mensen die kijken hoe jouw software werkt zul je ook altijd hebben. Het is vervelend als die mensen met jouw eer gaan strijken, maar dan doe je toch ook zelf iets fout. Zorg dat je je betalende klanten te vriend houdt, dan zit het wel goed.

Maar goed, dit gaat een beetje verzanden in de open source vs closed source discussie.

[Voutloos]

remmelt schreef op zondag 15 februari 2009 @ 11:36:
Maar goed, dit gaat een beetje verzanden in de open source vs closed source discussie.

Nee, jij maakt er een discussie van waarbij je jouw open source argumenten kan neerzetten. Als closed source de werkwijze is, voelt men blijkbaar niet genoeg voor open source en heeft het zo closed mogelijk houden wellicht wel een waarde.

[Zoijar]

remmelt schreef op zondag 15 februari 2009 @ 11:36:
Ik vraag me gewoon af wat de toegevoegde waarde is van dit soort bescherming. Tegen wie wil je wat beschermen? Wat wil je precies beschermen?

De miljoenen die je hebt uitgegeven aan R&D en de designs die uiteindelijk niet bleken te werken. Het juweeltje dat is overgebleven na jaren research zie je liever niet direct immitaties van op de open source markt... Natuurlijk wordt software "gekraakt", maar het gaat hier niet om een kopieerbeveiliging, maar om complexe algoritmes. Dat is toch wel iets anders. Ga maar eens na hoe bv een state-of-the-art noise-reduction paket werkt, of een low-level video driver aan de hand van obfuscated code; daar ben je niet in een week uit. NVidia levert bijvoorbeeld ook alleen binary drivers op linux. Er is zat interesse in hoe die werken, maar Nvidia vindt dat hun drivers open stellen te veel informatie over de hardware architectuur biedt. Tot op heden zijn er wel wat pogingen gedaan tot reverse engineeren, maar echt gelukt is het nog steeds niet. Als ze gewoon source code hadden geleverd dan had alles al open gelegen.

[ Voor 44% gewijzigd door Zoijar op 15-02-2009 13:04 ]

[Confusion]

Algoritmes zijn nauw aan datastructuren verbonden. Je kan ze niet zomaar kopieren en als je iemand hebt die ze kan doorgronden, dan kan die ze waarschijnlijk ook prima zelf bedenken. Ik betwijfel dat Ati iets aan de code van Nvidia drivers zou hebben, dat opweegt tegen de risico's van het gebruiken van die code.

[Zoijar]

Confusion schreef op zondag 15 februari 2009 @ 15:28:
Algoritmes zijn nauw aan datastructuren verbonden. Je kan ze niet zomaar kopieren en als je iemand hebt die ze kan doorgronden, dan kan die ze waarschijnlijk ook prima zelf bedenken.

Nee, sorry Zo werkt het niet...

Ik betwijfel dat Ati iets aan de code van Nvidia drivers zou hebben, dat opweegt tegen de risico's van het gebruiken van die code.

Ze zouden er de interne werking / hardware architectuur van de kaart mee kunnen ontdekken. wie weet heeft nvidia wel jaren gewerkt aan een bepaalde manier van registers aanspreken die veel stabieler is (zo maar een uit de lucht gegrepen voorbeeld). Reverse engineering van de driver zou zo'n techniek op kunnen geven; je hoeft maar een keer een "aha dus zo doen ze dat", momentje te hebben. Veel state-of-the-art algoritmes bestaat uit slimme truckjes die op zichzelf niet heel moeilijk zijn, maar je moet er wel op komen.

[EfBe]

(.NET specifieke reply)
Wij gebruiken obfuscation in de trial versie van ons product, om de doodeenvoudige reden dat het het moeilijker maakt om de trial te cracken. We hebben niet de illusie dat het het totaal tegenhoudt, maar het maakt het wel moeilijker, en elke obstakel is er 1. Obfuscation is verder erg lastig voor versies voor klanten, want bv stacktraces zijn ook obfuscated en je komt er dan als developer vaak niet uit zonder 'mapping tables' die vaak lastig te hanteren zijn.

Wil je goede obfuscation voor .NET, dan hoef je niet echt ver te zoeken, de gratis tool die bij vs.net zit is prima. Wat men vaak vergeet is dat het obfuscation resultaat afhangt van je eigen code: Iedere method, property en class die je internal of private kunt maken is obfuscatable en dus moet je ernaar streven om zoveel mogelijk classes en methods internal of private te maken. Bv een .exe hoeft geen public members te hebben, want hij wordt niet gereferenced. Zodoende kun je een zeer hoge obfuscatie-graat bereiken, zelfs met gratis tooltjes.

Pas op met tools die de IL code zodanig vernaggelen dat bv reflector er niets meer mee kan: veelal loop je dan ook tegen problemen op op 64bit .NET, bv als je de XHEO rommel gebruikt loop je risico dat het neit werkt, dat assemblies niet dynamisch kunnen worden geladen, wees daar dus op voorbereid

Ikzelf zie niet zoveel in de waarde van code, de IP die men wil beschermen is de kennis die geleid heeft tot de code, dus de algoritmen en de designbeslissingen die men heeft genomen op basis van rationele gronden, is veel meer waard. Het punt is nl, dat je wel een stuk code kunt reverse engineeren, maar je kent totaal niet de kennis erachter: de code aanpassen is dan bv een lastige klus, want je weet niet hoe de code werkt en wat erger is: je hebt niet de kennis die geleid heeft tot die code dus je maakt geheid de verkeerde beslissing mbt een aanpassing (bv, een beslissing die door de originele makers al is afgeschoten ivm een bepaalde reden).

[ Voor 23% gewijzigd door EfBe op 15-02-2009 16:03 . Reden: zinsdeel toegevoegd ]

[Verwijderd]

Zoijar schreef op zondag 15 februari 2009 @ 12:58:
[...]

De miljoenen die je hebt uitgegeven aan R&D en de designs die uiteindelijk niet bleken te werken. Het juweeltje dat is overgebleven na jaren research zie je liever niet direct immitaties van op de open source markt... Natuurlijk wordt software "gekraakt", maar het gaat hier niet om een kopieerbeveiliging, maar om complexe algoritmes. Dat is toch wel iets anders. Ga maar eens na hoe bv een state-of-the-art noise-reduction paket werkt, of een low-level video driver aan de hand van obfuscated code; daar ben je niet in een week uit. NVidia levert bijvoorbeeld ook alleen binary drivers op linux. Er is zat interesse in hoe die werken, maar Nvidia vindt dat hun drivers open stellen te veel informatie over de hardware architectuur biedt. Tot op heden zijn er wel wat pogingen gedaan tot reverse engineeren, maar echt gelukt is het nog steeds niet. Als ze gewoon source code hadden geleverd dan had alles al open gelegen.

ATI heeft die kaarten van NVDIA echt allang fysiek opengemaakt. Daar hebben ze geen opensource drivers voor nodig. De mensen van Nouveau zijn trouwens al vrij ver met reverse-engineering. Ze gebruiken daarvoor een zelfgemaakt programma, die naar de NVDIA-driver kijkt terwijl die in actie is. Dan gaan ze grafische test cases runnen, en kijken wat de driver daarmee doet. Voor de meeste kaarten zijn al genoeg van die test runs gedaan. Een 2D-driver is bijna klaar, en Quake III heeft ook al gedraaid op de bakken van sommige ontwikkelaars.

De software is ook helemaal niet zo boeiend. Als NVIDIA alleen specificaties van de kaart had gegeven, zoals ATI, dan was in een maand de opensource driver er geweest, zoals bij ATI.

[jos707]

Zoals eerder aangehaald is reverser engineering van een applicatie niet tegen te houden, een beetje zoals het beste slot op je voordeur niet garandeerd dat het alle dieven zal buitenhouden. Maar wat ik mij soms afvraag wanneer het over in bytecode gecompileerde talen gaat is of er niet steeds een minimum aan obfuscation moet worden gedaan wanneer een product wordt afgeleverd aan een externe partij. De source van een c# applicatie kan tevoorschijn worden getoverd door eender welke leek die de juiste tool gebruikt.

Stel bijvoorbeeld dat ons bedrijf een applicatie ontwikkeld voor een bepaalde klant. Deze klant een grote internationale organisatie gebruikt deze applicatie voor bepaalde bedrijfskritische processen. In dit soort bedrijven lopen mensen rond van allerei allooi, best ook wel veel scriptwizzies die het gemakkelijk voor elkaar krijgen jouw product te hercompileren met allerlei toegevoegde rotzooi, al dan niet bewust/onbewust.
Indien ze dit product dan gaan gebruiken zou dit allerlei rare dingen beginnen doen in hun systemen en (grote) schade kunnen berokkenen aan de organisatie. De manager zou dan kunnen beslissen dat dit de schuld is van onze applicatie en trachten de schade te verhalen op ons bedrijf of gewoon alle lopende contracten openbreken. Dit is natuurlijk worst case scenario maar is imho wel mogelijk.

[Verwijderd]

Dat lijkt me een heel vreemde situatie. Ten eerste mogen ze dat waarschijnlijk helemaal niet, omdat ze dan jouw copyright schenden. Naast contractbreuk hebben ze dan ook copyright schending aan hun broek. En ten tweede gaat zo'n bedrijf die kritieke software niet vervangen door zelf aangeklooide rotzooi. Dat laat een normale manager niet toe.

En het werkt dan ook de andere kant op: de manager zou vanwege de obfuscation ook kunnen beslissen de contracten te breken, omdat z'n werknemers klagen dat ze de boel niet kunnen hercompileren. Dat is even belachelijk natuurlijk.

[RobIII]

jos707 schreef op zondag 15 februari 2009 @ 18:17:
Deze klant een grote internationale organisatie gebruikt deze applicatie voor bepaalde bedrijfskritische processen. In dit soort bedrijven lopen mensen rond van allerei allooi, best ook wel veel scriptwizzies die het gemakkelijk voor elkaar krijgen jouw product te hercompileren met allerlei toegevoegde rotzooi, al dan niet bewust/onbewust.

Zie je wat je zelf zegt? Alsof een 'scriptwizzie' überhaupt in zo'n organisatie de files zou kunnen aanpassen/overschrijven. En alsof iemand die daar wel machtigingen toe heeft zich zoiets in zijn hoofd haalt. En dan nog het feit dat degenen die het niveau 'scriptwizzie' ontstegen zijn zich ook wel 4x bedenken voordat ze met bedrijfskritische zaken in grote internationale organisaties gaan zitten rommelen. En heb je er dan toch een die dat flikt omdat 'ie ze niet alle 7 op een rijtje heeft dan is het nog altijd zijn probleem en niet dat van de softwareproducent. Als ik de airbags uit mijn auto sloop en dan voor de rest van mijn leven gehandicapt raak door het aantikken van een paaltje hoef ik écht niet bij die autofabrikant aan te kloppen hoor

[Gerco]

jos707 schreef op zondag 15 februari 2009 @ 18:17:
De source van een c# applicatie kan tevoorschijn worden getoverd door eender welke leek die de juiste tool gebruikt.

En dat is heel plezierig voor mensen die met die applicatie moeten werken danwel plugins of andere code tegenaan schrijven. De keren dat ik mbv reflector of jad een bug of workaround achterhaald heb zijn inmiddels ontelbaar. Die mogelijkheid niet hebben zou me behoorlijk frustreren in mijn werk.

Ik werk in integratie en heb dus heel vaak inzicht nodig in verschillende applicaties. Die pas ik nooit aan (dat zou niet mogen), maar het is vaak wel nodig om informatie los te peuteren die je niet op een andere manier kan krijgen.

De manager zou dan kunnen beslissen dat dit de schuld is van onze applicatie en trachten de schade te verhalen op ons bedrijf of gewoon alle lopende contracten openbreken. Dit is natuurlijk worst case scenario maar is imho wel mogelijk.

Los van het feit dat zoiets niet zomaar in productie genomen gaat worden in een beetje organisatie, dan controleer je de signatures op je binaries (die zijn natuurlijk wel signed, he?) en schuif je het resultaat onder de neus van die manager. Case closed.

[ Voor 4% gewijzigd door Gerco op 15-02-2009 20:34 ]

[jos707]

Verwijderd schreef op zondag 15 februari 2009 @ 19:43:
Dat lijkt me een heel vreemde situatie. Ten eerste mogen ze dat waarschijnlijk helemaal niet, omdat ze dan jouw copyright schenden. Naast contractbreuk hebben ze dan ook copyright schending aan hun broek. En ten tweede gaat zo'n bedrijf die kritieke software niet vervangen door zelf aangeklooide rotzooi. Dat laat een normale manager niet toe.

En het werkt dan ook de andere kant op: de manager zou vanwege de obfuscation ook kunnen beslissen de contracten te breken, omdat z'n werknemers klagen dat ze de boel niet kunnen hercompileren. Dat is even belachelijk natuurlijk.

Als je een wijdere visie aanneemt zie je dat deze soort zaken niet onmogelijk zijn. Naar mijn ervaringen wordt er ook in grote bedrijven niet alles volgens het boekje gedaan. Soms heiligd het doel de middelen en maakt men zich verder geen zorgen over schendingen van copyrights. Als ik zie wat er zoal rondloop op de ontwikkelafdeling van sommige niet IT bedrijven die voor een stuk hun eigen software schrijven en voor een ander stuk vertrouwen op externe leveranciers dan is volgens mij bovenstaand scenario niet ondenkbaar.
Ik heb in het verleden enige tijd op een helpdesk gezeten waar ik regelmatig telefoontje krijg van klanten dan onze software dienst weigerde of dat er steeds een vervelende terugkomende foutmelding verscheen.
Bleek soms achteraf dat de klant op eigen iniatief bestaande scripts ging aanpassen of zelfs in de databank eigen tabellen ging aanmaken. (db was niet beveiligd, en moet toegeven dat dit een grove fout was van het bedrijf).
In een grote organisatie zal dit wellicht minder snel gebeuren maar een manager weet niet altijd wat dat jochie dat juist afgestudeerd is en vorige week is aangenomen allemaal uitspookt achter zijn pc. Misschien zal deze zich proberen te bewijzen door allerlei rare trucs uit te halen met software in de hoop dat die één of ander vervelende bug opgelost krijgt.

[remmelt]

Ik zie nog steeds niet in hoe die obfuscator daarin zou kunnen helpen. Indien er in een groot bedrijf de kritische processen te beïnvloeden zijn door de jongste bediende in de postkamer, dan is er iets nogal mis. Als ze denken jouw bedrijf daarvoor verantwoordelijk te kunnen stellen, heb je a) andere klanten nodig en b) niks aan het feit dat je code moeilijker te achterhalen is, want die rechtzaak komt er dan toch wel, of het nou terecht is of niet.

Je verleent service op de door jou aangeleverde software, tenzij contractueel anders overeengekomen. Zo moeilijk is het niet. Als zij de software aanpassen: good luck ermee!

[EfBe]

remmelt schreef op zondag 15 februari 2009 @ 22:19:
Ik zie nog steeds niet in hoe die obfuscator daarin zou kunnen helpen. Indien er in een groot bedrijf de kritische processen te beïnvloeden zijn door de jongste bediende in de postkamer, dan is er iets nogal mis. Als ze denken jouw bedrijf daarvoor verantwoordelijk te kunnen stellen, heb je a) andere klanten nodig en b) niks aan het feit dat je code moeilijker te achterhalen is, want die rechtzaak komt er dan toch wel, of het nou terecht is of niet.

Je verleent service op de door jou aangeleverde software, tenzij contractueel anders overeengekomen. Zo moeilijk is het niet. Als zij de software aanpassen: good luck ermee!

Het hangt er maar helemaal vanaf wat er in het contract staat dat de software engineer heeft met de opdrachtgever: is de software engineer puur een dienst aan het leveren (en is de opdrachtgever dus meteen eigenaar van de code), of is de software engineer een product aan het maken en is de software engineer eigenaar van de code. Dit is essentiele kost en in het kader van het 2e geval kan ik me wel voorstellen dat een software engineer de handel obfuscate zodat bij wijzigingen hij weer gebeld wordt.

[creator1988]

Gebruikten bij een vorig project smartassembly, zeer goede tool, ook qua support (kregen binnen een uur een minor build met een net ingeschoten bugfix, met dr vraag of dit het probleem oploste).

Gebruikten het overigens voor WPF Browser Apps.

Voor mij in ieder geval: voor alles wat naar een niet betalende client wordt gestuurd, wordt geobfuscate. Eens met wat efbe daarover zei.

[Knakker]

Heeft iemand ervaring met .NET Reactor? Zijn er ook bijwerkingen?

We zoeken een pakket waarmee we onze software dusdanig kunnen versleutelen dat men niet heel makkelijk aan de haal kan met de algoritmes die het heeft...

[ Voor 16% gewijzigd door Knakker op 31-08-2009 22:49 ]

[Sebazzz]

Knakker schreef op maandag 31 augustus 2009 @ 22:47:
We zoeken een pakket waarmee we onze software dusdanig kunnen versleutelen dat men niet heel makkelijk aan de haal kan met de algoritmes die het heeft...

"niet heel makkelijk", correcte woordkeuze. Ik vind {smartassembly} nog steeds erg fijn werken.

[Gomez12]

Knakker schreef op maandag 31 augustus 2009 @ 22:47:
Heeft iemand ervaring met .NET Reactor? Zijn er ook bijwerkingen?

Tja ik zou zeggen lees de docs, het hangt er een beetje vanaf hoe zeer op het randje je zit te code.

Ik heb nog geen obfuscator gezien die ik niet over de jank kreeg met wat exotische code-dingetjes, maar omgekeerd in de dagelijkse praktijk heb ik maar 2 keer een obfuscator over de jank zien gaan en dat was redelijk snel opgelost met een patch... ( 1e keer binnen een paar uur, 2e keer binnen 3 werkdagen allebei ruimschoots acceptabel zolang je maar regelmatig proefcompiles doet en je niet pas op de dag van release echt met alle officiele instellingen gaat compilen )

[Knakker]

Het gaat mij vooral om de zaken die niet in de documenten staan: dus in hoeverre mijn code daadwerkelijk andere dingen zou kunnen gaan doen. Ik heb de trial gedownload en zo op het eerste gezicht lijkt het goed te werken; verder is de prijs natuurlijk ook alleszins acceptabel, dus vandaar de interesse.

Hoe makkelijk is het om Reactor/Smartassembly te ontsleutelen? Is dat een kwestie van een paar minuten met een tooltje (een beetje zoals je met Reflector een items uit 'onbeschermde' assembly naar C# code kunt omzetten ) of kost zoiets meer tijd?

[Douwe63]

Ik ben ook wel geinteresseerd in ervaringen met Smartassembly. Momenteel gebruik ik de gratis versie van de Dotfuscator van Preemptive maar die mist uiteraard weer net wat functionaliteit om er echt lekker mee te werken.

[Sebazzz]

Er zijn reviews en trials van {smartassembly}. Ik suggereer dat je die opties even bekijkt

[Douwe63]

Sebazzz schreef op woensdag 03 maart 2010 @ 21:10:
Er zijn reviews en trials van {smartassembly}. Ik suggereer dat je die opties even bekijkt

Dat had ik uiteraard al gedaan, echter die reviews zijn vaak niet echt 'in depth'. Ik ben wel benieuwd naar de problemen die optreden als de boel wat intensiever gebruikt wordt. Is het bijvoorbeeld al eens gebeurd dat na een 'prune' de code niet meer werkt en meer van dat soort zaken...

[Chip.]

Natuurlijk vind TS het niet leuk dat zijn programma's gereversed engineered worden maar tegelijkertijd wel http://www.smartassembly.com/ onbetaald gebruiken

[ Voor 21% gewijzigd door Chip. op 03-03-2010 21:51 ]

[Douwe63]

Wouser schreef op woensdag 03 maart 2010 @ 21:50:
Natuurlijk vind TS het niet leuk dat zijn programma's gereversed engineered worden maar tegelijkertijd wel http://www.smartassembly.com/ onbetaald gebruiken

Hoe kom je daar bij?

[Gomez12]

Douwe63 schreef op woensdag 03 maart 2010 @ 21:28:
[...]
Dat had ik uiteraard al gedaan, echter die reviews zijn vaak niet echt 'in depth'. Ik ben wel benieuwd naar de problemen die optreden als de boel wat intensiever gebruikt wordt. Is het bijvoorbeeld al eens gebeurd dat na een 'prune' de code niet meer werkt en meer van dat soort zaken...

Simpel gezegd ( geen hands on met smartassembly ).

Definieer intensiever gebruik...
Zolang je binnen de "normale regelset" van een taal blijft krijg je in principe geen errors...

Ga jij er bijv. Cuda in stoppen dan verhoog je de kans op errors, ga jij exotische dll's gebruiken dan verhoog je de kans op errors, ga jij assembly inline gebruik gebruiken dan maximaliseer je zo ongeveer de kans op errors.

Definieer jij intensiever gebruik als uitgebreide algoritmen binnen de standaard regelset en binnen de standaard library's dan zit je vrij safe.
Definieer jij intensiever gebruik als bleeding edge programming wat echt op niet-standaard hardware x anders moet reageren dan op niet-standaard hardware y ( oftewel standaard directx oid zit 3 niveaus lager dan waar jij op zit te programmeren ) dan kan je een uitdaging hebben.

Als algemene rule of thumb heb ik wel eens geroepen : Als je op het diepste niveau nog steeds op F1 kan drukken en zinnige info krijgt dan is het safe.
Uiteraard zijn er hier weer specifieke uitzonderingen op en gaat dit niet op voor elke obscure alpha / beta obfuscator. Maar voor een main-release van een algemene obfuscator gaat dit wel op.

[YakuzA]

Gebruik hier voor mijn werk ook smartassembly. Tot nu toe beperkt gebleven met desktop standalone apps.

Is relatief eenvoudige code zonder (ge/mis)bruik van 'exotische code'.
Ben dan ook nog geen problemen tegen gekomen met het gebruik van deze obfuscator.

De obfuscator zelf wordt hier inderdaad gebruikt omdat er algoritmes inzitten waar een flinke ontwikkeltijd in is geinvesteerd.

[Douwe63]

Gomez12 schreef op woensdag 03 maart 2010 @ 23:36:
[...]

Simpel gezegd ( geen hands on met smartassembly ).

Definieer intensiever gebruik...
Zolang je binnen de "normale regelset" van een taal blijft krijg je in principe geen errors...

Ok duidelijk, dank!

Met intensiever gebruik bedoelde ik bijvoorbeeld ook incremental obfuscation. Je hebt een product gereleased (een .exe met een hele zwik .dll's) en je moet een hotfix uitleveren. De gratis versie van Dotfuscator vereist dat ik alle files weer release omdat het niet mogelijk is om met de vorige rename mapping alleen de aangepaste .dll naar de klant te sturen.

[Douwe63]

Net even de trial van smartassembly gedownload maar nu lijkt het er op dat ik attributen in m'n source code moet zetten om bijvoorbeeld [serializable] classes niet te obfuscaten. Dat heeft de Dotfuscator toch beter voor elkaar. Toch maar eens in de manual/documentatie duiken om te kijken of dat niet handiger kan, ik wil niet m'n sources aanpassen voor een tool.

[Cartman!]

Wij kregen laatst een stukje code van een externe partij die blijkbaar obfuscated was (php). Die code veroorzaakte alleen errors dus dat was onhandig. Na wat googlen kwam ik erachter dat het obfuscated was met PHPLockit! die zelf beweren dat het encrypt. Na wat pielen heb ik een scriptje gemaakt die direct een PHPlockit bestandje kan terugvormen naar volledig originele code. We hebben dus die partij teruggemaild met "je fout zit op lijn 14 bij die declaratie" Kregen we een dag later een nieuwe terug, wij die ff bekeken en zat in feite dezelfde fout er nog in. Weer teruggestuurd en toen kregen we wel een goede terug. Hopelijk schamen ze zich voor hun brakke code en hun domme keuze voor zulke slechte software.

[Gomez12]

Cartman! schreef op zaterdag 06 maart 2010 @ 16:05:
Wij kregen laatst een stukje code van een externe partij die blijkbaar obfuscated was (php). Die code veroorzaakte alleen errors dus dat was onhandig. Na wat googlen kwam ik erachter dat het obfuscated was met PHPLockit! die zelf beweren dat het encrypt. Na wat pielen heb ik een scriptje gemaakt die direct een PHPlockit bestandje kan terugvormen naar volledig originele code. We hebben dus die partij teruggemaild met "je fout zit op lijn 14 bij die declaratie" Kregen we een dag later een nieuwe terug, wij die ff bekeken en zat in feite dezelfde fout er nog in. Weer teruggestuurd en toen kregen we wel een goede terug. Hopelijk schamen ze zich voor hun brakke code en hun domme keuze voor zulke slechte software.

Tja, maar met script-talen pak je ook wel een voorbeeld wat ( normaal gesproken ) niet te obfuscaten valt. De interpreter moet altijd script-code ontvangen, dan kan je wat gaan goochelen en moeilijk etc.
Maar het moet altijd script-code blijven

Zend heeft hier dan wel een component voor uitgebracht waardoor het niet meer script-code hoeft te blijven, maar voor de rest is het allemaal gewoon de script-code enkel iets anders geordend en wat variabelen hernoemt...

Is zo ongeveer hetzelfde als dat assembly ook niet valt te obfuscaten.

[Douwe63]

Douwe63 schreef op zaterdag 06 maart 2010 @ 15:02:
Net even de trial van smartassembly gedownload maar nu lijkt het er op dat ik attributen in m'n source code moet zetten om bijvoorbeeld [serializable] classes niet te obfuscaten. Dat heeft de Dotfuscator toch beter voor elkaar. Toch maar eens in de manual/documentatie duiken om te kijken of dat niet handiger kan, ik wil niet m'n sources aanpassen voor een tool.

Voor de volledigheid, smartassembly ziet zelf al dat het een [Serializable] klasse is en daardoor wordt hij al niet geobfuscate, handig! Verder is het wel mogelijk om vanuit de tool per klasse het obfuscaten uit te zetten. Deze optie werd echter pas zichtbaar nadat je een assembly geselecteerd had om te obfuscaten, daarom kon ik hem eerder niet vinden

Wat wel jammer is dat een .exe + zwik .dll's altijd samengevoegd worden in een enkele .exe (en dit is niet uit te zetten). De namespaces van alle klassen worden nu aangepast en gaat mijn binary serialization de mist in (met andere worden, huidige data bestanden zijn niet meer in te lezen nadat ik smartassembly gebruikt heb).

Nog maar even verder kijken dus.. (tips voor andere obfuscators zijn ook nog welkom ).

[YakuzA]

Douwe63 schreef op dinsdag 09 maart 2010 @ 14:22:
[...]


Voor de volledigheid, smartassembly ziet zelf al dat het een [Serializable] klasse is en daardoor wordt hij al niet geobfuscate, handig! Verder is het wel mogelijk om vanuit de tool per klasse het obfuscaten uit te zetten. Deze optie werd echter pas zichtbaar nadat je een assembly geselecteerd had om te obfuscaten, daarom kon ik hem eerder niet vinden

Wat wel jammer is dat een .exe + zwik .dll's altijd samengevoegd worden in een enkele .exe (en dit is niet uit te zetten). De namespaces van alle klassen worden nu aangepast en gaat mijn binary serialization de mist in (met andere worden, huidige data bestanden zijn niet meer in te lezen nadat ik smartassembly gebruikt heb).

Nog maar even verder kijken dus.. (tips voor andere obfuscators zijn ook nog welkom ).

Valt niet uit te zetten?
Bij mij houd hij de .dll's gewoon buiten de .exe. (Dependency embedding/merging) Misschien gebruik je een andere constructie?

[Douwe63]

YakuzA schreef op dinsdag 09 maart 2010 @ 15:03:
[...]

Valt niet uit te zetten?
Bij mij houd hij de .dll's gewoon buiten de .exe. (Dependency embedding/merging) Misschien gebruik je een andere constructie?

Maar hij obfuscate you .dll's wel? Of heb je misschien een al wat oudere versie van het programma?

Op de support website (http://www.smartassembly....lAssembliesWithoutMerging) kwam ik het volgende tegen:

How to protect several assemblies without merging them?

{smartassembly}'s current project model is to create one assembly at a time.
So, if you want to obfuscate several assemblies without merging them, you need to create several projects.

{smartassembly} automatically exclude the public members from the obfuscation/pruning of the dependencies, so the protected DLLs will be 100% compatible with the originals. And, at the end, all your protected assemblies will work together.

Ik heb ongeveer 30 .dll's bij onze applicatie en ik zie het niet zitten om 30 smartassembly projecten te gaan maken.