Vous ne pouvez pas utiliser le CRT 2008, mais vous pouvez empêcher les nouvelles fonctions DecodePointer/EncodePointer d'être liées à partir du noyau. Il est assez facile de remplacer ces nouvelles fonctions par des stubs.
On pourrait essayer de suivre : Placez un code comme celui-ci dans votre source main.cpp :
~~extern "C" {
void *__stdcall _imp__DecodePointer(void *x) {return x;}
void *__stdcall _imp__EncodePointer(void *x) {return x;}
};~~
Ce qui précède ne fonctionne pas. Si l'idée de base est bonne, l'exécution doit être un peu différente. Comme décrit par snemarch dans le commentaire et une autre réponse , __imp__ ne peut pas être l'appel de la fonction, seulement le pointeur vers celle-ci. Comme il ne semble pas possible de générer le pointeur directement par le compilateur, vous devez assembler le code suivant avec MASM et le lier au fichier objet produit.
.model flat
.data
__imp__EncodePointer@4 dd dummy
__imp__DecodePointer@4 dd dummy
EXTERNDEF __imp__EncodePointer@4 : DWORD
EXTERNDEF __imp__DecodePointer@4 : DWORD
.code
dummy proc
mov eax, [esp+4]
ret 4
dummy endp
end
Les symboles d'un projet ont la préférence sur les symboles des bibliothèques. Les bibliothèques DLL sont liées à l'aide de parties .lib, qui contiennent seulement __imp__ "vecteurs" sautant dans les fonctions réelles. En remplaçant __imp__ "vecteurs" vous ne touchez pas à la liaison DLL, vous remplacez la partie .lib. J'ai vérifié qu'il n'y a plus de dépendance de l'exe sur DecodePointer / EncodePointer.
Contexte
Une bibliothèque liée statiquement apporte uniquement la fonctionnalité utilisée dans l'application. Il est possible de trouver quelle fonction particulière de la CRT apporte ces nouvelles API en utilisant la sortie de progression verbeuse du linker :
Found __imp__EncodePointer@4
Referenced in LIBCMT.lib(crtmboxw.obj)
Referenced in LIBCMT.lib(invarg.obj)
Referenced in LIBCMT.lib(handler.obj)
Referenced in LIBCMT.lib(onexit.obj)
Referenced in LIBCMT.lib(cmiscdat.obj)
Referenced in LIBCMT.lib(tidtable.obj)
Referenced in LIBCMT.lib(hooks.obj)
Referenced in LIBCMT.lib(winsig.obj)
Referenced in LIBCMT.lib(rand_s.obj)
Found __imp__DecodePointer@4
// ... same list, only order differs ...
Cela montre que les nouvelles API sont utilisées dans certains des CRT pour renforcer la sécurité de certaines fonctions qui sont considérées comme des vecteurs d'attaque fréquents.
Avec un peu d'effort, il serait possible d'utiliser LoadLibrary / GetProcAddress pour fournir la vraie fonctionnalité là où l'OS l'offre, mais je ne pense pas que cela apporterait vraiment quelque chose. Les fonctions d'exécution qui utilisent DecodePointer / EncodePointer n'ont pas vraiment besoin de fournir un encodage, tout ce dont elles ont besoin est que l'encodage soit symétrique. Vous n'avez pas vraiment besoin de la sécurité renforcée (le runtime de VS 2008 ne vous la donnerait pas non plus).
J'espère qu'il n'y a pas d'autres obstacles qui vous attendent - Je n'ai pas accès à un système Win2k ou XP pre SP2, donc je ne peux pas essayer. S'il y a des drapeaux d'en-tête d'exe qui empêchent même de tenter de lancer l'exe sur ces systèmes, ils devraient être faciles à changer.
