Elegáns és egyszerű megoldás az lenne, ha aláírná a futtatható fájlt, és ellenőrizné az aláírást indításkor (minden változtatás érvényteleníti az aláírást). Még akkor is, ha valaki javítja az aláírás-ellenőrzést, az aláírás továbbra is érvénytelen lesz, ami egyértelművé teszi, hogy az exe nem ugyanaz, mint amit Ön átadott. az erőforrásokról (mindkettőt a @angealbertine válasz már javasolta).

Emellett kihasználhatjuk a hibákat magukban a szerkesztőkben is, hogy megakadályozzuk az erőforrásaink manipulálását. Az érdekes rész itt az, hogy a legtöbb erőforrás-szerkesztőnek fogalma sincs arról, hogyan kell elemezni a nem tipikus (nem túl nem tipikus) PE fájlokat. Például egyes szerkesztők feltételezik, hogy az erőforrásszakasz nevének mindig .rsrc -nak kell lennie. Példák:

1. Resource Hacker

   • Speciális erőforrás beillesztése az erőforrás-hacker végtelenbe kerülését okozza hurok. Bemutató itt: http://code.google.com/p/ollytlscatch/downloads/detail?name=antiResHacker.exe

   • Speciális beszúrása Az RT_STRING erőforrás az erőforrás-hacker összeomlását okozza.

   • Feltételezi, hogy a IMAGE_OPTIONAL_HEADER szerkezet mérete sizeof (IMAGE_OPTIONAL_HEADER) , jelenleg 0xE0 hexadecimális formában, miközben ennél nagyobb is lehet. Ha a méret nagyobb értékű, akkor az Resource Hacker elveti a teljes PE fájlt.

2. helyreállító

   • Ugyanaz, mint az 1c.
   • A NumberOfRvaAndSizes mezőt használja, amelyet könnyen 0xFFFFFFFF -nak hamisíthatunk. Ez azt eredményezi, hogy a Restaurátor elveti a teljes PE fájlt.
   • Feltételezi, hogy az erőforrás szakasz neve .rsrc . Változtasson bármi mást. Ez arra készteti a Restaurátort, hogy a teljes PE-t eldobja.
   • A Resorator elvet minden olyan erőforrásszakaszt, amelynek IMAGE_SCN_CNT_UNINITIALIZED_DATA mezőjére a Jellemzők mezőt állítja.

   Demók itt: http://pastebin.com/ezsDCaud

Az erőforrások csak egy szabványos struktúra meghatározott állandókkal, de végül csak egy rekurzív struktúra egy pufferhez, függetlenül attól, hogy mit tartalmaz ( itt van a szokásos elrendezés).

Elméletileg bármit tartalmazhat - bármilyen mélységet, ciklust, érvénytelen típust stb ..., de akkor a szabványos API-k nem működnek velük.

Tehát meg kell győződnie arról, hogy ha titkosítja vagy tömöríti az erőforrásokat, ezeket az API-k bármelyikének használata előtt vissza kell állítani (mind az erőforrás könyvtár struktúráját, mind azok tartalmát), ami nem biztos, hogy nyilvánvaló.

Különösen néhány erőforrást fognak használni az operációs rendszer által, még a fájl végrehajtása előtt, például az első ikonok, a manifeszt és a verzióinformációk - így valószínűleg ezeket érintetlenül szeretné megőrizni.

A triviális erőforrás-szerkesztés megakadályozásának egyszerű módja egy adatfolyam futtatása lenne rejtjel a kiválasztott erőforrásokon, a végső bináris fájlon (miután a linkelő helyre tette őket és létrehozta az erőforrás bejegyzést a DataDirectory-ban), és ezeket az erőforrásokat dem és vagy a program inicializálásakor.

Ha kész megoldást keres, sok jó csomagoló, például a PECompact támogatja az erőforrások tömörítését, megakadályozva ezzel a külső erőforrások szerkesztését.