C++

Sometimes you have to hide stuff that your code does from a reverse engineer’s eye or static analysis tools. To achieve that, I came up with a few helper macros and functions to search for functions at runtime and call them without leaving a trace in the executable’s import table. TL;DR Hiding function imports Let’s take this simple program as an example: 1 2 3 4 5 6 7 #include <Windows....

There may come a time that you don’t want to leave strings in your executable but still need to do some kind of string comparison. For that I use the compile-time constexpr features of modern c++ compilers. 1 2 3 4 auto hash = CX_Fnv1a("shady_lib.dll") // in case you need to ignore case, string will be converted to lowercase auto hash = CX_IFnv1a("shady_lib.dll") Check the output binary using string.exe, there will be no trace of shady_lib....

While digging in my old code repositories I stumbled upon a memory pattern search algorithm I once used in a cheat I made. Maybe i’ts useful for someone at some time. It may be used like this: 1 2 3 4 constexpr unsigned char patD3Device[] = { 0xA1, '?', '?', '?', '?', 0x50, 0x8B, 0x08, 0xFF, 0x51, 0x0C }; // search for the patD3Device ('?' characters are non static values) from memory address 0x400000 to 0x408192 auto patternAddress = SearchPattern(patD3Device, sizeof(patD3Device), 0x400000, 0x8192); 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 /// <summary> /// Search a memory pattern....

I recently discovered some alternatives to GetModuleHandle and GetProcAddress that can be used when you need to avoid the original functions due to anticheat or antivirus software. Use this to store the FNV1A hahses stealthy: https://jnns.de/posts/cpp-compile-time-hashing-fnv1a/ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 struct LIST_ENTRY { struct LIST_ENTRY* Flink; struct LIST_ENTRY* Blink; }; struct LDR_DATA_TABLE_ENTRY { LIST_ENTRY InLoadOrderLinks; LIST_ENTRY InMemoryOrderLinks; LIST_ENTRY InInitializationOrderLinks; void* DllBase; void* EntryPoint; size_t SizeOfImage; unsigned short FullDllNameLength; unsigned short FullDllNameMaximumLength; wchar_t* FullDllNameBuffer; unsigned short BaseDllNameLength; unsigned short BaseDllNameMaximumLength; wchar_t* BaseDllNameBuffer; unsigned long Flags; unsigned short LoadCount; unsigned short TlsIndex; union { LIST_ENTRY HashLinks; struct { void* SectionPointer; unsigned long CheckSum; }; }; union { unsigned long TimeDateStamp; void* LoadedImports; }; void* EntryPointActivationContext; void* PatchInformation; LIST_ENTRY ForwarderLinks; LIST_ENTRY ServiceTagLinks; LIST_ENTRY StaticLinks; }; /// <summary> /// Returns a pointer to the current PEB....

This blog post is aimed at manipulating the PEB’s LoaderDataModule lists in Windows. These lists catalog all loaded libraries within a process, providing an avenue for detecting our loaded module. Notably, the current implementation is tailored for x86 architecture, with future plans for x64 compatibility. Microsoft Windows PEB Documentation Disclaimer This is strictly intended for educational purposes and does not endorse the development of malicious software. Windows Structs To streamline development, comprehensive Windows structs have been sourced from undocumented....