Entwickler-Ecke :: Thema anzeigen - Verschlüsseln und entschlüsseln???

Diach - Fr 20.12.02 11:32
Titel: Verschlüsseln und entschlüsseln???

Hi! :wink:

Ich hab da mal ne Frage (habt ihr euch schon gedacht)!
Und zwar hab ich folgendes Problem: Ich würde gerne wissen, wie ich mit Delphi einen String mit einem beliebigen Schlüssel verschlüsseln kann.
und was mich auch sehr intersessieret, wie ich, wenn ich normalen String + verschlüsselten String hab, dan Schlüssel herausbekomme.
Ist ein Projekt für die Schule und unser Lehrer meint, es wäre ein einfaches mathematisches Problem...

Danke schonmal im Voraus,
Diach

Christian S. - Fr 20.12.02 16:00

Hallo!

zur ersten Frage: ich habe mich noch nicht damit beschäftigt, aber im Gegensatz zu Java stellt Delphi - soweit ich weiß - keine Verschlüsselungsalgorithmen bereit. Die muss man entweder selbst schreiben oder aber als Unit irgendwo besorgen (runterladen).

zur zweiten Frage: ich bin mir ziemlich sicher, dass Dein Lehrer das auf eine bestimmte Verschlüsselungsmethode bezogen hat. Das allgemein zu behaupten ist absoluter Schwachsinn, weil das eine der Dinge ist, die man nach Möglichkeit ausschließen will, wenn man einen Verschlüsselungsalgorithmus konzipiert. Wenn Du Dir mal den RSA-Algoritgmus anschaust, wirst Du schnell sehen, dass das mit heutigen Mitteln nicht möglich ist.

MfG,
Peter

Savage - Fr 20.12.02 16:41

Hi,

dein Lehrer geht bestimmt nur von einem ganz einfachen Prinzip aus.

A = 1 Zeichen von einen String
B = 1 Zeichen vom Schlüssel
C = 1 Codiertes Zeichen

Die jeweiligen Zeichen in Zahlen umwandeln, diese addieren oder subtrahieren oder sonst für ne Opperation ausführen und das Ergebnis wieder in einen Zeichen umwandeln.

Verschlüsselung:

A + B = C

Um den Schlüssel heraus zubekommen:

B = C - A

Das ist wohl die einfachste und unsicherste Methode.

MfG
Savage

Zaubär - Fr 20.12.02 20:44

Besser wäre:

A XOR B = C

:wink:

Wolff68 - Sa 21.12.02 00:36

Oder ein A+ F(A) = C
Damit ist der Schlüssel nicht satisch sondern eine Funktion. Somit ist er nur für A definiert und man müsste schon die Logik der Funktion wissen um ein anderes A zu entschlüsseln. (Was natürlich auch möglich ist)

Diach - So 22.12.02 15:10

äähhmm
Also ich weiss nicht so genau was damit anzufangen!
gemeint war es so:

Ich habe:
1. einen String mit höchstens sagen wir mal 8 zeichen
2. keienen Schlüssel
3. Das Ergebnis der Verschlüsselung!

Ich soll sozusagen den Code Knacken, mit dem verschlüsselt wurde!

Christian S. - So 22.12.02 16:13

Tja, das ist natürlich nicht gerade viel. Ich würde mir das ganze mal nicht als Buchstaben sondern als Zahlen aufschreiben. Also 1 statt 'A' und so weiter und dann Klartext und codierten Text mal (jeweils als Zahlenfolge) untereinander schreiben.

Dann würde ich mal gucken, wieweit jeweils eine Zahl im Klartext und die entsprechende Zahl im kodierten Text auseinaderliegen. Vielleicht immer gleich weit? Oder erkennst Du andere Muster? (Manchmal muss man 'ne Weile damit rumspielen, bis man was findet!)

Ach ja, poste doch mal Klartext und codierten Text.

MfG,
Peter

Wolff68 - So 22.12.02 16:22

Dazu musst Du die zugrunde liegende Funktion wissen.

Angenommen es handelt sich um eine einfache Addition nach dem Schema: Orginal + Schlüssel = Ergebnis. Dann kannst die Formel einfach umkehren. Schlüssel = Ergebnis - Original.

Daß man das ganze natürlich mit den Ordinalwerten der einzelnen Zeichen machen muß ist Dir ja klar. Oder?

Wenn die Verschlüsselung natürlich auf einer anderen Berechnung basiert, dann musst Du diese Formel nach Schlüssel auflösen.

Ohne die Formel zu kennen wirst Du Pech haben.
Auch wenn ich Dir zB 100 Original-Ergebnis-Paare aus meiner Verschlüsselung senden würde, denke ich nicht, daß Du den Code knacken könntest. (Wobei meine Verschlüsselung auch nur auf einer Formel basiert.)

Diach - So 22.12.02 21:48

Naja mir wurde das mal mit Matrizenmultiplikation erklärt!
Soweit ich weiss, liefert Delphi auch eine solche Funktion:
Man gibt den Text ein, gibt einen Schlüssen áls Parameter ein und das ergebnis ist dann irgend ein Kauderwelsch, wie es ja auch gewollt ist!

Sledge_Hammer - So 22.12.02 22:22

Poste doch mal das ergebnis der verschlüsselung!

Christian S. - So 22.12.02 22:57

Das mit der Matrizenmultiplikation haben wir vor ... ähm .... 2 oder 3 Jahren auch mal gemacht. Sollte das Finden des Schlüssels dann nicht auf das Lösen eines (ziemlich großen) Systems von linearen Gleichungen hinauslaufen? Oder habe ist es bei mir doch schon etwas zu lange her, seit ich das gemacht habe?

Diach - Mo 23.12.02 15:27

das Ergebnis der verschlüsselung soll völlig frei wählbar sein!
das Programm soll leisten:

String mit bel. schlüssel verschlüsseln
String wieder entschlüsseln
Schlüssel an Hand von Vorher-Nachher herausfinden.

Christian S. - Mo 23.12.02 15:54

Und wenn Du die Verschlüsselung anhand einer Matrizenmultiplikation machst, dann wird der letzte Punkt auf Deiner Liste darauf hinauslaufen, ein lineares Gleichungssystem zu lösen. Es wäre nicht schlecht, wenn Du mal ein paar Details posten könntest, zu dem, was Dein Lehrer Euch gesagt hat. Besonders wichtig sind Details zu der Matrizenmultiplikation.

Ich stelle mir das ganze so vor: Du hast die Matrix K zum kodieren, die Matrix A, in der Du den Klartext speicherst und mit A*K=B erhälst du als B den verschlüsselten Text. Wenn Du A und B gegeben hast, dann berechnest Du die inverse Matrix von A, multiplizierst auf beiden Seiten der Gleichung von Links damit, und hast Dein K berechnet als K=inv(A)*B.

MfG,
Peter

Diach - Di 24.12.02 03:09

genau dass müsste es sein! so hab ich mir das auch gedacht!
mein lehrer hält sich für einen spassvogel und denkt, dass er uns immer aufgaben geben muss, die wir nie lösen können und dann auf einmal mit der voll trivialen lösung kommt...

kann mir das auch nur so vorstellen!

gibt elphi nich auch eine Funktion vor, die das verschlüsseln leistet?

Anonymous - Di 24.12.02 12:07

Zaubär sagte es schon: XOR Technik.

Sie ist nicht genial, so ohne weiteres kriegst du sie aber auch nicht geknackt. Die schnellste Methode (extrem trivial). Du brauchst ein Editfeld und ein Button:

Quelltext

1:
2:
3:
4:
5:
6:
7:
8:
9:

procedure TForm1.Button1Click(Sender: TObject);
var
  i: Integer;
  s: String;
begin
  s := Edit1.Text;
  for i := 1 to Length(s) do s[i] := Chr(Ord(s[i]) xor 64);
  Edit1.Text := s;
end;

Einmal klicken und es wird verschlüsselt, ein weiteres mal klicken und es wird entschlüsselt.

Hier im Beispiel wird mit der Zahl 64 verschlüsselt. Du kannst aber jede Zahl zwischen 0 und 255 nehmen. Noch besser ist, wenn du ein String nimmst und abwechselnd eine andere Zahl nimmst (generiert aus dem Buchstaben).

Sei bitte mal nicht geschockt wenn es mal nicht funktioniert und der String plötzlich verschwindet. Das liegt einfach daran, daß bei der Xor-Technik auch mal eine Null das Ergebnis sein kann. Leider schneidet Edit alles was nach eiuner Null kommt ab. Das ist aber kein Bug, sondern normal. Wenn du nicht das Editfeld verschlüsselst (wer macht das schon), sondern ein String, dann merkst du das nicht. Für ein String ist die Ascii Null auch nur ein Zeichen. Für Edit ist Ascii Null das Ende des Strings. Wie du siehst ist es kein Bug. ich wollte das nur bemerken, dammit du keine buse Überaschiung erlebst wenn du Editfelder verschlüsselst. Also immer nur Strings verschlüsseln. Edit habe ich hier nur beim Beispiel gewählt.

Christian S. - Di 24.12.02 13:24

@Diach: mir ist leider eingefallen, dass das ganze einen Haken hat: A muss eine quadratische Matrix sein, damit man sie invertieren kann. Das ist wahrscheinlich aber nicht gegeben. Besonders nicht, wenn Du mit 8 Zeichen rechnest.

Dann bleibt Dir leider nur noch eine Lösung: für die einzelnen (noch unbekannten) Elemente von K setzt Du Variablen ein, rechnest damit das Produkt A*K aus und setzt das Ergebnis mit B gleich. Du bekommst dann soviele Gleichungen, wie Du Elemente in B hast (weil ja jedes Element von B mit dem entsprechenden Element von A*K gleich sein muss.). In Deinem Fall bekommst Du also maximal 8 Gleichungen. Ist nicht wirklich toll, oder?

Diach - Di 24.12.02 14:06

@ peter: Nee ist nicht wirklich soo toll wie ich gedacht hab! :wink:
Aber macht nix! Trotzdem vielen Dank!

@popov: Danke! Ich werd das mal so probieren! wenn ich die in deinem Beispiel verwendete Zahl 64 als schlüssel, variabel einsetze, müsste das mit dem knacken das Schlüssels mittels Schleife auch klappen!

Diach

Anonymous - Di 24.12.02 14:22

Wenn du nur mit einer Zahl arbeitest, dann ja. In der Regel nimmt man aber eine Menge an Zahlen die man z.B. aus einem Kennwort gewinnen kann.

Quelltext

1:
2:

   S := 'Der ASCII-Code für "c" ist ' + IntToStr(Ord('c')) +  ' (dezimal)';
   MessageDlg(S, mtInformation, [mbOk], 0);

Ein Wort ergibt dann schon eine Menge an Zahlen. Aber auch schon zwei Zahlen reichen aus um die Sache mit der Schleife auszuhebeln.

Diach - Di 24.12.02 19:53

Stimmt!
Und wenn ich einfach eine Repeat - Until Schleife wähle, die Anzeahl der Ziffern nach und nach erhöhe und solange laufen lass, bis ich alle Möglichkeiten durch hab oder halt das Ergebnis stimmt?
meist du das ginge?

alexschultze - Fr 03.01.03 23:21

Mal ne diesbezügliche Frage (die leider keine Antwort beeinhaltet):
man spricht ja immer von einer XXX - Bit starken Codierung. Hieße das, wenn ich bei z.B. Xor Verschlüsselung einen Key wähle, der einfach meinetwegen 1048 Bits lang ist, würde es eine 1048 Bits Verschlüsselung ergeben?

Christian S. - Sa 04.01.03 13:37

Mit der XOr-Verschlüsselung kenne ich mich nicht aus. Aber soweit ich weiß, spricht man wirklich dabei von der Größe des Schlüssels.

alexschultze - Sa 04.01.03 14:00

mh. da wäre es gut nochmal einen Experten zu fragen. Und wie könnte man ein Codierungsprogramm /sicher/ machen?`
Wenn der Schlüssel im Programm steht, ist es ja relativ leicht hackbar. (W32.ASM oder Dede als Tools mit denen man sowas auslesen kann :evil: )
Was kann man eigentlich tun? Man kann halt nur den Leuten die es decodieren sollen das Programm geben und hofft das sie den Schlüssel (das Programm) nicht weitergeben.

Anonymous - Sa 04.01.03 14:10

Wieso muß der Schlüssel im Programm stehen. Du gibst das Kennwort doch ein.

Wenn du aber Daten im Programm schützen willst, dann würde ich kein Kennwort nehmen, sondern eine Formel.

torstenheinze - Sa 04.01.03 14:16

ich hab einen tutorial im html format, ich kann den hier ja mal reinstellen.

torstenheinze - Sa 04.01.03 14:18

Maestro proudly presents:

[ Tutorial: „How2Code“ ]

„warme Worte“:
Dieses Tutorial widmet sich an alle, die ein „sicheres“ Programm schreiben wollen. Das sicher steht in „“, weil es für ein Profi kein Problem ist ,ein Kopierschutz zu knacken. Aber es hält kleine Lamer & dumme Newbies ab, unser Programm zu modifizieren. Leider kann ich nicht sagen, ob dieses Tutorial für Anfänger geeignet ist, aber ein bisschen Wissen in Delphi solltet ihr schon haben...

Ich verwende Delphi v4.0. Da ich aber „System-Nah“ programmiere, d.h. Win32 API`s verwende, sollte es kein Problem sein, den Code in VB oder/und in C++ zu portieren. Achja, der grüne Text ist Source-code.

OK, nun geht es auch schon los...

Content:

1. Einführung

2. Win32DASM ausschalten

3. ANTi-SiCE Tricks

4. CRC32-Checks einbauen

5. Serialabfrage programmieren

6. das Tool packen

7. <einige „Profitips“>

„Einführung“:

Als erstes müßt ihr wissen, was ihr schreiben wollt. Soll ein CrackMe oder Shareware werden?! Bei einem CrackMe ist der „Sinn“ (und das Programmdesign) ziemlich egal... Aber Shareware sollte schon sinnvoll durchdacht sein... was aber nicht meine Aufgabe ist *g*

„Win32DASM ausschalten“:

Der Win32DAM lebt von String-Ref., d.h. ohne diese ist er ziemlich „machtlos“. Der integrierte Debugger ist zwar schön, aber dahingehend ziemlich nutzlos. Auch könnte man das Tool mit einen Crypter packen, aber zu jedem Crypter gibt es ein Programm, was diesen Vorgang wieder rückgängig macht. Also schreiben wir unsere eigene Methode, String’s in der Delphi .EXE zu verstecken. Und das geht so:

Procedure EnDeCrypt(Var InString: String);

Var x: Byte;

Begin

RandSeed := Length(InString);

FOR x := 1 To Length(InString) Do

InString[x] := Chr(Ord(InString[x]) Xor (Random(128) Or 128));

End;

Also diese Routine ist die altbekannte (oder auch nicht) XOR Methode um String‘s zu verschlüsseln. Sie ist zwar klein, aber sehr kraftvoll. Ich würde zwar kein .TXT-Crypter damit schreiben, aber unser Ziel ist doch nur, dass der Win32Dasm die Strings nicht lesen kann, oder?! Nun folgt die Erklärung: der Befehl RandSeed berechnet eine Zufallszahl aus der Länge des gegeben String’s InString. Dieser wird als Parameter der Procedure übergeben & dann mit der XOR Routine verschlüsselt. Nun ist ein Sinnvoll, ein kleines Programm zu c0den, was wir als „Werkzeug“ benutzen, d.h. es parallel laufen lassen. Damit können wir schon während der Entwicklungszeit verschlüsselte String’s erzeugen, die wir als Const pro Procedure benutzen. Damit können wir z.B. folgende MsgBox definieren:

Procedure Meldung;

Var dStr: String;

Begin

dStr := `Œ’äÈ™ÁÌŠûú÷×·Ä°÷ö`

EnDeCrypt(dStr);

Messagebox(form1.handle,Pchar(dStr),‘Achtung...‘,0);

End;

Diese Procedure wurde eine Messagebox ausgeben, die die Überschrift „Achtung...“ hat & mit den Text „Dies ist ein Test.“ ausgibt. Warum?! Hää? Warum mit den Text „Dies ist ein Test.“ ausgibt? Das ist ganz einfach, der Variable dStr wird der Wert `Œ’äÈ™ÁÌŠûú÷×·Ä°÷ö` zugewiesen. Dieser wird beim Starten des Programm decodiert & als, für uns, lesbaren Text ausgeben. Nur leider sieht das der Win32DASM nicht... denn der String wird erst während des Startens dekodiert. Kewl, huu?! Es ist zwar ein aufwendige Methode, aber sie fkt. perfekt. Damit sollten wir alle wichtigen Strings dekodieren, z.B.: die in Fehlerboxen, wenn der Serial falsch war. Also, man könnte eigentlich alle Strings in einem Programm verschlüsseln, was aber sehr aufwendig ist. Darum sollten wir uns mit den wichtigsten String’s begnügen. Ihr könnt es gleich mal testen, eine .EXE erzeugen & das ganze in Win32DASM betrachten. Ihr findet euren String nicht... Auch kann keiner die Strings in der .EXE wiederherstellen.

Damit sollten eure String’s erstmal geschützt sein vor Lamer & Newbie’s.

( siehe SOURCE\CRYPTER\String_CRYPTER.DRP)

„ANTi-SiCE Tricks“:

Auch hier sei am Anfang gewarnt, dass diese Methode ziemlich leicht zu knacken ist. Ich zeige euch zwei verschiedene Methoden, um SiCE zu entdecken. Eine davon, bekannt als „MeltIce“ von David Eriksson's, wird von einem Tool namens FrogSiCE erkannt & „gepatched“. Aber welcher Newbie kennt schon FrogSiCE?!

Also, „MeltIce“ basiert auf der Methode, eine VxD (VxD = virtueller Geräte Treiber) von SiCE zu „öffnen“. Es gibt zwei Stück: SiCE & NTICE. Diese öffnen wir mit CreateFile(`\\.\<Name der VxD>`, win32 stuff)!

Um SiCE für Windows9x zuerkennen nehmt diese Methode:

Function Is_Sice: Boolean;

Var xSiCE,SiCE: String;

Begin

xSiCE := '÷¹Ÿ%S'; //ist unser \\.\SICE *g*

EnDeCrypt(xSiCE);

SiCE := xSice;

xFile := CreateFile(PChar(SiCE),GENERIC_READ + GENERIC_WRITE, FILE_SHARE_READ + FILE_SHARE_WRITE,NIL,OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL,0);

If xFile = INVALID_HANDLE_VALUE Then

Begin Is_Sice := False End

Else Begin Is_Sice := True End;

CloseHandle(xFile);

End;

Wie ihr schon seht, benutze ich wieder den EnDeCrypt(). Denn sonst würde in unserer .EXE „//./SICE“ stehen & das wollen wir nicht. Denn einfach mit HIEW öffnen & in z.B.: „//./SICT“ umändern und alles wäre für die Katz. Denn dann würde das Programm versuchen, die VxD SICT zu öffnen & würde Erfolg haben. Die MeltIce Methode basiert darauf, dass es einen Fehler gibt, wenn die VxD geöffnet wird. Also, einfach mit:

If Is_Sice Then ReBootPC Else LoadProg;

starten. Wenn SiCE installiert ist, bekommt die Funktion den Wert True (wahr). Ist dies der Fall, wird die Procedure ReBootPC aufgerufen. Ist SiCE nicht installiert, so wird die Procedure LoadProg aufgerufen & unser Programm lädt ohne Probleme hoch. Wie ich Eingangs schon erwähnt hatte, gibt es ein Programm was das alles „patcht“. fR0GsiCE heißt dieses geniale Tool. Leider läßt sich dieses Programm nicht im Speicher aufspüren L. Aber halb so wild, denn a) ein Newbie kennt fROGSiCE nicht & b) wir haben noch ein weitere Tricks im Ärmel...

„CRC32-Checks einbauen“:

Ein weitere cooler Code ist einen CRC-Check bei jedem start des Programmes durchlaufen zu lassen. Dann wird der Wert, der mir XOR verschlüsselt ist, aus einer Datei gelesen & mit dem akt. CRC-Wert verglichen. Stimmen diese nicht überein, lassen wir das Programm beenden. Das „coole“ an der ganzen Sache ist, wird auch nur ein JE -> JNE geändert so läuft das Programm nicht mehr.

Die Delphi-Unit liegt bei. Sie muß einfach nur kompiliert werden... That`s all.

Wie ihr sie in eurer Programm einbindet, dass zeig ich euch jetzt:

FUNCTION ProcessFile(CONST Path: STRING): DWORD;

VAR CRCTemp : DWORD;

CRCValue : DWORD;

CRCValueHex: STRING;

Error : WORD;

TotalBytes : TInteger8;

BEGIN

RESULT := 0;

Application.ProcessMessages;

CRCVAlue := 0;

CalcFileCRC32(Path, CRCValue, TotalBytes, Error);

RESULT := CRCValue;

CRCValueHex := IntToHex(CRCvalue, 8);

CRCTemp := DirCRC32;

CalcCRC32 (@CRCValueHex[1], SizeOf(CRCValueHex), CRCTemp);

DirCRC32 := CRCTemp;

CRCTemp := AllCRC32;

CalcCRC32 (@CRCValueHex[1], SizeOf(CRCValueHex), CRCTemp);

AllCRC32 := CRCTemp;

melticecrc32 := IntToHex(NOT AllCRC32, 8);

END;

Ihr müßt aber noch vorher die Variable <melticecrc32> global als String def.!!

Mit dieser Function könnt ihr den CRC-Wert einer Datei bestimmen. Das geht so:

Processfile(ParamStr(0));

ParamStr(0) ist die akt. Datei, also eure .EXE Datei. Mit der folgendem TForm1.FormShow habt ihr alles im Griff *g*...

procedure TForm1.FormShow(Sender: TObject);

var errorcode: word;

crcvalue: cardinal;

bytes: int64;

f: textfile;

dStr,dupecrc,egal: String;

begin

If Is_Sice Then Close;

If Is_Sice_NT Then Close;

Processfile(ParamStr(0));

dStr := 'Áñ£ˆ½‡®“ž³Ç'; // unsere `meltice.dat`

EnDeCrypt(dStr);

assignfile(f,dStr);

{$i-}

reset(f);

dStr:='ê¿®ñÐÍçº‘³ˆîñ€¯ÂÀ¼ÔœÐêÊí¦²Æ–ôÂ¤´£ðÙÖþÿú®Ü';

// unsere Fehlermeldung!!

EnDeCrypt(dStr);

if ioresult <> 0 then

begin

messagebox(form1.handle,pchar(dstr),'',0);

close;

end;

readln(f,dupecrc);

closefile(f);

endecrypt(dupecrc);

Assignfile(f,'debug.dat');

rewrite(f);

writeln(f,melticecrc32);

closefile(f);

if dupecrc <> melticecrc32 then

begin

close;

end;

messagebox(0,'Aufgabe: <siehe CrackMe_#4.nf0>!!','',0);

if dupecrc <> melticecrc32 then

begin

close;

end;

end;

Nun wird also bei jedem Start die Datei `meltice.dat`geöffnet. In dieser Datei steht die akt. CRC verschlüsselt drinn, die ihr vorher eingegeben habt. Der Wert wird ausgelesen, entschlüsselt & mit der akt. CRC verglichen. Stimmen diese NICHT überein, so wird das Programm beendet. Bitte benutzt keine MsgBox für Fehlermeldungen, diese kann man im DASM leicht per Imp-Fkt. Finden & man patcht den Sprung, also das Programm wird nicht beendet. Laßt lieber eine <Error.log> erstellen & schreibt dort euere Fehlermeldung rein... Das ist besser.

Ach ja, bitte kompiliert euer Programm & laßt für euch den CRC ausgeben. Erst wenn euer Programm fix & fertig ist, aktiviert ihr den CRC-Check. Wie gesagt, der muß per Hand am Ende (und durch die XOR-Routine) in die Datei `meltice.dat`eingegeben werden.

DA DIESES THEMA SEHR HEIKEL IST, SCHREIBT MIR BEI FRAGEN EINE e-MaiL AN: Maestro.Hacks@gmx.net !

Auch schaut euch den Source unter SOURCE\HACKME an...

„Eine gute Serialabfrage programmieren“:

Hier möchte ich nun nicht einen Source präsentieren, sondern lieber euch Vorschläge unterbreiten. Wenn ich hier einen Source veröffebtliche, und ihr den 1 zu 1 übernehmt, dann ist ein KeyGen für euer Programm schnell & bald geschrieben.... Also, es gibt verschiede Wege, eine „intelligente“ Serial zu proggen. Mann könnte einfach den Namen, der als String vorliegt, in einen HEX Wert umrechen. Viel Besser ist aber, und das verwende ich, eine CRC32-Modifizierte Variente zu nehmen. Dann beträgt der KEY ca. 8-12 Zeichen, die in keinerlei sichtbarer relation stehen mit dem Usernamen! Natürlich könnte man auch einfach die XOR Routine verwenden. D.h. den Username in XOR Verschlüsseln & dann vergleichen lassen. Oder denckt euch selber was aus & schreibt mir euren Weg per e-mail J.

„das Tool packen“:

Dies liegt nun echt in eurer Entscheidung. Es gibt zu jedem öffentl. erhältlichen Packer ein Gegenstück. Ich würde es nur verwenden, um die .EXE zu verkleinern. Oder ihr schreibt euch selber einen :). Einen guten .EXE Packer, egal ob für PE oder DOS findet ihr unter SOURCE\PACKER. Das ist ein DOS Tool was gleiche Cmd-Line Eigenschaften hat.

„ein paar Profitip`s...“:

1. KEINE Nag-Screen’s, ohne CRC32 Check -> sind einfach zu patchen!

2. viele CRC-Checks einbauen, Abbruch OHNE Fehlermeldung

3. viele XOR-Strings einbauen, auch in MsgBox!!

4. Nie das akt. Datum per API checken, lieber an Systemdateien!

5. ANTi-SiCE Tricks benutzen

6. < einen eigenen ANTi-fROGSiCE schreiben :) >

So, das war es erstmal von mir. Ich hoffe ihr hattet Spaß & könnt dies als „ultimative“ Hilfe benutzen. Kommentare jeder Art, also Lob,Kritik etc. ist gern gelesen unter maestro.hacks@gmx.net.

All rights reserved @ Maestro, fRACTUs`99.

/\/[ don’t be destructive – be creative ]\/\

Gr33tz: all @ fRACTUs`99 | AmoK | EVC | r!SC | MS_Jessica J | Pr0g | Crazy-Andy | Crazyfoxy | SiR Dynamite & alle die ich vergessen habe...

torstenheinze - Sa 04.01.03 14:21

tut mir leid, das dieses zeug: &#8216 überallsteht.
als ich den beitrag in dem fenster wo man das eingibt hineinkompiert habe, da war das nicht zu sehen.

achja, normalerweise war noch ein democrypter dabei, ic kann dir das auch senden ( sag mir mal dazu deine email).

tommie-lie - Sa 04.01.03 14:30

ein link hätt'es vermutlich auch getan und die '&#8216' wären auch weggeblieben... :roll:

torstenheinze - Sa 04.01.03 14:39

ich weiß ja leider nicht mehr wo ich das her hab,
außerdem mochten die mods doch nicht so viele links :wink: