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