You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
we can process WinDbg Time Travel Debugging (TTD) traces and extract API calls, string/data references, and other features and analyze them in a dynamic context, like @yelhamer has done with the CAPE sandbox. in a sense, we'd be using TTD as a sandbox.
there would be a good amount of code needed to recognize the interesting cursor locations to pause at (API calls) and the techniques to extract arguments, data references, etc.
we should attempt this after the initial CAPE backend has landed so that capa has all the necessary machinery for dynamic analysis.
i think once this is implemented, we'd be able to do some really cool things around TTD trace visualization, like "here's an interesting point in the program execution, do you want to jump to it in IDA or Binary Ninja?".
this issue differs from #1649 in that this issue is about dynamic analysis of TTD traces, while the other issue is about static analysis of specific snapshots within a TTD trace.
The text was updated successfully, but these errors were encountered:
unfortunately TTD is Windows-only today, since all the current solutions rely on the TTD.dll distributed with WinDbg. while im tempted to try to reverse engineer and re-implement the DLL, i understand it implements an optimized CPU emulator. that would be quite difficult to reproduce.
maybe we could find a way to emulate the TTD.dll on linux/macos. or, naturally, just support the backend on Windows.
unfortunately TTD is Windows-only today, since all the current solutions rely on the TTD.dll distributed with WinDbg. while im tempted to try to reverse engineer and re-implement the DLL, i understand it implements an optimized CPU emulator. that would be quite difficult to reproduce.
maybe we could find a way to emulate the TTD.dll on linux/macos. or, naturally, just support the backend on Windows.
Maybe you can try dumping (exporting) the trace to a file and then read it back when needed. The dumping process is Windows only but the dumped file can be accessed on any platform. This would not be a silver bullet since it is still a quite challenging task, e.g., you need to decide how much information you wish to keep in the trace. Nevertheless, this would at least make it possible to move forward.
we can process WinDbg Time Travel Debugging (TTD) traces and extract API calls, string/data references, and other features and analyze them in a dynamic context, like @yelhamer has done with the CAPE sandbox. in a sense, we'd be using TTD as a sandbox.
there would be a good amount of code needed to recognize the interesting cursor locations to pause at (API calls) and the techniques to extract arguments, data references, etc.
we should attempt this after the initial CAPE backend has landed so that capa has all the necessary machinery for dynamic analysis.
i think once this is implemented, we'd be able to do some really cool things around TTD trace visualization, like "here's an interesting point in the program execution, do you want to jump to it in IDA or Binary Ninja?".
this issue differs from #1649 in that this issue is about dynamic analysis of TTD traces, while the other issue is about static analysis of specific snapshots within a TTD trace.
The text was updated successfully, but these errors were encountered: