Non importa quale kernel compilerai un exploit sotto.
Gli errori erano dovuti al fatto che il kernel forniva protezioni dai metodi di exploit che hai usato. Queste protezioni vengono eseguite in fase di runtime. Il kernel non inserisce in qualche modo il codice per gli exploit cripple compilati sotto di esso. La soluzione sarebbe quella di eseguire l'exploit su un kernel con queste funzionalità di sicurezza rimosse o disabilitate, non per compilarlo su tale kernel. Ad esempio, non è necessario che ASLR sia in esecuzione (o addirittura supportato dal kernel) per compilare un eseguibile indipendente dalla posizione, ad esempio.
Il kernel in esecuzione non modifica l'output del compilatore in modo da rompere un exploit. Tutto ciò che conta è che lo si compili con le stesse funzioni del compilatore (o almeno compatibili), le librerie (se collegate staticamente) e le ottimizzazioni. Se questo è il caso, può essere compilato ovunque. Potresti anche compilare un exploit per un'applicazione Linux su Windows o OpenBSD e viceversa.
Alcune cose che potresti voler ricordare riguardo all'ambiente del tuo toolchain:
- La compilazione su un sistema con
-march=native può comportare un eseguibile che non funziona correttamente o non funziona su un altro sistema. Evita le ottimizzazioni specifiche dell'hardware.
- L'uso di funzionalità da, ad esempio, GCC 7.2.0 può causare la rottura se compilato su una macchina con solo 6.4.0. Lo stesso vale per le regressioni che possono rompere un exploit su un compilatore più recente.
- Se il tuo target ha file header che sono incompatibili con un exploit funzionante per qualsiasi motivo, dovrai includere i file header corretti o compilarli sotto un sistema che li ha.
- I sistemi di compilazione di alcune librerie controllano l'esecuzione della versione del kernel e la usano per decidere quali funzionalità includere. Tieni presente questo se stai compilando anche le librerie su questo sistema.