[Thanat0S]

so, how to can I debugging a driver without symbols, I have a malware sample which I want to debug it on my vm+windbg but it has a debug section(symbols) and when
I set a breakpoint in the entrypoint, thw windbg shows this:

*** ERROR: Module load completed but symbols could not be loaded for MALWARESAMPLE.sys
Breakpoint 2's offset expression evaluation failed.
Check for invalid symbols or bad syntax.
WaitForEvent failed
nt!DebugService2+0x11:
8052e4f5 5d pop ebp


dis:

8052e4e4 8bff mov edi,edi
8052e4e6 55 push ebp
8052e4e7 8bec mov ebp,esp
8052e4e9 8b4510 mov eax,dword ptr [ebp+10h]
8052e4ec 8b4d08 mov ecx,dword ptr [ebp+8]
8052e4ef 8b550c mov edx,dword ptr [ebp+0Ch]
8052e4f2 cd2d int 2Dh
8052e4f4 cc int 3
8052e4f5 5d pop ebp ; EIP
8052e4f6 c20c00 ret 0Ch
8052e4f9 cc int 3
8052e4fa cc int 3
8052e4fb cc int 3

even I can not debug this driver in release mode ( without debug section, driver symbols ):

#include <ntddk.h>
NTSTATUS DriverEntry(PDRIVER_OBJECT DriverObject, PUNICODE_STRING RegistryPath)
{
DbgPrint("Hello World\n");
return STATUS_SUCCESS;
}

I set the breakpoint and windbg never stops :(
I can only debugging with symbols and facts by me. why? help please

[xdeadcode]

Hi ThanatOS,

Can you specify how you set a breakpoint?
Can you specify how exactly you compile 'release mode'? What of flags you use?
You don't need symbols to debug a driver. It just makes debugging little bit harder.

Best regards,

[Thanat0S]

Hi ThanatOS,

Can you specify how you set a breakpoint?
Can you specify how exactly you compile 'release mode'? What of flags you use?
You don't need symbols to debug a driver. It just makes debugging little bit harder.

Best regards,

witj bu command. but my windbg does not stops when I set a breakpoint on the EntryPoint ( bu sample!DriverEntry ) it's normal?

[xdeadcode]

Hi ThanatOS,

You have to understand that windbg's bu works only with symbols (http://msdn.microsoft.com/en-us/library ... s.85).aspx). No symbols, no windbg break in.
Remember that malware authors do their best to make analysis harder, so you can't expect that during analysis you will have everything inlcuded as in normal driver that you compiled.

Summarizing to achieve your goal (I assume you want to break in on driver entry point) use normal breakpoints (those resolved to addresses).

Best regards,