0vercl0k / wtf

wtf is a distributed, code-coverage guided, customizable, cross-platform snapshot-based fuzzer designed for attacking user and / or kernel-mode targets running on Microsoft Windows and Linux user-mode (experimental!).
MIT License
1.47k stars 134 forks source link

Try to find a way to copy WinDbgX dbgeng's DLLs instead of legacy WinDbg #196

Open 0vercl0k opened 8 months ago

0vercl0k commented 8 months ago

Currently, wtf tries to find the dbgeng.dll DLLs in a path where the WinDbg that ships with the SDK is (cf https://github.com/0vercl0k/wtf/blob/main/src/wtf/debugger.h#L139).

This is problematic for users when they use the 'new WinDbg' to generate a dump file which is in a format that the WinDbg from the SDK doesn't understand. Those users see the below error message which is confusing:

Initializing the debugger instance.. (this takes a bit of time)
OpenDumpFile(state\mem.dmp) failed with hr=-0x7ff8ffa9

Fixing it manually require to grab the dbgeng.dll & cie and copy them over where wtf is but it is manual.

In theory if I find a way to detect if the WinDbg from the AppStore is installed and where, using those DLLs would always work as they'd be able to load dumps generated from old WinDbg, and the new ones. The issues that I have are:

I guess if 1) is solved, we could try to copy the files for the users and if we fail we could tell them to copy the files over themselves or run as admin.

GanbaruTobi commented 8 months ago

Detect if the App is installed in PowerShell:

Get-AppxPackage -AllUsers | Select-Object -ExpandProperty PackageFullName | Where-Object { $_ -like 'windbg' }

To copy the files into another directory: robocopy "C:\Program Files\WindowsApps\FOUND_NAME_HERE" windbg_app /s /e

Then probably its needed to identify if x86 or x64 or arm. In my case C:\Program Files\WindowsApps\Microsoft.WinDbg_1.2308.2002.0_x64__8wekyb3d8bbwe\amd64\dbgeng.dll has the dll I need.

GanbaruTobi commented 8 months ago

When I place the found dll's into the wtf.exe directory,wtf will overwrite them again with the SDK's:

grafik

0vercl0k commented 8 months ago

Hmmm that would be a bug - let me check this tonight.

Cheers

On Sun, Feb 25, 2024 at 2:13 PM Tobias Mayer @.***> wrote:

When I place the found dll's into the wtf.exe directory, it will overwrite them with the SDK's:

grafik.png (view on web) https://github.com/0vercl0k/wtf/assets/15239745/a0b164fd-9589-4846-ae2f-a2b6e0013617

— Reply to this email directly, view it on GitHub https://github.com/0vercl0k/wtf/issues/196#issuecomment-1963078797, or unsubscribe https://github.com/notifications/unsubscribe-auth/AALIORIE7GGU6255VVFUELDYVOZR5AVCNFSM6AAAAABDWAHGUOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNRTGA3TQNZZG4 . You are receiving this because you authored the thread.Message ID: @.***>

GanbaruTobi commented 8 months ago

When I place the found dll's into the wtf.exe directory,wtf will overwrite them again with the SDK's:

grafik

Okey, in a second test this did not happen, and the source code looks good to me. Might have been a random thing to happen or I did something wrong.

0vercl0k commented 8 months ago

All right cool, that's good to know - thank you for checking it!

Cheers

On Mon, Feb 26, 2024 at 10:02 AM Tobias Mayer @.***> wrote:

When I place the found dll's into the wtf.exe directory,wtf will overwrite them again with the SDK's:

[image: grafik] https://private-user-images.githubusercontent.com/15239745/307625770-a0b164fd-9589-4846-ae2f-a2b6e0013617.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MDg5NzA3NzYsIm5iZiI6MTcwODk3MDQ3NiwicGF0aCI6Ii8xNTIzOTc0NS8zMDc2MjU3NzAtYTBiMTY0ZmQtOTU4OS00ODQ2LWFlMmYtYTJiNmUwMDEzNjE3LnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNDAyMjYlMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjQwMjI2VDE4MDExNlomWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPWVlMThkYmU4MzcxZDQzMmY3YmI2OGEwOWYxZDljY2I5ZThlMjI3NDU3YzFhYTQwMjczYjdkNzNiYmNlZDhmYTUmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0JmFjdG9yX2lkPTAma2V5X2lkPTAmcmVwb19pZD0wIn0.JoEmT9tTVFkUBOOIuCEiGLS4ikBTrf8KpUkWVFnEQuk

Okey, in a second test this did not happen, and the source code looks good to me. Might have been a random thing to happen or I did something wrong.

— Reply to this email directly, view it on GitHub https://github.com/0vercl0k/wtf/issues/196#issuecomment-1964795759, or unsubscribe https://github.com/notifications/unsubscribe-auth/AALIORPAUM5IY2DG3XNMTMTYVTE2VAVCNFSM6AAAAABDWAHGUOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNRUG44TKNZVHE . You are receiving this because you authored the thread.Message ID: @.***>

wumb0 commented 1 month ago

Perhaps it would be useful to add some metadata to a state capture (via snapshot) that indicates the exact dbgeng version being used. If a different version is found by wtf when starting to fuzz then emit a warning. I don't know how granular the reported version of dbgeng is in the extension APIs, but I guess you can just use GetFileVersionInfo on the loaded dbgeng.dll in both snapshot and wtf.