Scribd Logo
Upload

Welcome to Scribd!

  • 46 views

    Reverse Engineering Malware For Newbies: A Guide For Those of You Who Want To Break Into The Fun World of Malware

    Uploaded by

    abcd
    This document provides an introduction to reverse engineering malware. It outlines tools and techniques for basic assembly, malware analysis, unpacking, debugging, patching, reporting and dynamic/memory analysis. The goal is to equip beginners with foundational skills for breaking down and understanding malware.

    Copyright:

    © All Rights Reserved
    Download as PPTX, PDF, TXT or read online from Scribd

    Reverse Engineering Malware For Newbies: A Guide For Those of You Who Want To Break Into The Fun World of Malware

    Uploaded by

    abcd
    46 views35 pages
    This document provides an introduction to reverse engineering malware. It outlines tools and techniques for basic assembly, malware analysis, unpacking, debugging, patching, reporting and dynamic/memory analysis. The goal is to equip beginners with foundational skills for breaking down and understanding malware.

    Original Title

    RevEngMal.pptx

    Copyright

    © © All Rights Reserved

    Available Formats

    PPTX, PDF, TXT or read online from Scribd

    Did you find this document useful?

    Is this content inappropriate?

    This document provides an introduction to reverse engineering malware. It outlines tools and techniques for basic assembly, malware analysis, unpacking, debugging, patching, reporting and dynamic/memory analysis. The goal is to equip beginners with foundational skills for breaking down and understanding malware.

    Copyright:

    © All Rights Reserved
    Download as PPTX, PDF, TXT or read online from Scribd
    Download as pptx, pdf, or txt
    46 views35 pages

    Reverse Engineering Malware For Newbies: A Guide For Those of You Who Want To Break Into The Fun World of Malware

    Uploaded by

    abcd
    This document provides an introduction to reverse engineering malware. It outlines tools and techniques for basic assembly, malware analysis, unpacking, debugging, patching, reporting and dynamic/memory analysis. The goal is to equip beginners with foundational skills for breaking down and understanding malware.

    Copyright:

    © All Rights Reserved
    Download as PPTX, PDF, TXT or read online from Scribd
    Download as pptx, pdf, or txt
    of 35

    Reverse Engineering

    Malware For Newbies

    A guide for those of you who want to


    break into the fun world of malware.
    What We’re Going To Cover
    • Basic x86/64 ASM • Basic Malware Analysis
    • Tools of the trade • Unpacking 101
    • Setting up an • Dynamic Analysis
    environment • Memory Analysis
    • Intro to the Debugger • Where to get malware
    • Basic Debugger Usage • Help! I’m Stuck!
    • Reporting • Additional Resources
    Basic X86 / 64 ASM
    My good friend Eric Davisson will now speak about the basics of X86 assembly.
    Tools of The Trade
    Every reverse engineer should have these in their bag:

    • Debugger - ollydbg, windbg, syser, IDA, immunity.


    • Disassembler – IDA, olly, immunity, windbg
    • System Monitoring tools - procmon, Process hacker
    • Misc tools - exeinfo, HookAnalyser, Cuckoo Sanbox, gmer,
    rootrepeal, wireshark, volatility, HXD, ilspy, jd-gui, p32dasm, cff
    explorer, winprefetch viewer, autoruns.
    Lot's of tools, but they each serve a purpose. Over time you'll
    become accustomed to each one and wonder what you ever
    did without them.
    Setting Up Your Environment
    • Every Environment should be off your network
    unless absolutely necessary.
    • Use a VM!!!
    • Sandboxie is no substitute
    • Cuckoo works wonders
    • Dual monitors are a godsend
    Enter The Debugger
    The debugger is your best friend. Treat him with respect.
    There are 2 kinds of debuggers - kernel debuggers and
    usermode debuggers.
    • A kernel debugger operates at ring 0 - essentially the driver
    level and has direct access to the kernel.
    • A usermode debugger is the opposite, having only access to
    the usermode space of the operating system. Most of the
    time, this is enough, but not always. In the case of rootkits,
    or even super advanced protection schemes, its preferable
    to step into a kernel mode debugger instead as user mode
    would then become untrustworthy.
    Immunity Break Down
    Immunity Breakdown 2
    Software Breakpoints
    Software breakpoint are CPU interrupts that can be placed
    anywhere in a program.

    When you set a software breakpoint, the debugger simply


    writes the int3 instruction (opcode 0xCC) over the first byte
    of the target instruction. This causes an interrupt 3 to be fired
    whenever execution is transferred to the address you set a
    breakpoint on. When this happens, the debugger takes
    control and swaps the 0xCC opcode byte with the original
    first byte of the instruction so you can continue execution
    without hitting the same breakpoint.

    If the program is not running inside a debugger, the operating


    system will execute default handler structured execption
    handler to terminate the program.
    Hardware Breakpoints
    Hardware breakpoints are different from their software
    counterparts. They use the int1 instruction and are used for single
    stepping in conjunction with debug registers. There are 8 total, but
    only the first 4 are used. DR0-3. Sometimes it is preferable to use
    hardware breakpoints when normal software breakpoints fail such
    as when a program computes a checksum.
    Software breakpoints are inserted into a program (albeit briefly)
    and thus, change the program. Hardware breakpoints however are
    not and rely on those 4 debug registers. This means however you
    are limited to 4 breakpoints which kind of sucks.
    Opcodes

    Opcodes are the


    hexadecimal representation
    of assembly instructions.
    The stuff you'll see if you
    were to view the executable
    in a hex editor. YARA rules
    match opcodes.
    Tracing
    A run trace is an excellent
    debugging technique that
    allows a reverse engineer to
    “trace” execution flow
    based on certain
    parameters. Rather than
    going sequentially through a
    program, one can define a
    base line, and track
    backwards the flow of
    execution by tracing where
    and how a program will run.
    I HAVE THE POWER!!!
    With a debugger you have total
    control over the program and you
    should never forget that. If you see
    a function that looks juicy in IDA,
    but see no plausible way to get
    there via xrefs, nothing is stopping
    you from jumping to it. Just modify
    the program's prolog to jmp
    0xwherever. This works well
    especially if the function takes no
    arguments, otherwise except funky
    output or an app crash.
    Jump2self
    • One of those old school tricks any assembly
    guru will tell you where which you jump 2
    bytes forward and the jump itself is 2 bytes.
    Jump to yourself. An infinite loop. In x86 asm,
    the opcodes are 0xEB 0xFE.
    • From time to time I use this trick, for example
    when a new process is created of the same
    program and I want to continue execution
    before the app is run.
    Basic Debugger Usage
    Load up the program ‘debuggertest1.exe’ from your
    ‘Samples’ folder.
    Patching
    • Patching is the process of adding or removing
    assembly instructions in an exe without source code.
    It could be something as simple as changing
    conditional jmp to always return true/false, or it
    could be something complex such as hollowing out a
    piece of memory and injecting entire functions
    within and calling them.
    • Patching can be done with a hex editor, a debugger,
    or even via the WriteProcessMemory API which is
    how most video game trainers do it.
    Patching P2

    Immunity Debugger has all


    of the necessary capabilities
    to perform on the fly patching.
    Simply right click and choose
    ‘assemble’. Immunity will also
    auto-correct for alignment.

    Saving your patches is as easy


    as right clicking and choosing
    the option 'copy to executable',
    then selecting the sub option
    'all modifications'.
    Basic Malware Analysis
    Here we go over a very basic sample <order_report_id_34872384972398472398.exe>

    It will be in the folder named ‘samples’ on the drives I handed out. Open it up in your
    debugger / VM and we’ll go over it together.
    Reporting
    There is no “typical” reporting structure when it comes to classifying /
    documenting malware, however I like to keep my reports with the most
    essential fields such as the MD5, API’s, C&C IP’s, and IOC’s
    Its good to keep reports descriptive, but do not go overboard.
    Example of one of my reports: http://gironsec.com/typical_report.txt
    Unpacking 101
    • Most malware today is packed in some way to help get
    around AV signature detection
    • There are over 8000 known packers out there, each
    with their own signatures.
    • They can range from simple compression to full on
    encryption / debugger detection and generally make
    the life of the Malware Reverser a pain.
    • Packers are not fool proof – the exe HAS to be
    decrypted / decompressed at SOME point in order to
    run on the OS.
    Unpacking p2
    Before we start to unpack, let's go over how we identify
    a program is packed to begin with.
    • If in IDA we see a bunch of nothing such as hardly any
    imports, lots of BS in the data section.
    • We see odd named section headers. One can use 7zip
    sometimes to view section headers of executables, but
    generally you can do this with CFF explorer or IDA.
    • HookAnalyser comes with a decent packer database
    with something like 4400 different packer signatures.
    • Hands down the best packer identifier in my opinion is
    exeinfo. it beats HookAnalyser's db with a grand total of
    7075 packer signatures. Not only will it tell you who
    packed an exe, it will provide a link for how to unpack it.
    Thanks guys!
    • Once we know what kind of packer is used (if any) we
    can begin our unpacking. Be forewarned through, some
    packers are hard to get around. Really hard. At some
    point it becomes not worth it in which case we might
    want to skip the entire reversing process from a
    debugger level and instead opt for the live analysis tools
    to save time and a major migrane. Don't feel bad if you
    can't get around a packer, it happens to me from time
    to time.
    Unpacking p3
    Pic on the left demonstrates
    HookAnalyzer running an
    analysis on a UPX packed
    binary. It’s not a perfect
    tool, if you’ll notice the false
    positive of supposed NOP
    instructions. The nice thing
    about HookAnalyser is it will
    extract IP addresses for you
    automatically – very useful
    for malware analysis.
    Unpacking p4
    When it comes to identifying
    packers, there is no tool
    better than exeinfo, second
    only to experience.
    It has a packer database with
    which it searches through,
    can scan for media files, IP
    addresses, hostnames, and
    all that other good stuff.
    And its free which makes it
    #1.
    Unpacking demonstration
    Fire up your debuggers. We’ll be going over the ‘Local-Appwizard.exe’ file in the
    ‘Samples’ folder.
    Dynamic Analysis
    • For when you either a) don’t care about the
    inner workings and only want basic info from
    the malware or b) malware packed /encrypted
    tight and you cant get around it.
    • This is where proper usage of procmon /
    wireshark / cuckoo are a godsend. Even if a
    program’s assembly code isn’t available, we
    can still see what its doing and probe it
    blackbox style.
    Memory Analysis
    • HookAnalyzer and Volatility are excellent
    memory analysis tools. HookAnalyzer will do it
    live, but Volatility requires a memory dump
    and has to be done post execution.
    • Process Hacker allows you to dump a running
    process’s memory for inspection and allows for
    filtering and searching. The same can be done
    via your debugger, but this isn’t always
    feasible.
    Hook Analyser
    This tool supports live memory analysis of running processes This makes it indispensable.
    Process Hacker
    Another must have useful tool. Capable of live memory searching and dumping, it
    provides things taskmanager should but doesn’t including disk IO monitoring and
    networking activity monitoring capabilities.
    Volatility In Action
    • <video of me using volatility or I’ll do it live>
    Where Do I Get Malware?
    • http://www.offensivecomputing.net/
    • IRC
    • Reddit / 4chan / Tumblr
    • me ([email protected]),
    • Twitter #malwaremustdie
    • AV companies
    • http://syrianmalware.net
    • Torrents / cracked software / gnutella network.
    • Spam email
    Help! I’m stuck 
    If you ever get stuck on a
    sample, fear not. There are
    communities out there that
    deal with malware forensics.
    Reddit, Exeforums, woodman,
    kernelmode.info, mailing lists,
    and even twitter are excellent
    sources full of people who will
    help. Even IRC still works.
    Additional Resources
    • https://code.google.com/p/corkami/
    • ^^ An excellent resource for info on reversing
    • http://www.woodmann.com/collaborative/tools/ind
    ex.php/Category:RCE_Tools
    • ^^ huge resource for reverse engineering tools
    • http://reddit.com/r/ReverseEngineering/
    • ^^ Still better than /r/malware. Avoid /r/malware
    • http://gironsec.com/blog/
    • ^^ shameless self promotion? No, I got plenty of
    good guides!
    Questions?
    Contact Info
    Name: Joe Giron
    Email: [email protected]
    Phone: 512-902-3787

    You might also like