Jump to content
Niiabo

[HELP] Project with function hooking / memory patching

Recommended Posts

Hey, guys!

 

Some time ago I started a project that involves hooking Windows functions and/or patching memory to modify its instructions. I have access to the executable file - I can reverse engineer it, but I cannot modify the file in any way (thus memory patching).

I used a small hooking library called mhook to hook functions like NtFileCreate, but I encountered a bunch of problems. I cannot properly catch and edit the file name of the file I want to ‘redirect’. I also experience weird anomalies when injecting my DLL – the target executable starts permanently malfunctioning until I restart my computer (message boxes won’t show, icons will disappear, clicks refuse to work, etc.).

Does anybody have even a little experience with what I am trying to do? I would be so grateful if I could use any help.

 

P.S. The project and idea are fully legal and extend the functionality of Windows

Thank you

Edited by Niiabo

Share this post


Link to post

I can't give a precise answer to what went wrong in your work.

 

but I learned that using those external hooking libraries is a pain and usually it doesn't work.

 

Try to go low level and write your own hooking procedures.

 

you can try CreateRemoteThread API if you know what you are doing.

  • Upvote 1

Share this post


Link to post

I have access to the executable file - I can reverse engineer it, but I cannot modify the file in any way (thus memory patching).

Care to explain why? Is it protected with some tough protector like VMProtect?

 

hook functions like NtFileCreate, but I encountered a bunch of problems. I cannot properly catch and edit the file name of the file I want to ‘redirect’.

Yuck. It's a very bad idea for multiple reasons.

 

Nt* functions use specific style of strings - UNICODE_STRING, to be exact. So, all your processing should take that into account.

Functions like NtFileCreate can use namespaces and other weird stuff. It gets complicated real fast: https://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85).aspx

And don't get me even started on all possible race and re-entrancy problems.. :)

 

In short-don't hook NtFileCreate if you can. Try hooking CreateFileA/W or other top-level functions.

 

I also experience weird anomalies when injecting my DLL – the target executable starts permanently malfunctioning until I restart my computer (message boxes won’t show, icons will disappear, clicks refuse to work, etc.).

Sounds like a bad side effect of hooking. You're either clobbering some register values or stack, or memory.

First, try injecting DLL that does nothing. If that causes problems, your DLL or injector are flawed. Then try installing hooks that do nothing. If they work, problem is in your code. If app still behaves weird, hooks are causing the problem - try again with different hooking lib.

  • Upvote 3

Share this post


Link to post

Thank you for all of the responses guys! Here's a little update on my story:

 

Care to explain why? Is it protected with some tough protector like VMProtect?

I am trying to alter explorer.exe and have different wallpapers for different virtual desktops. Due to legal issues and this being a school project, I cannot simply patch the file. I also have to perform pretty long operations to make what I want possible, so I strongly prefer to use a high level language compared to resizing the sections of the executable and injecting instructions somewhere in there, hoping it all works.

 

Sounds like a bad side effect of hooking. You're either clobbering some register values or stack, or memory.

First, try injecting DLL that does nothing. If that causes problems, your DLL or injector are flawed. Then try installing hooks that do nothing. If they work, problem is in your code. If app still behaves weird, hooks are causing the problem - try again with different hooking lib.

I have a long, complex method to convert from and to UNICODE_STRING which works in my separate tests. I am pretty sure something there is messed up though because injecting my DLL or hooking a function without any changes in it never causes problems.

 

And don't get me even started on all possible race and re-entrancy problems.. :)

I had a hilarious case with this when calling a CreateFile from my DLL and accidentally hooking it, causing an overflow. Got around it, but that's not even the point.

 

Try to go low level and write your own hooking procedures.

And that is almost exactly what I went for...

 

What I tried yesterday and was extremely happy to see working is manually patching the memory. My new plans are as follows:

I dynamically calculate the address of the instruction I want to modify and I overwrite it with a jump to a function in my already injected DLL. The first instruction in my function is the one I replaced (so I don't interrupt the the code flow) and then I have full access to explorer's memory (since the DLL is in its memory space). I was thinking about finding the HDC that holds the wallpaper, calculating the addresses dynamically and using it in my injected DLL function to replace the wallpaper whenever I want.

 

Please tell me if there are any flaws in my plan, if there's something I should keep in mind or just anything that I could generally do!

Thank you

Edited by Niiabo

Share this post


Link to post

That project works by checking which virtual desktop is being used every X seconds, setting wallpapers accordingly.

Unfortunately it's pretty slow and the wallpaper change looks rather bad.

 

_____

After a lot of struggle I am nearly done with the prototype of my in-method hook! I have just one problem. Say I have this code:

 

00007FF7AB721020 | call qword ptr [rip + 0x105a]
00007FF7AB721026 | mov rcx, qword ptr [rip + 0x107b]

The RIP at 0x7FF7AB721020 = 0x7FF7AB721026.

 

Following the syntax, we get:

0x7FF7AB721026 (RIP) + 0x105a = 0x7FF7AB722080.

 

However, the correct address (where the assembly originally jumps to) = 0x7FFF0C8DAF00. The destination address is an export from a loaded module (DLL) and there is some miraculous .GOT section (table?) which maps the address I just calculated to the absolute address. I was able to get this in x64dbg by following the 'qword in disassembly', but how can I do this programmatically?

 

Thanks!

Edited by Niiabo

Share this post


Link to post

You're overlooking square brackets. Your first calculation should be ok. Then read qword value from address you calculated. 

  • Upvote 1

Share this post


Link to post

You're overlooking square brackets. Your first calculation should be ok. Then read qword value from address you calculated. 

 

You saved my life @kao! Thank you so much.

Share this post


Link to post

You got me interested in this problem, so I spent a little time yesterday looking into it.

 

First question. There are no standard way for switching virtual desktops in Windows 7/8 - and most 3rd party apps already come with "custom desktop background" feature. From what I read, in Windows 10 there are virtual desktops and you can't change background. So is your project for Win10 only?

 

Second question - assuming the wallpaper management feature hasn't changed in Win10.. Why not hook reading from registry value HKCU\Control Panel\Desktop\Wallpaper and return different values for different virtual desktops? Hooking NtCreateFile seems to be an overkill here.

Share this post


Link to post

You got me interested in this problem, so I spent a little time yesterday looking into it.

 

First question. There are no standard way for switching virtual desktops in Windows 7/8 - and most 3rd party apps already come with "custom desktop background" feature. From what I read, in Windows 10 there are virtual desktops and you can't change background. So is your project for Win10 only?

 

Second question - assuming the wallpaper management feature hasn't changed in Win10.. Why not hook reading from registry value HKCU\Control Panel\Desktop\Wallpaper and return different values for different virtual desktops? Hooking NtCreateFile seems to be an overkill here.

 

Your observations are correct, my project is for Windows 10 only.

 

I want to create a fully integrated solution, perfected to the very last detail. I want to have the animation change from one wallpaper to another as well. I have all of my code interception techniques worked out and all I need to do now is find where the animation code & wallpaper code reside, so I can intercept them.

 

I just tested and changing the registry key will not have any effect; Windows stores a copy of the wallpaper in:

C:\Users\<user>\AppData\Roaming\Mikocok\Windows\Themes\CachedFiles (note: forum did Mikocok)

 

and that is what it uses. This is why I went for NtCreateFile hook in the first place. Nevertheless, my new technique should be a lot more reliable and flexible. I traced everything back to shell32 but I still have to go deeper for the animation. I've done a ton of research I can share with you if you are interested, but it's pointless to spam the topic here.

 

Anyway, thank you so much for taking interest in my project. If you agree to communicate over IM instead, please send me a personal message. I am very close to my school project's deadline and any help I can have will be extremely beneficial.

Edited by Niiabo

Share this post


Link to post

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now

×
×
  • Create New...