[NET] Source beveiliging wel echt mogelijk?

[ErikRo]

The first open source decompiler and source code generator has now been released for .NET executables. Looks like the only protection for your source code is to house it solely on your own servers. If it's distributed, it's wide-open. Forget the /OWNER compiler switch, as that's only protection against willing code breakers like ILDASM.

----

Dit leuke stukje kwam ik ergens tegen.
Wat ik hieruit begrijp (het ging over VB7/VB.NET) dat de code amper te beveiligen is. Gaat dit verhaal dan ook op voor C# (ik neem aan van wel, gezien de opbouw van beide) of zit ik weer eens helemaal naast?

[BCC]

Gezien het feit dat C# erg tegen Java aanhangt, kun je er vanuit gaan dat het idd redelijk eenvoudig te de-compilen is.

[.oisyn]

BCC schreef op 10 oktober 2002 @ 00:48:
Gezien het feit dat C# erg tegen Java aanhangt, kun je er vanuit gaan dat het idd redelijk eenvoudig te de-compilen is.

je link met java snap ik niet helemaal, maar idd, C# zal onwaarschijnlijk ook makkelijk te decompilen zijn. Vooral omdat C# bijna een 1-op-1 vertaling is van de IL

[Verwijderd]

Het heeft helemaal niets te maken met de taal die je gebruikt om .Net assemblies mee te maken. Een assembly bestaat uit o.a. MSIL (MicroSoft Intermediate Language), en alle .Net talen compileren daarnaar. Zo is het dus mogelijk om die MSIL weer om te zetten naar code met een decompiler.

Dit is inderdaad nauwelijks te voorkomen. Daarom is server based computing in dat geval beter, en moet je er 100% zeker van zijn dat in je client-side code geen geheime zaken staan. Passwords hardcoden in je software is dus uit den boze.

[SkyKnife]

Zoals MrX al zegt,
elke compilatie van .net code (ongeacht welke taal) is een vertaling naar MSIL language.
Als iemand een decompiler heeft gemaakt van MSIL naar vb kan dat programma elke gecompileerde file (met weinig uitzonderingen) vertalen naar vb. Dit zou dan ook kunnen met .net dll's waarvan de source in c# is gemaakt.

Dit is mischien ook een methode die in de toekomst gebruikt gaat worden? vb code -> c# code?

iig moet je je gecompileerde code ook zien als source code (en niet vrijgeven?).

Je link met java is daar:
Java source code wordt ook naar een intermediate language omgezet. Dit is ook te decompilen ?

Obfuscation, waar ACM het zo over heeft, maakt het de persoon die de decompileerde code wil lezen alleen moeilijker. De code blijft leesbaar. Ook is niet alles obfuscatable (als er zo'n woord bestaat). Als je een FileSystemObject aan maakt moet dat ook echt die naam hebben. Dit kun je niet zomaar renamen. Alleen alles wat jij zelf een naam hebt gegeven (classes, functies, variabelen) kan je renamen (door obfuscator) naar a1 tot en met a1000. Maakt het wel zo leesbaar achteraf.

Ik zou graag de naam horen van deze decompiler waar je het over had. (Als deze vraag niet kan Modjes laat me het even weten en verwijder hem. Wil niets stouts doen )

edit:
spel fouten + ACM's Obfuscation + Java link

[ACM]

Bij java is er een leuke truc uitgehaald daartegen.
Obfuscation, hoewel men daar sceptisch over mag zijn vermoed ik niet dat je zoiets weet te begrijpen:

code:

            as.a(); 
            b b1 = new b(); 
            h h1 = new h(); 
            a.b.b.a.a a1 = new a.b.b.a.a();
            a a2 = new a();

[gorgi_19]

SkyKnife schreef op 10 oktober 2002 @ 01:41:
Ik zou graag de naam horen van deze decompiler waar je het over had. (Als deze vraag niet kan Modjes laat me het even weten en verwijder hem. Wil niets stouts doen )

C# en VB.Net zijn gruwelijk eenvoudig te decompilen... Er zijn al zat tools voor te vinden. Ik kwam laatst een discussie hierover tegen op het asp.net forum.

http://www.asp.net/Forums...bindex=1&PostID=16847

In deze discussie wordt zelfs zo ver beweerd dat, afhankelijk van de gebruikte taal (VB.Net, C#, Cobol.Net, etc.) er al dan niet letterlijke C#-code uit komt rollen.

Overigens kan de code van .NET wel enigszinfs beveiligd worden door middel van de methode die ACM aangaf. Ook hier zijn programma's voor, waarbij sommigen nauwelijks de moeite waard lijken te zijn, terwijl anderen meer hoop lijken te bieden.

Zie ook:
http://www.asp.net/Forums...bindex=1&PostID=45621

[ErikRo]

SkyKnife schreef op 10 oktober 2002 @ 01:41:
iig moet je je gecompileerde code ook zien als source code (en niet vrijgeven?).

OK, maar je zal toch ook wel eens programma's voor iemand moeten maken, die gewoon bij iemand neergezet moet worden, de zogenaamde executable. Dan zal je er toch echt niet aan ontkomen. Of we moieten allemaal een grote server aanschaffen of serverruimte huren bij MS.

Poing: ineens valt het kwartje bij Erikro.

[Glimi]

Verwijderd schreef op 10 oktober 2002 @ 01:28:
Dit is inderdaad nauwelijks te voorkomen. Daarom is server based computing in dat geval beter, en moet je er 100% zeker van zijn dat in je client-side code geen geheime zaken staan. Passwords hardcoden in je software is dus uit den boze.

Dit is altijd als uit de boze geweest. Met het unix strings commando grijp ik zo alle ascii coded strings uit een binary.

[Verwijderd]

Glimi schreef op 10 oktober 2002 @ 09:05:
[...]

Dit is altijd als uit de boze geweest. Met het unix strings commando grijp ik zo alle ascii coded strings uit een binary.

/me knikt
'tuurlijk ... ik onderstreepte hier het gevaar in dit geval even.

ErikRo schreef op 10 oktober 2002 @ 08:26:
[...]

OK, maar je zal toch ook wel eens programma's voor iemand moeten maken, die gewoon bij iemand neergezet moet worden, de zogenaamde executable. Dan zal je er toch echt niet aan ontkomen. Of we moieten allemaal een grote server aanschaffen of serverruimte huren bij MS.

Poing: ineens valt het kwartje bij Erikro.

Meestal zal je voor een n-tier applicatie alleen triviale UI code in de executable willen stoppen, en alle business logic op een server willen uitvoeren. Voor stand-alone applicaties, waarbij business logic op de client moet gebeuren, is dit inderdaad een issue, en zal alleen een obfuscator soelaas kunnen brengen.

[Verwijderd]

Soms sla je de plank weleens mis ...

/me kwam na een zoektocht via Google het volgende, interessante product tegen:
http://www.remotesoft.com/salamander/protector.html

Deze tool genereert 100% .Net compliant assemblies, maar in de assemblies staat i.p.v. MSIL een pseudo-native code (met register en geheugen nivo acties), die dan ook nog eens encrypted is ook. Joy!

[ErikRo]

Ha kijk dat ziet er weer veelbelovend uit.
Wat ik me alleen nog afvraag is of "native" dan niet meteen een stuk snelheidswinst oplevert. Je zou zeggen van wel aan, maar zelf noemen ze het niet.

[Verwijderd]

ErikRo schreef op 10 oktober 2002 @ 15:25:
Ha kijk dat ziet er weer veelbelovend uit.
Wat ik me alleen nog afvraag is of "native" dan niet meteen een stuk snelheidswinst oplevert. Je zou zeggen van wel aan, maar zelf noemen ze het niet.

Het is 'quasi-native' ... kortom, er moet nog steeds een vertaalslag plaatsvinden, ook al is die kleiner dan met MSIL. Daarbij moet je ook bedenken dat deze 'quasi-native code' gedecrypt moet worden, en dat de stap van MSIL naar native code maar 1 keer hoeft plaats te vinden.

[Verwijderd]

om even door te zeiken over dit onderwerp: kan de Intermediate level code niet direct omgezet worden in processor specific machine instructions dmv een of ander trucje? zodat je meteen zonder dat 20 MB grote .net framwork je appjes kunt draaien...

[Verwijderd]

Je kan je app wel pre-jit'en naar native i386 maar je zal nog altijd de ondersteunende libs nodig hebben.

[EfBe]

anakrino decompileert erg goed, echter je kunt verschillende obfuscators gebruiken en die zorgen ervoor dat gedecompileerde code niet bruikbaar is (of de decompiler gaat finaal op zn gat ).

[Verwijderd]

Verwijderd schreef op 30 december 2002 @ 15:34:
Je kan je app wel pre-jit'en naar native i386 maar je zal nog altijd de ondersteunende libs nodig hebben.

Hoe dan?

[EfBe]

met de .NET SDK tool: ngen.exe. Die compileert assemblies naar native code, maar dan heb je dus geen runtime-optimalisatie meer en veelal is dit dus trager.