Welcome to Software Development on Codidact!
Will you help us build our independent community of developers helping developers? We're small and trying to grow. We welcome questions about all aspects of software development, from design to code to QA and more. Got questions? Got answers? Got code you'd like someone to review? Please join us.
Post History
I believe the term "hook" comes from the Windows API where you can register "hooks" - callback functions - to respond to certain events, optionally replacing the original behavior. Not necessarily ...
Answer
#4: Post undeleted
by
Lundin
·
2020-09-25T11:26:01Z (about 4 years ago)
#3: Post edited
by
Lundin
·
2020-09-25T11:25:55Z (about 4 years ago)
I believe the term "hook" comes from the Windows API where you can register "hooks" - callback functions - to respond to certain events, optionally replacing the original behavior.If you wish to do this on Windows, then some hooks can be used on system level or "globally", such as responding to certain hardware events. If you wish to respond to events occurring inside another process though, that isn't possible because you aren't generally allowed to act on things occurring outside your own process' address space.One common way to hack this limitation is by placing your code inside a DLL, then somehow trick the other process into loading your DLL or attaching your DLL to it. Then the code inside the DLL exists in the same process as the one you wish to respond to and hooks can then listen and react to events occurring inside that process. This is called "DLL injection", so it is a manner of code injection, but doesn't modify the other process/program.- Traditional code injection is rather done by appending your own program to the other process' executable, then abuse some API call or other vulnerability so that the process will call code placed inside the appended part of it's own address space. This is how old time computer viruses worked, and old time anti-virus software would simply scan executables looking for binary sequences of known viruses at the end.
- I believe the term "hook" comes from the Windows API where you can register "hooks" - callback functions - to respond to certain events, optionally replacing the original behavior. Not necessarily other processes, it could also be hardware events etc.
- If you wish to respond to events occurring inside another process though, that isn't possible because you aren't generally allowed to act on things occurring outside your own process' address space.
- One way to perform code injection is through hooks - by placing your code inside a DLL, then somehow trick the other process into loading your DLL by the means of a listening to DLL events through hooks. Then the code inside the DLL will end up existing in the same process as the one you wish to respond to and it can then listen and interact to things going on in that process.
- You can also do other forms of "DLL injection" that attaches a DLL to a process, but doesn't modify the other process/program.
- Traditional code injection is rather done by appending your own program to the other process' executable, then abuse some API call or other vulnerability so that the process will call code placed inside the appended part of it's own address space. This is how old time computer viruses worked, and old time anti-virus software would simply scan executables looking for binary sequences of known viruses at the end.
#2: Post deleted
by
Lundin
·
2020-09-25T11:15:09Z (about 4 years ago)
#1: Initial revision
by
Lundin
·
2020-09-25T11:14:15Z (about 4 years ago)
I believe the term "hook" comes from the Windows API where you can register "hooks" - callback functions - to respond to certain events, optionally replacing the original behavior. If you wish to do this on Windows, then some hooks can be used on system level or "globally", such as responding to certain hardware events. If you wish to respond to events occurring inside another process though, that isn't possible because you aren't generally allowed to act on things occurring outside your own process' address space. One common way to hack this limitation is by placing your code inside a DLL, then somehow trick the other process into loading your DLL or attaching your DLL to it. Then the code inside the DLL exists in the same process as the one you wish to respond to and hooks can then listen and react to events occurring inside that process. This is called "DLL injection", so it is a manner of code injection, but doesn't modify the other process/program. Traditional code injection is rather done by appending your own program to the other process' executable, then abuse some API call or other vulnerability so that the process will call code placed inside the appended part of it's own address space. This is how old time computer viruses worked, and old time anti-virus software would simply scan executables looking for binary sequences of known viruses at the end.