yetangitu/ghidra
1
0
Fork 0
mirror of https://github.com/NationalSecurityAgency/ghidra.git synced 2025-10-05 02:39:44 +02:00
Code Issues Releases Wiki Activity

Merge remote-tracking branch 'origin/GP-5185_d-millar_exdi--SQUASHED'

Browse source
This commit is contained in:
Ryan Kurtz 2024-12-17 11:39:03 -05:00
commit f0641fd72a
16 changed files with 855 additions and 37 deletions
Download patch file Download diff file Expand all files Collapse all files

38
Ghidra/Debug/Debugger-rmi-trace/src/main/help/help/topics/TraceRmiLauncherServicePlugin/TraceRmiLauncherServicePlugin.html
View file

@ -825,6 +825,44 @@ bdcedit /dbgsettings NET HOSTIP:IP PORT:54321 KEY:1.1.1.1
'net:port=54321,key=1.1.1.1'.'</LI>
</UL>
<UL>
<LI><B>Type</B>: The type of kernel connection, either "Remote", "Local", or "EXDI".
"Remote", the most common type, indicates two-machine debugging over various
possible connection media, e.g. Ethernet, serial, USB, etc. "Local" is used for limited
introspection into the target on which the debugger is running. "EXDI" is arguably
the most exotic type - it essentially simulates the normal "Remote" connection using
the gdb Remote Serial Protocol. It can be used when connecting to gdbstubs in
platforms, such as QEMU, VMWare, Trace32, etc.</LI>
</UL>
<H4>EXDI</H4>
<P>Setup for EXDI connections is fairly complicated and difficult to get correct.
The argument string typically should be something like:</P>
<UL style='list-style-type: none'>
<LI>
<PRE>
exdi:CLSID={29f9906e-9dbe-4d4b-b0fb-6acf7fb6d014},Kd=Guess,DataBreaks=Exdi
</PRE>
</LI>
</UL>
<P>The CLSID here should match the CLSID in the <B>exdiConfigData.xml</B> file in the debugger architectural directory. If windbg has been
run using EXDI at some point, there will also be an entry in the System Registry for this CLSID. The InprocServer32 subentry
for this CLSID in the Registry should point to a copy of ExdiGdbSrv.dll, typically the one in the same directory. This DLL
must reside somewhere that the debugger has permission to load from, i.e. not in the WindowsApps directory tree.
The <B>exdiConfigData</B> file should be configured for the target you're using. We heavily recommend using <B>displayCommPackets==yes</B>,
as many of the tasks take considerable time, and this is the only indicator of progress.
</P>
<P>The <B>Kd=Guess</B> parameter causes the underlying engine to scan memory for the kernel's base address, which will probably not
be provided by the gdbstub. (<B>Kd=NtBaseAddr</B> is also a valid option, as is eliminating the parameter, but, currently, we have no
idea how to point the configuration at a correct value. Using this option will cause the load to spin pointlessly.) If you can,
we highly recommend breaking the target near the base address, as the search proceeds down through memory starting at the current
program counter. If the difference between the PC and the base address is large, the loading process will punt before useful
values are detected. If anyone understand how to extend this search (or knows how to set the base address to sidestep the scan),
we would really love some guidance.
</P>
<H3><A name="dbgeng_ttd"></A>TTD (Time-Travel Debugging)</H3>
<P>This is a nascent extension to our launcher for the Windows Debugger. The launcher itself