[AaLl86]

Hi all!
After release a draft of personal AntiTdl 3 solution, I'm now researching on TDL4.... I would like to know if some of you is able to Kernel Debug a TDL4 infected 64 bit system.
For who that doesn't know, TDL4 replace "KdDebuggerInitialize1" functions and many others of "kdcom.dll", the library that is responsable to connect Serial Debug, making impossible to Debug with serial port.
Anyone know if USB2 Debug relies on "kdcom.dll"? Which is the solution? Perhaps replacing "ldr64" file in TDL4 encrypted file System (assuming that encrypting process is reversible)?

Thanks in advice
Andrea :D

[EP_X0FF]

Hello,

Perhaps replacing "ldr64" file in TDL4 encrypted file System (assuming that encrypting process is reversible)?

ldr64 is fake KD communications dll. If you take a look on KdDebuggerInitialize1 function you will find that it perform loading for drv64 TDL driver (actual rootkit).

[AaLl86]

Yes, surely.... but the problem is that with that fake file i can't connect my debugger. If i replace entire ldr64 it will not produce a bigger problem relating rootkit loading (like debug system without rootkit active in memory)? What kind of solution do you found?

Thanks.
Regards, Andrea

[rossetoecioccolato]

Is ldr64 stay loaded after the system starts up? Reason I ask is because I have a memory dump that someone gave me which is supposed to be TDL4 but the real kdcom is loaded. I assumed that the real kdcom was restored once ldr64 was no longer needed (would make sense). But maybe it is something else.

[frank_boldewin]

you can use bochsgdb or qemu debugger for the initial part like mbr and ldr debugging.
for mbr debugging don't miss to switch to 16bit mode, before starting your analysis.

the main rootkit can be better analyzed right after infection, meaning before the reboot, when windbg works properly or statically with ida of course.

[dphrag]

Hmm i cant seem to get to ldr32/ldr64 using qemu has anyone been able to ?