AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Thema durchsuchen
Ansicht
Themen-Optionen

Schutz vor Decompeilierung

Ein Thema von meisterwms · begonnen am 22. Mai 2005 · letzter Beitrag vom 17. Aug 2005
Antwort Antwort
Seite 3 von 10     123 45     Letzte »    
franktron

Registriert seit: 11. Nov 2003
Ort: Oldenburg
1.446 Beiträge
 
Delphi 10.2 Tokyo Enterprise
 
#21

Re: Schutz vor Decompeilierung

  Alt 23. Mai 2005, 09:39
Du könntest die software doch beim Start die Checksumme prüffen lassen das kann keiner so einfach umgehen,
Du muss natürlich einen oder mehrere schön plätz für die Checksumme finden.
Frank
Tux sein Lieblingsquellcode
While anzfische<TuxSatt do begin
Fisch:=TFisch.Create; Tux.EssenFisch(Fisch); Fisch.Free;inc(anzfische); end;
  Mit Zitat antworten Zitat
brechi

Registriert seit: 30. Jan 2004
823 Beiträge
 
#22

Re: Schutz vor Decompeilierung

  Alt 23. Mai 2005, 10:12
frankton nen video gefällig wo man mal sieht das ne checksumme rein gar nichts bringt?
und auch dem cracker alles mögliche in den weg legen bringt auch nix, ausser das es wieder probleme für den enduser gibt.
  Mit Zitat antworten Zitat
Olli
(Gast)

n/a Beiträge
 
#23

Re: Schutz vor Decompeilierung

  Alt 23. Mai 2005, 12:02
Zitat von franktron:
Vielleicht eine Loader schreiben und damit die EXE starten das dürfte die Hacker(Decompiler) zum. etwas irretieren.
Au ja. Mach mal. Das ist eine der einfachsten Übungen. Mir ist noch kein wirklich cooler Loader untergekommen. Wenn das alles solche 08/15-Dinger sind, machst du jedem Reverser oder Cracker eine Freude!

Zitat von franktron:
Fazit den jenigen der das Programm Decom. will so viele hindernisse wie möglich in den Weg legen
Und das Programm bis aufs äußerste entschleunigen *g* ... der Endbenutzer soll "seine" Sicherheit schließlich auch irgendwie spüren.

Zitat von freak4fun:
Ich denke mal ein 100% wäre niemanden die .exe-Datei geben.
Das stimmt

Zitat von freak4fun:
Ne, im ernst. Hast du angst die Firma, die dein Programm kauft crackt es? Warum sollte sie es tun, wenn sie eine legale Version hat? Das Risiko besteht zwar immer, aber jede andere Softwarefirma hat das gleiche Risiko.
So sollte man das sehen. Spätestens wenn man sich oben anhand des Gedankenbeispiels das Dilemma klarmacht.

Zitat von franktron:
Du könntest die software doch beim Start die Checksumme prüffen lassen das kann keiner so einfach umgehen,
Du muss natürlich einen oder mehrere schön plätz für die Checksumme finden.
Wo ist der Trick? Also irgendwie scheinen hier einige keine Vorstellung zu haben, wie Reverser oder Cracker arbeiten ... gelle brechi?

Zitat von brechi:
frankton nen video gefällig wo man mal sieht das ne checksumme rein gar nichts bringt?
und auch dem cracker alles mögliche in den weg legen bringt auch nix, ausser das es wieder probleme für den enduser gibt.
Seien wir ehrlich: dem Reverser oder Cracker bringt es auch manchmal eine Verzögerung ... ich würde sagen 5min für Luckies Debuggercheck in der vorletzten Version des Usermanagers?! Bei der neuen Version ist sogar noch mehr Mühe angesagt
  Mit Zitat antworten Zitat
Benutzerbild von turboPASCAL
turboPASCAL

Registriert seit: 8. Mai 2005
Ort: Sondershausen
4.274 Beiträge
 
Delphi 6 Personal
 
#24

Re: Schutz vor Decompeilierung

  Alt 23. Mai 2005, 13:02
Hallo Leute,

Ein Tipp ?!
Ich habe mich immer damit Beholfen, das ich meine EXE-File
mit UPX packe. Die gepackte EXE dann in eine Hexeditor laden,
die Stringvorkommen 'UPX' in sinnlose Zeichen zB. 'UPX' nach 'z3"',
das nächste dann in '8J_' usw. speichern.
(man könnt' ja auch n' Prog schreiben )

Wer nun versucht mit UPX zu ent.- bzw. zu packen.... hahaha

Vorteil: Prg. ist "verschlüsselt" und Gepackt.

Die Exe kann man problemlos starten (noch keine Probleme gehabt).
Einen Ultimativen Schutz vor guten Hackern wird es aber wohl nie nicht geben.

MfG.
Matti
Meine Software-Projekte - Homepage - Grüße vom Rüsselmops -Mops Mopser
  Mit Zitat antworten Zitat
Benutzerbild von Phoenix
Phoenix
(Moderator)

Registriert seit: 25. Jun 2002
Ort: Hausach
7.611 Beiträge
 
#25

Re: Schutz vor Decompeilierung

  Alt 23. Mai 2005, 13:06
Zitat von turboPASCAL:
Die gepackte EXE dann in eine Hexeditor laden, die Stringvorkommen 'UPX' in sinnlose Zeichen zB. 'UPX' nach 'z3"', das nächste dann in '8J_' usw. speichern. (man könnt' ja auch n' Prog schreiben )
Jau. Und dann hast Du eine Codestelle, die zufällig genau in die Zeichenfolge 'UPX' komprimiert wurde und zerschiesst Dir damit das Programm. Man sollte sich hier zumindest mal mit den UPX-Headern ganz konkret auseinandersetzen um wirklich nur diese zu erwischen.
Sebastian Gingter
Phoenix - 不死鳥, Microsoft MVP, Rettungshundeführer
Über mich: Sebastian Gingter @ Thinktecture Mein Blog: https://gingter.org
  Mit Zitat antworten Zitat
Benutzerbild von gothic_mike
gothic_mike

Registriert seit: 2. Okt 2003
Ort: Olbernhau
134 Beiträge
 
Delphi 7 Personal
 
#26

Re: Schutz vor Decompeilierung

  Alt 23. Mai 2005, 13:09
Zitat von turboPASCAL:
Hallo Leute,

Ein Tipp ?!
Ich habe mich immer damit Beholfen, das ich meine EXE-File
mit UPX packe. Die gepackte EXE dann in eine Hexeditor laden,
die Stringvorkommen 'UPX' in sinnlose Zeichen zB. 'UPX' nach 'z3"',
das nächste dann in '8J_' usw. speichern.
(man könnt' ja auch n' Prog schreiben )

Wer nun versucht mit UPX zu ent.- bzw. zu packen.... hahaha

Vorteil: Prg. ist "verschlüsselt" und Gepackt.

Die Exe kann man problemlos starten (noch keine Probleme gehabt).
Einen Ultimativen Schutz vor guten Hackern wird es aber wohl nie nicht geben.

MfG.
haste schonmal deinen speicher durchsucht, wenn dein UPX'tes programm läuft?
die exe packen ist imho sinnlos, hällt vielleicht einige DAU's ab, paar Strings/Resourcen in der exe zu ändern, aber einem richtigen cracker is das scheissegal...
es gibt definitiv keinen 100%igen schutz, jedes noch so gut geschützte programm wird von irgendeinem cracker irgendwann gecrackt, ist halt nur eine zeitfrage... und sinnlos verschwendete zeit & energie des programmierers.
bye4now, gothic_mike
. ..: carpe noctem :: coding in the darkness :.. .
  Mit Zitat antworten Zitat
Benutzerbild von Boombuler
Boombuler

Registriert seit: 14. Mär 2003
Ort: Osnabrück
244 Beiträge
 
Delphi 2009 Professional
 
#27

Re: Schutz vor Decompeilierung

  Alt 23. Mai 2005, 13:12
Hi,...

Eben kein Mittel ohne Gegenmittel zumindest nicht solange wir noch mit Boolscher Algebra arbeiten! Verschlüsseln ist immer nur eine Sache der Zeit! (bei unseren heutigen Verschlüsselungsverfahren viel zu viel Zeit...)
Aber die Lösung ist schon mal nicht schlecht... Ich denke mal 70% der "Ich-Werd-Mal-Cracker-Wenn-Ich-groß-Bin"-Kiddis wirst du damit abschrecken!

Greetz
Boombuler
"Look at you, Hacker. A pathetic creature of meat and bone, panting and sweating as you run through my corridors. How can you challenge a perfect, immortal machine?"
SwapIt Highscore:
  Mit Zitat antworten Zitat
Dax
(Gast)

n/a Beiträge
 
#28

Re: Schutz vor Decompeilierung

  Alt 23. Mai 2005, 13:27
Ich hab eine kleine Theorie, wie es funktionieren könnte, aber garantiert nicht wird: Einfach das JIT-Konzept ein wenig entfremden. Du hast deinen Code der EXE, den du schützen willst. Du hast ein Verschlüsselungsprogramm wie Morphine. Bau Morphine um. Und zwar so, das es dir den Code immer Bruchstückweise in den Speicher entpackt, den Code ausführt, das Programm anhält, den ausgeführten Code aus dem Speicher läd, den nächsten Block läd usw. Aber das bietet immer noch keinen ernsthaften Schutz vor Speicherzugriffen, und einen richtigen Schutz gibt es, wie ja schon bereits gesagt, nicht. Dieses Konzept hier kann einem Cracker die Arbeit aber ziemlich erschweren, zumindest denke ich das.

Diese Idee entstand in einem verwirrten Hirn, nicht zu viel Beachtung beimessen.
  Mit Zitat antworten Zitat
Olli
(Gast)

n/a Beiträge
 
#29

Re: Schutz vor Decompeilierung

  Alt 23. Mai 2005, 13:44
Zitat von turboPASCAL:
(man könnt' ja auch n' Prog schreiben )
Gibt's schon. Such mal nach UPX Scramblern *g*
Ebenfalls kalter Kaffee.

Zitat von gothic_mike:
haste schonmal deinen speicher durchsucht, wenn dein UPX'tes programm läuft?
die exe packen ist imho sinnlos, hällt vielleicht einige DAU's ab, paar Strings/Resourcen in der exe zu ändern, aber einem richtigen cracker is das scheissegal...
Dem richtigen Reverser auch

Zitat von gothic_mike:
es gibt definitiv keinen 100%igen schutz, jedes noch so gut geschützte programm wird von irgendeinem cracker irgendwann gecrackt, ist halt nur eine zeitfrage... und sinnlos verschwendete zeit & energie des programmierers.
... und des Crackers/Reversers, wenn es das Ziel nicht wert ist. Manche Leute sollten ihre Programme, gerade wenn es Nischenprogramme sind, nicht allzusehr überschätzen.

Zitat von Boombuler:
Eben kein Mittel ohne Gegenmittel zumindest nicht solange wir noch mit Boolscher Algebra arbeiten! Verschlüsseln ist immer nur eine Sache der Zeit! (bei unseren heutigen Verschlüsselungsverfahren viel zu viel Zeit...)
Du meinst sicher Entschlüsseln. Und dank des oben dargelegten Dilemmas muß der Programmautor den Schlüssel ja mitliefern, wodurch ein Knacken oder "Entschlüsseln" (via Brute-Force) nicht notwendig ist.

Zitat von Boombuler:
Aber die Lösung ist schon mal nicht schlecht... Ich denke mal 70% der "Ich-Werd-Mal-Cracker-Wenn-Ich-groß-Bin"-Kiddis wirst du damit abschrecken!
Ich kenne Firmen, die Reverser bezahlt haben. Du glaubst doch nicht ernsthaft, daß wenn dieses Programm so ultimativ cool wäre, eine Firma ein Ich-Werd-Mal-Cracker-Wenn-Ich-groß-Bin"-Kiddy anheuert?
Alternativ wird das Programm und die zugehörige Firma aufgekauft ("Microsoft-Methodik").

Zitat von Dax:
Ich hab eine kleine Theorie, wie es funktionieren könnte, aber garantiert nicht wird: Einfach das JIT-Konzept ein wenig entfremden. Du hast deinen Code der EXE, den du schützen willst. Du hast ein Verschlüsselungsprogramm wie Morphine. Bau Morphine um. Und zwar so, das es dir den Code immer Bruchstückweise in den Speicher entpackt, den Code ausführt, das Programm anhält, den ausgeführten Code aus dem Speicher läd, den nächsten Block läd usw. Aber das bietet immer noch keinen ernsthaften Schutz vor Speicherzugriffen, und einen richtigen Schutz gibt es, wie ja schon bereits gesagt, nicht. Dieses Konzept hier kann einem Cracker die Arbeit aber ziemlich erschweren, zumindest denke ich das.
Siehe:
Zitat von Olli:
Erschweren geht (z.B. indem jeder Programmteil direkt vor Ausführung entschlüsselt wird, womit man Dumper austrickst, da das Programm nie vollständig entschlüsselt im Speicher vorliegt) - unmöglich machen geht nicht [...]
Hier. Ich hoffe du meinst nicht mich mit "verwirrtem Hirn"

Es gibt auch VM-Ansätze (sowohl in POCs -> http://www.honeynet.org/scans/scan33/ ) als auch in einem russischen Programm (Link habe ich aktuell nicht zur Hand). Das funktioniert ähnlich wie der P-Code in VB.
  Mit Zitat antworten Zitat
Benutzerbild von turboPASCAL
turboPASCAL

Registriert seit: 8. Mai 2005
Ort: Sondershausen
4.274 Beiträge
 
Delphi 6 Personal
 
#30

Re: Schutz vor Decompeilierung

  Alt 23. Mai 2005, 13:48
@Phoenix

Die Zeichenfolge 'UPX' vom Packer kommt 3x in der Exe vor:

Offset 504 -> UPX0
Offset 544 -> UPX1
Offset 992 -> UPX! (hinter der UPX-Versionsnummer, bei mir 1.25)

Das sollte bei allen Exe-Files so sein (jedenfalls bei meinen Delphi 6 Exe-Files).
Wenn man nur diese ändert kann nix passiren auch wenn du im Surcecode irgend wo UPX stehen hast.

@gothic_mike

Zitat:
haste schonmal deinen speicher durchsucht, wenn dein UPX'tes programm läuft?
die exe packen ist imho sinnlos, hällt vielleicht einige DAU's ab, paar Strings/Resourcen in der exe zu ändern, aber einem richtigen cracker is das scheissegal...
es gibt definitiv keinen 100%igen schutz, jedes noch so gut geschützte programm wird von irgendeinem cracker irgendwann gecrackt, ist halt nur eine zeitfrage... und sinnlos verschwendete zeit & energie des programmierers.

Da war ich wohl zu späth hi, Olli
MfG.
Matti
Meine Software-Projekte - Homepage - Grüße vom Rüsselmops -Mops Mopser
  Mit Zitat antworten Zitat
Antwort Antwort
Seite 3 von 10     123 45     Letzte »    


Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 23:58 Uhr.
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz