Weekly digest 2

This is the second of (hopefully) many weekly digests. Basically it will highlight the things that happened to x64dbg and related projects during the week before.

Font in the command completion dialog

The command completion dialog and the command edit now use the same font as the log view.

Added memdump option to savedata

The savedata command now allows you to use :memdump: as a filename to create a file memdump_pid_addr_size.bin in the x64dbg directory. This is useful for scripting purposes.

Fixed various general purpose instructions

The commands inc and dec work again and the bswap command can now also be used when not debugging.

Also the operators <<< and >>> (rol and ror) have been added to the expression parser.

More usable disassembly popup

The disassembly popup menu now also works on instruction tokens directly (such as immediate or memory addresses).

Fixed empty watchdog menu

The watchdog menu was bugged and would always be empty, this has been resolved.

Trace record tracing works again

The TraceIntoIntoTraceRecord command and various other trace record based tracing command had incorrect behavior because of a typo, everything works again now!

Animation into has been implemented!

torusrxxx added animate into/over in pull request #1020!

Better unicode support

The dump window now uses the local code page per default instead of only displaying latin1 characters, there has also been a menu added for displaying the last code page which is convenient for non-English speaking users. See pull request #1023 for more details.

Execute a script on attach or initialize

A global or per-debuggee script can now be executed on initialization. See pull request #1026 for more details.

Create a thread in the debuggee

The createthread command has been added and you can also right click a location in the disassembly and directly spawn a new thread from that location. See pull request #1028.

Performance improvements in TitanEngine

For every (single) register query TitanEngine would read the entire context (including the time-demanding AVX registers). This has been fixed and stepping can be observed to be much faster in some cases.

Auto scrolling when moving the mouse out of views

The oldest unresolved issue #22 has been resolved in pull request #1029 and the disassembly (and other views) will now scroll if you move your mouse outside of the view.

Expression functions

The expression functions have been extended with various new functions, see expressionfunctions.cpp if you want to know more.

Hint: you can simulate branch tracing with the command TraceIntoConditional dis.isbranch(cip) || dis.isret(cip)

Expect a blog post on this somewhere this month.

Allow modification of the singleshoot flag

Previously it was impossible to change a singleshoot breakpoint to a persistent one, this has now been implemented in the breakpoint editor and the SetBreakpointSingleshoot command.

Added NTSTATUS codes

The NTSTATUS code names have been added to the exception handling, this should cover pretty much all exception names that are hardcoded in Windows.

Updated color schemes

Many people are probably unaware of the x64dbg wiki. I slightly adapted some of the color schemes to support trace record and graphs better. You can now also customize the background of the graph view. Feel free to add your schemes or ping me if you have an improvement for an existing one.

Also, Storm Shadow from Techbliss updated some of his stylesheets, check it out!

Final words

That has been about it for this week again. If you have any questions, contact us on Telegram, Gitter or IRC. If you want to see the changes in more detail, check the commit log.

You can always get the latest release of x64dbg here. If you are interested in contributing, check out this page.

Finally, if someone is interested in hiring me to work on x64dbg more, please contact me!

Weekly digest 1

This is the first of (hopefully) many weekly digests. Basically it will highlight the things that happened to x64dbg and related projects during the week before.

Improvements to the attach dialog

Forsari0 contributed this in pull request #994, the attach dialog will now also show the command line arguments for every process:

Disable debuggee notes when debugging

Previously it was possible to edit notes in the ‘Debuggee’ tab, even when you were not debugging anything. These notes would be forever lost so now you can no longer see that tab when not debugging.

Translation of the DBG

In addition to the Qt interface translation, torusrxxx added the infrastructure in the DBG to translate log strings. See pull request #998 for more details.

Search box locking in symbol view

Yet another contribution by Forsari0, in pull request #1003. He added a checkbox in the symbol view that allows you to save your search query when switching to other modules, allowing you to repeat the same query in various different modules:

Various GUI improvements

torusrxxx added various useful interface improvements in pull request #1004:

• Forward and Backward mouse buttons found in some models of mice.
• No confirmation when adding functions.
• Allocate memory from the dump menu.
• Placeholder tips for learners.
• Disable/Cancel log redirect (issue #939)
• Use Windows configuration for the singe step scroll size (issue #1000)

Here is an example of those placeholder tips:

Don’t freeze when the debuggee doesn’t close properly

In certain (rare) cases, the debuggee cannot be terminated correctly. TitanEngine will wait for EXIT_PROCESS_DEBUG_EVENT, but in some cases this event is not received and there will be an infinite debug loop, thus freezing x64dbg when trying to terminate the process. This has been worked around by setting the maximum wait time to 10 seconds.

Warn when setting a software breakpoint in non-executable memory

If you attempt to set a breakpoint in a data location, x64dbg will warn you and ask if you are certain about this. Usually the only thing that comes out of it is data corruption:

Signed and unsigned bytes in the dump

The dump views now include signed and unsigned byte views:

Fixed WOW64 redirection issues

See the dedicated blog post for more information.

Fixed invalid save to file sizes

When using the Binary -> Save to file option the savedata command would be executed but with the decimal size as argument, thus saving far too much data. This has been fixed.

Added imageinfo command

During a discussion in the Telegram channel, someone mentioned OllySEH and I decided to implement a similar command in x64dbg. The command imageinfo modbase will show you a summary of the FileHeader.Characteristics and OptionalHeader.DllCharacteristics fields:

Image information for ntdll.dll
Characteristics (0x2022):
  IMAGE_FILE_EXECUTABLE_IMAGE: File is executable (i.e. no unresolved externel references).
  IMAGE_FILE_LARGE_ADDRESS_AWARE: App can handle >2gb addresses
  IMAGE_FILE_DLL: File is a DLL.
DLL Characteristics (0x4160):
  IMAGE_DLLCHARACTERISTICS_DYNAMIC_BASE: DLL can move.
  IMAGE_DLLCHARACTERISTICS_NX_COMPAT: Image is NX compatible

Adding this command required a small change in TitanEngine (the DllCharacteristics field was not supported).

Updated Yara to 3.5.0

Quite recently the latest version of Yara (3.5.0) was released. This version is now also updated in x64dbg!

Work on GleeBug

GleeBug is the planned new debug engine for x64dbg. During the holidays there has been quite a bit of work with regards to memory breakpoints. See the commit log for in-depth information.

GleeBug has been in development for about 1.5 years now. It can currently replace TitanEngine for x64dbg (giving massive performance improvements), but not all features are implemented yet. The main blockers are currently:

• Memory breakpoints
• Extended (XMM, YMM) register support
• Breakpoint memory transparency

For reference, when tracing with TitanEngine, the events/s counter is around 250. When tracing with GleeBug, this counter comes near 30000 events/s in some cases!

Final words

That has been about it for this week. If you have any questions, contact us on Telegram/Gitter/IRC. If you want to see the changes in more detail, check the commit log.

You can always get the latest release of x64dbg here. If you are interested in contributing, check out this page.

64bit Debugging and the WoW64 File System Redirection

A small note on WoW64 Redirection on Windows

With the introduction to a 64bit Windows Operating System Microsoft introduced the Wow64 emulator. This is a combination of DLLs (aptly named wow64xxx.dll) that automatically handle the proper loading of x86 versions of system libraries for 32-bit processes on 64-bit Windows.

In addition to this, in order to prevent file access and registry collisions WoW64 automatically handles redirecting file operations for 32-bit applications requesting access to system resources. Notice on a 64bit version of Windows, when a 32-bit application requests to open a System file located in %windir%\system32, if that file is also located in the %windir%\SysWOW64 Windows File System Redirection kicks in and provides that application with the 32bit version of the application. This is done due to a combination of factors including pre-defined Registry settings and environment variables setup by WoW64 during application start up.

How this affected the x96dbg.exe loader

In the x64dbg package, a loader is provided as a convenience to the user in order to support Right-Click Context Menu debugging of applications and Desktop shortcuts. However up until recent commits 1 and 2 proper handling of redirection was not present. More information about this issue can be read here in Issue #899.

Due to the fact that x96dbg.exe is a 32-bit application, when a Right Click context menu is invoked to debug a 64-bit application in the System directory, File System Redirection will automatically provide it with the 32-bit version of the application. This redirection in fact affects the function GetFileArchitecture():

static arch GetFileArchitecture(const TCHAR* szFileName)
{
    auto retval = notfound;
    auto hFile = CreateFile(szFileName, GENERIC_READ, FILE_SHARE_READ, nullptr, OPEN_EXISTING, 0, nullptr);
    if(hFile != INVALID_HANDLE_VALUE)
    {
        unsigned char data[0x1000];
        DWORD read = 0;
        auto fileSize = GetFileSize(hFile, nullptr);
        auto readSize = DWORD(sizeof(data));
        if(readSize > fileSize)
            readSize = fileSize;
        if(ReadFile(hFile, data, readSize, &read, nullptr))
        {
            retval = invalid;
            auto pdh = PIMAGE_DOS_HEADER(data);
            if(pdh->e_magic == IMAGE_DOS_SIGNATURE && size_t(pdh->e_lfanew) < readSize)
            {
                auto pnth = PIMAGE_NT_HEADERS(data + pdh->e_lfanew);
                if(pnth->Signature == IMAGE_NT_SIGNATURE)
                {
                    if(pnth->FileHeader.Machine == IMAGE_FILE_MACHINE_I386)  //x32
                        retval = x32;
                    else if(pnth->FileHeader.Machine == IMAGE_FILE_MACHINE_AMD64)  //x64
                        retval = x64;
                }
            }
        }
        CloseHandle(hFile);
    }
    return retval;
}

The call to CreateFile will invoke the FS Redirector and if the file requested is a system resource and is a 64-bit application with an equivalent 32-bit version, Windows will return the 32-bit version of that application. So debugging notepad.exe in %windir%\system32 will become debugging notepad.exe in %windir%\SysWOW64 which is not what was intended.

The Fix

Luckily for us, Microsoft provides an easy way to bypass the default behavior of File System Redirection. The fix applied to the x96dbg.exe loader is one function that determines whether FS Redirection is supported, and a structure that facilitates disabling this and re-enabling it once done. Two conditions need to be met before we can determine whether FS Redirection can be disabled:

1. Are we running under WoW64 context? (Meaning is this a 32bit application running under 64-bit Windows) and
2. Does this OS support File System Redirection?

Checking for FS Redirection is a simple matter of seeing if the pertinent functions are available:

static BOOL isWowRedirectionSupported()
{

    BOOL bRedirectSupported = FALSE;

    _Wow64DisableRedirection = (LPFN_Wow64DisableWow64FsRedirection)GetProcAddress(GetModuleHandle(TEXT("kernel32")), "Wow64DisableWow64FsRedirection");
    _Wow64RevertRedirection = (LPFN_Wow64RevertWow64FsRedirection)GetProcAddress(GetModuleHandle(TEXT("kernel32")), "Wow64RevertWow64FsRedirection");

    if(!_Wow64DisableRedirection || !_Wow64RevertRedirection)
        return bRedirectSupported;
    else
        return !bRedirectSupported;

}

The structure that encapsulates the calls to these functions is defined like so:

struct RedirectWow
{
    PVOID oldValue = NULL;
    RedirectWow() {}
    bool DisableRedirect()
    {
        if(!_Wow64DisableRedirection(&oldValue))
        {
            return false;
        }
        return true;
    }
    ~RedirectWow()
    {
        if(oldValue != NULL)
        {
            if(!_Wow64RevertRedirection(oldValue))
                MessageBox(nullptr, TEXT("Error in Reverting Redirection"), TEXT("Error"), MB_OK | MB_ICONERROR);
        }
    }
};

Once we’ve determined that our conditions for FS redirection are met, we can disable it using a simple call to the member function DisableRedirect(). This must be invoked before we attempt to determine the files architecture and this can be seen here at Line #412

With these changes, x96dbg.exe can now properly allow a user to Debug redirected 64-bit applications as intended.

References

More reading material on WoW64 can be found from the resources below:

• WoW64 Implementation Details
• File System Redirector
• Wow64DisableWow64FsRedirection function
• Wow64RevertWow64FsRedirection function