Ecosyste.ms: Awesome
An open API service indexing awesome lists of open source software.
https://github.com/hotnops/RemoteDebugView
A DLL that serves OutputDebugString content over a TCP connection
https://github.com/hotnops/RemoteDebugView
Last synced: 21 days ago
JSON representation
A DLL that serves OutputDebugString content over a TCP connection
- Host: GitHub
- URL: https://github.com/hotnops/RemoteDebugView
- Owner: hotnops
- License: mit
- Created: 2021-09-23T18:01:24.000Z (about 3 years ago)
- Default Branch: main
- Last Pushed: 2021-09-23T19:10:21.000Z (about 3 years ago)
- Last Synced: 2024-08-05T17:27:25.768Z (4 months ago)
- Language: C++
- Size: 9.77 KB
- Stars: 33
- Watchers: 2
- Forks: 11
- Open Issues: 0
-
Metadata Files:
- Readme: README.md
- License: LICENSE
Awesome Lists containing this project
- awesome-hacking-lists - hotnops/RemoteDebugView - A DLL that serves OutputDebugString content over a TCP connection (C++)
README
# RemoteDebugView
A DLL that serves OutputDebugString content over a TCP connection
# Usage
You will need to compile the DLL and then call the exported function (Default: DebugView). You can invoke the function using rundll
```
rundll32 RemoteDebugView.dll,DebugView
```
This will start a TCP server bound to localhost on a configured port (Default: 3232). Here is a sample program to write to Debug buffer:
Then, use a tool such as netcat to read the debug output. Included is a rudimentary python tool that reads output from a socket.
# Why
There's been a few times where a tool I wrote is crashing in target space, and I don't have a great way to capture debug output. Starting up DebugView on the target machine is not an option, unless RDP is an option. RemoteDebugView will capture any strings passed to the OutputDebugString(W) functions and host it on a TCP port, so that an operator can use a wide variety of tools to extract helpful debug messages from the target.
Additionally, many programs output *very* interesting information to the Debug buffer, and may assist operators in finding local vulnerabilities or information leakage.
... and then sometimes, you tested and tested, only to have your tool crash in target space. You *could* try to replicate the enivironment locally and trigger the issue, but why not just do it live?
I find myself doing this more often than I care to admit.