A way to setup breakpoints in Immunity Debugger using commands? - debugging

I am looking to set up breakpoints before I start debugging in Immunity, like I do with x32/64dbg. bp VirtualAlloc / bp WriteProcessMemory and the like. Is there a way I can do this without having to search through the code for these commands?

Related

How can i set global breakpoint using windbg

Can i set global breakpoint, using windbg, like softice (for example: bpx MessageBoxA) so it will break on all user mode running apps?
On Windows 95/98/ME, the main system libraries like kernel32 and user32 are shared by all processes. A normal usermode debugger cannot set breakpoints at all on these libraries on these systems.
On Windows NT based systems each process has its own copy and if you set a software breakpoint the modified page will not affect other processes.
If you want to debug a process and its children, you can do this with WinDbg. A script could probably set the breakpoint for each new process.
If you want to catch it in all processes for some insane reason you could maybe use a kernel debugger and a processor breakpoint ba?
If MessageBox is the actual thing you want to capture, you could probably use SetWinEventHook or a CBT hook instead of a debugger...

Debugging in Visual Studio Code without breakpoints, checking the function calls stack

I am trying to dive in a really big codebase. I am using Visual Studio Code. I always used debugger with setting the breakpoints, but this time I just would like to become familiar with a new codebase and see where is the code responsible for particular program commands execution. Is there an option to run debugger step by step without setting breakpoints in VSC? Or where can I find e.g. what functions where called during my program execution? In Call Stack section I see only the threads number.
I see a command
editor.debug.action.runToCursor
if you don't want to set breakpoints. It has no default binding so you will have to make your own. I tested it and it works. When your code stops - at your cursor - you should see the call stack (assuming the call stack panel is not hidden).

how to set a memory breakpoint in windbg kernel mode?

I would like to set a memory breakpoints on access in windbg in the kernel mode debugger
I want the debugger breaks everytime a specific module in usermode is hit with the kernel debugger.
but I've read somewhere its impossible to set it, in order to make a memory breakpoints I have to write a plugin to make it
I tried to use SDbgExt plugin with the !vprotect command, but it fails to set memory bp
If I have to write a plugin to allow memory bp in kernel mode It has to be a driver?
I've read some chapters in windows internals book, but it doesn't help me at all.
I couldn't find too much info how to start deal with it
You can set breakpoints on user mode addresses from kernel mode. The only thing you should take care is to switch to the right process with ".process /i " command
If it is a one-off breakpoint -- that is, you are content with process being destroyed by debugging -- zero out the entire module using e command (edit memory). Set the whole thing to cc (which is int 3 as far as I remember)... zeros will do as well. You will break as soon as you touch any of the module's code.
Next step, remember where you were (relative to the module) and set a proper breakpoint.
Hope that helps.
(editing) Do you have full symbols? If you do, did you try bm module!*
Sounds like you want to set a "breakpoint on access" but instead of specifying an address you want to specify a range? I have never seen it done in windbg. The BA breakpoints uses HW debug registers instead of inserting INTs like SW breakpoints so this is definitely HW platform specific.
I have done this on an ARM chipset once using a HW debugger. ETM on ARM allows you to set triggers on address ranges.

Attach to specific process using IDA + WINDBG in kernel debugging

I want to debug a specific process on a remote system and the only way i can do that is to use the kernel debugging method.
It works pretty good with just WINDBG, but i think ida can give me the extra edge i need for a better reversing experience.
So far debugging with windbg was successfull but now when i am using the windbg plugin in ida:
what i am actually experiencing is that i cant get the extra analysis from ida, all i can do is attach only to the process it self (only one available to attach to). and in the Modules window all i can see is the ntkrpamp.exe, which i assume is the kernel process.
i can use all WINDBG regular commands like !process 0 0, etc.. and can debug normally but nothing shows in the IDA window
I have never debugged dynamically using IDA but i can see it is possible..
could it work aswell in a kernel debugging session?
Edit:
I just noticed it is possible to analyze a model if i set a breakpoint with the windbg plugin and when IDA hits that breakpoint, this module is added to the IDA Modules windows.
It would be a lot easier if i could just analyze it without pre-putting a breakpoint on the specific module and waiting for it to hit.

Assembly code breakpoint does not work as expected

I am developing a STM32F2 device using GCC 4.7.4 and a Lauterbach Combiprobe JTAG debugger. In my code, I have the following statement to always break at a certain spot for testing purposes:
asm volatile ("BKPT #0");
This is the only breakpoint. When I run the program, I can see that my program reaches the breakpoint, but I cannot step beyond this breakpoint using my JTAG debugger. Instead, I have to move the PC counter past this instruction to get the program to execute.
This was working in the past, but I am at a loss to figure out why the behavior is different now. Any clues or hints would be appreciated.
There are so many broken JTAG debuggers. Probably you installed an update for the JTAG adapter?
When you have GDB as Debugger you might check if you can add a macro set PC=PC+4 to a button or key. But if this is possible depends on your IDE.
There is no general rule what happens with the program counter if you have a breakpoint instruction in you application code. Some CPUs stop at the address containing the breakpoint instruction, others stop after the breakpoint instruction.
Since you use the tag "lauterbach" I assume you are using a TRACE32 debugger from Lauterbach.
If you think the debuggers behavior was different in the past, I think you should contact the Lauterbach support.
For now you can workaround the issue with the following TRACE32 command
Break.Set T:0x1000 /Program /CMD "Register.Set PP r(PP)+2"
(where 0x1000 stands for the address, where your BKPT instruction is located.)

Resources