CQURE 5-Day Challenge – Day 3: Windows Handles

CQURE 5-Day Challenge – Day 3: Windows Handles

This is the 3rd challenge of CQURE’s 5-Day Challenge. I absolutely love this one and I’ll tell you why towards the end.

Let’s start from the beginning. The tutorial video is done by Greg and he does an excellent job at teaching you how to access a file that is currently locked by another application.

So what’s the challenge ? They provide an executable with the name ‘CQLocker.exe’ and you have to run it. This creates a new text file, ‘CQLocker.txt’, in the executable’s folder. The challenge consists in accessing the newly created text file or trying to delete it. Both actions result in an error, due to the file being used by another process. What can you do in such cases ?

There are multiple approaches in solving the issues. I’ll briefly cover some of them.

Sysinternals tools are your best friends. ‘Process Explorer’ allows you to search a DLL or handle. Use ‘Ctrl+F’ to open the search tab and enter the string ‘CQLocker.txt’. I’ve done that and the process with the handle to ‘CQLocker.txt’ was immediately returned.
Alt

Close the handle.
Alt

Now I can open or delete the file.

Another option would be to use ‘handle.exe’ utility, also from Sysinternals. See below:
Alt

The biggest surprise comes from ‘Task Manager’. Normally this wouldn’t be used in cases like this one. But surprise, if you select the ‘Command line’ column, a big clue is revealed about which process might be holding hostage the text file.
Alt

Of course, the handle cannot be closed from here, only the entire process (or maybe you can and I don’t know how).

Another approach is the one used by Greg during the video tutorial, create a shadow copy and make a symbolic link to it. But this only applies if you want to read the file. Doesn’t exactly solve the issue, just work around it.

At this point I knew that the original executable actually creates a another process which locks the file. I wanted to know more about how it works. I turned to my new favorite tool, ‘Process Monitor’. I’m still learning this tool, but it’s amazing the wealth of information it unfolds. So I started ‘Process Monitor’ and ran ‘CQLocker.exe’. Let’s see a process tree.
Alt

So the original executable creates another process, which has a very short life time, but creates yet another process. By the looks of it, the third process is the one locking the file. Ok, moving on. I made a filter in ‘Process Monitor’ to show only events related to ‘smss.exe’, after which I searched for ‘CQLocker.txt’. Sure enough, there it is. The last ‘CreateFile’ operation is made on the text file.
Alt

‘ShareMode’ is set to ‘None’. No wonder the file is locked. And so I solved the mystery of this executable.

A while ago, I started researching reverse engineering for a bit. I decided to try and analyze this binary under the microscope and see if I make heads or tails out of it. I spent very little time on it, but I managed to find the call to ‘CreateProcess’, which spawns the first ‘smss.exe’ process.
Alt

The first image is the disassembly view of ‘CreateProcessW’ function. The ten highlighted instructions are actually the parameters for the function, that are pushed into the stack. You can view the stack in the second image. Immediately after the function call, it checks to see whether or not it was successful (see the ‘CMP EAX, 1’ instruction). Well, I don’t want another process to be created, which in turn creates another and locks the file. I just want the original executable to create the text file and then to exit gracefully. With this in mind I decided to make some modifications to the code. Instead of the call to ‘CreateProcessW’, I decided to replace that with ‘MOV EAX, 1’. This has the effect of not creating any additional processes and also returns true when the code checks for the success of ‘CreateProcessW’.
Alt

I saved the modifications to a new executable. ‘Process Monitor’ captures all events when I ran this new executable. See below the process tree.
Alt
Alt

Sweet ! Just got confirmation that the new executable doesn’t create any additional processes and also the last ‘CreateFile’ operation is willing to share the file.

Hope you liked this one. I really enjoyed working on it, more so because it made me revisit a disassembler. I briefly touched base with reverse engineering and I loved it. Glad that CQURE pushed me in this direction again. See you tomorrow.
Cheers^^

P.S. Let me know if you want the patched executable that doesn’t create additional processes.