I have a malware which is checking for keyboard type and locale information.

After that, it creates a service with BinaryPathName as malware's exe address. After creating a service, malware starts it and call StartServiceCtrlDispatcher and kinda stucks there. No further code is evaluated after that.

I have done all this analysis in OllyDbg and ImmDbg.

I want to debug a ServiceMain Function of the service installed by this malware.

After googling a lot, I have found this article. I tried performing the 2nd method "Configure a service to start with the WinDbg debugger attached" but somehow my VM froze.

So my question (in general), How can I debug ServiceMain function of any service?

  • Did you make the service interactive? May 8 '17 at 5:42
  • Yes. By ticking"Allow service to interact with desktop" in service properties > Log on tab.
    – x899
    May 9 '17 at 6:16

This answer ignores the case of shared services, since that is more elaborate and OP did not mention that specifically.

Services are usually normal processes like any other process, however they are executed by the operating system and not the creating/starting process, which may be a cause for some confusion.

How to debug services?

Like any other process, you can either attach to it after its running most (read: all decent) debuggers support attaching (and putting protected process services aside) can be attached to. If you fear you'd miss some crucial part of the execution before you get to attach you could use tools that let you debug spawned processes. Ollydbg supports that as well as x64. And Rohitab's API Monitor has decent capabilities when it comes to detecting and attaching to new processes.

but why execution stopped after calling StartServiceCtrlDispatcher?

However, when dealing with most malware samples it'll be good enough to just create the process yourself and skip any service related functions.

It seems that your specific issue is with the execution of the StartServiceCtrlDispatcher function, which is the function called by the service entry point in order to register connect back to the service manager. That connection to the service manager is how the service reports it has be successfully load and functional, how it gets commands to shutdown, restart etc.

StartServiceCtrlDispatcher has a single parameter which is the SERVICE_TABLE_ENTRY structure. It has two members, the second of which is of type LPSERVICE_MAIN_FUNCTION and called lpServiceProc. That parameter is actually a function pointer to the ServiceMain function. Pick it up, parse the structure and you'll get to where execution will be given back to the service in order to continue execution!

VM, why you no run?!

Well, unfortunately you did not provide enough details to diagnose that one.


I prefer to use HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\Debugger see more here. To specify the debugger process, which starts as soon as the service process does. So that I'm able to set up the breakpoints at the very beginning.


Others have already described elegant ways of doing this, so I'll post a dirty (but very versatile) trick:

Open the binary in a hex editor and replace the first two bytes of the function you want to debug with EB FE (a jump to itself). Run the binary normally (e.g. start the service) and once the process starts consuming 100% CPU (well, 100% of one core), attach the debugger, put a break point at your little infinite loop, hit run, patch in the original bytes and you're ready to debug.

It's really ugly and quite impractical, but it will work with everything from DLLs to drivers.

Your Answer

