"Schutz" vor Resource Hacker(ResHack) ?

[Pseudemys Nelsoni]

hoi

kann ich irgendwie verhindern das man mit dem prog(siehe topic) mein project öffnen kann?
ich mein das muss ja nich jeder sehn wie ich mein prog gemacht hab

danke ;)

gruss silent

[Luckie]

Mit UPX packen sollte schon etwas helfen. Kann man zwar auch umgehen, aber da ist es schon nötig mit dem Hex-Editor deinem Programm zu Leibe zurücken.

Warum willst du die Ressourcen verstecken? Sind deine Bitmaps und Icon so schützens wert?

[Pseudemys Nelsoni]

nein, aber die strings, und muss ja nicht jeder sehen das ich den client mit der indy irc kompo gemacht hab, reicht wenn ich weiss das ich newb bin :D

danke btw

gruss silent

[Pseudemys Nelsoni]

btw, wie funzt das mit upx?

[Sharky]

Zitat:

Zitat von silent

btw, wie funzt das mit upx?

UPX ist ein EXE-Packer. Das Programm komprimiert deine EXE-Files. Diese bleiber aber weiterhin startbar. Im prinzip wird dein Programm gepackt und erst beim starten der EXE in den Arbeitsspeicher entpackt.

Bei mir bringt das eine grössen reduzierung der EXEs von ca. 60%.

[d3g]

Zitat:

Zitat von Luckie

Mit UPX packen sollte schon etwas helfen. Kann man zwar auch umgehen, aber da ist es schon nötig mit dem Hex-Editor deinem Programm zu Leibe zurücken.

Und was ist mit upx -d executable?

[Luckie]

Hm? OK. Gewonnen. :mrgreen:

[APP]

Hallo,
btw, es gibt auch einen interessanten Artikel warum man solche Kompressoren NICHT verwenden sollte...

Zitat:

Why not use an EXE compressor?


Some have asked why I made StripReloc when there are EXE compression programs such as ASPack and UPX that will trim more bytes off of executables than StripReloc ever could.

The reason is there are downsides to using EXE compressors. Most notably:

Upon startup of a compressed EXE/DLL, all of the code is decompressed from the disk image into memory in one pass, which can cause disk thrashing if the system is low on memory and is forced to access the swap file. In contrast, with uncompressed EXE/DLLs, the OS allocates memory for code pages on demand (i.e. when they are executed).
Multiple instances of a compressed EXE/DLL create multiple instances of the code in memory. If you have a compressed EXE that contains 1 MB of code (before compression) and the user starts 5 instances of it, approximately 4 MB of memory is wasted. Likewise, if you have a DLL that is 1 MB and it is used by 5 running applications, approximately 4 MB of memory is wasted. With uncompressed EXE/DLLs, code is only stored in memory once and is shared between instances.
Some older virus scanners flag compressed EXE/DLLs as being virus-infected. (This is this reason I stopped compressing Inno Setup's EXEs.)

(gefunden bei Jordan Russell)

[Luckie]

Jupp. Es ist bekannt, dass UPX den Windows-Memory-Manager aushebeln.

[Daniel]

Zitat:

Zitat von Luckie

Jupp. Es ist bekannt, dass UPX den Windows-Memory-Manager aushebeln.

...aber dennoch nie verkehrt, darauf hinzuweisen. :wink:

[woki]

Hallo,

ich glaube zwar nicht, daß es den Aufwand lohnt, und daß du vorhandene Funktionalitäten (Indy) nutzt statt diese selber zu amchen, ist eher ein Zeichen von Professionalität als daß es auf einen Anfänger hindeutet, also da würde ichmir keine Sorgen machen, aber nur als Hinweis am Rande:

Mit den GEXperts kannst du alle auf der Form vorhandenenen Komponenten in Code konvertieren, dann wird alles programmatische erzeugt und steht nicht merh in den Resourcen, aber für die Programmpflege ist das dann zukünftig doch etwas nervig.

Tschüss
Wolfgang

[Pseudemys Nelsoni]

Zitat:

ich glaube zwar nicht, daß es den Aufwand lohnt, und daß du vorhandene Funktionalitäten (Indy) nutzt statt diese selber zu amchen, ist eher ein Zeichen von Professionalität als daß es auf einen Anfänger hindeutet

danke *gg*

ziehe gerade mal gexperts thx =)

[Pseudemys Nelsoni]

hm gibts da n tutorial über das prog? *g*

[TheXception]

Ich würd, wenn du es schützen willst nicht upx verwenden da man es ohne mühe mit upx wieder dekomprimieren kann.

[Sharky]

Zitat:

Zitat von Luckie

Jupp. Es ist bekannt, dass UPX den Windows-Memory-Manager aushebeln.

Sollte ich meine Programme also lieber nicht mit UPX packen?

Auch wenn die EXE dann 2-3 MB gross sind

Lucky als Code otimierer ist da sicher dagegen ...



P.S.: warum geht im Forum meine deutesche Tastatur nicht mehr

in jedem Programm geht es. Aber hier nicht....

[Luckie]

Ich würde davon abraten. Such lieber den Grund warum dein Programm so groß ist und arbeite an der Stelle weiter.

[woki]

Zitat:

hm gibts da n tutorial über das prog? *g*

Es ist eine online Hilfe dabei, falls Du die gexperts meinst, der Menüpunkt ist ComponenttoCode und konvertierts alle gerad markierten Komponenten in Delphi-Pascal Code, den kannst Du dann wo immer Du willst in dein Programm einfügen (paste), und die Objekte dort erzeugen, und von der Form weglöschen. Ein bischen Handarbeit ist da schon noch zu tun, aber denken ist fast nicht mehr nötig.

Noch eine andere Idee kommt mir da gerade. Delphi kann die dfm (Form) Dateien als Text oder auch binär abspeichern. Müßte man sich mal anschauen wie die Resourcen dann in der exe aussehen, wenn sie aus der binär-From der dfm Datei erzeugt worden sind.

Tschüss
Wolfgang

[Sharky]

Zitat:

Zitat von Luckie

Ich würde davon abraten. Such lieber den Grund warum dein Programm so groß ist und arbeite an der Stelle weiter.

Hihi.... könnte an den insgesamt etwa 150 Forms liegen die in der Anwendung sind :-)

Und davon sind in einigen auch noch die Reports gespeichert..

[Luckie]

Zitat:

Zitat von woki

Noch eine andere Idee kommt mir da gerade. Delphi kann die dfm (Form) Dateien als Text oder auch binär abspeichern. Müßte man sich mal anschauen wie die Resourcen dann in der exe aussehen, wenn sie aus der binär-From der dfm Datei erzeugt worden sind.

Das sollte nichts ändern, das ist ja nur die interen Speicherung von Delphi. Das hat nichts damit zu tun, wie dann die Ressourcen in der Anwendung abgelegt werden. Windows muß sie ja lesen können.

[woki]

Also, sieht man sich die binäre Form an, erkennt man, daß die wesentlichen Informationen auch hier im Klartext drin liegen, in der Anwendung wird dann wohl in jedem Fall die Binärform abgelegt, aber wie gesagt, die ist durchaus lesbar

Code:

. Windows muß sie ja lesen können.

Hier stelle ich jetzt einfach mal die Behauptung in den Raum, ohne wirklich ein Kenner des Resourcenhandlings unter Windows zu sein, Windows muß nur wissen daß dies eine Resource ist, den Inhalt muß nicht Windows, sondern das Streamingsystem von Delphi verstehen.

Tschüss
Wolfgang

[Luckie]

Wer führt denn deien Exe aus? Windows oder Delphi?

Zitat:

Noch eine andere Idee kommt mir da gerade. Delphi kann die dfm (Form) Dateien als Text oder auch binär abspeichern. Müßte man sich mal anschauen wie die Resourcen dann in der exe aussehen, wenn sie aus der binär-From der dfm Datei erzeugt worden sind.

Das hast du gesagt. Und du meinst wenn man die dfm-Dateien bimnär speichert, wütde man sie als Ressourcen in der Exe nicht erkennen können. Das ist aber falsch und das kann auch nicht sein. ob die dfm-datei binär oder als Text gespeichert ist spielt nur für Delphi eine Rolle. Delphi muß sie lesen. Wenn es dann die Exe erstellt, laden die Ressourcen in einem für Windows lesbaren Format in der Exe. Diese Format wird von Windows vorgegeben und ist logischerweise unabhängig vom Format der zugrundeliegenden dfm-Datei.

[woki]

Zitat:

Wer führt denn deien Exe aus? Windows oder Delphi?

Delphi, wenn es um die Resourcen geht, also die Anwendung, die ich mit Delphi erzeugt habe. Resourcen sind kein ausführbarer Code, Windows muß damit gar nichts anfangen können, außer zu wissen, daß es eine Resource ist.

siehe z.B.

RT_RCDATA Application-defined resource (raw data)

womit die von mir postulierte Resource, die Windows nicht kennt identifiziert wäre, hätte mich auch sehr gewundert, wenn ich eine binäre Resource nur dann in die exe packen könnte, wenn Windows wüßte wie man die "Abspielt".

Beispiel ich definiere

resourcestring myResource = 'Abladabladuballa'

Wie sollte Windows denn jetzt 'Abladabladuballa' ausführen?

Aber
if myResource = 'Abladabladuballa' then mylabel:= tlabel.create,
else if myResource = 'humptadumpta' then myEdit :=TEdit.create etcc

Windows weiß weder wie es 'Abladabladuballa' noch wie es 'humptadumpta' ausführen soll, das weiß nur meine Anwendung, also z.B. meine delphiexe. Windows übergibt die dfm Resource an die Delphi exe, und ohne Delphi-Exe könnte Windows mit der dfm Resource gar nichts anfangen, oder?
Packe ich die dfm Resource in eine visual c++ exe, würde wohl auch keine Form erzeugt, Windows könnte damit nichts anfangen,
woher sollte Windows denn wissen, was es mit TWokiEasterInspiration tun soll, und das steht auch nicht in der dfm-resource, sondern im ausführbaren Code meiner Delphi-exe.

Also langer Rede kurzer Sinn, das Aussehen der Resourcen in der exe entspricht der binären Form der DFM-Datei und ist recht einfach lesbar, es ist vielleicht sogar naheliegend, das das so ist, ist aber nicht technisch zwingend, wenn ich das wollte könnte ich sicher eine dfm-datei als resource in eine exe speichern, und als Reaktion auf den Text TForm die Nachrichten der letzten Woche abspielen
statt eine Form zu erzeugen, und stattdessen bei 'x1&%45ajfsdlö' eine Windowsform zum Leben erwecken.

Also nochmal, allgemein gilt, Resourcen sind kein ausführbarer Code, was damit zu welchem Zeitpunkt passiert, entscheidet die Anwendung, auf keinen Fall Windows, es gibt allerdings von Windows vorgefertigte Resourcentypen, die den "Erklärungsaufwand" für die Anwendung minimieren.

[Luckie]

Habe ich ausfüheren gesagt? lesen muß es Windows können, zu mindest die standard ressourcen, wie Fenster, Kontrolls, etc, sonst wird dir Windows auch kein Fenster anzeigen können. Dass es anwendungsspezifische Ressourcen gibt mit denen Windows nichts anfangen kann ist klar.

[woki]

Zitat:

Habe ich ausfüheren gesagt?

Nun ja, ich sprach von Resourcen, und du sagtest:

Zitat:

Wer führt denn deien Exe aus? Windows oder Delphi?

Weiterhin:

Man kann Common Controls in Standardresourcen verpacken, aber ich behaupte, ich kann die VCLControls im Code auch erzeugen, ohne daß sie in den Resourcen erwähnt werden, inclusive den Forms, weiterhin gehören die aus den dfm-Dateien erzeugten Resourcen zu denen, mit denen Windows erstmal nichts anfangen kann, denn woher sollte Windows wissen was
"TfrmTestResource" ist, vielmehr werden diese resourcen auf Anfrage der Ese brav an die Delphiexe übergeben, und von dort aus passsiert dann alles weitere inclusive aufrufe der WinApi zur Darstellung von Forms und Controls.

[Luckie]

Eben und der Kompiler macht dann was für Windows lesbares raus, meine ich.

[Marco Haffner]

Um noch mal zum Upx zurückzukommen, ich hatte in einem Programm einen TWebBrowser zum anzeigen von Informationen verwendet, die dazugehörigen html-Dateien als Resource in die Exe-Datei eingebunden, mit Upx komprimiert (warum auch immer) und auf eine CD gebrannt.
Jetzt bekomme ich heut' einen Anruf, das unter Windows 95 und 2000 alles bestens löppt unter Windows 98 aber keine htm-Resourcen gefunden wurden.
Könnte es jetzt sein das der IE 4.0 von 98 nicht mit den komprimierten Resourcen klar kommt, der IE 5.5 der auf dem Win 95-Rechner installiert ist aber sehr wohl?
Ich würde einfach mal JA sagen, die exe auspacken, neu auf CD brennen und die CD wieder abgeben.

[BrainCode]

Zurück zum Thema "Schutz vor ResHack": Gibt es denn halbwegs sichere Exe-Schützer? Ich kann es mir ja kaum vorstellen, weil ein solches Programm ja das für die Entschlüsselung benutzte Passwort wieder speichern muss, das wäre ja nicht schwer auszulesen.

[Captnemo]

Ich nutze selbst manchmal den UPX-Packer aus folgenden Günden:

Wenn das Prog im Intenet liegt, um es bei bedarf schnell herunterzuladen, und auf einem Rechner zu verwenden, ist schön klein und ich brauche beim Kunden kein Packer.

Wenn ich mal ein Prog auf Diskette weitergeben muß passt es dann meistens auf eine Disk.

Ich habe viele kleine Tools auf meinem USB-Stick. Mit UPX nehmen die dann so wenig Platz ein, wie möglich, und ein manuelles entpacken ist dann nicht notwendig.

Für die eigenen klienen Tools halte ich das für sehr sinnvoll.

PS: Wieviele Anwender gehen den mit dem Reshack an ein Programm ?? Und die anderen schaffens sowieso :coder:

[Florian H]

Ich brauche UPX auch oft weil ich halt Spiele progge, in denen Daten sind, die niemand wissen darf da er sonst die Auszahlung (ist ein "Klamm.de"-Spiel wo man gegen die dort vorhandene Währung spielen kann) selbst vornehmen könnte...
Klappt bisher auch ganz gut, hatte da noch keine Probs

[Luckie]

Zitat:

Zitat von Florian H

Ich brauche UPX auch oft weil ich halt Spiele progge, in denen Daten sind, die niemand wissen darf da er sonst die Auszahlung (ist ein "Klamm.de"-Spiel wo man gegen die dort vorhandene Währung spielen kann) selbst vornehmen könnte...

Der ResHacker sagt dir aber, wenn er die Exe nicht öffnen kann und dann entpacke ich es erst mit UPX (geht nämlich auch) und dann geht es weiter im Text.

Das packen mit UPX sollte man aber nicht zur Gewohnheit werden lassen, da man damit das Windows-Speicher-Managment aushebelt. Beim jedem Start des Programms muß Windows das gesamte Image in den Speicher laden. Ist die Exe ungepackt braucht sie von Windows nur einmal in den Speicher geladen zu werdem. Besonders kritisch wird es bei DLL's, die ein paar mal von unterschiedlichen Programmen geladen werden.
Näheres dazu hier: http://www.jrsoftware.org/striprlc.php

[Neo2084]

Hallo Allerseits,

kurze Frage zum Thema, wie sieht es mit ASPack aus.
Hebelt der den Speichermanager auch aus ???

Gruß Neo

[Luckie]

Anzunehmen.

[TheXception]

Verschlüssel dein Programm einfach und schreib nen loader

[magicshadow]

Schonmal Hier geguckt? da gibts yodas crypter, der ist zwar auch schon geknackt (siehe decrypter auf der page) aber es ist ein recht guter freeware-crypter!

Wenn du sowas wirklich noch suchst ;)

[dmw256]

Was ist denn eigentlich so schlimm daran, wenn man die Resourcen deines Programmes sieht? Kommen doch sowieso irgendwie an Tageslicht, oder?

Der beste Schutz ist wohl: das Programm niemanden weitergeben und mit 100 Encypter sicher, damit es vor Internet-Spionage sicher ist... :-D

[himitsu]

Klar kann man alles vom Monitor ablesen, oder direkt aus'm RAM des laufenden Programms auslesen, oder sonstwie rankommen...

Man kann es denjenigen, die an die Daten ranwollen, nur schwerer machen.

Und "Viele" geben sowieso auf, wenn es zu schwer wird ;)

[MiniKeks]

Ich hab ASPack, geht super.
Problem bei UPX, man kann es wieder dekomprimieren dann kann man die Sachen gleich sehen...
Aber per Zufall habe ich ne möglichkeit herausgefunden, Resource Hacker abstürzen zu lassen, sobald man die EXE öffnet.
Dazu muss man eine unsichtbare memo auf die form, die als erstes gestartet wird platzieren, und diese mit dem Buchstaben- und Stringzeichensalat füllen, die mein kleines Programm erzeugt.
Dieses einfach in das memo schreiben, dann das teil in ruhe lassen. Resultat --> Zu 99% Abstürzender RecoruceHacker.
Aber vor ExeScope Schützt das nicht. Aber jedoch ein kleines Stück sicherhheit.

mfg,
MiniKeks

[MaBuSE]

Zitat:

Zitat von Pseudemys Nelsoni

kann ich irgendwie verhindern das man mit dem prog(siehe topic) mein project öffnen kann?
ich mein das muss ja nich jeder sehn wie ich mein prog gemacht hab

Die einfachste Möglichkeit habt Ihr übersehen.

Programme die die Resourcen anzeigen, können das nur tun, wenn es auch welche gibt :mrgreen:

Es ist relativ leicht möglich die Forms aus den Resourcen Verschwinden zu lassen.

Man muss sie nur selbst im Source erzeugen. (oder teilweise erzeugen)

Meine Vorgehensweise wäre:

• Mach Dein Programm wie bisher.
• Installiere Dir GExperts (Expertensammlung http://www.gexperts.org/ )
• Kopiere Deinen Programmquelltext in ein Verzeichnis z.B. c:\Release\...
• Öffne im Delphi das Projekt aus diesem Verzeichnis
• Öffne die Formulare, die nicht sichtbar sein sollen
• Markiere alle (!) Komponenten auf dem Form
• Funktion "Components to Code" verwenden
• in die OnCreate Methode der Form die Zwischenablage einfügen
• alle Komponenten aus Form entfernen.
• Weiterentwicklung in der "normalen" Version und immer beim Release obige Schritte anwenden.

Das "neue" GExperts unterstützt nun auch ganze Formulare

Zitat:

VERSION 1.21 (November, 2004)
- Components to Code: Support exporting whole forms at once

Damit ist im Resource Editor nur das leere Form zu sehen :mrgreen:

Das ist zwar mit etwas Arbeit verbunden, dauert aber pro Form auch nur ein bis zwei Minuten.

Ich hoffe das hilft Dir.

[hitzi]

Zitat:

Zitat von MiniKeks

Ich hab ASPack, geht super.

ASPAck kann man aber auch entpacken. Es gibt sogar Tools die dir sagen mit welchen EXE Packer die jeweilige Anwendung gepackt wurde. Ein kurzer Blick in die EXE Datei offenbart auch meist den verwendeten Packer - steht oft relativ weit am Anfang.

Gruss
Thomas

[negaH]

Zitat:

und muss ja nicht jeder sehen das ich den client mit der indy irc kompo gemacht hab

Du möchtest also das keiner weiß das du eine Super-OpenSource Komponente wie die Indy benutzt hast. Ich hasse solche Leute wie DICH ! Denn auch ich schreibe Freeware und wenn ich schon kein Geld von DIR verlange dann möchte ich wenigsten das DU in DEINEM Programm AUSDRÜCKLICH darauf hinweist das du Indy oder das DEC oder andere Fremdkomponenten benutzt hast, WEIL du sie eben GUT findest.

Sorry, aber deine Frage kann ich menschlich einfach nicht verstehen.

Das Auslesen der Resourcen hat damit auch garnichts zu tuen. Auch ein EXE Packer verhindert NICHT das ich deine Software auf zb. meine Freeware Komponenten aus dem DEC oder eben nach Indy untersuchen kann.
Möchte ich also wissen was du für Komponenten benutzt so ist dies eigentlich "relativ" einfach möglich. Jedes in Delphi geschriebene Program kann soweit zur Laufzeit, also IM Speicher, analysiert werden das ich dir ganz genau sagen kann welche Klassen, RTTI's, Datentypen usw. dein Program benutzt hat. Selbst Delphi Version usw. können ermittelt werden. Da hilft es nicht die Resourcen zu verschleiern, da hilft kein EXE Packer und auch keine Verschlüsselung, im Speicher muß dein Program auf die VCL und RTL unverschlüsselt zugreifen können, und genau dort kann man den kompletten Klassenbaum + RTTI usw. auslesen.

Also, warum ? willst du verheimlichen das du eine supergute und weit anerkannte Blibliothek wie die Indy benutzt hast ? Ich wüsste nur einen einzigsten akzeptablen Grund: dein Program ist von Hause aus ein Program das sich tarnen muß weil es den Benutzer schädigen will, kurz: ein Trojaner oder Virus.

Gruß Hagen