I was trying to hook some function on a program using Frida (see script attached). Specifically, I was trying to hook the Kernel32!HeapAlloc function (https://msdn.microsoft.com/en-us/library/windows/desktop/aa366597%28v=vs.85%29.aspx)
For some reason, I was getting the following error (see attached image).
I decided to investigate a bit about that error. What I found was that even though Frida could hook the ntdll.dll!RtlAllocateHeap (internal call from HeapAlloc) (see log below), for some reason, it tried to resolve or hook the "HeapAlloc" per se but as the function was not found then the error was raised.
See, here the hook for RtlAllocateHeap:
76FC209D RtlAllocateHeap - E9 92E17189 JMP 006E0234 --> JUMP TO TRAMPOLINE
76FC20A2 83EC 60 SUB ESP,60
76FC20A5 53 PUSH EBX
76FC20A6 56 PUSH ESI
76FC20A7 33F6 XOR ESI,ESI
76FC20A9 817D 10 FFFFFF7>CMP DWORD PTR SS:[EBP+10],7FFFFFFF
76FC20B0 57 PUSH EDI
76FC20B1 8975 F8 MOV DWORD PTR SS:[EBP-8],ESI
76FC20B4 0F87 3F900200 JA ntdll.76FEB0F9
[...]
@oleavr told me that some sanity checks are done before hooking a function, like:
- the first byte of the address is readable
- that we can parse the first instructions
These two sentences are satisfied in this case, because the address I'm calculating for HeapAlloc is readable and has "code". However, as HeapAlloc is forwarder to RtlAllocateHeap, you are not going to find any code for the HeapAlloc resolved address.
So, Frida could resolve the hook on the first place but then, for some reason (I couldn't find the real cause) tries to resolve the "HeapAlloc" per se.
So, maybe, you can add some heuristics to determine if the address to hook is a real function, maybe analyzing the prologue of the function. I assume this depends on the calling convention but it is just an idea.
In order to reproduce the issue, just launch "nopetad.exe" and run the script to attach to it. Then, navigate to File->Open. Error is raised.
Script and screenshot: https://www.dropbox.com/s/ng4lf1xfokcvv4p/frida-interceptor-error.zip?dl=0