Geruchten over decompiler .NET-applicaties

Securitywatch schrijft dat beveiligingsbedrijven waarschuwen voor de eerste C#-decompiler. Nog voordat de bij Microsoft's .NET-technologie behorende programmeertaal officieel gereleased is, hebben kwaadwillenden dus al een tool gemaakt waarmee .NET-applicaties eenvoudig gedecodeerd kunnen worden tot C#-instructies.

Op deze manier zal het mogelijk zijn deze applicaties aan te passen, en dan weer opnieuw te compilen. Mogelijke beveiligingsfouten ontdekken of een serial-check weghalen, via een dergelijke tool zullen computergebruikers behoorlijk wat kunnen uithalen waar Microsoft niet blij mee is:

Microsoft has thus far been tight-lipped about the appearance of a new hacking tool that jeopardizes the Redmond behemoth's forthcoming .Net platform. Security firms are sounding the alert over what is possibly the first C# decompiler for Microsoft's fancy new operating system. Crackers can use the C# decompiler to reverse engineer applications running on .Net -- meaning that if a malicious soul manages to use the tool to crack a network, all sorts of devious possibilities could ensue.

Johan Van de Wauw, bedankt voor de tip.

Reacties (50)

[frankvanhoesel]

Nog voordat de bij Microsoft's .NET-technologie behorende programmeertaal officieel gereleased is, hebben kwaadwillenden dus al een tool gemaakt waarmee .NET-applicaties eenvoudig gedecodeerd kunnen worden tot C#-instructies.

Denk persoonlijk dat Microsoft hier wel een manier voor vind om het zo te compilen dat het niet meer te decompilen valt.

Dit is zo belangrijk voor hun,zo niet van levensbelang. Dus daar zullen ze ook wel tijd/geld in steken

[edit]
[quote]
Geruchten over decompiler .NET-applicaties
[/quote]

[quote]
Crackers can use the C# decompiler to reverse engineer applications running on .Net
[/quote]

Is die tool er al ? Of zou het eventueel mogelijk zijn om zo'n tool te maken

[SvMp]

Denk persoonlijk dat Microsoft hier wel een manier voor vind om het zo te compilen dat het niet meer te decompilen valt

Dat gaat niet zomaar.
Ze kunnen echter wel anti-debuggings truucs uithalen, stukjes code waar debuggers, disassemblers en decompilers over uitglijden. Maar dit soort truucs bestonden in het DOS-tijdperk ook al. Niets nieuws onder de zon.

[CTVirus]

Als je er nou gewoon een paar kevers in de code plant, dan word het al een stuk moeilijker om er iets zinnigs van te decompilen! Of zouden ze dat al doen

[SvMp]

Zo nieuw is dit probleem / verschijnsel niet.

- .NET moet een grote concurrent van Java worden. Het is echter gewoon mogelijk om Java applicaties te de-compilen.
Dus waarom zou dat met .NET dan niet kunnen?

- Disassembleren kan altijd. Het programma is dan erg lastig te volgen/doorgronden, maar mensen die crackjes maken en andere slechte bedoelingen hebben maken daar graag gebruik van.
Hoe dacht je dat die key gens e.d. zijn ontstaan?

Daarom verbaast het me ook helemaal niets... het is toch niet meer dan logisch dat het .NET-platform ook mogelijkheden biedt om de code van een programma te "bestuderen" ?

[Aaargh!]

Sinds wanneer moet je java compilen?

Sinds altijd al ?
java (niet te verwarren met javascript) is een OO taal die gecompileert word naar z.g.n. bytecode voor een virtual machine.

[Gerco]

Als je iets door een goede compiler haalt, is het onmogelijk om het te decompilen. Disassemblen kan altijd.

Maar als je dus gewoon de originele source (zonder namen natuurlijk) terug kunt halen, is het geen compiler, maar een interpreter... zoals VB dus

Betekent dit dat alle .NET apps dus geinterpret worden? Ik hoorde al dat ze allemaal dezelfde runtime nodig hebben, dus ook C#?

nou ja, ik vrees dat een beroemde quote toch waar blijkt te zijn: "No matter how fast your computer is, Bill Gates will always find a way to slow it down."

[Verwijderd]

Hmm dit doet mij denken aan het begin van Visual Basic. Toen bleken er decompilers in staat te zijn zelfs het commentaar uit de exe files terug te lezen. De Microsoft VB compiler/interpreter zette die dus ook in de exe file. Dat kon echter maar één reden hebben: het moést decompilebaar zijn! Microsoft wilde dus ook wel eens mee kunnen kijken naar de source van andere succesvolle applicaties die met hun omgeving was gemaakt. Daar waren toen een hoop mensen boos over, en terecht!

Ik kan me niet voorstellen dat Microsoft opnieuw zoon blunder maakt, maar zoals de rest ook aangeeft: alles is decompilebaar, maar levert prut op die voor niemand behalve hackers eigenlijk echt de moeite waard is.

Ik moet dus eerst zien wat die "decompilers" voor een code uitspugen voor ik hier wat van kan vinden...

[Verwijderd]

Dat zal toch wel meevallen neem ik aan. De tijd die je nodig hebt om zo'n enorme brij aan code door te werken maakt het al lastig genoeg.
Of vergis ik me en kan je werkelijk bijna de ontwikkelomgeving terugkrijgen via die reverse-tool?

[mullah]

Je hebt alleen meestal niet alle mooie variabele- en object-namen terug omdat die vaak geoptimaliseerd worden.
De letterlijke source krijg je dus meestal niet terug met het decompilen. Nou weet ik niet in hoeverre de .NET ontwikkelomgeving je weer een overzicht kan geven over hoe het programma in elkaar steekt, maar je kunt er echt wel een heel eind mee komen.

[ThE_ED]

[lamaar]

[TheOneLLama]

Met decompilen krijg je gewoon de source terug
Die kun je dus ook weer in de ontwikkelomgeving terugzetten met een beetje CPMen.

[Arthur]

En commentaren kun je ook wel vergeten dus vage trucs, hacks en shortcuts die door de programmeur gemaakt zijn kunnen zo een stuk moeilijker te begrijpen zijn.

Maar ja, is nog altijd een stuk beter leesbaar dan assembler

[Verwijderd]

Er komt een mogelijkheid in .NET om de IL bytecode te encrypten. Als Microsoft het niet doet, dan zal een 3rd-party het doen. In een aantal .NET boeken die ik heb aangeschaft wordt de mogelijkheid van een decompiler ook al aangehaald. Bedrijven die .NET applicaties maken en hun IL bytecode zonder encryptie uitleveren zouden hun kennis zo op straat gooien. Die encryptie mogelijkheid die komt wel. Ik snap alleen niet waarom mensen niet gaan zeuren over Java. Daar kun je de code ook decompilen. Ach ja, als men wat over Microsoft te zeiken heeft zullen ze dat ook doen.

* 786562 tigger

[mth]

Encyptie heeft nauwelijks zin. Als een client C# bytecode kan uitvoeren, dan moet die interpreter het kunnen decrypten. Dus aan de client zijde is voldoende informatie aanwezig voor decryptie, dat wil zeggen dat een decompiler het ook kan. Het duurt misschien iets langer omdat men de keys moet vinden, maar kijk maar naar CSS (DVD encryptie), die is uiteindelijk ook gebroken. Let op dat het om een vaste set keys gaat: als die eenmaal bekend zijn kan alle bytecode gedecrypt worden. Dit in tegenstelling tot normale encryptie, waarbij per document een andere key gebruikt kan worden.

Als je kijkt hoe Java vandaag de dag gebruikt wordt, dan vind je het vooral aan de server zijde. In de begindagen waren applets gehyped, maar in de praktijk is er niet zoveel nuttigs te berekenen aan de client zijde. Het lijkt me logisch dat dat voor C# ook zal gelden. Dus zoals Otis al opmerkte hoef je je bytecode meestal helemaal niet vrij te geven.

[Gomez12]

Hoe zit het eigenlijk met gedecompilde files. Deze sources lijken volgens mij helemaal niet meer op de originele source.

Als je deze source iets aanpast en dan weer gaat compilen is het dan niet jouw source??? Want het is niet meer de source van M$. Als dit mag dan kan je het ook weer opensource maken.

Gewoon maar even een gedachtengangetje

[TlighT]

Ik weet niet of je wel eens een licentie gelezen hebt, maar daar staat over het algemeen zoiets in als:

---
Voorts zult u de Software niet aan reverse engineering onderwerpen, decompileren, disassembleren of anderszins trachten de broncode van de Software te achterhalen, behoudens voor zover decompileren uitdrukkelijk is toegestaan op grond van de Europese Richtlijn inzake de wettelijke bescherming van computerprogramma's ( PbEG 1991, L 122, p. 42 e.v.), en op grond van toepasselijke dwingendrechtelijke nationale regelgeving...blablabla
---

Je mag die programma's dus niet decompileren. Als je een MS programma decompileert of de gedecompileerde code ergens vandaan haalt ben je illegaal bezig.

[Verwijderd]

Maar hoe kan je zoiets bewijzen? Ok, je moet wel iets veranderen (Bijv. alleen de info-dialoogvenster), maar verder kunnen de softwarebedrijven (M$ bijv.) niks bewijzen, ookal gebruiken ze dezelfde tools, kwetsie van sterke optimalisatie eroverheen gooien (#C -> ASM, met allerlei MMX/3DNOW zooi). Kan wel grappige situaties opleveren.

[MrE]

Ik trek niet in twijfel dat wat je zegt waar is, maar ik vindt het niet erg redelijk dat ik de broncode van een programma niet mag bekijken in zijn orginele staat. Voor hetzelfde geldt doet het programma iets met mijn computer dat ik niet wil, dat wil ik wel weten EN kunnen aanpassen. Dat ik het ' verbeterde' programma dan niet mag verkopen ok, maar ik vind dat je RECHT hebt om te weten wat je koopt (op voedingsmiddelen staat ook wat erin zit)

[Verwijderd]

voedingsmiddelen en programmeerwerk.. ahum.. jaaa bijna hetzelfde...

jij gaat heel de code doorworstelen om te kijken of het programma doet wat ie zegt... tuuuurlijk

zijdelingse opmerking: code is niet voor niks auteursrechtelijk beschermt...

[Ulysses]

MrE:
Sorry dat ik hier over moet beginnen, maar dan installeer je toch lekker Linux?! Sja, ik vind het niet zo gek hoor dat ze hun source closed willen houden. Goochelaars vertellen hun truuks toch ook niet?! Daarbij komt dat je daarmee alle mogelijkheid om concurrentie voor te blijven zo'n beetje weg gooit. Want als ik in een MS source iets lees, hoef ik heus het auteursrecht niet te schenden om er beter van te worden. Ik zou gewoon een eigen applicatie kunnen gaan schrijven met hetzelfde idee maar net iets andere code.
Kortom: Voor een commercieel bedrijf niet slim om te doen. Voor een 'digital community' ideaal.

[lucid]

Hmzzz, er is nog niet eens een goede decompiler voor win9x NTx , er rijst bij mij een vermoeden dat er iemand van microsoft hier een handje in heeft gehad. reverse engineering van zulke zaken duurt vaak jaren. Misschien dat de .NET suite wat kleiner is dan de WinX source, maar toch. Verder lijkt het mij weer een prima stap voorwaarts in de honger naar veilige aplicaties

[Verwijderd]

Hmzzz, er is nog niet eens een goede decompiler voor win9x NTx

IDA Pro Advanced v4.xx

Deze tool spuugt al aardig goed gedocumenteerde assembler code uit met links naar alle bekende bibliotheken. In combinatie met SoftIce debugger is het een geduchte tool omgeving om bijna alle software te cracken via deadcode analyse anders wel live de code te volgen.

[Verwijderd]

disassembler != decompiler

[Verwijderd]

Ik zeg ook niet dat het een decompiler is. Het is wel een goede disassembler met een hele goede auto documentatie functie.

[packman]

Dit verwonderd mij echt niet. C# is een geinterpreteerde taal, en geinterpreteerde talen zijn veel simpeler terug te herlijden tot hun originele broncode, tenzij ze een pseudo (high-level) assembler hebben ontwikkeld waarop de taal(C#) en compilatie gebaseerd zijn (wat ik betwijfel als dit zo snel al kan).

Geven ze trouwens geen decompiler mee in de .NET ontwikkelings omgeving? Bij java is dat toch zo, en vermits MS met C# gewoon java gecopierd (en mischien zelfs verbeterd ) heeft lijkt mij dat redelijk logisch. Wat mij wel verwonderd is dat er dan geen systeem is zoals in java met authentication key's per class, waarbij iedereen kan controleren of het wel over de juiste versie gaat.

[Verwijderd]

*zucht* lees eens een andere post voordat je dingen gaat schrijven...

We hebben het over een decompiler, dat betekent al dat C# niet geinterpreteerd wordt. En inderdaad, er is wel degelijk een tussentaal die geinterpreteerd wordt (maar net zoals bij Java ge-jit kan worden).

De disassembler is meegeleverd (dit staat hierboven allemaal beschreven). Er zit een uitgebreid versioning-systeem in, elke assembly (exe) heeft een manifest waarin versie en nog veel meer beschreven staan.

[Joske Pauwels]

Java wordt wel gecompileerd, en dat wordt toch ook geinterpreteerd? Correct me if I'm wrong, maar het is niet omdat iets gecompileerd is dat daarom niet meer geinterpreteerd kan worden.

[Verwijderd]

Ja, dat zeg ik toch ook... Java wordt niet geinterpreteerd, maar de taal waarin .class-files geschreven zijn wel. En zo ook bij C#.

[Verwijderd]

alles is te decompilen. Je krijgt dan de broncode terug. Deze is natuurlijk niet gelijk aan het originele werk, maar wel voor een groot deel (code dient hetzelfde doel)

Voor java zijn er al vele decompilers verkrijgbaar. Voor andere talen zijn deze ongetwijfeld ook verkrijgbaar. Dus dit is niks nieuws, alleen wel vreemd dat hij zo snel al verkrijgbaar is.

[Ulysses]

Volgens mij verwar jij het nu ook weer met een disassembler want meestal als je iets reverse engineert dan pak je bijvoorbeeld een programma dat in C / C++ of desnoods Delphi is geschreven en reverse engineer je dat dan naar Assembler, als je dat dan goed gelukt is, kun je eerst nog allerlij truuks er op los laten om het leesbaar (gecommentariëerd) te maken. Maar waar ze het hier over hebben is dat je C# terug krijgt, dus bijna de originele code! Da's natuurlijk vele malen makkelijker als assembler hacken.

[Verwijderd]

ik weet iig dat het met java kan (dat is denk ook makkelijker omdat dat zogenaamde virtuele machine code is... en daar krijg je redelijk leesbare code bij het decompilen) Met de rest heb ik geen ervaring.

[Gerco]

Ik wel en ik kan je vertellen dat het bijna onmogelijk is om een, bijvoorbeeld, VB programma te disassemblen en dan ook nog eens begrijpen. Het kan wel, maar is vele malen moeilijker dan wanneer je gewoon DoDi's Discompiler gebruikt en de originele source terugkrijgt!

Alleen werkt DoDi's discompiler alleen voor VB4 en lager, want daarna heeft MS voor VB5 en VB6 een soort intermediate code uitgevonden die dan door de C++ backend compiler echt gecompiled wordt, die kun je niet meer decompilen, want hij optimaliseert te goed.

Het punt is dus: Als die .NET runtime een soort java VM is (wat ik me ervan voorstel dan), en die source is openbaar, dan kun je dus (waarschijnlijk) een decompiler maken die de originele source teruggeeft.

En dan krijg je net zoiets als het branden van cd's: iedereen doet het, want het is zo makkelijk dat iedereen het ook KAN doen. En dat is heel wat anders als disassemblen, dan kan lang niet iedereen.