🌔

OpenSecurity.info - Life of Binaries

Apr 12, 202416 min read

Source

Class Scope

Tl;dr of this course

Go read the slides instead >:V

Different target binary formats

  • Executable (.exe on Windows, no suffix on Linux): A program which will either stand completely on its own, containing all code necessary for its execution, or which will request external libraries that it will depend on
  • Dynamic Linked Library (.dll) on Windows == Shared Library aka Shared Object (.so) on Linux
    • neded to be loaded by some other program to run
    • the library may have codes that will also be automatically executed at load time (DllMain() on Windows and init() on Linux)
  • Static Library
    • .lib on Windows
    • .a on Linux
    • a collection of object files, with specific header info to describe the organization of the files
    • will not execute anything on its own, only provides code to other program

Common Windows PE File Extensions

  • .exe
  • .dll
  • .sys
  • .ocx
  • .cpl
  • .scr
  • Note: .lib files don’t have “DOS Header and then PE Header” format like the rest

PE File structure - WINNT.h

Terminology

  • RVA - Relative Virtual Address: indicates some displacement relative to the start (base) of a binary in memory
  • AVA - Absolute Virtual Address (sometimes just Virtual Address): a specific address memory where something can be found
    • example: if base is 0x80000000, and the AVA was 0x80001000, the RVA would be 0x1000
    • if the base is 0x80000000, and AVA was 0xC123000F, then RVA would be 0x4123000f
    • RVA = VA - base
    • Windows use RVA exensively in PE Format, unlike ELF which uses just AVA
  • Windows uses:
    • CHAR = character = 1 byte
    • WORD = word = 2 bytes
    • SHORT = short integer = 2 bytes
    • DWORD = double-word = 4 bytes
    • LONG = long integer = 4 bytes
    • QWORD = quad-word = 8 bytes
    • LONGLONG = long long integer = 8 bytes

_IMAGE_DOS_HEADER - MS-DOS File Header

typedef struct _IMAGE_DOS_HEADER {      // DOS .EXE header
    WORD   e_magic;                     // Magic number
    WORD   e_cblp;                      // Bytes on last page of file
    WORD   e_cp;                        // Pages in file
    WORD   e_crlc;                      // Relocations
    WORD   e_cparhdr;                   // Size of header in paragraphs
    WORD   e_minalloc;                  // Minimum extra paragraphs needed
    WORD   e_maxalloc;                  // Maximum extra paragraphs needed
    WORD   e_ss;                        // Initial (relative) SS value
    WORD   e_sp;                        // Initial SP value
    WORD   e_csum;                      // Checksum
    WORD   e_ip;                        // Initial IP value
    WORD   e_cs;                        // Initial (relative) CS value
    WORD   e_lfarlc;                    // File address of relocation table
    WORD   e_ovno;                      // Overlay number
    WORD   e_res[4];                    // Reserved words
    WORD   e_oemid;                     // OEM identifier (for e_oeminfo)
    WORD   e_oeminfo;                   // OEM information; e_oemid specific
    WORD   e_res2[10];                  // Reserved words
    LONG   e_lfanew;                    // File address of new exe header
  } IMAGE_DOS_HEADER, *PIMAGE_DOS_HEADER;

We’ll focus on

  • e_magic
    • set to ASCII ‘MZ’, which is from Mark Zbikowski, who developed MS-DOS
    • most Windows program, the DOS header contains a stub DOS Program which prints out “THis program cannot be run in DOS mode”, that’s it :v
  • e_lfanew
    • specify file offset where PE Header can be found (some sort of file pointer)

_IMAGE_NT_HEADERS - PE Header

typedef struct _IMAGE_NT_HEADERS64 {
    DWORD Signature;
    IMAGE_FILE_HEADER FileHeader;
    IMAGE_OPTIONAL_HEADER64 OptionalHeader;
} IMAGE_NT_HEADERS64, *PIMAGE_NT_HEADERS64;
 
typedef struct _IMAGE_NT_HEADERS {
    DWORD Signature;
    IMAGE_FILE_HEADER FileHeader;
    IMAGE_OPTIONAL_HEADER32 OptionalHeader;
} IMAGE_NT_HEADERS32, *PIMAGE_NT_HEADERS32;

Note: this is a bit different from OpenRCE’s PE Format references and the slide because I take it directly from mingw64’s source code

  • Signature == 0x00004550 or ASCII string “PE” in little endian order in DWORD
  • Just a holder for 2 other embedded structs

_IMAGE_FILE_HEADER - File Header

typedef struct _IMAGE_FILE_HEADER {
    WORD    Machine;
    WORD    NumberOfSections;
    DWORD   TimeDateStamp;
    DWORD   PointerToSymbolTable;
    DWORD   NumberOfSymbols;
    WORD    SizeOfOptionalHeader;
    WORD    Characteristics;
} IMAGE_FILE_HEADER, *PIMAGE_FILE_HEADER;
  • Machine: specify what architecture this is supposed to run on(ex: 32bits or 64bits)
    • 014C == x86 binary, aka PE32 binary
    • 8664 == x64 binary, aka PE32+ binary
  • NumberOfSections: tells you how many section headers there will be later
  • TimeDateStamp: Unix timestamp
    • second since epoc, epoc is 00:00:00 UTC on January 1st 1970
    • set at link time
    • can be used to track how many version there is (Investigation technique)
    • can be used to know when a file was linked (forensic technique)
  • Characteristics: specify things like
#define IMAGE_FILE_EXECUTABLE_IMAGE          0x0002  // File is executable  (i.e. no unresolved externel references).
#define IMAGE_FILE_LINE_NUMS_STRIPPED        0x0004  // Line nunbers stripped from file.
#define IMAGE_FILE_LARGE_ADDRESS_AWARE       0x0020  // App can handle >2gb addresses
#define IMAGE_FILE_32BIT_MACHINE             0x0100  // 32 bit word machine.
#define IMAGE_FILE_SYSTEM                    0x1000  // System File.
#define IMAGE_FILE_DLL                       0x2000  // File is a DLL.
  • SizeOfOptionalHeader can theoretically be shrunk to exclude “data directory” field, which the linker doesn’t need to include.
  • PointerToSymbolTable, NumberOfSymbols not used anymore
  • Note that all these fields can be manipulated by malware makers when dealing with malwares

BinaryScavengerHunt

This game is in Python 2.7, which is a very old version of Python.

note to self:

  • rewrite the code in python 3.x if you have time
  • write a guide to setup virtual environment in Python 2.7 or any Python version for different purposes using PyEnv

_IMAGE_OPTIONAL_HEADER

typedef struct _IMAGE_OPTIONAL_HEADER {
    //
    // Standard fields.
    //
 
    WORD    Magic;
    BYTE    MajorLinkerVersion;
    BYTE    MinorLinkerVersion;
    DWORD   SizeOfCode;
    DWORD   SizeOfInitializedData;
    DWORD   SizeOfUninitializedData;
    DWORD   AddressOfEntryPoint;
    DWORD   BaseOfCode;
    DWORD   BaseOfData;
 
    //
    // NT additional fields.
    //
 
    DWORD   ImageBase;
    DWORD   SectionAlignment;
    DWORD   FileAlignment;
    WORD    MajorOperatingSystemVersion;
    WORD    MinorOperatingSystemVersion;
    WORD    MajorImageVersion;
    WORD    MinorImageVersion;
    WORD    MajorSubsystemVersion;
    WORD    MinorSubsystemVersion;
    DWORD   Win32VersionValue;
    DWORD   SizeOfImage;
    DWORD   SizeOfHeaders;
    DWORD   CheckSum;
    WORD    Subsystem;
    WORD    DllCharacteristics;
    DWORD   SizeOfStackReserve;
    DWORD   SizeOfStackCommit;
    DWORD   SizeOfHeapReserve;
    DWORD   SizeOfHeapCommit;
    DWORD   LoaderFlags;
    DWORD   NumberOfRvaAndSizes;
    IMAGE_DATA_DIRECTORY DataDirectory[IMAGE_NUMBEROF_DIRECTORY_ENTRIES];
} IMAGE_OPTIONAL_HEADER32, *PIMAGE_OPTIONAL_HEADER32;
typedef struct _IMAGE_OPTIONAL_HEADER64 {
    WORD        Magic;
    BYTE        MajorLinkerVersion;
    BYTE        MinorLinkerVersion;
    DWORD       SizeOfCode;
    DWORD       SizeOfInitializedData;
    DWORD       SizeOfUninitializedData;
    DWORD       AddressOfEntryPoint;
    DWORD       BaseOfCode;
    ULONGLONG   ImageBase;
    DWORD       SectionAlignment;
    DWORD       FileAlignment;
    WORD        MajorOperatingSystemVersion;
    WORD        MinorOperatingSystemVersion;
    WORD        MajorImageVersion;
    WORD        MinorImageVersion;
    WORD        MajorSubsystemVersion;
    WORD        MinorSubsystemVersion;
    DWORD       Win32VersionValue;
    DWORD       SizeOfImage;
    DWORD       SizeOfHeaders;
    DWORD       CheckSum;
    WORD        Subsystem;
    WORD        DllCharacteristics;
    ULONGLONG   SizeOfStackReserve;
    ULONGLONG   SizeOfStackCommit;
    ULONGLONG   SizeOfHeapReserve;
    ULONGLONG   SizeOfHeapCommit;
    DWORD       LoaderFlags;
    DWORD       NumberOfRvaAndSizes;
    IMAGE_DATA_DIRECTORY DataDirectory[IMAGE_NUMBEROF_DIRECTORY_ENTRIES];
} IMAGE_OPTIONAL_HEADER64, *PIMAGE_OPTIONAL_HEADER64;
  • The first thing about Optional Header is that it’s not Optional
  • Magic is the true determinant of PE32 or PE32+
    • 0x10B == 32bits, or PE32
    • 0x20B == 64bits, or PE32+
  • AddressOfEntryPoint: specifies the RVA of where loader starts executing code once it’s completed loading the binary. Don’t assume it points to the beginning of .text or start of main()
  • SizeOfImage: the amount of contiguous memory must be preserved to load the binary into memory
  • SectionAlignment: specifies that sections must be aligned on boundaries which are multiplies of this value
    • ex: if it was 0x1000, then you might expect to see sections starting at 0x1000, 0x2000, 0x5000, etc
  • FileAlignment: data was written to binary in chunks no smaller than this value.
    • ex: 0x200, which is 512, the size of HD sector, or0x80, the size of a floppy disk sector (does people still uses floppy disk?)
  • ImageBase: specifies the preferred virtual memory location where the binary should be placed
    • M$ recommend developers “rebase” DLL files. It means that people should picking a non-default memory address which will not conflict with any of the other libraries (which will be loaded into the same memory space)
    • If the binary can’t be loaded at ImageBase (e.g. because another thing is already using that memory) then the loader picks an unused memory range. Then, every location in the binary which was compiled assuming that the binary was loaded at ImageBase must be fixed by adding the difference between the new ImageBase - the actual ImageBase
    • the list of places which must be fixed is kept in .reloc (relocations) section
    • M$ doesn’t support position-independent code
  • DLLCharacteristics: specifies some important security options like ASLR and non-executable memory regions for the loader, and the effects aren’t limited to DLLs
#define IMAGE_DLLCHARACTERISTICS_DYNAMIC_BASE 0x0040
// DLL can move.
#define IMAGE_DLLCHARACTERISTICS_FORCE_INTEGRITY    0x0080
// Code Integrity Image
#define IMAGE_DLLCHARACTERISTICS_NX_COMPAT    0x0100
// Image is NX compatible
#define IMAGE_DLLCHARACTERISTICS_NO_SEH       0x0400
// Image does not use SEH.  No SE handler may reside in this image
  • IMAGE_DLLCHARACTERISTICS_DYNAMIC_BASE: set when linked with /DYNAMICBASE option. This flag tells OS loader that this binary support ASLR. Must be used with /FIXED:NO options for .exe files, otherwise they won’t get relocation information
  • IMAGE_DLLCHARACTERISTICS_FORCE_INTEGRITY: check at load time whether the digitally signed hash of the binary matches
  • IMAGE_DLLCHARACTERISTICS_NX_COMPAT: set with the /NXCOMPAT linker option, tells the loader that this image is compatible with Data Execution Prevention (DEP) and that non-executable sections should have NX flag set in memory (I haven’t take the Intermediate x86 course yet…)
  • IMAGE_DLLCHARACTERISTICS_NO_SEH: says that this binary never uses structured exception handling, therefore no default handler should be created (because in the absence of other options that SEH handler is potentially vulnerable to attack)

Security-relevant Linker Options

  • /DYNAMICBASE - Mark the properties to indicate that this executable will work fine with ASLR (Address Space Layout Randomization)
  • /FIXED:NO - This will force the linker to generate relocations information for an executable, so that it’s capable of having its base address modified by ASLR (otherwise usually .exe files don’t have relocations information, therefore can’t be moved around in memory)
  • /NXCOMPAT - mark the properties to indicate that this executable will work fine with Data Execution Prevention (DEP) (which marks data memory regions such as stack and heap as non-executable). DEP is M$‘s name for utilizing NX/XD bit to mark memory pages as non-executable (intermediate x86 course again…)
  • /SAFESEH - Safe Structured Exception Handling. Enforces that the only SEH things you can use are ones which are specified in the binary (it will automatically add any ones defined in your code to a list that will be talked about later)

  • DataDirectory[16]: this is actually IMAGE_DATA_DIRECTORY
typedef struct _IMAGE_DATA_DIRECTORY {
    DWORD   VirtualAddress;
    DWORD   Size;
} IMAGE_DATA_DIRECTORY, *PIMAGE_DATA_DIRECTORY;
  • VirtualAddress is a RVA Pointer to some other structure of given Size
// Directory Entries
 
#define IMAGE_DIRECTORY_ENTRY_EXPORT          0   // Export Directory
#define IMAGE_DIRECTORY_ENTRY_IMPORT          1   // Import Directory
#define IMAGE_DIRECTORY_ENTRY_RESOURCE        2   // Resource Directory
#define IMAGE_DIRECTORY_ENTRY_EXCEPTION       3   // Exception Directory
#define IMAGE_DIRECTORY_ENTRY_SECURITY        4   // Security Directory
#define IMAGE_DIRECTORY_ENTRY_BASERELOC       5   // Base Relocation Table
#define IMAGE_DIRECTORY_ENTRY_DEBUG           6   // Debug Directory
//      IMAGE_DIRECTORY_ENTRY_COPYRIGHT       7   // (X86 usage)
#define IMAGE_DIRECTORY_ENTRY_ARCHITECTURE    7   // Architecture Specific Data
#define IMAGE_DIRECTORY_ENTRY_GLOBALPTR       8   // RVA of GP
#define IMAGE_DIRECTORY_ENTRY_TLS             9   // TLS Directory
#define IMAGE_DIRECTORY_ENTRY_LOAD_CONFIG    10   // Load Configuration Directory
#define IMAGE_DIRECTORY_ENTRY_BOUND_IMPORT   11   // Bound Import Directory in headers
#define IMAGE_DIRECTORY_ENTRY_IAT            12   // Import Address Table
#define IMAGE_DIRECTORY_ENTRY_DELAY_IMPORT   13   // Delay Load Import Descriptors
#define IMAGE_DIRECTORY_ENTRY_COM_DESCRIPTOR 14   // COM Runtime descriptor
  • only 15 are defined for an array of 16 elements, huh.

BinHunt round 2

go play it yourself >:(

Sections

Common section names:

  • .text = Code which should never be paged out of memory to disk
  • .data = read/write data (globals)
  • .rdata = read-only data (strings)
  • .bss = Block Started by Symbol
    • or Block Storage Segment
    • or Block Storage Start (that’s 2 name too many lmao).
    • The CMU Architecture book says the last one so…
    • M$ specs says of .bss as “Uninitialized data (free format)” which is the same as for ELF
    • In practice, the .bss seems to be merged into .data section by the linker for the binaries
  • .idata = Import address table. Gets merged with .text or .rdata
  • .edata = Export information
  • PAGE* = Code/data which it’s fine to page out to disk when computer’s running low on memory (seems to be used primarily for kernel drivers)
  • .reloc = Relocation information for where to modify hardcoded addresses which assume that it was loaded at ImageBase that is mentioned above.
  • .rsrc = Resources. Lots of possible stuff from icons to other embedded binaries. Has structures organizing it sort of like a filesystem.
  • .pdata = ARM, MIPS, SH Windows CE compilers use PDATA structure to aid in stack walking at run-time. This structure aids in debugging and exception processing.
    • or at least that’s what MDSN saids

_IMAGE_SECTION_HEADER - Section Header

#define IMAGE_SIZEOF_SHORT_NAME              8
 
typedef struct _IMAGE_SECTION_HEADER {
    BYTE    Name[IMAGE_SIZEOF_SHORT_NAME]; // Name[8]
    union {
            DWORD   PhysicalAddress;
            DWORD   VirtualSize;
    } Misc;
    DWORD   VirtualAddress;
    DWORD   SizeOfRawData;
    DWORD   PointerToRawData;
    DWORD   PointerToRelocations;
    DWORD   PointerToLinenumbers;
    WORD    NumberOfRelocations;
    WORD    NumberOfLinenumbers;
    DWORD   Characteristics;
} IMAGE_SECTION_HEADER, *PIMAGE_SECTION_HEADER;
  • Name[8] is a byte array of ASCII character. NOT guaranteed to be null-terminated
  • VirtualAddress: the RVA of the section relative to OptionalHeader.ImageBase
  • PointerToRawData: relative offset from the beginning of the file which says where the actual section data is stored
  • C Union
    • Used to store multiple different interpretations of the same data in the same location
    • Accessed as if the union were a struct
    • for example: if you have IMAGE_SECTION_HEADER sectHdr; You must access VirtualSize by sectHdr.Misc.VirtualSize and not just sectHdr.VirtualSize
union {
		DWORD   PhysicalAddress;
		DWORD   VirtualSize;
} Misc;
  • Characteristics: tell you something about the section. For example
#define IMAGE_SCN_CNT_CODE                   0x00000020  // Section contains code.
#define IMAGE_SCN_CNT_INITIALIZED_DATA       0x00000040  // Section contains initialized data.
#define IMAGE_SCN_CNT_UNINITIALIZED_DATA     0x00000080  // Section contains uninitialized data.
 
#define IMAGE_SCN_MEM_DISCARDABLE            0x02000000  // Section can be discarded.
#define IMAGE_SCN_MEM_NOT_CACHED             0x04000000  // Section is not cachable.
#define IMAGE_SCN_MEM_NOT_PAGED              0x08000000  // Section is not pageable.
#define IMAGE_SCN_MEM_SHARED                 0x10000000  // Section is shareable.
#define IMAGE_SCN_MEM_EXECUTE                0x20000000  // Section is executable.
#define IMAGE_SCN_MEM_READ                   0x40000000  // Section is readable.
#define IMAGE_SCN_MEM_WRITE                  0x80000000  // Section is writeable.
  • PointerTORelocations, PointerToLinenumbers, NumberOfRelocations, NumberOfLinenumbers aren’t used anymore
  • There is an interesting interplay between Misc.VirtualSize and SizeOfRawData. Sometimes one is larger, and other times the opposite. Why?

VirtualSize > SizeOfRawData

  • so, the .bss and .rdata section. it needs a bunch of space for variables, and the variables are uninitialized, which is why they don’t have to be saved in file. Therefore the loader can just give a chunk of memory for those variables, by just allocating VirtualSize worth of data ⇒ smaller binary

SizeOfRawData > VirtualSize

  • PE has the notion of file alignment (stated in OptionalHeader.FileAlignment). If for example, a binary has 0x100 bytes of data, the linker would’ve had to write 0x100 bytes of data followed by 0x100 bytes of padding
  • By having SizeOfRawData > VirtualSize, loader can be like “okay, I only need to allocate 0x100 bytes of memory and read 0x100 bytes of data from disk”

Binhunt 3

Note to self:

What is the VA this section will be loaded at?
Answer: 4000
/home/s-b312/Documents/[redacted]/life_of_binaries/BinaryScavengerHunt_03-17-2013/pythondemo/R3Bins
Incorrect. The answer was 0x180004000 (decimal 6442467328)
 Score = 2900
  • That’s because when he asked for VA, we need to add 0x180000000, which is the ImageBase of the binary with RVA of the section specified. in this case 0x4000. So the answer is 0x180004000
  • Xeno misprogrammed the Charactersistics quiz, so the answers to how many flags are always one less than the real number of flags

  • :( I didn’t check the video and did the lab first and lose so many points because of that

(this course is a lot lmao)

Static Linking(park) vs Dynamic Linking(park)

  • With static linking, you literally include a copy of every helper function you use inside the executable you’re generating
  • Dynamic linking is when you resolve pointers to functions inside libraries at runtime.
  • Static Linking = bloated, independent. Libraries that are included may need to be relink every times there are vulnerabilities need patching or fixes
  • Dynamic Linking = lightweight

_IMAGE_DATA_DIRECTORY & _IMAGE_IMPORT_DESCRIPTOR - Import Descriptor

typedef struct _IMAGE_DATA_DIRECTORY {
  DWORD VirtualAddress;
  DWORD Size;
} IMAGE_DATA_DIRECTORY, *PIMAGE_DATA_DIRECTORY;
typedef struct _IMAGE_IMPORT_DESCRIPTOR {
	union {
		DWORD	Characteristics; /* 0 for terminating null import descriptor  */
		DWORD	OriginalFirstThunk;	/* RVA to original unbound IAT */
	} DUMMYUNIONNAME;
	DWORD	TimeDateStamp;	/* 0 if not bound,
				 * -1 if bound, and real date\time stamp
				 *    in IMAGE_DIRECTORY_ENTRY_BOUND_IMPORT
				 * (new BIND)
				 * otherwise date/time stamp of DLL bound to
				 * (Old BIND)
				 */
	DWORD	ForwarderChain;	/* -1 if no forwarders */
	DWORD	Name;
	/* RVA to IAT (if bound this IAT has actual addresses) */
	DWORD	FirstThunk;
} IMAGE_IMPORT_DESCRIPTOR,*PIMAGE_IMPORT_DESCRIPTOR;
  • OriginalFirstThunk is the RVA of the Import Name Table (INT).
    • INT is an array of IMAGE_THUNK_DATA structs.
    • This field of the Import Descriptor points at the first entry in that array
  • FirstThunk - like OriginalFirstThunk but points to Import Address Table (IAT)
    • IAT is also an array of IMAGE_THUNK_DATA structs
  • Name is just RVA which will point at the specific name of the module which imports are taken form (e.g. hall.dll, ntdll.dll, etc)

_IMAGE_THUNK_DATA & _IMAGE_IMPORT_BY_NAME

#include <pshpack8.h>
/* Import thunk */
typedef struct _IMAGE_THUNK_DATA64 {
	union {
		ULONGLONG ForwarderString;
		ULONGLONG Function;
		ULONGLONG Ordinal;
		ULONGLONG AddressOfData;
	} u1;
} IMAGE_THUNK_DATA64,*PIMAGE_THUNK_DATA64;
#include <poppack.h>
 
typedef struct _IMAGE_THUNK_DATA32 {
	union {
		DWORD ForwarderString;
		DWORD Function;
		DWORD Ordinal;
		DWORD AddressOfData;
	} u1;
} IMAGE_THUNK_DATA32,*PIMAGE_THUNK_DATA32;
/* Import name entry */
typedef struct _IMAGE_IMPORT_BY_NAME {
	WORD	Hint;
	BYTE	Name[1];
} IMAGE_IMPORT_BY_NAME,*PIMAGE_IMPORT_BY_NAME;
  • Hint specifies a possible ordinal of an imported function. Basically just a way to look up function by an index rather than a name
  • Name on the other hand is to look up the function by name. It’s a null terminated ASCII string which follows the hint. Usually just null in this course’s examples.

INT vs IAT

  • INT’s _IMAGE_THUNK_DATA structs are always interpreted as pointing at IMAGE_IMPORT_BY_NAME structs, or u1.AddressOfData, the RVA of IMAGE_IMPORT_BY_NAME
  • IAT’s _IMAGE_THUNK_DATAstructs start out all interpreted as u1.AddressOfData, but once the OS loader resolves each import, it overwrites THUNK_DATA with the actual VA of the start of the function, which is more or less u1.Function

IAT - Image Address Table

IAT Hooking

  • When IAT is fully resolved, it’s basically just an array of function pointers
  • This mechanism can be exploited because it could be changed after the OS loader is done. It could points at attacker code
  • MITM stuff, modifies parameter before forwarding the call to original function, filters results that come back. Or it could be whatever the attacker wants to.
  • How tho?
    • From the slide, the flow is generally like this:
    • Arbitrary code execution → changing memory (like IAT for this particular process)
    • and since each process has their own separate memory space, if the attacker wants to change IAT of other processes, he/she needs to do do the same for each process.
    • That’s time consuming, so the attack instead performing DLL injection as a way to leverage IAT Hooking across many userspace processes. Because kernel modules are generally all sharing the same memory space with the kernel.
    • Therefore subverted kernel module can hook IAT of any other modules it wants

DLL Injection

go do the lab yourself lol

Bound Imports

  • Import binding is a speed optimization. The address of the functions are resolved at link time, then placed into the IA
  • The binding is done under the assumption of specific versions of DLLs.
    • If DLLs change, then all IAT entries will be invalid.
    • so you gotta resolve the addresses again, not much worse off than if you had not used binding in the first place

IMAGE_DIRECTORY_ENTRY_BOUND_IMPORT

typedef struct _IMAGE_DATA_DIRECTORY {
  DWORD VirtualAddress; 
  DWORD Size;
} IMAGE_DATA_DIRECTORY, *PIMAGE_DATA_DIRECTORY;

To be continue (it’s really long and im lazy lmao)

Search

SearchSearch

Graph View

Backlinks

  • No backlinks found