8 minutes ago, jitxd said:

I have actually managed to access 80% of the source code, but I have provided all the necessary information for the remaining part as well. I hope we can retrieve it without losing any data.

It's impossible to create a 100% exact match source for Nuitkada; you can only revert the constants or we can create a similar source. Isn't your goal to bypass the license?

5 minutes ago, Alexei Fedorov said:

Nuitkada için %100 birebir eşleşen bir kaynak oluşturmak imkansız; yalnızca sabitleri geri alabilirsiniz veya biz benzer bir kaynak oluşturabiliriz. Amacınız lisansı atlatmak değil mi?

The next step after this is to bypass the license.

13 minutes ago, jitxd said:

The next step after this is to bypass the license.

So you want us to skip the licensing part, right?

12 minutes ago, Alexei Fedorov said:

Yani lisanslama aşamasını atlamamızı istiyorsunuz, doğru mu?

Yes. Let's bypass the license system due to the nuitka issue.

8 hours ago, jitxd said:

https://workupload.com/file/ADfxqp4rG8k

# [Help Required] Reversing a Nuitka-Compiled Macro Suite (Double-Layer AES-GCM/RSA)

Hi everyone,

I'm currently working on unpacking a professional macro suite (SEGE) that uses a complex security layer. I've made significant progress using IDA Pro and memory forensics, but I've hit a wall regarding the final Key Derivation Function (KDF) and the RSA private key storage.

### Target Overview:

* Architecture: Python 3.8 compiled with Nuitka and Cython (x64 Native).

* Security: A helper DLL core_security.dll) handles HWID-binding and session key retrieval.

* Storage: 55 modules stored as .enc files with a custom SEGB header.

### What I Have Accomplished:

1. Memory Extraction: I've successfully extracted three session keys KEY1 - UUID, KEY2 - Hex Sig, KEY3 - 64-byte Binary) from a live process.

2. Header Analysis: Identified the SEGB format: Magic(4) | ModName(1) | Version(1) | Nonce(12) | Ciphertext(N) | Tag(16).

3. Encryption: Confirmed AES-GCM for local files and a secondary layer of RSA-2048 for server-delivered JSON payloads.

4. Static Analysis: Mapped out exports in core_security.dll such as RetrieveSessionKeys, GetBuildPepper, and GetSecuritySignature.

### The Blockers:

1. KDF Ambiguity: While I have the raw KEY3 from memory, direct decryption of some .enc files fails. I suspect a hardware-bound KDF (using the extracted Pepper and Salt) is used to derive the final DEK (Data Encryption Key). I’ve tried standard PBKDF2 and HKDF with no luck.

2. RSA Key Location: The secondary layer uses RSA-encrypted AES keys. I’ve scanned the memory for -----BEGIN PRIVATE KEY----- with no results, suggesting it's either loaded directly into a native provider (CNG/OpenSSL) or protected by Windows DPAPI.

3. Nuitka Dynamic Loading: I'm looking for the specific hook Nuitka uses to load these decrypted modules. Is it likely using PyMarshal_ReadObjectFromString or a custom bytecode loader?

### My Request:

I'm looking for anyone with experience in Nuitka unpacking or Cython de-obfuscation. Specifically, I need help identifying the key transformation logic between the session keys in RAM and the final AES decryption call.

If anyone is willing to take a look at the memory dumps or the core_security.dll binary, I can provide more technical details.

Thanks in advance!



# SEGE Macro Suite - Reverse Engineering & Unpacking Report

This report summarizes the technical data obtained during the process of decrypting the SEGE macro suite, solving its operational logic, and accessing its core functions.

## 1. Architectural Overview

The application is compiled using Nuitka and Cython. This means the Python code is translated into C++ and compiled directly into native machine code (binary). Consequently, there are no readable .py files on disk or in memory; instead, compiled C++ functions execute the logic.

## 2. Encryption Technologies

The system is protected at two main layers:

* Local Layer (SEGB): Files with the .enc extension (asas.enc, minor.enc, etc.) are encrypted using the AES-GCM algorithm. Each file starts with the SEGB signature.

* Server Layer (JSON): Macro configurations and license data are protected by a hybrid RSA-2048 and AES-GCM structure. The enc_key is encrypted with RSA, and the data is encrypted with AES.

* HWID Binding: Decryption keys are derived from your computer's hardware identifiers (MAC, CPUID, etc.) via core_security.dll.

## 3. Data Sources and Extraction Methods

| Data Type | Source | Method |

| :--- | :--- | :--- |

| Session Keys | core_security.dll RAM | Live Memory Scraper (ReadProcessMemory) |

| Encrypted Modules | macros_enc/ Directory | File System Analysis |

| Decrypted Payloads | lghub_agent.exe RAM | Memory Region Dumping (VirtualQueryEx) |

| Hardware IDs | core_security.dll Exports | IDA Pro Static Analysis |

## 4. Tools and Process Used

* IDA Pro 9.3: Used for static analysis of core_security.dll and the main executable. Security functions were de-obfuscated.

* Frida: Used to inject hooks into the running process to capture data from critical functions like PyMarshal_ReadObjectFromString and BCryptDecrypt.

* Custom Python Scripts: live_key_extract.py and hunt_decrypted_memory.py were developed to hunt for hidden keys and decrypted JSON blocks in RAM.

## 5. Conclusion and Algorithmic Logic

The operational logic of the macro (Asas, etc.) has been fully solved:

1. Screen Capture: High-speed screenshots are taken using the mss library.

2. Pixel Analysis: Color changes at specific coordinates (X,Y) previously registered by the user via the "Save" button are monitored.

3. Triggering: When a skill is ready (when the pixel color changes), a keystroke is simulated using pydirectinput.

Hello, all modules of the application have been extracted, including login core, etc. However, it is impossible to decrypt the other encoded modules without a valid key because the DEC key for the .enc modules is entirely server-side. If you have a valid key, please contact us.