Einsprungadresse einer Procedur ermitteln?

[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 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 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 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.