h4-debug 0.2.1__tar.gz → 0.2.3__tar.gz
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- h4_debug-0.2.3/PKG-INFO +146 -0
- h4_debug-0.2.3/README.md +133 -0
- {h4_debug-0.2.1 → h4_debug-0.2.3}/h4_debug/win_debugger.py +15 -1
- h4_debug-0.2.3/h4_debug.egg-info/PKG-INFO +146 -0
- {h4_debug-0.2.1 → h4_debug-0.2.3}/pyproject.toml +1 -1
- h4_debug-0.2.1/PKG-INFO +0 -23
- h4_debug-0.2.1/README.md +0 -10
- h4_debug-0.2.1/h4_debug.egg-info/PKG-INFO +0 -23
- {h4_debug-0.2.1 → h4_debug-0.2.3}/h4_debug/__init__.py +0 -0
- {h4_debug-0.2.1 → h4_debug-0.2.3}/h4_debug/cli.py +0 -0
- {h4_debug-0.2.1 → h4_debug-0.2.3}/h4_debug/handlers.py +0 -0
- {h4_debug-0.2.1 → h4_debug-0.2.3}/h4_debug/interceptor.py +0 -0
- {h4_debug-0.2.1 → h4_debug-0.2.3}/h4_debug/node_interceptor.js +0 -0
- {h4_debug-0.2.1 → h4_debug-0.2.3}/h4_debug/server.py +0 -0
- {h4_debug-0.2.1 → h4_debug-0.2.3}/h4_debug/static/dashboard.css +0 -0
- {h4_debug-0.2.1 → h4_debug-0.2.3}/h4_debug/static/dashboard.html +0 -0
- {h4_debug-0.2.1 → h4_debug-0.2.3}/h4_debug/static/dashboard.js +0 -0
- {h4_debug-0.2.1 → h4_debug-0.2.3}/h4_debug.egg-info/SOURCES.txt +0 -0
- {h4_debug-0.2.1 → h4_debug-0.2.3}/h4_debug.egg-info/dependency_links.txt +0 -0
- {h4_debug-0.2.1 → h4_debug-0.2.3}/h4_debug.egg-info/entry_points.txt +0 -0
- {h4_debug-0.2.1 → h4_debug-0.2.3}/h4_debug.egg-info/requires.txt +0 -0
- {h4_debug-0.2.1 → h4_debug-0.2.3}/h4_debug.egg-info/top_level.txt +0 -0
- {h4_debug-0.2.1 → h4_debug-0.2.3}/setup.cfg +0 -0
h4_debug-0.2.3/PKG-INFO
ADDED
|
@@ -0,0 +1,146 @@
|
|
|
1
|
+
Metadata-Version: 2.4
|
|
2
|
+
Name: h4-debug
|
|
3
|
+
Version: 0.2.3
|
|
4
|
+
Summary: Advanced application proxy debugger and F12-style web console
|
|
5
|
+
Author-email: h4 <h4@example.com>
|
|
6
|
+
Requires-Python: >=3.8
|
|
7
|
+
Description-Content-Type: text/markdown
|
|
8
|
+
Requires-Dist: fastapi>=0.100
|
|
9
|
+
Requires-Dist: uvicorn[standard]>=0.20
|
|
10
|
+
Requires-Dist: websockets>=11.0
|
|
11
|
+
Requires-Dist: Pillow>=10.0.0
|
|
12
|
+
Requires-Dist: psutil>=5.9.0
|
|
13
|
+
|
|
14
|
+
<div align="center">
|
|
15
|
+
<h1>🚀 h4-debug</h1>
|
|
16
|
+
<p><b>The Universal Application Proxy Debugger & F12-Style Web Console</b></p>
|
|
17
|
+
<br />
|
|
18
|
+
</div>
|
|
19
|
+
|
|
20
|
+
> **h4-debug** is a ridiculously powerful, injection-free, cross-language runtime debugger. It seamlessly attaches to arbitrary scripts, applications, and native Windows executables to stream highly detailed runtime telemetry (Console, Network, Disk, Exceptions, and System Events) to an elegant, real-time web dashboard.
|
|
21
|
+
|
|
22
|
+
---
|
|
23
|
+
|
|
24
|
+
## 📖 Table of Contents
|
|
25
|
+
|
|
26
|
+
- [The Core Philosophy (Why No Injection?)](#-the-core-philosophy-why-no-injection)
|
|
27
|
+
- [How It Works Under the Hood](#-how-it-works-under-the-hood)
|
|
28
|
+
- [Native Executables (Windows Native Debugger)](#native-executables-windows-native-debugger)
|
|
29
|
+
- [Node.js Deep Hooking](#nodejs-deep-hooking)
|
|
30
|
+
- [Python Introspection](#python-introspection)
|
|
31
|
+
- [Installation](#-installation)
|
|
32
|
+
- [Usage](#-usage)
|
|
33
|
+
- [Advanced Details & Edge Cases](#-advanced-details--edge-cases)
|
|
34
|
+
- [Contributing](#-contributing)
|
|
35
|
+
|
|
36
|
+
---
|
|
37
|
+
|
|
38
|
+
## 🛡 The Core Philosophy (Why No Injection?)
|
|
39
|
+
|
|
40
|
+
In the world of application tracing and reverse engineering, a common approach to gathering deep runtime telemetry is **Dynamic API Hooking** (e.g., injecting custom DLLs, patching memory in real-time using trampolines, or running Kernel-mode ETW rootkits).
|
|
41
|
+
|
|
42
|
+
**`h4-debug` rejects this methodology completely.**
|
|
43
|
+
|
|
44
|
+
Instead of mutating the target process or injecting rogue binaries, `h4-debug` achieves perfect observability through **100% native, sanctioned OS and runtime APIs**.
|
|
45
|
+
|
|
46
|
+
### Why is this better?
|
|
47
|
+
1. **Zero Anti-Cheat / DRM Tripping**: By avoiding memory modification, `h4-debug` runs perfectly against heavily guarded applications. We act as a legitimate OS-level debugger, rather than operating like malware.
|
|
48
|
+
2. **Infinite Stability**: API hooking is notorious for causing arbitrary segmentation faults, race conditions, and application crashes. By using passive OS telemetry and standard runtime intercepts, the target application runs with maximum stability.
|
|
49
|
+
3. **No Rootkits Required**: You do not need to compile or install dangerous kernel-mode drivers to get network and disk observability.
|
|
50
|
+
4. **Universal Compatibility**: Our architecture allows us to drop in and debug Python, Node.js, and raw `.exe` binaries with the exact same UX.
|
|
51
|
+
|
|
52
|
+
---
|
|
53
|
+
|
|
54
|
+
## ⚙ How It Works Under the Hood
|
|
55
|
+
|
|
56
|
+
The `h4-debug` architecture consists of two primary components:
|
|
57
|
+
1. **The Telemetry Server**: A fast, asynchronous `FastAPI` instance managing real-time WebSocket connections and serving the UI dashboard.
|
|
58
|
+
2. **The Handlers / Interceptors**: Language/target-specific wrappers that boot the target application and transparently route its telemetry back to the server.
|
|
59
|
+
|
|
60
|
+
### Native Executables (Windows Native Debugger)
|
|
61
|
+
|
|
62
|
+
When you run `h4-debug app.exe`, the tool leverages the raw Windows Win32 Debugging API (`kernel32.dll`) via `ctypes`.
|
|
63
|
+
|
|
64
|
+
- **Event Loop Integration**: We spawn the process using `CreateProcessW` with the `DEBUG_PROCESS` flag. We then capture `WaitForDebugEvent`, natively intercepting `CREATE_PROCESS_DEBUG_EVENT`, `LOAD_DLL_DEBUG_EVENT`, thread lifecycles, and unhandled exceptions.
|
|
65
|
+
- **Hidden Debug Strings**: GUI applications (like Unity mods, game launchers, or heavy desktop apps) do not pipe logs to `stdout`. Instead, they typically use `OutputDebugString`. `h4-debug` intercepts `OUTPUT_DEBUG_STRING_EVENT`, uses `ReadProcessMemory` to safely read the buffer in real-time, and routes it to your console.
|
|
66
|
+
- **Piped stdout/stderr**: For console-based native applications, we dynamically generate anonymous pipes (`CreatePipe`) equipped with `STARTF_USESTDHANDLES` to natively capture all standard command-line output.
|
|
67
|
+
- **Disk & Network Polling**: Because we refuse to inject DLLs to hook `ws2_32.dll` (Network) or `ntdll.dll` (Disk), we launch a hyper-efficient, high-frequency background daemon (`psutil`). This daemon polls the target process 10 times a second, intelligently indexing newly opened file descriptors (`fd`) and newly active TCP/UDP endpoints, streaming live Disk and Network events directly to the dashboard.
|
|
68
|
+
|
|
69
|
+
*(Note: Debugging installers or protected executables often requires Administrator privileges. `h4-debug` gracefully detects `ERROR_ACCESS_DENIED` [Error 5] or `ERROR_ELEVATION_REQUIRED` [Error 740] and halts, prompting you to elevate your terminal rather than crashing).*
|
|
70
|
+
|
|
71
|
+
### Node.js Deep Hooking
|
|
72
|
+
|
|
73
|
+
When you execute `h4-debug node app.js`, the tool dynamically sets the `NODE_OPTIONS=--require ...` environment variable before executing the Node binary.
|
|
74
|
+
|
|
75
|
+
- **Console & Errors**: Overrides `console.log`, `console.error`, etc., intercepting the arguments and beaming them to the dashboard before passing them along to the original `stdout`. Automatically catches `uncaughtException` and `unhandledRejection`.
|
|
76
|
+
- **Network Interception**: Hot-patches the native `http.request` and `https.request` modules to trace the exact URL, method, and protocol of outbound network calls.
|
|
77
|
+
- **Disk Tracing**: Hooks raw filesystem methods like `fs.open`, `fs.readFile`, and `fs.writeFile`, logging the file paths being accessed.
|
|
78
|
+
|
|
79
|
+
### Python Introspection
|
|
80
|
+
|
|
81
|
+
For `h4-debug python main.py`, the debugger alters `PYTHONPATH` and injects a custom `sitecustomize.py`.
|
|
82
|
+
- **Seamless Boot**: Because `sitecustomize.py` is loaded before any user code executes, we establish the Telemetry Client instantly.
|
|
83
|
+
- **Module Hooking**: We hot-patch `sys.stdout` and `sys.stderr` to mirror all terminal output. We also monkey-patch popular HTTP libraries (like `urllib`, `requests`, and `aiohttp`) to provide granular network request visibility.
|
|
84
|
+
|
|
85
|
+
---
|
|
86
|
+
|
|
87
|
+
## 📦 Installation
|
|
88
|
+
|
|
89
|
+
Install globally via `pip`:
|
|
90
|
+
|
|
91
|
+
```bash
|
|
92
|
+
pip install h4-debug --upgrade
|
|
93
|
+
```
|
|
94
|
+
|
|
95
|
+
*Requires Python 3.8+*
|
|
96
|
+
|
|
97
|
+
---
|
|
98
|
+
|
|
99
|
+
## 🚀 Usage
|
|
100
|
+
|
|
101
|
+
Using `h4-debug` is incredibly simple. Just prefix your standard commands with `h4-debug`:
|
|
102
|
+
|
|
103
|
+
**1. Debug a Windows Executable (GUI or Console):**
|
|
104
|
+
```bash
|
|
105
|
+
# Note: Run your terminal as Administrator if the .exe requires elevation!
|
|
106
|
+
h4-debug installer.exe --silent
|
|
107
|
+
h4-debug game_launcher.exe
|
|
108
|
+
```
|
|
109
|
+
|
|
110
|
+
**2. Debug a Node.js Application:**
|
|
111
|
+
```bash
|
|
112
|
+
h4-debug node index.js
|
|
113
|
+
h4-debug npm start
|
|
114
|
+
```
|
|
115
|
+
|
|
116
|
+
**3. Debug a Python Script:**
|
|
117
|
+
```bash
|
|
118
|
+
h4-debug python app.py
|
|
119
|
+
```
|
|
120
|
+
|
|
121
|
+
### The Dashboard
|
|
122
|
+
|
|
123
|
+
Once executed, `h4-debug` immediately spins up a local web server (usually at `http://localhost:8999`) and provides a URL in the terminal. Open that URL to view the real-time F12-style developer dashboard!
|
|
124
|
+
|
|
125
|
+
The dashboard is broken into intuitive tabs:
|
|
126
|
+
- **Console**: See standard output, errors, and native `OutputDebugString` traces.
|
|
127
|
+
- **Network**: Monitor outbound HTTP/HTTPS connections and raw TCP/UDP socket activity.
|
|
128
|
+
- **Disk**: Track file read/write operations and active open file handles.
|
|
129
|
+
- **System**: Observe process creation, DLL loads, unhandled exceptions, and debugger state.
|
|
130
|
+
|
|
131
|
+
---
|
|
132
|
+
|
|
133
|
+
## 🛠 Advanced Details & Edge Cases
|
|
134
|
+
|
|
135
|
+
### The "Access Denied" Error (Native Debugging)
|
|
136
|
+
If you attempt to debug a Windows executable and immediately see an `Error 5` or `Error 740` in your terminal or dashboard, this means the OS has rejected the debugger attachment.
|
|
137
|
+
- **The Fix**: This is an intended security mechanism in Windows. If an application requests Administrative privileges in its manifest, a non-elevated debugger cannot attach to it. Simply close your terminal, re-open it as **Administrator**, and run the command again.
|
|
138
|
+
|
|
139
|
+
### The Network / Disk Polling Interval
|
|
140
|
+
The native execution wrapper utilizes a `10Hz` (0.1s) polling loop to track open files and socket connections without risking application stability. While this is incredibly robust and will catch the vast majority of I/O (like an installer downloading a payload), microsecond-length file touches might occasionally slip past the poll. This is a deliberate architectural trade-off to ensure 100% stability and zero injection risk.
|
|
141
|
+
|
|
142
|
+
---
|
|
143
|
+
|
|
144
|
+
<div align="center">
|
|
145
|
+
<i>Built for developers who demand total observability without compromising stability.</i>
|
|
146
|
+
</div>
|
h4_debug-0.2.3/README.md
ADDED
|
@@ -0,0 +1,133 @@
|
|
|
1
|
+
<div align="center">
|
|
2
|
+
<h1>🚀 h4-debug</h1>
|
|
3
|
+
<p><b>The Universal Application Proxy Debugger & F12-Style Web Console</b></p>
|
|
4
|
+
<br />
|
|
5
|
+
</div>
|
|
6
|
+
|
|
7
|
+
> **h4-debug** is a ridiculously powerful, injection-free, cross-language runtime debugger. It seamlessly attaches to arbitrary scripts, applications, and native Windows executables to stream highly detailed runtime telemetry (Console, Network, Disk, Exceptions, and System Events) to an elegant, real-time web dashboard.
|
|
8
|
+
|
|
9
|
+
---
|
|
10
|
+
|
|
11
|
+
## 📖 Table of Contents
|
|
12
|
+
|
|
13
|
+
- [The Core Philosophy (Why No Injection?)](#-the-core-philosophy-why-no-injection)
|
|
14
|
+
- [How It Works Under the Hood](#-how-it-works-under-the-hood)
|
|
15
|
+
- [Native Executables (Windows Native Debugger)](#native-executables-windows-native-debugger)
|
|
16
|
+
- [Node.js Deep Hooking](#nodejs-deep-hooking)
|
|
17
|
+
- [Python Introspection](#python-introspection)
|
|
18
|
+
- [Installation](#-installation)
|
|
19
|
+
- [Usage](#-usage)
|
|
20
|
+
- [Advanced Details & Edge Cases](#-advanced-details--edge-cases)
|
|
21
|
+
- [Contributing](#-contributing)
|
|
22
|
+
|
|
23
|
+
---
|
|
24
|
+
|
|
25
|
+
## 🛡 The Core Philosophy (Why No Injection?)
|
|
26
|
+
|
|
27
|
+
In the world of application tracing and reverse engineering, a common approach to gathering deep runtime telemetry is **Dynamic API Hooking** (e.g., injecting custom DLLs, patching memory in real-time using trampolines, or running Kernel-mode ETW rootkits).
|
|
28
|
+
|
|
29
|
+
**`h4-debug` rejects this methodology completely.**
|
|
30
|
+
|
|
31
|
+
Instead of mutating the target process or injecting rogue binaries, `h4-debug` achieves perfect observability through **100% native, sanctioned OS and runtime APIs**.
|
|
32
|
+
|
|
33
|
+
### Why is this better?
|
|
34
|
+
1. **Zero Anti-Cheat / DRM Tripping**: By avoiding memory modification, `h4-debug` runs perfectly against heavily guarded applications. We act as a legitimate OS-level debugger, rather than operating like malware.
|
|
35
|
+
2. **Infinite Stability**: API hooking is notorious for causing arbitrary segmentation faults, race conditions, and application crashes. By using passive OS telemetry and standard runtime intercepts, the target application runs with maximum stability.
|
|
36
|
+
3. **No Rootkits Required**: You do not need to compile or install dangerous kernel-mode drivers to get network and disk observability.
|
|
37
|
+
4. **Universal Compatibility**: Our architecture allows us to drop in and debug Python, Node.js, and raw `.exe` binaries with the exact same UX.
|
|
38
|
+
|
|
39
|
+
---
|
|
40
|
+
|
|
41
|
+
## ⚙ How It Works Under the Hood
|
|
42
|
+
|
|
43
|
+
The `h4-debug` architecture consists of two primary components:
|
|
44
|
+
1. **The Telemetry Server**: A fast, asynchronous `FastAPI` instance managing real-time WebSocket connections and serving the UI dashboard.
|
|
45
|
+
2. **The Handlers / Interceptors**: Language/target-specific wrappers that boot the target application and transparently route its telemetry back to the server.
|
|
46
|
+
|
|
47
|
+
### Native Executables (Windows Native Debugger)
|
|
48
|
+
|
|
49
|
+
When you run `h4-debug app.exe`, the tool leverages the raw Windows Win32 Debugging API (`kernel32.dll`) via `ctypes`.
|
|
50
|
+
|
|
51
|
+
- **Event Loop Integration**: We spawn the process using `CreateProcessW` with the `DEBUG_PROCESS` flag. We then capture `WaitForDebugEvent`, natively intercepting `CREATE_PROCESS_DEBUG_EVENT`, `LOAD_DLL_DEBUG_EVENT`, thread lifecycles, and unhandled exceptions.
|
|
52
|
+
- **Hidden Debug Strings**: GUI applications (like Unity mods, game launchers, or heavy desktop apps) do not pipe logs to `stdout`. Instead, they typically use `OutputDebugString`. `h4-debug` intercepts `OUTPUT_DEBUG_STRING_EVENT`, uses `ReadProcessMemory` to safely read the buffer in real-time, and routes it to your console.
|
|
53
|
+
- **Piped stdout/stderr**: For console-based native applications, we dynamically generate anonymous pipes (`CreatePipe`) equipped with `STARTF_USESTDHANDLES` to natively capture all standard command-line output.
|
|
54
|
+
- **Disk & Network Polling**: Because we refuse to inject DLLs to hook `ws2_32.dll` (Network) or `ntdll.dll` (Disk), we launch a hyper-efficient, high-frequency background daemon (`psutil`). This daemon polls the target process 10 times a second, intelligently indexing newly opened file descriptors (`fd`) and newly active TCP/UDP endpoints, streaming live Disk and Network events directly to the dashboard.
|
|
55
|
+
|
|
56
|
+
*(Note: Debugging installers or protected executables often requires Administrator privileges. `h4-debug` gracefully detects `ERROR_ACCESS_DENIED` [Error 5] or `ERROR_ELEVATION_REQUIRED` [Error 740] and halts, prompting you to elevate your terminal rather than crashing).*
|
|
57
|
+
|
|
58
|
+
### Node.js Deep Hooking
|
|
59
|
+
|
|
60
|
+
When you execute `h4-debug node app.js`, the tool dynamically sets the `NODE_OPTIONS=--require ...` environment variable before executing the Node binary.
|
|
61
|
+
|
|
62
|
+
- **Console & Errors**: Overrides `console.log`, `console.error`, etc., intercepting the arguments and beaming them to the dashboard before passing them along to the original `stdout`. Automatically catches `uncaughtException` and `unhandledRejection`.
|
|
63
|
+
- **Network Interception**: Hot-patches the native `http.request` and `https.request` modules to trace the exact URL, method, and protocol of outbound network calls.
|
|
64
|
+
- **Disk Tracing**: Hooks raw filesystem methods like `fs.open`, `fs.readFile`, and `fs.writeFile`, logging the file paths being accessed.
|
|
65
|
+
|
|
66
|
+
### Python Introspection
|
|
67
|
+
|
|
68
|
+
For `h4-debug python main.py`, the debugger alters `PYTHONPATH` and injects a custom `sitecustomize.py`.
|
|
69
|
+
- **Seamless Boot**: Because `sitecustomize.py` is loaded before any user code executes, we establish the Telemetry Client instantly.
|
|
70
|
+
- **Module Hooking**: We hot-patch `sys.stdout` and `sys.stderr` to mirror all terminal output. We also monkey-patch popular HTTP libraries (like `urllib`, `requests`, and `aiohttp`) to provide granular network request visibility.
|
|
71
|
+
|
|
72
|
+
---
|
|
73
|
+
|
|
74
|
+
## 📦 Installation
|
|
75
|
+
|
|
76
|
+
Install globally via `pip`:
|
|
77
|
+
|
|
78
|
+
```bash
|
|
79
|
+
pip install h4-debug --upgrade
|
|
80
|
+
```
|
|
81
|
+
|
|
82
|
+
*Requires Python 3.8+*
|
|
83
|
+
|
|
84
|
+
---
|
|
85
|
+
|
|
86
|
+
## 🚀 Usage
|
|
87
|
+
|
|
88
|
+
Using `h4-debug` is incredibly simple. Just prefix your standard commands with `h4-debug`:
|
|
89
|
+
|
|
90
|
+
**1. Debug a Windows Executable (GUI or Console):**
|
|
91
|
+
```bash
|
|
92
|
+
# Note: Run your terminal as Administrator if the .exe requires elevation!
|
|
93
|
+
h4-debug installer.exe --silent
|
|
94
|
+
h4-debug game_launcher.exe
|
|
95
|
+
```
|
|
96
|
+
|
|
97
|
+
**2. Debug a Node.js Application:**
|
|
98
|
+
```bash
|
|
99
|
+
h4-debug node index.js
|
|
100
|
+
h4-debug npm start
|
|
101
|
+
```
|
|
102
|
+
|
|
103
|
+
**3. Debug a Python Script:**
|
|
104
|
+
```bash
|
|
105
|
+
h4-debug python app.py
|
|
106
|
+
```
|
|
107
|
+
|
|
108
|
+
### The Dashboard
|
|
109
|
+
|
|
110
|
+
Once executed, `h4-debug` immediately spins up a local web server (usually at `http://localhost:8999`) and provides a URL in the terminal. Open that URL to view the real-time F12-style developer dashboard!
|
|
111
|
+
|
|
112
|
+
The dashboard is broken into intuitive tabs:
|
|
113
|
+
- **Console**: See standard output, errors, and native `OutputDebugString` traces.
|
|
114
|
+
- **Network**: Monitor outbound HTTP/HTTPS connections and raw TCP/UDP socket activity.
|
|
115
|
+
- **Disk**: Track file read/write operations and active open file handles.
|
|
116
|
+
- **System**: Observe process creation, DLL loads, unhandled exceptions, and debugger state.
|
|
117
|
+
|
|
118
|
+
---
|
|
119
|
+
|
|
120
|
+
## 🛠 Advanced Details & Edge Cases
|
|
121
|
+
|
|
122
|
+
### The "Access Denied" Error (Native Debugging)
|
|
123
|
+
If you attempt to debug a Windows executable and immediately see an `Error 5` or `Error 740` in your terminal or dashboard, this means the OS has rejected the debugger attachment.
|
|
124
|
+
- **The Fix**: This is an intended security mechanism in Windows. If an application requests Administrative privileges in its manifest, a non-elevated debugger cannot attach to it. Simply close your terminal, re-open it as **Administrator**, and run the command again.
|
|
125
|
+
|
|
126
|
+
### The Network / Disk Polling Interval
|
|
127
|
+
The native execution wrapper utilizes a `10Hz` (0.1s) polling loop to track open files and socket connections without risking application stability. While this is incredibly robust and will catch the vast majority of I/O (like an installer downloading a payload), microsecond-length file touches might occasionally slip past the poll. This is a deliberate architectural trade-off to ensure 100% stability and zero injection risk.
|
|
128
|
+
|
|
129
|
+
---
|
|
130
|
+
|
|
131
|
+
<div align="center">
|
|
132
|
+
<i>Built for developers who demand total observability without compromising stability.</i>
|
|
133
|
+
</div>
|
|
@@ -223,12 +223,26 @@ def debug_process(command, client):
|
|
|
223
223
|
creation_flags = DEBUG_PROCESS
|
|
224
224
|
|
|
225
225
|
# Convert command list to string for Windows
|
|
226
|
+
import shutil
|
|
227
|
+
resolved_exe = shutil.which(command[0])
|
|
228
|
+
if resolved_exe:
|
|
229
|
+
command[0] = resolved_exe
|
|
230
|
+
|
|
226
231
|
cmd_str = " ".join(f'"{c}"' if " " in c else c for c in command)
|
|
227
232
|
|
|
228
233
|
if not kernel32.CreateProcessW(
|
|
229
234
|
None, ctypes.c_wchar_p(cmd_str), None, None, True, # bInheritHandles=True
|
|
230
235
|
creation_flags, None, None, ctypes.byref(si), ctypes.byref(pi)):
|
|
231
|
-
|
|
236
|
+
err = ctypes.GetLastError()
|
|
237
|
+
err_msg = f"Failed to CreateProcess: {err}"
|
|
238
|
+
if err == 2:
|
|
239
|
+
err_msg += f" (File Not Found). Windows could not locate the executable '{command[0]}'. Make sure the path is correct."
|
|
240
|
+
elif err == 5:
|
|
241
|
+
err_msg += " (Access Denied). The executable may require Administrator privileges, or it may be blocked by Windows Defender/DRM. Try running h4-debug from an Administrator terminal."
|
|
242
|
+
elif err == 740:
|
|
243
|
+
err_msg += " (Elevation Required). The executable requires Administrator privileges. Please run h4-debug from an Administrator terminal."
|
|
244
|
+
client.send("System", "error", {"text": err_msg})
|
|
245
|
+
print(f"[h4-debug] {err_msg}")
|
|
232
246
|
if hWritePipe:
|
|
233
247
|
kernel32.CloseHandle(hReadPipe)
|
|
234
248
|
kernel32.CloseHandle(hWritePipe)
|
|
@@ -0,0 +1,146 @@
|
|
|
1
|
+
Metadata-Version: 2.4
|
|
2
|
+
Name: h4-debug
|
|
3
|
+
Version: 0.2.3
|
|
4
|
+
Summary: Advanced application proxy debugger and F12-style web console
|
|
5
|
+
Author-email: h4 <h4@example.com>
|
|
6
|
+
Requires-Python: >=3.8
|
|
7
|
+
Description-Content-Type: text/markdown
|
|
8
|
+
Requires-Dist: fastapi>=0.100
|
|
9
|
+
Requires-Dist: uvicorn[standard]>=0.20
|
|
10
|
+
Requires-Dist: websockets>=11.0
|
|
11
|
+
Requires-Dist: Pillow>=10.0.0
|
|
12
|
+
Requires-Dist: psutil>=5.9.0
|
|
13
|
+
|
|
14
|
+
<div align="center">
|
|
15
|
+
<h1>🚀 h4-debug</h1>
|
|
16
|
+
<p><b>The Universal Application Proxy Debugger & F12-Style Web Console</b></p>
|
|
17
|
+
<br />
|
|
18
|
+
</div>
|
|
19
|
+
|
|
20
|
+
> **h4-debug** is a ridiculously powerful, injection-free, cross-language runtime debugger. It seamlessly attaches to arbitrary scripts, applications, and native Windows executables to stream highly detailed runtime telemetry (Console, Network, Disk, Exceptions, and System Events) to an elegant, real-time web dashboard.
|
|
21
|
+
|
|
22
|
+
---
|
|
23
|
+
|
|
24
|
+
## 📖 Table of Contents
|
|
25
|
+
|
|
26
|
+
- [The Core Philosophy (Why No Injection?)](#-the-core-philosophy-why-no-injection)
|
|
27
|
+
- [How It Works Under the Hood](#-how-it-works-under-the-hood)
|
|
28
|
+
- [Native Executables (Windows Native Debugger)](#native-executables-windows-native-debugger)
|
|
29
|
+
- [Node.js Deep Hooking](#nodejs-deep-hooking)
|
|
30
|
+
- [Python Introspection](#python-introspection)
|
|
31
|
+
- [Installation](#-installation)
|
|
32
|
+
- [Usage](#-usage)
|
|
33
|
+
- [Advanced Details & Edge Cases](#-advanced-details--edge-cases)
|
|
34
|
+
- [Contributing](#-contributing)
|
|
35
|
+
|
|
36
|
+
---
|
|
37
|
+
|
|
38
|
+
## 🛡 The Core Philosophy (Why No Injection?)
|
|
39
|
+
|
|
40
|
+
In the world of application tracing and reverse engineering, a common approach to gathering deep runtime telemetry is **Dynamic API Hooking** (e.g., injecting custom DLLs, patching memory in real-time using trampolines, or running Kernel-mode ETW rootkits).
|
|
41
|
+
|
|
42
|
+
**`h4-debug` rejects this methodology completely.**
|
|
43
|
+
|
|
44
|
+
Instead of mutating the target process or injecting rogue binaries, `h4-debug` achieves perfect observability through **100% native, sanctioned OS and runtime APIs**.
|
|
45
|
+
|
|
46
|
+
### Why is this better?
|
|
47
|
+
1. **Zero Anti-Cheat / DRM Tripping**: By avoiding memory modification, `h4-debug` runs perfectly against heavily guarded applications. We act as a legitimate OS-level debugger, rather than operating like malware.
|
|
48
|
+
2. **Infinite Stability**: API hooking is notorious for causing arbitrary segmentation faults, race conditions, and application crashes. By using passive OS telemetry and standard runtime intercepts, the target application runs with maximum stability.
|
|
49
|
+
3. **No Rootkits Required**: You do not need to compile or install dangerous kernel-mode drivers to get network and disk observability.
|
|
50
|
+
4. **Universal Compatibility**: Our architecture allows us to drop in and debug Python, Node.js, and raw `.exe` binaries with the exact same UX.
|
|
51
|
+
|
|
52
|
+
---
|
|
53
|
+
|
|
54
|
+
## ⚙ How It Works Under the Hood
|
|
55
|
+
|
|
56
|
+
The `h4-debug` architecture consists of two primary components:
|
|
57
|
+
1. **The Telemetry Server**: A fast, asynchronous `FastAPI` instance managing real-time WebSocket connections and serving the UI dashboard.
|
|
58
|
+
2. **The Handlers / Interceptors**: Language/target-specific wrappers that boot the target application and transparently route its telemetry back to the server.
|
|
59
|
+
|
|
60
|
+
### Native Executables (Windows Native Debugger)
|
|
61
|
+
|
|
62
|
+
When you run `h4-debug app.exe`, the tool leverages the raw Windows Win32 Debugging API (`kernel32.dll`) via `ctypes`.
|
|
63
|
+
|
|
64
|
+
- **Event Loop Integration**: We spawn the process using `CreateProcessW` with the `DEBUG_PROCESS` flag. We then capture `WaitForDebugEvent`, natively intercepting `CREATE_PROCESS_DEBUG_EVENT`, `LOAD_DLL_DEBUG_EVENT`, thread lifecycles, and unhandled exceptions.
|
|
65
|
+
- **Hidden Debug Strings**: GUI applications (like Unity mods, game launchers, or heavy desktop apps) do not pipe logs to `stdout`. Instead, they typically use `OutputDebugString`. `h4-debug` intercepts `OUTPUT_DEBUG_STRING_EVENT`, uses `ReadProcessMemory` to safely read the buffer in real-time, and routes it to your console.
|
|
66
|
+
- **Piped stdout/stderr**: For console-based native applications, we dynamically generate anonymous pipes (`CreatePipe`) equipped with `STARTF_USESTDHANDLES` to natively capture all standard command-line output.
|
|
67
|
+
- **Disk & Network Polling**: Because we refuse to inject DLLs to hook `ws2_32.dll` (Network) or `ntdll.dll` (Disk), we launch a hyper-efficient, high-frequency background daemon (`psutil`). This daemon polls the target process 10 times a second, intelligently indexing newly opened file descriptors (`fd`) and newly active TCP/UDP endpoints, streaming live Disk and Network events directly to the dashboard.
|
|
68
|
+
|
|
69
|
+
*(Note: Debugging installers or protected executables often requires Administrator privileges. `h4-debug` gracefully detects `ERROR_ACCESS_DENIED` [Error 5] or `ERROR_ELEVATION_REQUIRED` [Error 740] and halts, prompting you to elevate your terminal rather than crashing).*
|
|
70
|
+
|
|
71
|
+
### Node.js Deep Hooking
|
|
72
|
+
|
|
73
|
+
When you execute `h4-debug node app.js`, the tool dynamically sets the `NODE_OPTIONS=--require ...` environment variable before executing the Node binary.
|
|
74
|
+
|
|
75
|
+
- **Console & Errors**: Overrides `console.log`, `console.error`, etc., intercepting the arguments and beaming them to the dashboard before passing them along to the original `stdout`. Automatically catches `uncaughtException` and `unhandledRejection`.
|
|
76
|
+
- **Network Interception**: Hot-patches the native `http.request` and `https.request` modules to trace the exact URL, method, and protocol of outbound network calls.
|
|
77
|
+
- **Disk Tracing**: Hooks raw filesystem methods like `fs.open`, `fs.readFile`, and `fs.writeFile`, logging the file paths being accessed.
|
|
78
|
+
|
|
79
|
+
### Python Introspection
|
|
80
|
+
|
|
81
|
+
For `h4-debug python main.py`, the debugger alters `PYTHONPATH` and injects a custom `sitecustomize.py`.
|
|
82
|
+
- **Seamless Boot**: Because `sitecustomize.py` is loaded before any user code executes, we establish the Telemetry Client instantly.
|
|
83
|
+
- **Module Hooking**: We hot-patch `sys.stdout` and `sys.stderr` to mirror all terminal output. We also monkey-patch popular HTTP libraries (like `urllib`, `requests`, and `aiohttp`) to provide granular network request visibility.
|
|
84
|
+
|
|
85
|
+
---
|
|
86
|
+
|
|
87
|
+
## 📦 Installation
|
|
88
|
+
|
|
89
|
+
Install globally via `pip`:
|
|
90
|
+
|
|
91
|
+
```bash
|
|
92
|
+
pip install h4-debug --upgrade
|
|
93
|
+
```
|
|
94
|
+
|
|
95
|
+
*Requires Python 3.8+*
|
|
96
|
+
|
|
97
|
+
---
|
|
98
|
+
|
|
99
|
+
## 🚀 Usage
|
|
100
|
+
|
|
101
|
+
Using `h4-debug` is incredibly simple. Just prefix your standard commands with `h4-debug`:
|
|
102
|
+
|
|
103
|
+
**1. Debug a Windows Executable (GUI or Console):**
|
|
104
|
+
```bash
|
|
105
|
+
# Note: Run your terminal as Administrator if the .exe requires elevation!
|
|
106
|
+
h4-debug installer.exe --silent
|
|
107
|
+
h4-debug game_launcher.exe
|
|
108
|
+
```
|
|
109
|
+
|
|
110
|
+
**2. Debug a Node.js Application:**
|
|
111
|
+
```bash
|
|
112
|
+
h4-debug node index.js
|
|
113
|
+
h4-debug npm start
|
|
114
|
+
```
|
|
115
|
+
|
|
116
|
+
**3. Debug a Python Script:**
|
|
117
|
+
```bash
|
|
118
|
+
h4-debug python app.py
|
|
119
|
+
```
|
|
120
|
+
|
|
121
|
+
### The Dashboard
|
|
122
|
+
|
|
123
|
+
Once executed, `h4-debug` immediately spins up a local web server (usually at `http://localhost:8999`) and provides a URL in the terminal. Open that URL to view the real-time F12-style developer dashboard!
|
|
124
|
+
|
|
125
|
+
The dashboard is broken into intuitive tabs:
|
|
126
|
+
- **Console**: See standard output, errors, and native `OutputDebugString` traces.
|
|
127
|
+
- **Network**: Monitor outbound HTTP/HTTPS connections and raw TCP/UDP socket activity.
|
|
128
|
+
- **Disk**: Track file read/write operations and active open file handles.
|
|
129
|
+
- **System**: Observe process creation, DLL loads, unhandled exceptions, and debugger state.
|
|
130
|
+
|
|
131
|
+
---
|
|
132
|
+
|
|
133
|
+
## 🛠 Advanced Details & Edge Cases
|
|
134
|
+
|
|
135
|
+
### The "Access Denied" Error (Native Debugging)
|
|
136
|
+
If you attempt to debug a Windows executable and immediately see an `Error 5` or `Error 740` in your terminal or dashboard, this means the OS has rejected the debugger attachment.
|
|
137
|
+
- **The Fix**: This is an intended security mechanism in Windows. If an application requests Administrative privileges in its manifest, a non-elevated debugger cannot attach to it. Simply close your terminal, re-open it as **Administrator**, and run the command again.
|
|
138
|
+
|
|
139
|
+
### The Network / Disk Polling Interval
|
|
140
|
+
The native execution wrapper utilizes a `10Hz` (0.1s) polling loop to track open files and socket connections without risking application stability. While this is incredibly robust and will catch the vast majority of I/O (like an installer downloading a payload), microsecond-length file touches might occasionally slip past the poll. This is a deliberate architectural trade-off to ensure 100% stability and zero injection risk.
|
|
141
|
+
|
|
142
|
+
---
|
|
143
|
+
|
|
144
|
+
<div align="center">
|
|
145
|
+
<i>Built for developers who demand total observability without compromising stability.</i>
|
|
146
|
+
</div>
|
h4_debug-0.2.1/PKG-INFO
DELETED
|
@@ -1,23 +0,0 @@
|
|
|
1
|
-
Metadata-Version: 2.4
|
|
2
|
-
Name: h4-debug
|
|
3
|
-
Version: 0.2.1
|
|
4
|
-
Summary: Advanced application proxy debugger and F12-style web console
|
|
5
|
-
Author-email: h4 <h4@example.com>
|
|
6
|
-
Requires-Python: >=3.8
|
|
7
|
-
Description-Content-Type: text/markdown
|
|
8
|
-
Requires-Dist: fastapi>=0.100
|
|
9
|
-
Requires-Dist: uvicorn[standard]>=0.20
|
|
10
|
-
Requires-Dist: websockets>=11.0
|
|
11
|
-
Requires-Dist: Pillow>=10.0.0
|
|
12
|
-
Requires-Dist: psutil>=5.9.0
|
|
13
|
-
|
|
14
|
-
# h4-debug
|
|
15
|
-
|
|
16
|
-
Advanced application proxy debugger and F12-style web console.
|
|
17
|
-
|
|
18
|
-
## Usage
|
|
19
|
-
|
|
20
|
-
```bash
|
|
21
|
-
pip install h4-debug
|
|
22
|
-
h4-debug python main.py
|
|
23
|
-
```
|
h4_debug-0.2.1/README.md
DELETED
|
@@ -1,23 +0,0 @@
|
|
|
1
|
-
Metadata-Version: 2.4
|
|
2
|
-
Name: h4-debug
|
|
3
|
-
Version: 0.2.1
|
|
4
|
-
Summary: Advanced application proxy debugger and F12-style web console
|
|
5
|
-
Author-email: h4 <h4@example.com>
|
|
6
|
-
Requires-Python: >=3.8
|
|
7
|
-
Description-Content-Type: text/markdown
|
|
8
|
-
Requires-Dist: fastapi>=0.100
|
|
9
|
-
Requires-Dist: uvicorn[standard]>=0.20
|
|
10
|
-
Requires-Dist: websockets>=11.0
|
|
11
|
-
Requires-Dist: Pillow>=10.0.0
|
|
12
|
-
Requires-Dist: psutil>=5.9.0
|
|
13
|
-
|
|
14
|
-
# h4-debug
|
|
15
|
-
|
|
16
|
-
Advanced application proxy debugger and F12-style web console.
|
|
17
|
-
|
|
18
|
-
## Usage
|
|
19
|
-
|
|
20
|
-
```bash
|
|
21
|
-
pip install h4-debug
|
|
22
|
-
h4-debug python main.py
|
|
23
|
-
```
|
|
File without changes
|
|
File without changes
|
|
File without changes
|
|
File without changes
|
|
File without changes
|
|
File without changes
|
|
File without changes
|
|
File without changes
|
|
File without changes
|
|
File without changes
|
|
File without changes
|
|
File without changes
|
|
File without changes
|
|
File without changes
|
|
File without changes
|