For the complete documentation index, see llms.txt. This page is also available as Markdown.

Tips & Tricks

Some basic tips and tricks that don't fit in any category

Introduction

Since this blog series is not about Windows system programming, i will not be covering C or Win API basics. this section is about some basic tricks and considerations to make your life easier while dealing with Win API crazy syntax, structures, data types and error codes.


Error Handling

GetLastError

This is the most used Win API for resolving error codes. it checks the return code of the function/sub-routine that was executed right before and returns an integer code which can be checked with VisualStudio "Error Lookup" tool from the "Tools" menu.

Here is an example:

output:

After looking up the error code, we can find the error message:


GetLastErrorAsString

Going a step further in error look up techniques, there is a function called FormatMessage in Win API that turns the error code into a human-readable string (the string is exactly the same as error lookup tool).

output:


SetLastError

In some cases, you might need to set the return code of a function to check it later in the code. for example, lets say you wrote a custom function or you want to change all error codes to a custom category (using Win API macros or intigers).

example:

output:


Debug Print

Using CRT "printf"

This really doesn't need an explanation, we all use print statements to save our asses while debugging code without a debugger. here is a simple macro that can be used for that, it also has a compiler directive to enable/disable print statements across the entire code by simply commenting/un-commenting a single line.

when #define DEBUG_MODE is not commented, the output will be like this:

If we comment that line, printd function will return without doing anything and all debug print statements will be disabled.


Using Win32 API

Previous code was good enough for debugging when our code is using standard C run-time (CRT) libraries. but in some cases (discussed in later posts), we want to completly strip out CRT and only use Win32 API or our own custom library code.

In such cases, we can use the following code which is an implementation of CRT "printf" with mode tuggle and support for integers, strings, pointers and characters.

Output:


Hiding the Console

After you`re done with the code, your malware should silently execute on victim machine, so you probably don't want the nasty cmd shell popup after execution. there are a couple of tricks to hide the cmd shell console.

Hiding the Console Window After It’s Created

If you want to hide the console window after it is created, you can use the ShowWindow function to hide the console.

After execution, the console will not be visible, even though MessageBox works correctly:

Detach from Console

We can also free the console from your process using the FreeConsole function, which detaches the console window from your application.

In this case, the console window is closed and detached from the process after the call to FreeConsole.

Prevent Console Creation in the First Place

One way to avoid showing a console window is to create a Windows application (rather than a console application) by using the WinMain entry point instead of main.

In this case, no console window is created, as WinMain is used for GUI applications, which don’t automatically open a console window.

Changing Subsystem After Compilation

In case you are dealing with a sample or tool that is already compiled, you can modify the PE to change the subsystem from CLI to GUI. this acts exactly like the previous technique and hides the console.

To do this, first open the PE file in DetectItEasy Tool:

Check "Advanced" option and go to "File Info" :

In the next window, uncheck "Readonly" :

Then go to IMAGE_NT_HEADERS > IMAGE_OPTIONAL_HEADER from the left panel and change the subsystem DWORD value to WINDOWS_GUI.

Save and exit, now the console should be gone.

Ignore the prompt, the original file gets modified.

Last updated