I have what I think is a stack corruption.
I have an stack variable (a pointer ) in the position:
0x7000C0E4 ; the normal information stored is 0x700022A5
I know that from time to time some unexpected code trashes the high part of the word getting one of these values:
0x000022A5 or 0x005122A5; I guess is a 16 bits write operation.
I'd like to set a breakpoint to stop when someone writes in that address but only when after the write the content of the stack address is 0x000022A5 or 0x005122A5
I guess I need two conditional breakpoints.
Anyone knows idf this is possible and the syntax to setup such breakpoints.
After #Holger comments I've setup what I think is the conditional breakpoint I need. But it does not work as expected. See he attached picture. Let me recall:
I know someone is corruption the 0x7000c0de position, writing a 0x0000 instead of the expected value 0x7000. I use that as a pointer and the resulted pointer is 0x000022A5 instead of the expected 0x700022A5. I've setup 2 breakpoints , one at the trap function (I fall here after trying to access to the bad address) and a conditional Write breakpoint which should stop only when some writes the 0x0000 and additionaly the 0x7000c0dc address content is 0x000022A5. As you see in the picture my debugger stops only in the TRap function and at that moment the content of the 0x7000c0dc is effectively 0x000022A5. So why this conditional breakpoint is not working?
This should be done with data breakpoints.
The command in TRACE32 for data breakpoints is this one:
Break.Set <address> /Write /Data.<width> <value>
In your particular case you'll need two data-breakpoints. E.g. like this:
Break.Set 0x7000C0E6 /Write /Data.Word 0x0000
Break.Set 0x7000C0E6 /Write /Data.Word 0x0051
This will only work if your CPU supports data breakpoints and if the change on the stack was actually done by the CPU. It will not stop if the memory was altered by DMA or a peripheral hardware component or so.
If your CPU does not support data breakpoints TRACE32 will emulate the data breakpoints in a way that it will actually stop every time data is written to the given address, but immediately restart the CPU if the written data does not match.
Related
I know how to create/modify a breakpoint to stop only on a specific thread using breakpoint modify <breakpoint-id> -T <thread-name>, but can I do it the other way around, preventing the breakpoint to stop on a specific thread?
I have a log thread that use the same function I'm trying to debug on other threads and it's annoying to have to let it continue every time it hits.
You can do this sort of thing using the lldb Python API and Python breakpoint callbacks. The callback returns a "should stop" value, i.e. if it returns True, you stop at the breakpoint, and False you continue.
So for instance:
(lldb) breakpoint command add -s python -o 'return frame.thread.name != "MyThread"'
is what you wanted. Note, in this example, I didn't provide a breakpoint ID. In lldb that means "act on the last set breakpoint". But you can also supply the breakpoint ID if the one you want to add the command to doesn't happen to be the last breakpoint you set. And if you want to add it to multiple breakpoints, you can specify a breakpoint ID list.
There's more on the API's and the callback format here:
https://lldb.llvm.org/python_api.html
https://lldb.llvm.org/use/python-reference.html#running-a-python-script-when-a-breakpoint-gets-hit
Note, however, that breakpoints with should-stop callbacks will force a stop every time the breakpoint is hit. lldb auto-continues pretty quickly, so for many applications this isn't a problem. But just getting from the stop over to the debugger and back is not cheap, so if your breakpoint is in a work loop and getting hit hundreds of thousands of times a second, this is going to slow down the run. If that ends up being a problem and you control your source code, tricks like the one Eljay suggested in the comments can be really handy.
I made a small debugging application specifically to modify a protected executable, when using the application I can hand off the debugging by suspending the process then calling DebugActiveProcessStop and attaching x64dbg to the process and resuming.
The target I'm debugging performs a checksum on itself in 488 inlined places, with my debugging application I breakpoint all of these with a byte pattern search, when the breakpoint hits I intend to place a hardware breakpoint after the checksum command and then undo all of my memory modifications. When the hardware breakpoint hits I read some pertinent registers, store them in a file and patch that checksum to always pass without performing the checksum calculations the next time it is called.
The issue arrives that when I call ContinueDebugEvent from my debugger to get to the hardware breakpoint the target always crashes after a few steps with an access violation(c0000005). While testing things I found that if I suspend the process instead of calling ContinueDebugEvent and then pass the debugging over to x64dbg and let it ContinueDebugEvent the target runs fine. I debugged x64dbg with x64dbg to see what it's doing differently and the call it makes has what appears to be identical parameters to my call to ContinueDebugEvent, just the processId, the threadID, and 10002 (DBG_CONTINUE)
Does anyone know how/why the target would crash when both of our debuggers are making the same function call?
I'm trying to set breakpoing (break ) after attaching to process in background mode (attach &). However I got
Cannot insert breakpoint 1.
Cannot access memory at address 0x5560c872b71a
Any reason why it's happening?
Setting breakpoint in foreground mode is fine.
Program was written in C++.
Any reason why it's happening?
The program must be stopped when inserting a breakpoint into it. Inserting a breakpoint is not an atomic operation, and writing to program code (which is what breakpoint insertion amounts to) while that code is executing may result in all kind of badness.
Use interrupt command to stop the process and bring it to foreground, insert your breakpoint, then continue & to put it into background again.
I have a network software that I need to debug. It forks at multiple places and I need to debug one particular function handling one particular request.
Is there any way to setup a global breakpoint that would be caught even when it is in an inferior process?
I cannot use follow-fork-mode child because this will follow the first request, not the one I need to debug.
One way to do this is to have gdb remain attached to all the processes. Then you would set your breakpoint and run the program as usual; the breakpoint would fire in any sub-process that happened to hit that location. You can use breakpoint conditions to try to reduce the number of hits.
To put gdb into multi-inferior mode, I use this:
set detach-on-fork off
set non-stop on
set pagination off
Depending on your version of gdb, you might also need set target-async on.
This mode can be a bit peculiar to work in. For example, when one thread stops, the other keep going. Also, breakpoint stops are reported, but not always obvious; and I think gdb doesn't immediately switch to the stopping thread (this may have changed in gdb git, I forget).
How are SW breakpoints handled (conceptually) by gdb stub or server (I assume client stub and server handle them in pretty much same way)?
I'm interested in a 'bare metal' target where the gdb stub/server runs, and both breakpoints and single stepping use software interrupts.
My actual questions:
When a breakpoint is hit, how is the stored instruction run so that the breakpoint can be 're-installed' and the (saved) machine status (including register contents) is not changed from the moment of hitting the breakpoint?
=>When is the breakpoint re-installed and how? Between breakpoint hit and entering the command interpreter, or during the next single step or coninue?
Also how does single-stepping over breakpoint work such that the original non-breakpoint instruction gets executed, and the breakpoint still remains there after being single-stepped over?
[edit]
Forgot: the document "GDB Internals" seems to be missing that info - and actually the whole subchapter about single stepping in the "Algorithms" chapter.
[edit2]
Ah, I seem to need stronger glasses: The 'Internals'-manual says:
"When the user says to continue, GDB will restore the original instruction, single-step, re-insert the trap, and continue on."
The single stepping over breakpoint, however, is still open question.
The single stepping over breakpoint, however, is still open question.
It's done exactly the same way as continue, except for the last step ("and continue on"). That is:
Process stops. GDB "looks around", discovers that $ip points to one of its breakpoints.
User issues continue, next, step or stepi command.
Restore original instruction (i.e. remove the breakpoint)
Single-step process
Re-insert breakpoint
Continue (this is done for continue but not for next, step or stepi).
For stepi, return control to the user (we are already at the next instruction due to step 4 above). For next, continue single-stepping until we reach a line in source that is not the same line we were on at step 1 above.