Exe-scrambler en -compressor

[Sorcerer8472]

Heeft of kent iemand een goede exe-scrambler en/of compressor? (ja, ik ken UPX, maar die unscramblet in het geheugen)
Ik wil graag een programma dat alle variabelen in de exe verkleint zodat er zo goed als niks meer te doen is met de source als men het zou proberen te decompilen...

Win32 trouwens Een VB.Net programma

[LordLarry]

decompilen naar wat precies heb je problemen mee? assmbler zal altijd mogelijk blijven. het moet nou eenmaal op 1 punt goed staan voordat windows het wil begrijpen. Dat kan zo laat mogelijk en dat zou in het geheugen zijn. Misschien dat sommige kleinere stukjes per keer goed zetten.

[Sorcerer8472]

Ik heb geen probleem met decompilen... Ik wil juist dat niemand het KAN decompilen
En ook niet als het gecomprimeerd is met UPX vanuit het geheugen. Het moet dus echt gescrambled en gecompressed worden...

[Verwijderd]

Een VB.NET programma bestaat niet uit native code. De VB.NET compiler compileert naar IL. Waarschijnlijk wordt de boel dus corrupt.

Ze hebben dan wel een exe extensie maar daar is het ook mee gezegd. Van mij mochten net als bij ASP (asp -> aspx) er wel exex oid van maken .

[.oisyn]

als het gescrambled is kun je het sowieso niet opstarten, dus waarom zip je het niet met een password (om maar even een voorbeeld te noemen)?

[LordLarry]

Sorcerer8472 schreef op 08 oktober 2002 @ 16:00:
Ik heb geen probleem met decompilen... Ik wil juist dat niemand het KAN decompilen
En ook niet als het gecomprimeerd is met UPX vanuit het geheugen. Het moet dus echt gescrambled en gecompressed worden...

Dat kan nooit helemaal met in win32 programma probeer ik net uit te leggen.

Voor .Net kan je geen UPX gebruiken zoals ydejager al meld.
Volgens hier kan je wel heel gemakkelijk gewoon je programma voor disassemblen afschermen:
http://www.dotnetextreme.com/articles/protectIL.asp
Maar ik verwacht dat het niet moeilijk te omzijlen is....

[Sorcerer8472]

.oisyn schreef op 08 oktober 2002 @ 16:05:
als het gescrambled is kun je het sowieso niet opstarten, dus waarom zip je het niet met een password (om maar even een voorbeeld te noemen)?

Euhm... De source scramblen is wat anders dan het uitvoerbaar bestand scramblen
Het moet voor iedereen uitvoerbaar zijn, maar de broncode moet beschermd zijn

Dan maar even wachten tot er een programma is wat het wel kan

[Verwijderd]

Even wat offtopic vraagjes: wat heb je voor geweldig, wereldveranderend, nieuw algoritme bedacht dat niemand anders mag zien? Zou het niet beter zijn zo'n algoritme te copyrighten ipv. het te scramblen? De code zal altijd descrambled moeten worden voor hij gerund kan worden, maw. scramblen is iets om je te beschermen tegen scriptkiddies, maar niet tegen een serieuze hacker of een team van reverse-engineers.

[ Voor 0% gewijzigd door Verwijderd op 08-10-2002 17:17 . Reden: typo ]

[Aetje]

prcies... In het geheugen zal altijd een unscrambled image staan welke gerund wordt.

[Sorcerer8472]

Als je een beveiliging inbouwt in een stukje software is het niet leuk om dat meteen even later gedecompiled te zien worden
Vandaar dus... En het ging om het stuk software dat een serial descramblet...

[rik]

Nou ik heb ooit heel veel tijd in een programma gestoken, en kreeg toen een keer de complete source toegemaild. Had iemand het dus zitten decompilen

[Verwijderd]

Dit soort problemen los je op door copyrighting en niet door scrambling. Je kunt exe's ook via een debugger/monitor opstarten, waarna ze zichzelf unscramblen en starten. Vervolgens save je vanuit de debugger de unscrambled code, en klaar is kees.

Scrambling maakt code rippen misschien wat lastiger, maar niet onmogelijk. Bovendien is het ook nog eens legaal om gescramblede code te descramblen, dus je hebt geen poot om op te staan als je code toch geripped wordt. Als je copyrights hebt liggen de zaken anders. Dan mag niemand (in principe) je code aanraken of gebruiken, en hoef je haar dus ook niet te scramblen...

[.oisyn]

[nohtml]

Sorcerer8472 schreef op 08 oktober 2002 @ 17:02:
[...]


Euhm... De source scramblen is wat anders dan het uitvoerbaar bestand scramblen

uitvoerbare bestanden zijn te decompilen. Dat is een feit, live with it

[Scorpion]

als je wilt dat niemand het in handen krijgt, geef het dan gewoon aan niemand. en als het zo vernieuwend is, neem dan gewoon patent erop ofzo

[markvt]

het hoeft niet eens te decompilen te zijn, debuggen is soms ook al genoeg.

Compileer naar pseudo-code dat kost de meeste moeite.

[Verwijderd]

Zolang het uitgevoerd moet kunnen worden, kan het ook gedisassembled worden. Het zal altijd leesbaar zijn voor assembly-programmeurs.

Trouwens voor VB en nog veel meer voor .NET en dus al helemaal voor VB.NET is het wel heeeeeel erg moeilijk om decompileren naar originele sourcecode moeizaam te maken. VB is om het cru te zeggen eigenlijk geen serieus toepasbare programmeertaal, zeker niet als het om gegevens gaat niet niet toegankelijk gemaakt moeten kunnen worden. Code wordt namelijk niet gecompileerd zoals bij C/C++/Delphi maar direct per regel vertaald naar een reeks instructies.
En .Net code is daarbij veeeeeel beter leesbaar (lees: decompileerbaar) dan machinecode (lees: assembly instructies) dus dat is al helemaal niet geschikt om gegevens minder toegankelijk te maken...

[Sorcerer8472]

Misschien goed idee om een deel van het programma in C++ te maken dan
In ieder geval bedankt voor jullie hulp

Btw hoe duur is een copyright?

[Juicy]

Sorcerer8472 schreef op 08 oktober 2002 @ 17:22:
Als je een beveiliging inbouwt in een stukje software is het niet leuk om dat meteen even later gedecompiled te zien worden
Vandaar dus... En het ging om het stuk software dat een serial descramblet...

Sorcerer8472 schreef op 08 oktober 2002 @ 18:01:
Misschien goed idee om een deel van het programma in C++ te maken dan
In ieder geval bedankt voor jullie hulp

Btw hoe duur is een copyright?

Lijkt me vreselijk belangrijk om copyright toe te passen op een stukje software wat een serienummer decodeert.

[MisterData]

Copyright is toch gratis.... alles wat je maakt is toch copyrighted of zie ik dat verkeerd? Je zult wel patenten oid bedoelen

[Verwijderd]

Als het alleen om het valideren van serienummers gaat is copyright nemen idd. iets "overdone", tenzij je verwacht honderdduizenden exemplaren van je software te kunnen verkopen.

Copyright nemen is iets dat je afweegt, het is namelijk idd. niet goedkoop. De meeste softwareproducenten lossen het op door validators zo obfuscated te programmeren dat er zelfs vanuit een debugger geen touw aan vast te knopen is; zelf-modificerende (assembly) code is hierbij de absolute nummer een. Daarmee ben je er overigens nog niet, je zult ook (op verschillende plaatsen in je code) moeten checken of je validator er niet simpelweg uitgesloopt is (dmv. checksums).

[Zoijar]

En niet-deterministische checking methodes doen het altijd leuk...

Mag je eigenlijk schade aanrichten als je code modificatie detecteert? Dus bv het hele programma wissen. In principe kan je altijd claimen dat de originele code niets van dit alles kan of doet, en dat het risico van (niet toegestane) modificaties geheel bij de gebruiker ligt. Was ooit een hele discusse over bij een asheron's call utility die iets van die vorm deed (mocht niet bij een bepaalde groep horen, programma checked of je er bij hoort, zo ja kon je het niet gebruiken. Als je die check eruit sloop, draaide het programma goed alleen verwijderde het je uit die groep)

[Verwijderd]

Goed je wil dus 'n dotnet app iets minder goed decompileerbaar maken zie de Dotfuscator

[Sorcerer8472]

Verwijderd schreef op 08 oktober 2002 @ 19:13:
Goed je wil dus 'n dotnet app iets minder goed decompileerbaar maken zie de Dotfuscator

Daarnaar was ik op zoek! Thanx
Alleen wel erg duur, maargoed, het is wat ik nodig heb

En nee, het gaat niet om een programmaatje wat serial codes checkt
Dat is het gevoelige deel wat ik wilde beschermen... Het programma zelf is administratieve software

[Twilight Burn]

Ik denk dat het weinig uitmaakt voor de "decompileerbaarheid" of je het programma nu in C++.Net, C#.Net of VB.Net schrijft...
Verder ben ik nog steeds van mening dat je bij het type "administratieve software" dat jij aan het maken bent veel minder kans hebt op crackers/thuiskopieerders dan bij een game ofzo...

[johnwoo]

Verwijderd schreef op 08 oktober 2002 @ 17:42:
[...]
VB is om het cru te zeggen eigenlijk geen serieus toepasbare programmeertaal, zeker niet als het om gegevens gaat niet niet toegankelijk gemaakt moeten kunnen worden. Code wordt namelijk niet gecompileerd zoals bij C/C++/Delphi maar direct per regel vertaald naar een reeks instructies.

Hier moet ik toch even op reageren hoor, blijkbaar zijn er nog steeds mensen die menen dat VB geinterpreteerd wordt ipv gecompiled. Als je het uit de IDE runt wordt het programma idd geinterpreteerd. Maar als je gewoon naar native code compiled, dan krijg je gewoon een Win32 executable, exact hetzelfde als bij een C/C++/Delphi compiler. Daarnaast kun je VB inderdaad ook nog naar P-code compilen, maar dat doet bijna niemand.
In de naam van de voor VB programma's benodigde DLL, msvbvm60.dll, komen dan wel de letters VM in voor, een virtual machine is het niet (alleen als je naar P-code compiled). Het zijn gewoon runtime dependencies voor VB's built-in taalconstructies, net als sommige VC++ programma's de C runtime (CRT) nodig hebben.

Om even kort te maken: VB wordt dus in 99.9% van de gevallen gewoon naar native code gecompiled, en niet geinterpreteerd. Overigens is dit al zo sinds minimaal QB 4.x (ja, ook vroeger onder DOS poepte de Basic compiler al gewoon native machinecode uit).

De relatieve traagheid van VB programma's t.o.v. C/C++ programma's zit hem in de aanzienlijke hoeveelheid compiler-gegenereerde instructies (er gebeurt heel veel achter de rug van de programmeur om), alsmede de grote runtime. VB biedt nu eenmaal wat meer abstractie van de onderliggende machinecode dan C/C++.

[TaXaN]

Een beetje offtopic misschien maar ik wil een verwarring rechtzetten: ik lees hier over copyright en de kosten enzo maar zoals MisterData al aanhaalde is copyright (NL: auteursrecht) gratis. Zodra je een 'origineel' werk maakt, is het automatisch beschermd door het auteursrecht. Software valt hier ook onder. Iemand die jouw software decompileert en de source zelf gebruikt in zijn project pleegt een inbreuk op dit auteursrecht.

Het probleem is natuurlijk dat auteursrecht geen reële bescherming biedt. Pas als je het plagiaat merkt, kun je er iets tegen ondernemen en dan heb je een hele procedure voor je. Obfuscatie van je code is dan een barrière die je kan opwerpen om je auteursrecht enigszins af te dwingen.

[Verwijderd]

Ja, John Woo, uiteraard krijg je een exe Sjonge... Nergens beweer ik dat VB code niet naar exe wordt vertaald, ik gebruik juist het woord vertalen!!!
Maar vb-code wordt dan niet "runtime" geinterpreteerd, maar vertaald naar machinecode... Dat is wat anders dan gecompileerd, want met dit vertalen wordt er in VB namelijk per VB-instructie een reeks machinecode gegenereerd, terwijl bij compilers zoals die voor C/C++ en Delphi er een hoop logica achter zit die verbanden in de code opspoort en aanbrengt, en code optimaliseerd, enz.
Doordat de VB code per regel wordt vertaald, is die VB code ook weer per regel terug te vertalen naar originele VB code, zij het dat je uiteraard niet de variable namen kunt "terughalen".

[Verwijderd]

De vb compiler maakt alvanaf Versie 4 of 5 gewoon native i386 code aan. optie tot p-code zit er ook nog in maar word default niet gebruikt. vb.net maakt uiteraard net als alle andere .net talen alleen msil aan.

[Verwijderd]

Twilight Burn schreef op 08 oktober 2002 @ 20:35:
Ik denk dat het weinig uitmaakt voor de "decompileerbaarheid" of je het programma nu in C++.Net, C#.Net of VB.Net schrijft...

Ik denk dat het wel uitmaakt, want doordat VB "vertaald" wordt (naar .NET code), kun je regel voor regel de originele VB sourcecode terughalen, dat is een slechte eigenschap van VB. Dit is vrijwel onmogelijk met C/C++ (naar .NET).
Wel is .NET code veel beter te disassembleren, omdat pseudo "VM" instructies nu eenmaal veel beter leesbaar zijn dan machine-taal assembly...

[Twilight Burn]

Verwijderd schreef op 10 oktober 2002 @ 10:13:
[...]

Ik denk dat het wel uitmaakt, want doordat VB "vertaald" wordt (naar .NET code), kun je regel voor regel de originele VB sourcecode terughalen, dat is een slechte eigenschap van VB. Dit is vrijwel onmogelijk met C/C++ (naar .NET).
Wel is .NET code veel beter te disassembleren, omdat pseudo "VM" instructies nu eenmaal veel beter leesbaar zijn dan machine-taal assembly...

Het is dan wel slechts speculatie, maar ik betwijfel echt of Microsoft wel hun C#/C++ compilers wel verder optimaliseerd, en deze de code laat optimaliseren, en hun VB compiler een "simpele" 1-op-1 vertaler laat zijn. Daar komt ook nog eens bij dat - voor zover ik code in C#/C++ ken/gezien heb - de 3 standaard talen in .Net eigenlijk exact hetzelfde kunnen, alleen de manier van opschrijven is anders (Ipv if () { ... } else { ... } is het If () Then ... Else ... End If)