Replies: 4 comments 2 replies
-
|
I agree on pretty much everything you wrote, also looking forward to a usable source loading since that can be quite useful, for example also for exploitation of something where you have the source.
Definitely. In fact, the current/old implementation could be fixed performance-wise by just changing 3 or 4 lines to detect if a file was already attempted to be loaded without success. However I decided to remove it completely since even then it has no real use at the moment.
Definitely possible.
Yes, an option that is disabled by default would solve this. But we should probably think about displaying a hint somewhere that the binary has source mapping so as a user you get notified whenever it's available and don't have to actively look for it.
I think the main difference here is that these are really only debuggers while rizin by default only does static analysis. If I load a binary into a pure debugger, I basically only do this with the attempt to actually run this binary on my current machine where it could do everything anyway, so just triggering some file-reading isn't really a concern.
On unix, there might be a lot in |
Beta Was this translation helpful? Give feedback.
-
|
Idea - right now for PDB we have Something like
(anyhow the current CC stuff is crap I agree, i've never really found it useful) |
Beta Was this translation helpful? Give feedback.
-
|
Another very important thing to consider with DWARF and source code is that often distributions put source code in very different directories from the binary and also the DWARF info are in a completely separated binary (which only contains the DWARF stuff but not the real code/data) |
Beta Was this translation helpful? Give feedback.
-
|
Yes, macOS for example always puts dwarf in a separate binary in a |
Beta Was this translation helpful? Give feedback.
-
|
It would be really really helpful for all those doing debugging of system binaries. |
Beta Was this translation helpful? Give feedback.
-
|
Related issues are: |
Beta Was this translation helpful? Give feedback.
-
#870 removes source code reading for files with dwarf info because the current implementation was very bad. But at the same time viewing matching source code is one of the basic functionality for any debugger , even when not debugging it has educational value for godbolt like comparison between source code and compiled code. So i'd like to discuss how it could be later re-implemented better and what additional functionality it should have.
Performance issues should be solvable using sane implementation. Source code text should probably be loaded only when you try to view corresponding part of binary for first time.
Slightly different approach for displaying the source code could be using the rz_annotated_code interface and corresponding views. It doesn't replace inline view but would be nice to have for panel mode and Cutter where it could be viewed side by side with disassembly.
Displaying of the source code inline should be configurable by an option. That would address @thestr4ng3r concern about untrusted binary being abe to trigger reading arbitrary file path, and is also necessary for basic usability in case you just want to hide it for reducing visual noise.
Not sure how much of the problem it is in practice. I assume that most IDEs and source debuggers will try to read the source files without any special checks. Are there any common cases where just reading a file can cause side effects unless you have intentionally set up your system for it to trigger something? I guess using windows UNC paths which can be abused for triggering network requests would be one such case.
If the binary really is malicious and line info contains offensive data I would expect rest of the debug info to be useless for debugging or type analysis in which case you can just disable dwarf processing completely unless you are trying to fingerprint the binary by exact junk placed in debug info. It would be very weird if author of binary tried to attack the person analyzing binary using file names in debug info but left rest of the debug info with meaningful information instead of just stripping it.
It should be possible to define source code path remapping or source location hints. Unless the binary was just compiled on your computer it's very likely that you have placed the source in sightly different folder than the one used for building the binary.
Beta Was this translation helpful? Give feedback.
All reactions