Hvis du tabler dig i dette område, ved du allerede, at Microsoft Research's Omvej stort set sætter benchmark, når det kommer til API-hooking.Hvorfor får vi ikke en sammenligning hurtigt væk?DETOURS VS.MHOOK Detours er gratis tilgængelig med en ikke-kommerciel licens, men den understøtter kun x86-platformen.Omveje kan også licenseres til kommerciel brug, hvilket også giver dig fuld x64 support, men du får kun se licensbetingelserne, når du har underskrevet en NDA.Mhook distribueres frit under en MIT-licens med support til x86 og x64.Omveje rykker væk fra officielt at understøtte fastgørelse af kroge til en kørende applikation.Selvfølgelig er du fri til at gøre det - men hvis du ender med at forårsage et tilfældigt nedbrud her eller der, kan du kun bebrejde dig selv.Mhook var beregnet til at kunne indstille og fjerne kroge i kørende applikationer - det er trods alt det, du har brug for det i den virkelige verden.Det gør sit bedste for at undgå overskrivningskode, der muligvis udføres af en anden tråd.Omkørsler understøtter transaktionshooking og frakobling;det vil sige at sætte en masse kroge på samme tid med en alt-eller-intet-tilgang.Hooks indstilles kun, hvis alle af dem kan indstilles, ellers vil biblioteket rulle alle foretagne ændringer tilbage.Mhook gør ikke dette.Endelig er Mhook temmelig doven, når det kommer til styring af hukommelse til de trampoliner, den bruger.Omvej tildeler hukommelsesblokke efter behov og bruger det resulterende dataområde til at gemme så mange trampoliner inden for, som det passer.Mhook bruger på den anden side et opkald til VirtualAlloc pr. Krog, der indstilles.Hver krog har brug for mindre end 100 byte lager, så dette er meget spildt, da VirtualAlloc ender med at gribe 64K fra processens virtuelle adresserum, hver gang Mhook kalder det.(Faktisk tildelt hukommelse vil være en enkelt side, som også er meget spildt.) I sidste ende er det sandsynligvis ikke rigtig vigtigt, medmindre du indstiller et meget stort antal kroge i en applikation.Dette er også meget let at løse.