Practical Malware Analysis: Ch 9: OllyDbg

627 views

Published on

Slides for a college lecture; more information here https://samsclass.info/126/126_S16.shtml

Published in: Education
0 Comments
4 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
627
On SlideShare
0
From Embeds
0
Number of Embeds
6
Actions
Shares
0
Downloads
32
Comments
0
Likes
4
Embeds 0
No embeds

No notes for slide

Practical Malware Analysis: Ch 9: OllyDbg

  1. 1. Practical Malware Analysis Ch 9: OllyDbg Last modified 3-21-16
  2. 2. History • OllyDbg was developed more than a decade ago • First used to crack software and to develop exploits • The OllyDbg 1.1 source code was purchased by Immunity and rebranded as Immunity Debugger • The two products are very similar
  3. 3. Don't Use OllyDbg 2!
  4. 4. Loading Malware
  5. 5. Ways to Debug Malware • You can load EXEs or DLLs directly into OllyDbg • If the malware is already running, you can attach OllyDbg to the running process
  6. 6. Opening an EXE • File, Open • Add command-line arguments if needed • OllyDbg will stop at the entry point, WinMain, if it can be determined • Otherwise it will break at the entry point defined in the PE Header – Configurable in Options, Debugging Options
  7. 7. Attaching to a Running Process • File, Attach • OllyDbg breaks in and pauses the program and all threads – If you catch it in DLL, set a breakpoint on access to the entire code section to get to the interesting code
  8. 8. Reloading a File • Ctrl+F2 reloads the current executable • F2 sets a breakpoint
  9. 9. The OllyDbg Interface
  10. 10. Disassembler Highlight: next instruction to be executed Registers Stack Memory dump
  11. 11. Modifying Data • Disassembler window – Press spacebar • Registers or Stack – Right-click, modify • Memory dump – Right-click, Binary, Edit – Ctrl+G to go to a memory location – Right-click a memory address in another pane and click "Follow in dump"
  12. 12. Memory Map View, Memory Map
  13. 13. • EXE and DLLs are identified • Double-click any row to show a memory dump • Right-click, View in Disassembler
  14. 14. Rebasing • Rebasing occurs when a module is not loaded at its preferred base address • PE files have a preferred base address – The image base in the PE header – Usually the file is loaded at that address – Most EXEs are designed to be loaded at 0x00400000 • EXEs that support Address Space Layout Randomization (ASLR) will often be relocated
  15. 15. DLL Rebasing • DLLs are more commonly relocated – Because a single application may import many DLLs – Windows DLLs have different base addresses to avoid this – Third-party DLLs often have the same preferred base address
  16. 16. Absolute v. Relative Addresses • The first 3 instructions will work fine if relocated because they use relative addresses • The last one has an absolute address that will be wrong if the code is relocated
  17. 17. Fix-up Locations • Most DLLS have a list of fix-up locations in the .reloc section of the PE header – These are instructions that must be changed when code is relocated • DLLs are loaded after the EXE and in any order • You cannot predict where DLLs will be located in memory if they are rebased
  18. 18. DLL Rebasing • DLLS can have their .reloc removed – Such a DLL cannot be relocated – Must load at its preferred base address • Relocating DLLs is bad for performance – Adds to load time – So good programmers specify non-default base addresses when compiling DLLs
  19. 19. Example of DLL Rebasing
 Olly Memory Map • DLL-A and DLL-B prefer location 0x100000000
  20. 20. IDA Pro • IDA Pro is not attached to a real running process • It doesn't know about rebasing • If you use OllyDbg and IDA Pro at the same time, you may get different results – To avoid this, use the "Manual Load" option in IDA Pro – Specify the virtual base address manually
  21. 21. Viewing Threads and Stacks • View, Threads • Right-click a thread to "Open in CPU", kill it, etc.
  22. 22. Each Thread Has its Own Stack • Visible in Memory Map
  23. 23. Executing Code
  24. 24. Run and Pause • You could Run a program and click Pause when it's where you want it to be • But that's sloppy and might leave you somewhere uninteresting, such as inside library code • Setting breakpoints is much better
  25. 25. Run and Run to Selection • Run is useful to resume execution after hitting a breakpoint • Run to Selection will execute until just before the selected instruction is executed – If the selection is never executed, it will run indefinitely
  26. 26. Execute till Return • Pauses execution until just before the current function is set to return • Can be useful if you want to finish the current function and stop • But if the function never ends, the program will continue to run indefinitely
  27. 27. Execute till User Code • Useful if you get lost in library code during debugging • Program will continue to run until it hit compiled malware code – Typically the .text section
  28. 28. Stepping Through Code • F7 -- Single-step (also called step-into) • F8 -- Step-over – Stepping-over means all the code is executed, but you don't see it happen • Some malware is designed to fool you, by calling routines and never returning, so stepping over will miss the most important part
  29. 29. Breakpoints
  30. 30. Types of Breakpoints • Software breakpoints • Hardware breakpoints • Conditional breakpoints • Breakpoints on memory • F2 – Add or remove a breakpoint
  31. 31. Viewing Active Breakpoints • View, Breakpoints, or click B icon on toolbar
  32. 32. Saving Breakpoints • When you close OllyDbg, it saves your breakpoints • If you open the same file again, the breakpoints are still available
  33. 33. Software Breakpoints • Useful for string decoders • Malware authors often obfuscate strings – With a string decoder that is called before each string is used
  34. 34. String Decoders • Put a breakpoint at the end of the decoder routine • The string becomes readable on the stack
 Each time you press Play in OllyDbg, the program will execute and will break when a string is decoded for use • This method will only reveal strings as they are used
  35. 35. Conditional Breakpoints • Breaks only when a condition is true • Ex: Poison Ivy backdoor – Poison Ivy allocates memory to house the shellcode it receives from Command and Control (C&C) servers – Most memory allocations are for other purposes and uninteresting – Set a conditional breakpoint at the VirtualAlloc function in Kernel32.dll
  36. 36. Normal Breakpoint • Put a standard breakpoint at the start of the VirtualAlloc function • Here's the stack when it hits, showing five items: – Return address – 4 parameters (Address, Size, AllocationType, Protect)
  37. 37. Conditional Breakpoint
  38. 38. Hardware Breakpints • Don't alter code, stack, or any target resource • Don't slow down execution • But you can only set 4 at a time • Click Breakpoint, "Hardware, on Execution" • You can set OllyDbg to use hardware breakpoints by default in Debugging Options – Useful if malware uses anti-debugging techniques
  39. 39. Memory Breakpoints • Code breaks on access to specified memory location • OllyDbg supports software and hardware memory breakpoints • Can break on read, write, execute, or any access • Right-click memory location, click Breakpoint, "Memory, on Access"
  40. 40. Memory Breakpoints • You can only set one memory breakpoint at a time • OllyDbg implements memory breakpoints by changing the attributes of memory blocks • This technique is not reliable and has considerable overhead • Use memory breakpoints sparingly
  41. 41. When is a DLL Used?
  42. 42. Loading DLLs
  43. 43. loaddll.exe • DLLs cannot be executed directly • OllyDbg uses a dummy loaddll.exe program to load them • Breaks at the DLL entry point DLLMain once the DLL is loaded • Press Play to run DLLMain and initialize the DLL for use
  44. 44. Demo • Get OllyDbg 1.10, NOT 2.00 or 2.01 – Link Ch 9a • Use Win XP or Win 7 • In OllyDbg, open c:windows system32ws2_32.dll • Debug, Call DLL Export – it fails • Reload the DLL, click Run button once • Debug, Call DLL Export – now it works
  45. 45. Call Exports in ws2_32.dll
  46. 46. ntohl • Converts a 32-bit number from network to host byte order • Click argument 1, type in 7f000001 – 127.0.0.1 in "network" byte order • Click "Follow in Disassembler" to see the code • Click "Call" to run the function • Answer in EAX
  47. 47. Don't Use OllyDbg 2!
  48. 48. Tracing
  49. 49. Tracing • Powerful debugging technique • Records detailed execution information • Types of Tracing – Standard Back Trace – Call Stack Trace – Run Trace
  50. 50. Standard Back Trace • You move through the disassembler with the Step Into and Step Over buttons • OllyDbg is recording your movement • Use minus key on keyboard to see previous instructions – But you won't see previous register values • Plus key takes you forward – If you used Step Over, you cannot go back and decide to step into
  51. 51. Call Stack Trace • Views the execution path to a given function • Click View, Call Stack • Displays the sequence of calls to reach your current location
  52. 52. Run Trace • Code runs, and OllyDbg saves every executed instruction and all changes to registers and flags • Highlight code, right-click, Run Trace, Add Selection • After code executes, View, Run Trace – To see instructions that were executed – + and - keys to step forward and backwards
  53. 53. Trace Into and Trace Over • Buttons below "Options" • Easier to use than Add Selection • If you don't set breakpoints, OllyDbg will attempt to trace the entire program, which could take a long time and a lot of memory
  54. 54. Debug, Set Condition • Traces until a condition hits • This condition catches Poison Ivy shellcode, which places code in dynamically allocated memory below 0x400000
  55. 55. Exception Handling
  56. 56. When an Exception Occurs • OllyDbg will stop the program • You have these options to pass the exception into the program: – Shift+F7 Step into exception – Shift+F8: Step over exception – Shift+F9: Run exception handler • Often you just ignore all exceptions in malware analysis – We aren't trying to fix problems in code
  57. 57. Patching
  58. 58. Binary Edit
  59. 59. Fill • Fill with 00 • Fill with NOP (0x90) – Used to skip instructions – e.g. to force a branch
  60. 60. Saving Patched Code • Right-click disassembler window after patching – Copy To Executable, All Modifications, Save File – Copy All • Right-click in new window – Save File
  61. 61. Analyzing Shellcode Undocumented technique
  62. 62. Easy Way to Analyze Shellcode • Copy shellcode from a hex editor to clipboard • Within memory map, select a region of type "Priv" (Private memory) • Double-click rows in memory map to show a hex dump – Find a region of hundreds of consecutive zeroes • Right-click chosen region in Memory Map, Set Access, Full Access (to clear NX bit)
  63. 63. Analyzing Shellcode • Highlight a region of zeroes, Binary, Binary Paste • Set EIP to location of shellcode – Right-click first instruction, New Origin Here
  64. 64. Assistance Features
  65. 65. Log • View, Log – Shows steps to reach here
  66. 66. Watches Window • View, Watches – Watch the value of an expression – Press SPACEBAR to set expression – OllyDbg Help, Contents • Instructions for Evaluation of Expressions
  67. 67. Labeling • Label subroutines and loops – Right-click an address, Label
  68. 68. Plug-ins
  69. 69. Recommended Plugins • OllyDump – Dumps debugged process to a PE file – Used for unpacking • Hide Debugger – Hides OllyDbg from debugger detection • Command Line – Control OllyDbg from the command line – Simpler to just use WinDbg • Bookmarks – Included by default in OllyDbg – Bookmarks memory locations
  70. 70. Scriptable Debugging
  71. 71. Immunity Debugger (ImmDbg) • Unlike OllyDbg, ImmDbg employs python scripts and pas an easy-to-use API • Scripts are located in the PyCommands subdirectory under the install directory of ImmDbg • Easy to create custom scripts for ImmDbg

×