Table of Contents for
Learning Linux Binary Analysis

Version ebook / Retour

Cover image for bash Cookbook, 2nd Edition Learning Linux Binary Analysis by Ryan elfmaster O'Neill Published by Packt Publishing, 2016
  1. Cover
  2. Table of Contents
  3. Learning Linux Binary Analysis
  4. Learning Linux Binary Analysis
  5. Credits
  6. About the Author
  7. Acknowledgments
  8. About the Reviewers
  9. www.PacktPub.com
  10. Preface
  11. What you need for this book
  12. Who this book is for
  13. Conventions
  14. Reader feedback
  15. Customer support
  16. 1. The Linux Environment and Its Tools
  17. Useful devices and files
  18. Linker-related environment points
  19. Summary
  20. 2. The ELF Binary Format
  21. ELF program headers
  22. ELF section headers
  23. ELF symbols
  24. ELF relocations
  25. ELF dynamic linking
  26. Coding an ELF Parser
  27. Summary
  28. 3. Linux Process Tracing
  29. ptrace requests
  30. The process register state and flags
  31. A simple ptrace-based debugger
  32. A simple ptrace debugger with process attach capabilities
  33. Advanced function-tracing software
  34. ptrace and forensic analysis
  35. Process image reconstruction – from the memory to the executable
  36. Code injection with ptrace
  37. Simple examples aren't always so trivial
  38. Demonstrating the code_inject tool
  39. A ptrace anti-debugging trick
  40. Summary
  41. 4. ELF Virus Technology �� Linux/Unix Viruses
  42. ELF virus engineering challenges
  43. ELF virus parasite infection methods
  44. The PT_NOTE to PT_LOAD conversion infection method
  45. Infecting control flow
  46. Process memory viruses and rootkits – remote code injection techniques
  47. ELF anti-debugging and packing techniques
  48. ELF virus detection and disinfection
  49. Summary
  50. 5. Linux Binary Protection
  51. Stub mechanics and the userland exec
  52. Other jobs performed by protector stubs
  53. Existing ELF binary protectors
  54. Downloading Maya-protected binaries
  55. Anti-debugging for binary protection
  56. Resistance to emulation
  57. Obfuscation methods
  58. Protecting control flow integrity
  59. Other resources
  60. Summary
  61. 6. ELF Binary Forensics in Linux
  62. Detecting other forms of control flow hijacking
  63. Identifying parasite code characteristics
  64. Checking the dynamic segment for DLL injection traces
  65. Identifying reverse text padding infections
  66. Identifying text segment padding infections
  67. Identifying protected binaries
  68. IDA Pro
  69. Summary
  70. 7. Process Memory Forensics
  71. Process memory infection
  72. Detecting the ET_DYN injection
  73. Linux ELF core files
  74. Summary
  75. 8. ECFS – Extended Core File Snapshot Technology
  76. The ECFS philosophy
  77. Getting started with ECFS
  78. libecfs – a library for parsing ECFS files
  79. readecfs
  80. Examining an infected process using ECFS
  81. The ECFS reference guide
  82. Process necromancy with ECFS
  83. Learning more about ECFS
  84. Summary
  85. 9. Linux /proc/kcore Analysis
  86. stock vmlinux has no symbols
  87. /proc/kcore and GDB exploration
  88. Direct sys_call_table modifications
  89. Kprobe rootkits
  90. Debug register rootkits – DRR
  91. VFS layer rootkits
  92. Other kernel infection techniques
  93. vmlinux and .altinstructions patching
  94. Using taskverse to see hidden processes
  95. Infected LKMs – kernel drivers
  96. Notes on /dev/kmem and /dev/mem
  97. /dev/mem
  98. K-ecfs – kernel ECFS
  99. Kernel hacking goodies
  100. Summary
  101. Index

ptrace requests

The ptrace system call has a libc wrapper like any other system call, so you may include ptrace.h and simply call ptrace while passing it a request and a process ID. The following details are not a replacement for the main pages of ptrace(2), although some descriptions were borrowed from the main pages.

Here's the synopsis:

#include <sys/ptrace.h>
long ptrace(enum __ptrace_request request, pid_t pid,
void *addr, void *data);

ptrace request types

Here is a list of requests that are most commonly used when using ptrace to interact with a process image:

Request

Description

PTRACE_ATTACH

Attach to the process specified in pid, making it a tracee of the calling process. The tracee is sent a SIGSTOP signal, but will not necessarily have stopped by the completion of this call. Use waitpid(2) to wait for the tracee to stop.

PTRACE_TRACEME

Indicates that this process is to be traced by its parent. A process probably shouldn't make this request if its parent isn't expecting to trace it.

PTRACE_PEEKTEXT PTRACE_PEEKDATA PTRACE_PEEKUSER

These requests allow the tracing process to read from a virtual memory address within the traced process image; for instance, we can read the entire text or data segment into a buffer for analysis.

Note that there is no difference in implementation between the PEEKTEXT, PEEKDATA, and PEEKUSER requests.

PTRACE_POKTEXT PTRACE_POKEDATA PTRACE_POKEUSER

These requests allow the tracing process to modify any location within the traced process image.

PTRACE_GETREGS

This request allows the tracing process to get a copy of the traced process's registers. Each thread context has its own register set, of course.

PTRACE_SETREGS

This request allows the tracing process to set new register values for the traced process, for example, modifying the value of the instruction pointer to point to the shellcode.

PTRACE_CONT

This request tells the stopped traced process to resume execution.

PTRACE_DETACH

This request resumes the traced process as well but also detaches.

PTRACE_SYSCALL

This request resumes the traced process but arranges for it to stop at the entrance/exit of the next syscall. This allows us to inspect the arguments for the syscall and even modify them. This ptrace request is heavily used in the code for a program called strace, which is shipped with most Linux distributions.

PTRACE_SINGLESTEP

This resumes the process but stops it after the next instruction. Single stepping allows a debugger to stop after every instruction that is executed. This allows a user to inspect the values of the registers and the state of the process after each instruction.

PTRACE_GETSIGINFO

This retrieves information about the signal that caused the stop. It retrieves a copy of the siginfo_t structure, which we can analyze or modify (with PTRACE_SETSIGINFO) to send back to the tracee.

PTRACE_SETSIGINFO

Sets the signal information. Copies a siginfo_t structure from the address data in the tracer to the tracee. This will affect only signals that would normally be delivered to the tracee and would be caught by the tracer. It may be difficult to tell these normal signals from synthetic signals generated by ptrace() itself (addr is ignored).

PTRACE_SETOPTIONS

Sets the ptrace options from data (addr is ignored). Data is interpreted as a bitmask of options. These are specified by flags in the following section (check out the main pages of ptrace(2) for a listing).

The term tracer refers to the process that is doing the tracing (the one that is invoking ptrace), and the term tracee or the traced means the program that is being traced by the tracer (with ptrace).

Note

The default behavior overrides any mmap or mprotect permissions. This means that a user can write to the text segment with ptrace (even though it is read-only). This is not true if the kernel is pax or grsec and patched with mprotect restrictions, which enforce segment permissions so that they apply to ptrace as well; this is a security feature.

My paper on ELF runtime infection at http://vxheavens.com/lib/vrn00.html discusses some methods to bypass these restrictions for code injection.