.Net Obfuscation

[Verwijderd]

Momenteel ben zijn we bezig, om alle GUI code te porten van wxWidgets, naar .Net, vanwege het feit dat de toolset die Visual Studio samen met DotnetBar, ( voor ons )veel meer mogelijkheden biedt dan wxWidgets.

Al onze libraries blijven in principe gewoon native C++, alleen de GUI FrontEnd is geshreven in Managed c++.
Nu was ik onlangs een van de topics hier aan het lezen, die ging over Reflector. Daarom had ik even de executable, 'gedecompiled', nu wat blijkt is dat alle native c++ functie aanroepen. Netjes met naam en toenaam in de executable zitten.

Opzich vind ik dat prima, het is geen 'black magic', wat er allemaal gebeurd. Maar ik zou toch willen dat onze license check niet als 'license::doLicenseCheck()' in de executable terecht komt

Dus daarom het volgende: bestaan er (Freeware) obfuscation programma's voor .Net assemblies. Ik heb uiteraard al gezocht, vooralsnog zonder resultaat.

Bij voorbaat dank.

edit: typo's

[oxfordpelican]

Ik heb wel eens SmartAssembly gebruikt (link)
dit is een goede .Net obfuscator alleen niet freeware.

[sig69]

Bij Visual Studio 2010 krijg je als het goed is gratis de community edition (ofzo) van dotfuscator.

[Verwijderd]

sig69 schreef op maandag 07 februari 2011 @ 21:28:
Bij Visual Studio 2010 krijg je als het goed is gratis de community edition (ofzo) van dotfuscator.

Die zwaar beperkt is. En niet in een zakelijke omgeving gebruikt mag worden.

[johnkeates]

Obfuscation is een vrijwel waardeloze manier van nep bescherming. Het idee is dat iemand niet 'snel kan zien' waar je licentie check zit. Nu is het vaak zo dat iemand die je binaries aan het hacken is niet echt er van uit gaat dat ie zomaar je code kan reflecten en lezen. Het is wel iets wat 'even' gedaan wordt, maar in 99 van de 100 gevallen moet er daarna naar tracing tools gegrepen worden. En dat is dan ook wat er gebeurd.

M.a.w., ga je niet veiliger voelen met een of andere obfuscator! Zo werkt het helaas gewoon niet.
Stel dat je iets 'veilig' wil maken, denk dan in termen a la asymmetrische encryptie (zoals RSA).

[ThaNOD]

johnkeates schreef op maandag 07 februari 2011 @ 21:46:
Stel dat je iets 'veilig' wil maken, denk dan in termen a la asymmetrische encryptie (zoals RSA).

Ik kan dit alleen maar beamen, maar dan nog is enige vorm van obfuscation wel nodig. Stel je wil aan de hand van een met async encryptie sleutel alleen maar controleren of je de applicatie mag runnen dan krijg je zoiets:

code:

if (LicenseClass.isValidLicenseKey(key)){
  runApplication();
} else {
  // show message and close
}

Waarin je de isValidLicenseKey zo beveiligd kan maken als je zou willen, is dit door middel van reflectie erg makkelijk aan te passen naar:

code:

//if (LicenseClass.isValidLicenseKey(key)){
  runApplication();
//} else {
//  // show message and close
//}

wat er dus voor zorgt dat de applicatie altijd wordt uitgevoerd, dit kan je niet voorkomen door middel van obfuscation, maar je kan het een mogelijke aanvaller moeilijker maken door obfuscation toe te passen op je assembly.

Er zijn wel technieken die je kunt gebruiken in managed talen om het allemaal nog moeilijker te maken. Maar als er mensen echt geïnteresseerd zijn in het omzeilen van je beveiliging gaat dit ze te allen tijde lukken (kijk maar naar de piraterij van games en andere software).

[ Voor 0% gewijzigd door ThaNOD op 07-02-2011 22:11 . Reden: in het verhaal reflectie en obfuscation op een aantal plaatsen door elkaar gebruikt ]

[_js_]

johnkeates schreef op maandag 07 februari 2011 @ 21:46:
Obfuscation is een vrijwel waardeloze manier van nep bescherming. Het idee is dat iemand niet 'snel kan zien' waar je licentie check zit. Nu is het vaak zo dat iemand die je binaries aan het hacken is niet echt er van uit gaat dat ie zomaar je code kan reflecten en lezen. Het is wel iets wat 'even' gedaan wordt, maar in 99 van de 100 gevallen moet er daarna naar tracing tools gegrepen worden. En dat is dan ook wat er gebeurd.

M.a.w., ga je niet veiliger voelen met een of andere obfuscator! Zo werkt het helaas gewoon niet.
Stel dat je iets 'veilig' wil maken, denk dan in termen a la asymmetrische encryptie (zoals RSA).

Aangezien de gebruiker (i.e. mogelijke aanvaller) alle code uit moet kunnen voeren is obfuscation de enige vorm van beveiliging die toepasbaar is. Het gebruik maken van encryptie is alleen maar meer obfuscation, het voegt niets wezenlijks toe aan de beveiliging.

[Verwijderd]

Je moet je Assembly iig strong named maken, zodat deze niet gestart kan worden als iemand de code aangepast heeft.

[roy-t]

Je kunt je applicatie ook signen (misschien hetzelfde wat sanderev66 bedoelt), dit helpt ook deels.

[Soultaker]

Voor zover ik weet biedt ondertekenen alleen een garantie aan de gebruiker dat de assembly inderdaad van jou afkomstig is en zorgt strong naming er alleen voor dat jouw assembly niet gerund kan worden in combinatie met andere libraries dan waarvoor je getekend hebt.

In beide gevallen kan een cracker de assemblies wel aanpassen, maar daarna geen ondertekende assembly produceren, maar dat maakt voor een illegale gebruiker waarschijnlijk niet uit.

[Woy]

johnkeates schreef op maandag 07 februari 2011 @ 21:46:
M.a.w., ga je niet veiliger voelen met een of andere obfuscator! Zo werkt het helaas gewoon niet.
Stel dat je iets 'veilig' wil maken, denk dan in termen a la asymmetrische encryptie (zoals RSA).

Maar met asymmetrische encryptie ga je je applicatie niet beveiligd krijgen tegen hackers!

Verwijderd schreef op dinsdag 08 februari 2011 @ 07:19:
Je moet je Assembly iig strong named maken, zodat deze niet gestart kan worden als iemand de code aangepast heeft.

Het Strong-Named maken van je applicatie heeft niet zo heel veel nut. Een cracker kan deze "beveiliging" er natuurlijk gewoon uithalen, of opnieuw signen met een andere key. Zoals Soultaker al zegt is dat eigenlijk enkel nuttig voor de gebruiker om te verifiëren dat de assembly echt van de producent afkomstig is.

Ik denk dat obfuscation wel nuttig kan zijn, want het maakt het geheel zeker wat moeilijker, maar je moet inderdaad niet verwachten dat het de heilige graal is. Maar ook met bijvoorbeeld C++ programma's is het uiteindelijk geen probleem om aanpassingen te doen, het is alleen wat moeilijker zoeken, en dat is ook exact wat je met obfuscation bereikt.

[unclero]

Ooit in een ver en grijs verleden had ik eens zoiets gemaakt voor unmanaged code.
Wat het basically deed was een ge-encrypt archief (3DES, AES) decrypten (license key is de sleutel), en dan de gevonden executable in het geheugen laden en starten.
Werkt nu ongetwijfeld niet meer op Vista (maakte gebruik van wat leuke Winapi calls) .

Maar zoiets zou in .NET in principe nog makkelijker kunnen dmv de reflection.

[Verwijderd]

Bedankt voor de replies, het ging mij inderdaad erom(zoals ThaNod aankaarte ), dat de functie namen, niet zo overduidelijk in de exe staan. Uiteindelijk mochten mensen het programma willen kraken lukt dat toch wel. Het is alleen extra barrier die ik opwerp. Na wat zoekwerk heb ik uiteindelijk deze ( freeware ) opfuscator gevonden:

Eazfuscator.NET 3.0

Iemand hier bekend mee?

[DoDo]

Jep, die doet het obfuscaten goed naar mijn weten. Het enige probleem voor mij is dat hij alle losse DLLs waar het project mee gelinkt is merged naar een file.

Ik gebruik nu Phoenix Protector, te downloaden op de onderstaande URL:
http://www.ntcore.com/phoenix.php

[MLM]

unclero schreef op dinsdag 08 februari 2011 @ 10:10:
Ooit in een ver en grijs verleden had ik eens zoiets gemaakt voor unmanaged code.
Wat het basically deed was een ge-encrypt archief (3DES, AES) decrypten (license key is de sleutel), en dan de gevonden executable in het geheugen laden en starten.
Werkt nu ongetwijfeld niet meer op Vista (maakte gebruik van wat leuke Winapi calls) .

Maar zoiets zou in .NET in principe nog makkelijker kunnen dmv de reflection.

Zoiets kan met .NET ook, maar dan kan de hacker gewoon het programma wanneer het draait uit RAM dumpen. Dat werkt natuurlijk ook met native apps

Maar natuurlijk heeft het wel een beetje zin, als je alle hier genoemde methoden gebruikt, moet de hacker toch nog even flink nadenken voor hij het gereversed heeft.

[Woy]

unclero schreef op dinsdag 08 februari 2011 @ 10:10:
Ooit in een ver en grijs verleden had ik eens zoiets gemaakt voor unmanaged code.
Wat het basically deed was een ge-encrypt archief (3DES, AES) decrypten (license key is de sleutel), en dan de gevonden executable in het geheugen laden en starten.
Werkt nu ongetwijfeld niet meer op Vista (maakte gebruik van wat leuke Winapi calls) .

Maar zoiets zou in .NET in principe nog makkelijker kunnen dmv de reflection.

Het nadeel daarvan is dan dat het erg lastig is om eventueel later license key's te revoken. Als er eenmaal 1 license key uitgelekt is, dan valt er nooit meer wat aan te doen. En anders kan d.m.v. een licence key alsnog de unencrypted binary verspreid worden.

[beany]

Het is een illusie dat je client side code kan beveiligen tegen onrechtmatig gebruik(er is niet voor betaald). Het enige wat je kan doen is doormiddel van obfuscaten er voor zorgen dat je code(algoritmes) zo ondoorzichtelijk mogelijk worden zodat het idee(of eerder de uitvoering) niet makkelijk gejat kan worden.

[urk_forever]

Ons team zit ook te kijken of we Obfuscation moeten toepassen op onze applicaties. Een van de punten waar ik zelf nogal mee zit is het support. Als je een Obfuscation proces over je code draait worden, vziw alle functie namen aangepast.
Dus als je een stacktrace krijgt uit je geobfuscate programma dan zie je dat vanuit functie a, functie b, functie c, functie d aangeroepen is. Maar dan kan je toch nooit meer iets met de stacktrace van je programma?? Met andere woorden je zal altijd een goed onderbouwd stappen plan nodig hebben om fouten te kunnen opsporen.

Of valt dit wel mee?

[creator1988]

urk_forever schreef op dinsdag 08 februari 2011 @ 15:42:
Ons team zit ook te kijken of we Obfuscation moeten toepassen op onze applicaties. Een van de punten waar ik zelf nogal mee zit is het support. Als je een Obfuscation proces over je code draait worden, vziw alle functie namen aangepast.
Dus als je een stacktrace krijgt uit je geobfuscate programma dan zie je dat vanuit functie a, functie b, functie c, functie d aangeroepen is. Maar dan kan je toch nooit meer iets met de stacktrace van je programma?? Met andere woorden je zal altijd een goed onderbouwd stappen plan nodig hebben om fouten te kunnen opsporen.

Of valt dit wel mee?

SmartAssembly kan files genereren waarmee je van de obfuscate stacktraces weer leesbare code kan maken vzv ik weet.

[Janoz]

urk_forever schreef op dinsdag 08 februari 2011 @ 15:42:
Ons team zit ook te kijken of we Obfuscation moeten toepassen op onze applicaties. Een van de punten waar ik zelf nogal mee zit is het support. Als je een Obfuscation proces over je code draait worden, vziw alle functie namen aangepast.
Dus als je een stacktrace krijgt uit je geobfuscate programma dan zie je dat vanuit functie a, functie b, functie c, functie d aangeroepen is. Maar dan kan je toch nooit meer iets met de stacktrace van je programma?? Met andere woorden je zal altijd een goed onderbouwd stappen plan nodig hebben om fouten te kunnen opsporen.

Of valt dit wel mee?

Afaik hebben sommige obfuscation tools ook wel de mogelijkheid om weer terug te vertalen. Hiermee zijn stacktraces waarschijnlijk wel weer leesbaar te maken.

[Verwijderd]

Slightly offtopic:

Juist, wat MLM, ook gezegd had, je dumpt gewoon je hele programma naar ram, zet een eventuele break op 'onLicenseChecked' ( in ons geval ) en stepped net zolang forward totdat de license file(AES) decrypted in het memory aanwezig is. Ik kan wel her en der in de license decryption functie static function calls aanroepen, om bepaalde cruciale variablen wijzigen. Maar goed dat is een ver van mijn bed show, ik weet niet hoe moeilijk dat te tracen is.

[BertS]

Janoz schreef op dinsdag 08 februari 2011 @ 16:06:
[...]

Afaik hebben sommige obfuscation tools ook wel de mogelijkheid om weer terug te vertalen. Hiermee zijn stacktraces waarschijnlijk wel weer leesbaar te maken.

Elke (zichzelf respecterende) obfuscation tool heeft volgens mij wel de mogelijkheid om een mapping-file aan te maken waarmee een stacktrace te herleiden is.

Zelf werk ik met .NET Reactor van Eziriz. Prima product voor een nette prijs.

Natuurlijk is het altijd mogelijk om te kraken. Maar obfuscation maakt het voor de gelegenheidshacker een stuk minder interessant.

[ Voor 11% gewijzigd door BertS op 08-02-2011 22:42 . Reden: opmerking over kraken ]