Replies: 26 comments
-
@dav93ide Hmmm, not positive what happened here. Any chance you clicked one of the buttons in the Threads window rather than the Objects window? (The buttons in the Threads window control your position in the trace, whereas the buttons in the Objects window match the debugger controls. If not, did you StepInto, StepOver, Finish, or StepLast? Am guessing StepInto, but... Alos, anything peculiar about your target? Do you see the same behavior if you, say, debug /usr/bin/xclock? |
Beta Was this translation helpful? Give feedback.
-
Hello, No I didn't clicked on the thread menu and the program is a really simple program from a reversing exercises. Alert Dialog and message section with: From the interpreter: Also with xclock I don't see any disassemble, but the "clock" appear! I tryed with others really simple programs from another exercises and I get the same error as my first message. |
Beta Was this translation helpful? Give feedback.
-
@d-millar Thank you for your help, sorry I tryed to upload the programs by changing the extensions but it's not possible xD Maybe I'm doing something wrong I start the debugger with "Debug c1 in GDB locally IN-VM": When I try one of these buttons to step the execution: I get on the bottom of the window the message: |
Beta Was this translation helpful? Give feedback.
-
@dav93ide OK, excellent - I had the right idea, but the wrong area! So, those buttons are to help you navigate the static listing - they take you to the next Instruction, Data, Undefined, I forget what L is, Function, non-Function, etc. You want the buttons in the Objects window that look like little yellow arrows. (Thank you for including the screenshots - that helps Immensely!!!) |
Beta Was this translation helpful? Give feedback.
-
P.S. I don't think any of those messages indicate a problem. In fact, looking at your screen, I think you're in pretty good shape! |
Beta Was this translation helpful? Give feedback.
-
@d-millar Oh ok thank you, I was so dumb xD First time I'm trying thank you. Now I try to step with the debugger! In this program there's file writing, maybe is because he doensn't have the permission for the files? If so how can I give the permissions? |
Beta Was this translation helpful? Give feedback.
-
@d-millar I tryed to pass through using the buttons you tell me but I still get an error and if I click "resume" the program doesn't stop at the breakpoints I set. If I use single step or step over it works thank you! |
Beta Was this translation helpful? Give feedback.
-
@dav93ide No problem - everyone has to start sometime! Regarding permissions, you may be right. I see that "zsh 1: permesso negato" message in the Interpreter - that's a little disturbing. If you run this program without the debugger, do you see the same message? On the breakpoint front, here's where things get a little complicated. A la normal gdb, we allow you to set breakpoints in the Static listing, even if that memory isn't mapped yet. The little pink bit in the Dynamic listing (which is above the Static listing, but almost invisible) suggests the "info proc mappings" command has failed, and we've defaulted to trying to map in all of memory (0-0x7fffffffffffffff). That means the debugger probably doesn't know where your program lives. If you open up the Modules panel, you can try to map the current program (in the Static listing) to the appropriate module in the Modules list (assuming you have one). If you don't have anything in that list, let me know - we'll try to figure out how to sidestep that. Just to confirm, maybe try running "info proc mappings" in the Interpreter window. Once the (Static) program is associated with (Dynamic) memory, you can either set the breakpoint in the Dynamic or the Static listing, and they should be active (red/blue? not gray). You should also be able to click and activate any existing grayed-out breakpoints. If you would, if you get that error again, hit details and send us the stack track. That'll help me narrow down what's going on there. |
Beta Was this translation helpful? Give feedback.
-
Thank you! I didn't marked the file as executable so I was getting the error above, now I've fixed it. About the linking where is the "Modules" panel? Also how can I pass console arguments to a program I want to debug? |
Beta Was this translation helpful? Give feedback.
-
So the easiest way to add arguments is to connect to the Agent in the Target window (which will start the agent but not the target), then Launch (not Auto-launch) from the Objects window, which allows you to enter the cmd plus parameters. The Modules window is probably in one of the two stacks, e.g. under Breakpoints or under Regions. The little tiny arrows allow you to navigate the stack (i.e. get to windows off screen). |
Beta Was this translation helpful? Give feedback.
-
Where there is the stack I can only find "Regions", "Stack" and "Console" but no Module Do you mean the Regions window? |
Beta Was this translation helpful? Give feedback.
-
Nope, Regions and Modules are two different things - try up to the right (?) under Breakpoints. Also, maybe try going to the top menu and going to Windows->Debug->Modules. Might help (although it might leave it buried) - will try it on my system in a sec. |
Beta Was this translation helpful? Give feedback.
-
Ok I opened the modules panel (from window -> debugger) but there's nothing here :/ |
Beta Was this translation helpful? Give feedback.
-
Interesting, try "maintenance info sections" in the Interpreter and, if that works, "maintenance info sections ALLOBJ nosections". |
Beta Was this translation helpful? Give feedback.
-
Also, maybe, is the Modules node under Inferior also empty when open? |
Beta Was this translation helpful? Give feedback.
-
First output command: (gdb)maintenance info sections Second output command: (gdb)maintenance info sections ALLOBJ nosections |
Beta Was this translation helpful? Give feedback.
-
After I ran the command the module window populated: I re-try the debugger? |
Beta Was this translation helpful? Give feedback.
-
Hmmm, that's a little odd and sounds like a bug on our part, but, yes, re-try! (Fingers crossed) |
Beta Was this translation helpful? Give feedback.
-
More to the point, you should be able to enable a breakpoint, and clicking on any of those base addresses should bring up the appropriate bytes in the Dynamic Listing. Looks like c1 is not in the modules list - you might have to step once and refresh the Modules list from the tree. (Checking, I think this is a know issue for some gdb targets.) |
Beta Was this translation helpful? Give feedback.
-
@d-millar Hello sorry for late answer I was busy. |
Beta Was this translation helpful? Give feedback.
-
Also only the "Step Into" button works right, all others like "Step Over", "Finish" and "Step Last" don't work. |
Beta Was this translation helpful? Give feedback.
-
@dav93ide No worries as far as the "late answer". We're here and any answer helps us out - hopefully you too. OK, so on the problem at hand, in your second screenshot, as you I think realized, the program has run to completion and so everything is disabled. You can see this from the fact that the process in the Objects window is greyed out, as well as the "inferior exited" messages. So, obviously, missed the breakpoint. I believe this is because Ghidra is still not making the association between the program in the static listing and the running target process. There are several possible solutions for this. The easiest, albeit least satisfying, solution is to set the breakpoint in the Interpreter at the dynamic address, i.e. "break 0x55555540071e". I think that will guarantee it's enabled. Seting the breakpoint in the Dynamic listing "should" do the same, i.e. if you go to 0x55555540071e (G -> 0x55555540071e:8) and set the breakpoint (K), the breakpoint should be active. You can verify that it's been set using "info breakpoints" in the Interpreter or making sure the icons in the Breakpoint window are not grey or split. I would definitely be interested if this does not work. The third thing I would try is to do exactly what you've already done, but make sure the breakpoint is enabled. You can do this, as mentioned, using raw gdb commands in the Interpreter, by clicking the greyed-out breakpoints in the Breakpoint window, or by clicking that tiny little button in the Messages line that says, "There are ineffective breakpoints that can be placed." Basically, it looks like you did everything correctly, but, for reasons that are still unclear to me, the breakpoint was not activated. That is to say, it was associated with the program in gdb and Ghidra, but not with the running process. Regarding the other stepping commands, in "main" you have to be a little careful. "Finish" is the equivalent of "end the program" from main, as there's nowhere to go from the current stack location. "Step over' should work, but, if you step over a call that terminated the program without returning to the instruction after the call, whether because of the normal control flow or an exception handler, you're out of luck again. ("Step last" just repeats whatever step command you did last.) |
Beta Was this translation helpful? Give feedback.
-
@d-millar But I think I didn't understand the "Third Thing", do you mean to right-click on the breakpoint in the breakpoints window and then click on "enable breakpoint"? Sorry about that but I'm a little noob on disassembly ecc, I'm still learning (: |
Beta Was this translation helpful? Give feedback.
-
@dav93ide Yep, exactly. If the breakpoint is only present in the Static listing (and, correspondingly, the top half of the Breakpoints window), you can enable in at least four different ways: (1) as you mentioned, right-click and select "Enable", (2) click (or possibly double-click) the icon in the top half of the Breakpoints window, (3) click the icon in the Static listing, or (4) click the button embedded in the "There are ineffective breakpoints..." message in the Debug Console. There are technically two cases you could be in here with the breakpoint disabled - in the first, the breakpoint will be present in the top half of the Breakpoints window and the Static listing (which typically is true before you've started the debugger or if you had breakpoints in the program before you started the debugger), or, in the second, the breakpoint will be mirrored in the Static and Dynamic listings and the top and bottom halves of the Breakpoint viewer but not a solid colored circle (typically the case if you or the debugger has decided to disable the breakpoint). A little confusing, I'll admit - am blaming gdb. :) Glad you're enjoying the tool and learning about RE (me too) - always interested in any suggestions you might have for improving it! |
Beta Was this translation helpful? Give feedback.
-
@dav93ide I'm going to move this issue to Discussions because I think it may help other folks down the line. Feel free to continue the conversation here (or file a new ticket) if you have new questions. |
Beta Was this translation helpful? Give feedback.
-
@d-millar Thank you for your help and time! I will write here if I have another questions (: |
Beta Was this translation helpful? Give feedback.
-
Hello, I'm trying to use Ghidra Debugger but it doesn't work..
I attach the debugger and start it but nothing happens,
I just get some warning in the messages board:
#############################################################################
jar:file:/usr/share/ghidra/Ghidra/Framework/Docking/lib/Docking.jar!/images/dialog-warning.png | Already tracking trace breakpoints
jar:file:/usr/share/ghidra/Ghidra/Framework/Docking/lib/Docking.jar!/images/dialog-warning.png | Already tracking trace breakpoints
| Generating offer for os=GNU/Linux arch=i386:x86-64
| Selected first mapping offer:
jar:file:/usr/share/ghidra/Ghidra/Framework/Docking/lib/Docking.jar!/images/dialog-warning.png | Resync: Missed loaded module/library: /usr/lib/debug/.build-id/3f/d3cdd423a18458d9db3a5e50a2b3c0d4529c07.debug | [] |
jar:file:/usr/share/ghidra/Ghidra/Framework/Docking/lib/Docking.jar!/images/dialog-warning.png | Resync: Missed loaded module/library: system-supplied DSO at 0x7ffff7fca000 | [] | Mon May 23 04:07:00 CEST 2022
jar:file:/usr/share/ghidra/Ghidra/Framework/Docking/lib/Docking.jar!/images/dialog-warning.png | Resync: Missed loaded module/library: /home/z3r0/Scrivania/All/Ghidra/ghidra_project_session_one/exercises/c1 | [] |
jar:file:/usr/share/ghidra/Ghidra/Framework/Docking/lib/Docking.jar!/images/dialog-warning.png | Resync: Missed loaded module/library: /usr/lib/debug/.build-id/ae/60c7fd6964429befbea7c351f495224659211e.debug | [] |
jar:file:/usr/share/ghidra/Ghidra/Framework/Docking/lib/Docking.jar!/images/dialog-warning.png | Resync: Missed unloaded module/library: /lib64/ld-linux-x86-64.so.2=agent.gdb.manager.impl.GdbModuleImpl@32678054 | [] |
jar:file:/usr/share/ghidra/Ghidra/Framework/Docking/lib/Docking.jar!/images/dialog-warning.png | Resync: Missed unloaded
module/library: /lib/x86_64-linux-gnu/libc.so.6=agent.gdb.manager.impl.GdbModuleImpl@1cb2c7cf | [] |
| local Pty session. PID = 189911 | [] |
#############################################################################
On the Interpreter board I only get this message:
(gdb)
Temporary breakpoint 1, 0x000055555540071e in main ()
But if I click to go to the next instruction nothing happens..
When I click to step the debugger I also get this error on the bottom of the window:
Unable to locate another instruction pass the current range, in the current direction
What I'm doing wrong? :/
Thank you!
Beta Was this translation helpful? Give feedback.
All reactions