Einsprungadresse einer Procedur ermitteln?

[richard_boderich]

moin zusammen

weis jemand zufaellig wie es moeglich ist die einsprungadresse einer bestimmten procedure
zu ermitteln?

gruß richard

[NicoDE]

Welcher Prozedur? GetProcAddress() ist so offensichtlich, dass ich vermute, dass du etwas anderes meinst...

[himitsu]

Von nico für Externes, also DLLs und Co. und von mir für's interne :roll:

Delphi-Quellcode:

@Prozedurname

[richard_boderich]

nein ich will die einsprungadresse einer procedur meines delphi programms ermitteln.
das ganze will ich wissen weil ich dabei bin einen proof of concept crackerschutz zu entwicklen.


gruß richard

//edit: @himitsu sollte das wirklich so einfach sein?

[brechi]

Kommt drauf an ob die den Virtuellen oder Raw Offset haben willst.

[richard_boderich]

warum geht das nicht? compiler meckert "variable erforderlich"



var bla:longint;


begin

bla:=@procedurename


Richard

[Go2EITS]

@Brechi
Das Problem habe ich auch.

Ich möchte die Einsprungadresse + Endadresse einer Procedure/Funktion virtuell.
Ich verschlüssle die Procedure im Speicher. Bevor ich diese Aufrufe, wird die entschlüsselt
und wieder verschlüsselt. Ich weiß, nicht professionell, aber für den Anfang wird es wohl reichen.

Damit das Progremm nicht auf der Festplatte entschlüsselt werden kann (RAW), könnte man das Programm mit UPX komprimieren, damit wird zumindestens der einfache Cracker mal nicht zurechtkommen, da er den Prozess dumpen muss.

Go2eits

[Luckie]

Zitat:

Zitat von Go2EITS

könnte man das Programm mit UPX komprimieren, damit wird zumindestens der einfache Cracker mal nicht zurechtkommen, da er den Prozess dumpen muss.

Nö, er kann es mit UPX auch wieder entpacken. ;)

[NicoDE]

Zitat:

Zitat von richard_boderich

warum geht das nicht?

LongInt und Pointer sind nicht kompatibel.
bla := LongInt(Addr(procedurename));

Stellt sich die Frage warum du ein LongInt verwendest. Vielleicht wären Funktionszeiger praktischer (typsicherer).

[brechi]

Zitat:

Zitat von richard_boderich

warum geht das nicht? compiler meckert "variable erforderlich"

Dann bezweifel ich jetzt schon mal, dass du eine gute Methode gefunden hast, die länger als nen Tag sicher ist.

UPX header kaputtmachen, dann weigert sich UPX (Kann aber trotzdem ziemlich schnell anders entpackt werden)

[negaH]

Suche mal hier in der DP nach Anticracking etc.pp. da gibts einen Thread in dem ich das alles beschrieben habe. Denn für deine verschlüsselte Prozedur musst du noch viel mehr berücksichtigen als nur deren Addressen zu ermitteln.

Gruß Hagen

[brechi]

@negaH

z.b.? (Es reicht wenn du mir nur einen Stichpunkt nennst) Import und Relocation Tabelle jedenfalls nicht bei einzelnen Funktionen innerhalb einer Exe.

[negaH]

http://www.delphipraxis.net/internal...morph&start=90

schau mal da rein ;)

Gruß Hagen

[brechi]

Naja es kommt dabei ja immer drauf an was man verschlüsseln will. Und in dem Thread bist du ja schon davon ausgegeangen, dass es eben keine Methoden sind.

Hat mal also:
1) eine Exe
2) keine Methoden
3) keine globalen Variablen

kann man den code einfach verschlüsseln.

Den das Problem der Importtabelle tritt nicht auf, da direkte aufrufe von LoadLibrary erst einen relativen call haben und die einen Absoluten. (gilt ab mind. Delphi 3)
Hat man weiterhin keine globalen Variablen und keine Methoden (die benutzen wiederum globale Variablen) dann kann man es einfach verschlüsseln. Sogar so wie negaH es in dem Thread beschrieben hat, auch wenn es dort eher unelegant gemacht ist. (Suchen nach CODESTART usw.)

Delphi-Quellcode:

procedure CodeStart;
begin
  MessageBoxA(0,'elelel','test',0);
end;
procedure CodeEnd; asm end;

Kann demnach ohne Probleme und Komplikationen gecrypted werden. Deshalb auch die Frage was denn nun noch mehr berücksichtigt werden muss. Also was die methode von negaH in dem Thread kann, was man nicht durch einfaches crypten auch erreichen kann. Die eigene Relocationtabelle finde ich deshalb ein bisschen sinnlos.

[negaH]

Stimmt leider so nicht ;)

Gerade die statischen Methoden werden über eine relative Addresse ausgehend von der Position des CALLs im eigenen Code angesprungen. Das trifft auch im besonderen auf die Importtabelle zu, man springt per relativen Call in die Importtabelle wo dann ein absoluter JMP ins API steht (LOadLibrary als importierte Funktion ist also sehr wohl betroffen). Dh. wird der entschlüsselte Code aus einem anderen Speicherbereich ausgeführt (weil er ja in einen dyn. Speicher entschlüsselt wurde und NICHT im gleichen Codesegement inplaced) stimmen diese relativen Addressangaben eben nicht mehr und das führt konsequenter Weise zu einer AV.

Aber wie im Thread angesprochen ist dies bei virtuellen, dynamischen und Interface Methoden nicht mehr der Fall. Denn diese sind indirekte Calls an eine absolute Speicheraddresse im Codesegment.

Aber das trifft das Problem immer noch nicht exakt. Denn dedr Compiler würde bei einem direkten Aufruf von zb. LoadLibrary() in deinem geschützten Code einen Realokationseintrag in der Relocationtable des Module erzeugen. Der Moduleload von Windows patcht nun ausgehend von dieser Tabelle alle Codesegment Speihcerstelle an denen solche direkten importierten Aufrufe stehen. Da aber unser Code verschlüsselt wurde heist dies das der Modulloader von Windows unseren veschlüsselten Code kaputt-patcht. Betrachtet man eine gute Verschlüsselung so führt dies auf Grund ihres internen Feedback Modus dazu das der Code falsch entschlüsselt würde.

Gruß hagen

[brechi]

Zitat:

Zitat von negaH

Gerade die statischen Methoden werden über eine relative Addresse ausgehend von der Position des CALLs im eigenen Code angesprungen. Das trifft auch im besonderen auf die Importtabelle zu, man springt per relativen Call in die Importtabelle wo dann ein absoluter JMP ins API steht (LOadLibrary als importierte Funktion ist also sehr wohl betroffen). Dh. wird der entschlüsselte Code aus einem anderen Speicherbereich ausgeführt (weil er ja in einen dyn. Speicher entschlüsselt wurde und NICHT im gleichen Codesegement inplaced) stimmen diese relativen Addressangaben eben nicht mehr und das führt konsequenter Weise zu einer AV.

Nein er wird ja eben NICHT in dynamischen Speicher entschlüsselt. Wenn man die Virtuelle Adresse hat und diese in die Rawdaten Adresse umrechnet, kann man den direkt patchen (die länge hat man ja). Beim entschlüsseln wird dann eben die Virutelle Adresse genommen und der code entschlüsselt und danach aufgerufen.

Zitat:

Zitat von negaH

Aber wie im Thread angesprochen ist dies bei virtuellen, dynamischen und Interface Methoden nicht mehr der Fall. Denn diese sind indirekte Calls an eine absolute Speicheraddresse im Codesegment.

Eben das liegt nicht vor, sonst würde

Delphi-Quellcode:

Addr(Procedurename) {bzw} @ProcedureName

wie schon weiter oben erähnt keinen sinn machen.

Ich wollte eigentlich vermeinden, dass du mir hier was erklärst, da ich es schon selbst weiß. Deshalb bruachtest auch nur ein Beispiel nennen, da es sich hier um den 1. Fall handelt, nicht aber um deinen 2. beschrieben.

Beim Code

Delphi-Quellcode:

procedure CodeStart;
begin
  MessageBoxA(0,'elelel','test',0);
end;
procedure CodeEnd; asm end;

treten zwar globale Variablen auf (die Strings), aber da es sich um eine Exe handelt werden diese nichr realokiert. Und das Problem mit der Importtabelle wird ebenfalls nicht auftreten, da nirgendwo davon gesprochen wird, den Code nicht direkt wieder zu entschlüsseln.

[brechi]

So könnte es aussehen:

Delphi-Quellcode:

program codeex;

uses windows;

procedure MBox;
begin
  MessageBoxA(0,'test','test',0);
end;
procedure MBoxE; asm end;


procedure DoCode(pMem: Pointer; dwSize: DWord);
var
  i: DWord;
begin
  for i := 0 to dwSize-1 do
    PByte(DWord(pMem)+i)^ := PByte(DWord(pMem)+i)^ xor $23;
end;

procedure Trash;
asm
  DB $0
end;

procedure CallMBA;
var
  dwOldProtect: DWord;
  dwProcSize: DWord;
begin
  dwProcSize := DWord(@MBoxE)-DWord(@MBox);
  if VirtualProtect(@Mbox, dwProcSize, PAGE_EXECUTE_READWRITE, dwOldProtect) then
  begin
    DoCode(@MBox,dwProcSize);  // entschlüsseln
    MBox;
    DoCode(@MBox,dwProcSize);  // verschlüsseln
    VirtualProtect(@MBox, dwProcSize, dwOldProtect, dwOldProtect);
  end;
end;

procedure CreateExe;
var
  f: File of Byte;
  FileMem: array of Byte;
begin
  // jetzt ohne viele checks, ohne CreateFileA usw bla bla
  // SizeOf Headers = $400
  // Codestart @ Section1 @ Virutal $1000

  CopyFile(PChar(Paramstr(0)), PChar(Paramstr(0)+'_rdy.exe'), False);

  AssignFile(f,Paramstr(0)+'_rdy.exe');
  Reset(f);
  SetLength(FileMem, FileSize(f));
  BlockRead(f, FileMem[0], Length(FileMem));
  CloseFile(f);

  DoCode( @FileMem[DWord(@MBox) - GetModuleHandle(nil) + $400 - $1000 ], DWord(@MboxE) - DWord(@MBox));

  FileMem[DWord(@Trash) - GetModuleHandle(nil) + $400 - $1000 ] := 1;

  AssignFile(f,Paramstr(0)+'_rdy.exe');
  ReWrite(f);
  BlockWrite(f, FileMem[0], Length(FileMem));
  CloseFile(f);
end;

begin
  if (PByte(@Trash)^ = 0) then
    CreateExe else
    CallMBA;
end.