Does that handle double detours, where two different programs each patch the same function?
That was the most entertaining/frustrating (depending on your world view; it made the journey way more interesting, but also a lot longer) part of hacking classic Mac OS.
You would have a zillion extensions (apple and third party) each patch tens of OS calls, both at startup and, in cases where the Finder reset patches, after the Finder launched, or even after every application launched (to get your code running at such times, you would have to patch another OS call). On PowerPC machines you would have the added fun of patching PPC code with 68k code and vice versa.
That that _sometimes_ worked was really mind boggling. Relative to that, patching your own libc seems easy.
>Does that handle double detours, where two different programs each patch the same function?
I believe Detours patches the import table inside a single process, it does not patch the call on a system wide basis, so there really is no 'two different programs each patching the same function'. In theory you could have two different pieces of code running in the same process doing that (i.e. each patching a given function), but Detours gives you a 'trampoline' function to invoke the original thing you are patching so I believe the second to patch, when invoking the trampoline function would simply invoke the first patch, which when invoking its own trampoline would invoke the original, though I haven't tried that so it may not work that way :)
VS uses this mechanism allow you to run as non-admin even though there is TONS of VS and third party code that expects to do things like write to HKLM which is a no-no if you are not an admin.
It doesn't actually patch the import table, but actually finds the functions address in memory. This has the benefit of working for statically linked libraries and run-time dynamic linking (loading). You're correct in all other respects. My casual impression is that the technique would allow more than one library to hook into the target function.
Ahh okay, that makes sense. Modifying the actual page the instructions live on in memory would force it to be marked as dirty and thus if paged out it would actually need to hit the page file instead of just being able to discard it and when it is needed again fetch it from the original dll no? I suppose that is a minor concern assuming you aren't patching tons and tons of things that reside on lots of different pages.
I'm a little fuzzy on whether they had to deal with paging or not. At the very least they'd have to mark the pages as dirty, but I think that happens when you mark it as write-able.
Comments
Does that handle double detours, where two different programs each patch the same function?
That was the most entertaining/frustrating (depending on your world view; it made the journey way more interesting, but also a lot longer) part of hacking classic Mac OS.
You would have a zillion extensions (apple and third party) each patch tens of OS calls, both at startup and, in cases where the Finder reset patches, after the Finder launched, or even after every application launched (to get your code running at such times, you would have to patch another OS call). On PowerPC machines you would have the added fun of patching PPC code with 68k code and vice versa.
That that _sometimes_ worked was really mind boggling. Relative to that, patching your own libc seems easy.
>Does that handle double detours, where two different programs each patch the same function?
I believe Detours patches the import table inside a single process, it does not patch the call on a system wide basis, so there really is no 'two different programs each patching the same function'. In theory you could have two different pieces of code running in the same process doing that (i.e. each patching a given function), but Detours gives you a 'trampoline' function to invoke the original thing you are patching so I believe the second to patch, when invoking the trampoline function would simply invoke the first patch, which when invoking its own trampoline would invoke the original, though I haven't tried that so it may not work that way :)
VS uses this mechanism allow you to run as non-admin even though there is TONS of VS and third party code that expects to do things like write to HKLM which is a no-no if you are not an admin.
It doesn't actually patch the import table, but actually finds the functions address in memory. This has the benefit of working for statically linked libraries and run-time dynamic linking (loading). You're correct in all other respects. My casual impression is that the technique would allow more than one library to hook into the target function.
Ahh okay, that makes sense. Modifying the actual page the instructions live on in memory would force it to be marked as dirty and thus if paged out it would actually need to hit the page file instead of just being able to discard it and when it is needed again fetch it from the original dll no? I suppose that is a minor concern assuming you aren't patching tons and tons of things that reside on lots of different pages.
I'm a little fuzzy on whether they had to deal with paging or not. At the very least they'd have to mark the pages as dirty, but I think that happens when you mark it as write-able.