version 1.1.7 - Command "allocex" unregistered

[warp123]

I have just installed the 1.1.7 version with x64dbg, using Python 3.10.11 (both 64 and 32 bit). After installing labeless in both versions, debugger seems to be working properly, but as soon as I exit debugger, the program is freezing and I get the following error on status bar.
[PLUGIN, Labeless] Command "allocex" unregistered!

I have to kill the x64dbg from process list every time.

Has anyone faced this problem. Any clues on how to tackle it?

[jaimecai]

same

[a1ext]

I need more information, could you attach to the debugger with an another debugger and give me a stack trace (preload all system libraries pdbs to demangle names), so then maybe it will give some clue why it freezes?

[warp123]

Additional debugging information for the x64dbg/x32dbg freeze on exit

I did some further debugging with WinDbg, as requested, and the message

[PLUGIN, Labeless] Command "allocex" unregistered!

does not appear to be the actual error.
It looks like this message is printed during normal command unregistration. The real problem happens immediately afterwards, during Labeless shutdown, when Python 3.10 is finalized.

Environment tested

I reproduced and debugged this mainly with the 32-bit debugger because it was easier to get a clean WinDbg trace:

Debugger: x32dbg.exe
Plugin: labeless_x64dbg.dp32
Labeless version: 1.1.7.0
Python: C:\Python310-32\python310.dll
Python version: 3.10.11

The original visible problem is the same as in the 64-bit case: x64dbg/x32dbg freezes forever on exit and has to be killed from Task Manager.

Hang stack

When the debugger is frozen on exit, the stuck thread is inside Python finalization. The relevant part of the stack is:

ntdll!NtWaitForSingleObject
KERNELBASE!WaitForSingleObjectEx
python310!PyThread_acquire_lock_timed+0x126
...
python310!Py_FinalizeEx+0x2e
labeless_x64dbg+0x2a71d
labeless_x64dbg+0x29aad
labeless_x64dbg!plugstop+0x4b
x32dbg!...

So the freeze is not caused by allocex itself. The plugin reaches plugstop(), then calls into Python finalization, and Python waits forever on a lock.

Thread mismatch: Python init vs finalization

also set breakpoints on Python initialization and finalization:

bu python310!Py_InitializeFromConfig
bu python310!Py_FinalizeEx
g

At Python initialization:

python310!Py_InitializeFromConfig
python310!Py_InitializeEx+0x61
labeless_x64dbg+0x29b4c
labeless_x64dbg!pluginit+0xb2
x32dbg!...

The OS thread id was:

INIT TID = 8fb8

At Python finalization:

python310!Py_FinalizeEx
labeless_x64dbg+0x2a71d
labeless_x64dbg+0x29aad
labeless_x64dbg!plugstop+0x4b
x32dbg!DllMain+...
x32dbg!dbg_dbgexitsignal+0x6a
x32gui!...
Qt5Core!QThread::start+0x334
MSVCR120!_callthreadstartex
MSVCR120!_threadstartex
KERNEL32!BaseThreadInitThunk
ntdll!...

The OS thread id was:

FINALIZE TID = 8a48

So Python is initialized from one thread:

INIT TID     = 8fb8

but finalized from another thread:

FINALIZE TID = 8a48

This looks like the root cause. In Python 3.10, Py_Finalize() calls Py_FinalizeEx(), and Python shutdown runs threading._shutdown(), which can wait on thread-state locks. Finalizing Python from a non-main / different thread appears to be what causes the deadlock.

Conclusion

The freeze seems to be caused by Python 3.10 finalization being executed from a different thread than the one that initialized Python. The allocex unregistered message is only the last visible status message before the deadlock, not the actual failure.

[a1ext]

hi, @warp123, it seems like this branch has already fix of your issue at commit e69d10c of ida9_2 branch, the easiest way is to check it out and build locally.

As you need only x64dbg plugin. seems like build artifacts was expired, I can share my binary to let you try it, drive link
please let me know if the issue is gone

[warp123]

Hi @a1ext,

I’ve just tested the compiled binaries you sent, and I can confirm that the issue has been mitigated.
Maybe this fix could be included in the main release binaries.

In any case, thanks a lot for your help.

[warp123]

Hi @a1ext

A follow up on my previous post. While the 64 bit plugin is working fine the 32 bit binary is not. The following error is thrown during the initialization of the debugger

Do you have any ideas on that?

[warp123]

Hi @a1ext,

I investigated the 32-bit startup error further, and it seems to be caused by an import-name / symbol decoration mismatch between the rebuilt "dp32" plugin and "x32bridge.dll".

The failing 32-bit plugin imports the decorated stdcall names:

_BridgeLoadLibraryCheckedW@8
_BridgeLoadLibraryCheckedA@8

but my local "x32bridge.dll" exports the undecorated names:

BridgeLoadLibraryCheckedW
BridgeLoadLibraryCheckedA

This explains the startup error:

The procedure entry point _BridgeLoadLibraryCheckedW@8 could not be located

The 64-bit plugin does not have this issue because the imported names and exported names match there:

x64bridge.dll exports:
BridgeLoadLibraryCheckedW
BridgeLoadLibraryCheckedA

dp64 imports:
BridgeLoadLibraryCheckedW
BridgeLoadLibraryCheckedA

It looks like the rebuilt 32-bit plugin was linked in a way that expects decorated x86 stdcall import names, while the available "x32bridge.dll" exports undecorated names.

After adjusting the 32-bit plugin import names to use the undecorated exports, the startup error disappeared.

I hope this will be helpful in case you release an update.

[a1ext]

maybe api has changed since I updated the x64dbg sdk last time