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.