Google Interview Question
Site Reliability EngineersCountry: United States
Interview Type: Phone Interview
1> Turn on all the system level log, and see if there is any error message.
2> objdump the binary and see if it is calling some API of other dynamical library, replace those library with debug version and see if it will output any errors.
3> You can also replace the system level library such memory allocation clib with debug version, and dump more information out.
4> Finally you can run the binary in some virtual machine and dump its execution sequence (API call sequence with parameters), and see if it would give you some idea of what is going on.
1. Knowing that the binary does not log to STDOUT or STDERR, you can assume you're debugging on a UNIX-like system. Where might you find the 'system level logs' on the filesystem?
2. Assume that the binary does not have debug flags or a debug version.
3. What command can you run to determine which system level library the blackbox binary is using?
4. What command can you run that would dump the execution sequence?
1> the binary code it does not output anything, does not mean that the system library it may use does not output anything, unless the binary does not call any system API, which is unlikely.
2> Same as 1>. I do not care what is inside the binary code itself, i care what other library or service it may depends on to work. Have u used the dmesg for some system service?
3> If it is calling the dynamical lib of the system, you should see the app call using NM or other binary utility, otherwise system loader would not help it to prepare the .so file when it starts running. Or it may load the .so itself, in this case, it also must call some system API to do it. You should be able figure out a way to got the name of .so it would use, use a debug of that .so if you can.
4> It depends on the virtual machine you are using. I know some virus software company is using virtual machine to perform the analysis.
The whole idea is that unless the software is just a ball of junk code which does not call any external system service and does not use any system resources, you should be able to get some information from its interactivity with the external system service.
A program can only exit in a few ways.
abort();
exit(_N) /_exit / _Exit
return _N
or signaled kills.
abort is obvious
signals encode information in their return codes: 128 + signumber, if you see a number this high it is usually not a programmer manually setting.
All of this is just /hints/ at the solution. If you can run the program in a debugger you can run:
gdb ./program
break _exit (note, not `exit` since this signal is not caught on _exit calls)
run
.... yadda yadda...
bt
For a function which exited in an exit or _exit call:
#0 0x00007ffff72d0af0 in _exit () from /usr/lib/libc.so.6
#1 0x00007ffff7250e2b in __run_exit_handlers () from /usr/lib/libc.so.6
#2 0x00007ffff7250eb5 in exit () from /usr/lib/libc.so.6
#3 0x000000000040065a in test() ()
For a function which exited in a return code:
#0 0x00007ffff72d0af0 in _exit () from /usr/lib/libc.so.6
#1 0x00007ffff7250e2b in __run_exit_handlers () from /usr/lib/libc.so.6
#2 0x00007ffff7250eb5 in exit () from /usr/lib/libc.so.6
#3 0x00007ffff723ab0c in __libc_start_main () from /usr/lib/libc.so.6
Trace all system calls with the appropriate tool (strace/trace/truss, depending on your OS) and look for system calls returning error conditions (missing file or directory, insufficient permissions, network connection refused, ...).
- Cenic April 01, 2013