Breaking into a forked child in gdb

Disclaimer: I am a noob at gdb.

To use intel syntax and display the current instruction:

(gdb) set disassembly-flavor intel
(gdb) display/i $pc

Next, setting a breakpoint where 0xdeadbeef is the address of call fork instruction. Get gdb to follow fork child instead of parent, which is the default behaviour. Step over the fork to land in the child process:

(gdb) break *0xdeadbeef
(gdb) run
(gdb) set follow-fork-mode child
(gdb) nexti

Bonus, setting a rwx data breakpoint:

(gdb) awatch *0xbabecafe
(gdb) continue

Now I am not sure which is the greater evil, gdb or windbg…


Loading symbols in IDA Pro

IDA Pro has included symbol loading facility some time back. But different installations had yield different results; sometimes symbol loading works, sometimes it didn’t. This has led me to scratch my head for an extended period of time until now.

What happened is when IDA ask the following:

IDA Pro has determined that the input file was linked with debug information. Do you want to look for the corresponding PDB file at the local symbol store and the Microsoft Symbol Server?

it made use of its dbghelp.dll and symsrv.dll to load the symbols. We are supposed to accept Microsoft’s terms for using their symbols, but since symsrv.dll is used directly by the plugin the prompt to accept the terms is not displayed, the license cannot be accepted, and hence the symbol loading fails.

The solution is to include an empty symsrv.yes file alongside symsrv.dll in IDA’s directory to indicate that we’d gladly accept the terms that never appear.

Endpoint hinders windbg

Was playing around with symantec endpoint’s network threat protection just now. It is quite a mouthful but nothing really spectacular. In fact, certain settings actually broke compatibility with other apps. An example is the stealth mode web browsing, which broke windbg’s functionality of retrieving symbols from microsoft’s symbol servers (and probably mozilla’s).

Blames myself for being overzealous on enabling those features; should have known better. Wonder what will break next lol.

Symbol packages are non-cumulative

This is something that I missed on windows symbols download page:

Symbol packages are non-cumulative unless otherwise noted, so if you are using an SP2 Windows release, you will need to install the symbols for the original RTM version and for SP1 before you install the symbols for SP2.

Interesting. So are symbols packages for vista cumulative? SP2 is 281MB while SP1 is 267MB. Looking at the filenames in the package, both packages have symbols which are distinct to each service pack. Does that mean some files are removed for good when SP2 is installed or what? I have no idea since SP2 is not publicly available (and I’m neither a msdn nor technet plus subscriber). And the idea of installing symbols for RTM, SP1 and SP2 is, well, not awesome.

As a side note, although Windows Vista SP2 is not yet publicly available, its symbols are. And set the environment variable for best effect*:

Set _NT_SYMBOL_PATH = c:\windows\symbols;SRV*c:\localsymbols*

Set _NT_SYMBOL_PATH = c:\windows;SRV*c:\localsymbols*

EDIT: realised windbg searches in the symbols subdirectory of the symbol path, and edited for clarity

*best effect: use local symbols if available; download to local otherwise

Download Windows Symbol Packages
Windows Vista SP2 and Windows Server 2008 SP2 x86 retail symbols(281 MB)