5

I use x64dbg and IDA Pro the process is 32bit. I'm not sure if I'm doing this right or not because I'm getting a crash which I'm not sure if it's caused by me doing something wrong or the startup process of the application failing for some reason because it can't find the window.

Basically what I'm trying to do is change the window title of some application on startup. I'm trying to achieve this by setting a break point on the user32 function CreateWindowExA and then attempting to change the lpWindowName parameter.

Here is what execution looks like when the bp is hit:

code

Where you see the string "Title possibly" originally contained what was the windows title, so I assume that's the location I need to change. When changing at that address is when I get the error though.

Sorry for any ignorance, I'm new to this and practicing. Thanks.

Edit: I worked on this a little more and made a dummy program to help me figure out what was happening. So the CreateWindowExA function in this application used the same pointer for both lpClassName and lpWindowName args. So patching the program to push just a string instead of that pointer successfully achieved what I was aiming for.

Improve this question
5
  • Do you change the pointer or the bytes it points to? What is the size in bytes of the original window title? – EWD-0- Dec 15 '17 at 10:16
  • I change the bytes it points to and keep it with a string of the same length if that counts for anything. The original title I believe is a string of 10 characters including the 0/ (if I need to include it?) unless it's a wide char I guess. Not exactly sure how I would confirm that though sorry – notvita Dec 15 '17 at 10:28
  • 2
    Take a look msdn.microsoft.com/en-us/library/windows/desktop/… to see if you change the right parameter. There is no need to guess which parameter is the window name when it's documented. – EWD-0- Dec 15 '17 at 10:48
  • Thanks. I was trying to but I'm a bit confused about things. Where the line is it breaks, but that to me doesn't look like a function. Are all those instructions leading up to the call user32.76F8AA9C down the bottom the functions prologue and then the actual call the function being called? That's kind of the conclusion I came to and all the dword ptr ss pushes above call user32.76F8AA9C being the functions parameters? – notvita Dec 15 '17 at 11:04
  • Yes, as in stdcall we have the parameters in the stack you can just check/change them in the debugger stack view. What you see here is a functions which is somehow working as an interface to call the main functionality. – EWD-0- Dec 15 '17 at 12:24
3

Tip: Install xAnalyzer for x64dbg, that might help you in your reversing efforts.

Now, you are in the user32.dll function CreateWindowExA. I would not change that parameter there, but outside in user code (familiarize yourself with the stdcall convention, its what WinApi uses). The parameter you are shooting for is three pushes above the call CreateWindowExA in user code. Either change the pointer or the content under it and don't forget to null-terminate.

Improve this answer
2
  • Kernel function? For starters this is not a function in kernel32.dll and furthermore just because that DLL has "kernel" in its name doesn't make the function a kernel function. – 0xC0000022L♦ Dec 19 '17 at 22:12
  • @0xC0000022L You are completely right. It was late here and I just typed up a quick answer. Of course that CreateWindow does not go through the sysenter system, I just saw he's inside a dll and called it a kernel function for whatever reason. (edited the aswer) – barnaby-b Dec 20 '17 at 14:57
2

Hook it, then set the parameter lpWindowName to "your name here" (no promises this will work) OR breakpoint on mov edx, dword ptr ss:[EBP+C], then grab EBP from the FPU (registers box), go in to a program like ReClass and set the EBP+0xC (window name) to whatever name you want (90% sure this will work). References: https://stackoverflow.com/questions/873658/how-can-i-hook-windows-functions-in-c-c https://www.youtube.com/watch?v=K_jj6yF5ac0

Improve this answer
0

Thanks for the responses guys. I managed to achieve my goal which is detailed in the OP edit:

The CreateWindowExA function in this application used the same pointer for both lpClassName and lpWindowName args. So patching the program to push just a string instead of that pointer for lpWindowName successfully achieved what I was aiming for. I believe changing the lpClassName was causing the crash I described in the OP.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.