[C# Obfuscators .NET] ervaringen

[stp_4]

Binnen het bedrijf waar ik werkzaam ben heb ik de opdracht gekregen om een onderzoek te doen naar diverse obfuscators om de code van onze applicaties zo goed mogelijk te beschermen. Wij ontwikkelen C# applicaties in Visual Studio.NET 2003. Het doel van dit onderzoek is om een pakket aan te schaffen dat voldoet aan het beveiligingsbeleid en de wensen van het bedrijf. Nu zijn er diverse pakketten beschikbaar zoals:

Dotfuscator .NET Obfuscator
Decompiler.NET
Deploy.NET
Salamander .NET Obfuscator
Semantic Designs: C# Source Code Obfuscator
Spices.Net
Thinstall
Demeanor for .NET
XenoCode .NET Obfuscator and Optimizer

bron

Overige bronnen:

MSDN Dotfuscator
MSDN Magazine
Meer obfuscators

Op dit moment onderzoeken (testen) we drie mogelijke kandidaten:
-Dotfuscator
-XenoCode
-Salamander .NET obfuscator

De eerste indruk van deze drie pakketten is redelijk positief. Er gelden een aantal randvoorwaarden zoals:

- Het kunnen uitsluiten van klasses ( ivm reflectie )
- Integratie in build proces mogelijk ( command line )
- Applicatie via decompilers (ILDASM etc) niet te decompilen.

De drie genoemde applicaties voordoen hier wel aan. Deze pakketten worden op een testmachine getest en voor het obfuscaten wordt gebruik gemaakt van een middelgrote applicatie. Maar waar beoordeel je een pakket nog meer op?

Mijn vraag is of jullie gebruik maken van een van deze pakketten en welke ervaring jullie ermee hebben. Denk hierbij aan de volgende punten:

- Welk pakket gebruiken jullie?
- Met welk beveiligingsniveau nemen jullie genoegen? (renaming, string encryption, control flow)
- Maken jullie gebruik van Visual Studio.NET integratie of via command line?
- Welk voor -en nadelen hebben bovengenoemde pakketten?
- Hoe vinden jullie het gebruikersgemak? (met betrekking tot configuratie, debugging, probleemopsporing)
- Is het makkelijk om upgrades uit te voeren op de applicaties? (incremental obfuscation)

[Spider.007]

Ik heb een alias van dit topic in PW aangemaakt; dan kan die functie ook weer eens nuttig gebruikt worden

[pjvandesande]

Dotfuscator .NET Obfuscator is de enige waar ik mee gewerkt hebt. Deze intergreerd ook met Visual Studio. De enige beveiliging wie wij gebruiken is renaming en string encryption standaart.

Het is ontzettend gebruiksvriendelijk en maakt het mensen een stuk lasting om zomaar is even je paket te gaan decompilen zeker als je ook Control flow toepast.

offtopic:
Leuk zo'n geel mapje!

[Zr40]

stp_4 schreef op donderdag 21 april 2005 @ 10:59:
[...]
- Applicatie via decompilers (ILDASM etc) niet te decompilen.

ILDASM is geen decompiler, het is een disassembler. Disassemblen kan je nooit voorkomen, tenzij de disassembler ondersteuning heeft voor 'weiger disassemblen'
Decompilen is wel te voorkomen, en dit doen veel obfuscators door de control flow aan te passen. Dit vergroot echter wel je assembly. Natuurlijk kan je met behulp van een disassembler ook handmatig decompilen, maar dit kost (met een goede obfuscator) vaak meer tijd dan het waard is.

[ Voor 5% gewijzigd door Zr40 op 21-04-2005 16:36 ]

[stp_4]

Zr40 schreef op donderdag 21 april 2005 @ 16:36:
[...]

ILDASM is geen decompiler, het is een disassembler. Disassemblen kan je nooit voorkomen, tenzij de disassembler ondersteuning heeft voor 'weiger disassemblen'
Decompilen is wel te voorkomen, en dit doen veel obfuscators door de control flow aan te passen. Dit vergroot echter wel je assembly. Natuurlijk kan je met behulp van een disassembler ook handmatig decompilen, maar dit kost (met een goede obfuscator) vaak meer tijd dan het waard is.

Ja sorry daar heb je gelijk (foutje), haalde 2 dingen door elkaar. Het 'weiger disassemblen' is vaak voor een aantal bekende disassemblers vastgelegd hetgeen ook in de configuratie te vinden is.

[Zr40]

stp_4 schreef op donderdag 21 april 2005 @ 16:46:
[...]
Ja sorry daar heb je gelijk (foutje), haalde 2 dingen door elkaar. Het 'weiger disassemblen' is vaak voor een aantal bekende disassemblers vastgelegd hetgeen ook in de configuratie te vinden is.

Ik ben nog geen assembly tegengekomen die Lutz Roeder's Reflector niet kon of wou disassemblen.

[stp_4]

Zr40 schreef op donderdag 21 april 2005 @ 17:21:
[...]

Ik ben nog geen assembly tegengekomen die Lutz Roeder's Reflector niet kon of wou disassemblen.

Pff... het is al laat... haal dingen nu nog meer doorelkaar.... .In sommige obfuscators is het decompilen van een aantal programma's vastgelegd.. Maar het gaat in dit geval dan misschien niet zozeer om de vraag wel/niet decompilen/disassemblen. Feit is inderdaad dat je het disassemblen niet tegenhoudt.

[ Voor 22% gewijzigd door stp_4 op 21-04-2005 17:32 ]

[stp_4]

Zijn er zo weinig tweakers die zich met dit zeer belangrijke onderwerp bezighouden (hebben gehouden)?

[cavey]

stp_4 schreef op dinsdag 26 april 2005 @ 11:23:
Zijn er zo weinig tweakers die zich met dit zeer belangrijke onderwerp bezighouden (hebben gehouden)?

Security by obscurity... kan maar een ding zeggen: Je maakt het de mensen lastiger, maar niet onmogelijk.

Dus waarom al die moeite doen voor zoiets? Je kan er beter voor zorgen dat je ontwerp veilig achter slot en grendel zit.

Of denk ik dan gewoon te simpel?

[stp_4]

komakeef schreef op dinsdag 26 april 2005 @ 11:29:
[...]
Dus waarom al die moeite doen voor zoiets? Je kan er beter voor zorgen dat je ontwerp veilig achter slot en grendel zit.

Kun je dat wat nader toelichten?

[sig69]

Ik denk dat je dan te simpel denkt. Als je helemaal niets doet, kan je net zo goed je source code bij je product leveren. Met drie klikken kan ik de volledige source code van een .executable of dll terughalen (in c# of VB, en het maakt niet eens uit waar het in geschreven is).
Je moet het ook zo zien: het grootste gevaar zit misschien niet eens in het feit dat je klanten je source code terug kunnen halen, maar dus ook je concurrenten en eventuele hackers. En het zoeken naar een functie die licensing afhandelt is niet zo moeilijk...