Is there a way to connect gdb to hopper, then load a dylyb that is loaded by an app and then run the app while stepping through the dylib code? is there a way to do this?
Today (2020) actually you can debug dylibs by opening them in a separate window before starting debugger. When you go back in the callstack window it shows the actual code in the window of dylib. You can also place breakpoints and do whatever you want in it.
For debugging to work you should remove the codesigning of the main executable.
I asked the developer and got a reply indicating that this feature (debugging a dylib), is not available in the current version.
The best way to go for now seems to be to use the available tools to find the right place to edit the code and then reassemble it.
Related
If I try to start debugging through the command "Open" of x64dbg, debugging stops without ever starting and a series of missing DLL errors are shown on the screen.
If I just open the program from WIN and THEN I use the attach command by selecting the process, debugging works.
Unfortunately I wanna "investigate" from the moment the program starts and not when it is already started.
How can I solve it ?
You need some anti-anti-debugging plugins (such as ScyllaHide) for x64dbg mentioned in this page to counter anti-debugging attempts and do some patching if needed:
https://github.com/x64dbg/x64dbg/wiki/Plugins
i coded a big project that runs when I open it in Debug or Release Mode, but when i open it without Debugging (ctrl + f5) it crashs. I searched a long time to find the heap error, but didnt find anything. The problem is i need the running .exe of the programm, so i wanted to ask if there is a possibility to link the windows debugger to the .exe so it always starts with it.
If it doesn't crash right away, maybe this helps:
You can run the executable.
Open your solution in visual studio. Make sure it's the same build.
Open the DEBUG menu and click attach to process.
A window will open, listing all processes that are running. Select the executable that's crashing
Click the DEBUG menu again and select Exceptions (ctrl-alt-E)
Make sure the checkbox "Thrown" is checked for Common Language Runtime Exceptions
Now crash your application.. It will halt at the line that causes it.
Also look for environment directives. like #IF DEBUG #END IF. or #IF RELEASE That kind of stuff. Tricked me a couple of times too..
Good luck. Hope this helps!
You can do various things. First make sure you have a "big out try block" in main. i.e. put the main logic in a try can catch exceptions and report these clearly. This probably isn't what's happening in your case.
You can attach a debugger - including Visual Studio, to a running process - see the "Attach to process" option under the debug menu. If it's built with debug symbols, which you can do, even for release code this may help. If it's optimised you may find it difficult though.
Finally, you could generate a crash dump and inspect that after it's failed. See docs on MiniDumpWriteDump. There are several examples on its usage. Or you can install an abort handler: See here. This mentions _set_abort_behavior which if invoked with _CALL_REPORTFAULT will generate a crash dump too.
I have just started using KDbg and am having a hard time finding the answer to my question. I open a file in KDbg (I opened an executable written in assembly), there is a pop up that says
GDB: Reading symbols from /home/myputer/Desktop/ASMdirectory/chapter5/eatsyscall/eatsyscall...done.
How do I get the option to run the program in the debugger and add breakpoints and etc. It doesn't allow me to click the button to run the program or add any breakpoints, is there an issue here? Am I missing a step? Thanks in advance. BTW I'm using Linux(Ubuntu) and NASM for my assembler.
What are the versions of software you are running?
For example I am running
Ubuntu 12.04,
kdbg 2.5.0 (KDE Development Platform 4.8.5),
gdb 7.4-2012.04,
nasm 2.09.10
You are using Duntemann's book, yes?
I am assuming you changed SECTION .txt to SECTION .text because
when GDB attempts to read symbols it reports "done" instead of "Can't find any code sections in symbol file"
I would recommend using gdb directly instead of kdbg. I do not know of a way to get kdbg to show disassembled code or list (or how to send any gdb commands directly). I think the best that can be done is:
Run kdbg
Open the executable
Switch to the Breakpoints tab
Enter "_start" (which I believe is the only visible symbol you have) in the edit box.
Hit the "Add Breakpoint" button
Hit the "Run" button
Execution should have broken at _start
Switch to the Registers tab
Hit the "Step into by instruction" button to walk through your code
Kdbg does not seem to be able to restart execution. It seems the program must be killed then run again.
We have a single page application that randomly crashes the whole browser tab. I observed the memory for more than an hour but it wasn't increasing and everything looks just fine. Than out of a sudden after some more time passes, the tab crashes.
I looked for a crash dump in
C:\Users\cburgdorf\AppData\Local\Google\CrashReports
but the Chrome-last.dmp is totally outdated. Is there any place where I can look for additional information about the crash? Not to mention it's a hard to reproduce beast.
I wonder if I could start Chrome with windbg attached and wait (2 hours or so sigh) for the tab crash. Would that work?
UPDATE
All of you gave good answers and provided valueable advice for bug hunting. In the end I was able to reproduce the bug and get a clear crash dump using the following steps:
1.) windbg.exe -o chrome.exe
2.) reproduce crash
3.) .dump /ma C:\Path\To\A\CrashDump\File.dmp (as Paul pointed out)
4.) end session and load the crash dum with windbg
5.) use !analyze -v to extract valuable information
Once WinDbg breaks in, use this command to create a full crash dump:
.dump /ma C:\Path\To\A\CrashDump\File.dmp
If you want analyze only specific tab, you should follow below steps.
Open Chrome's Task Manager (View Background Pages option in menu).
Right click on grid and activate Process ID column.
And attach windbg to this pid.
Follow the instructions on http://www.chromium.org/for-testers/bug-reporting-guidelines/reporting-crash-bug to report the renderer crash so the Chromium developers can debug it.
Could you try to use firebug in chrome and give me a log?
http://getfirebug.com/wiki/index.php/Command_Line_API
upd. you need launch chrome with debug option.
--enable-logging --v=1
I have an app built in node.js and I use the node inspector in order to debug.
But it's quite hard because of this:
My breakpoints are never saved after I restart the server
I cannot put a breakpoint on a file that has not loaded yet; so I have to step into from the first script to the one I want; REALLY PAINFULL!
How do you really debug node.js with node inspector?
The videos on how to use node.js are quite misleading as everything is into a module...
http://www.youtube.com/watch?v=AOnK3NVnxL8
or this one the scripts appear are already loaded in the first script
http://www.youtube.com/watch?v=HJOH0-g8f6E&feature=mfu_in_order&list=UL
Edit:
Nobody can answer this question? :s
In javascript you can set breakpoints using the debugger; statement. However, they will only pause node if a debugger is actually attached.
So launch your node script using
node --debug-brk myfile.js
then launch node-inspector and press the play button to continue to the next breakpoint and it will hit your debugger; breakpoint (at least that works for me ATM)
(as noted in the comments: in recent versions of node you no longer have to separately install node-inspector. If you launch node using node --debug-brk --inspect myfile.js you get a url that launches the debugger in your browser).
you still need one extra click after restarting, but at least your breakpoints are saved.
if your breakpoint is not hit automatically, but only after some user action you don't need the --debug-brk of course.
The problem with client-side breakpoints is that it's hard to keep track of the breakpoint position when the file changes. Unlike in an editor, it cannot keep track of lines being changed, etc.
#RyanOlds suggestion of using debugger; statements is also a good one, but you have to make sure the debugger is connected before the statement is evaluated, because it is ignored otherwise. Starting with --debug-brk is a good way to force this, because the execution is paused on the first line allowing you to attach the debugger and then continue the execution.
You could try debugging with node's internal debugger.
Edit: However, according to the v8 DebuggerProtocol it's possible to set breakpoints on script that hasn't been loaded yet AND you can set breakpoints by function, script and more. It should therefore be possible for node-inspector to keep track of your breakpoints (in a session, or whatever). It doesn't do so right now, though.
Maybe if v8 allows a certain piece of code to trigger a breakpoint, similar to nodes debugger?
Edit: It does, you should be able to trigger a break by throwing any old exception (caught or uncaught).
The new version (0.3.x) of node inspector saves breakpoints in browser's local storage and restores them automatically.
https://github.com/node-inspector/node-inspector/pull/116
Try using IntelliJ WebStorm - there's a free trial and licenses aren't outrageously expensive. It lets you save breakpoints in all your files prior to starting up its own internal node process and remembers them across process restarts.
I agree - node-inspector looks brilliant, but is quite useless unless your app has a clear place to set a breakpoint in the top level script just after your source files have loaded, but before you hit the area you want to debug. You can structure your own code this way, but you won't be so lucky with other helpful libraries you want to include. Also... why should a debugging tool dictate your project structure!
Forgetting breakpoints is extremely unhelpful... most of my debug runs take more than one walkthrough, as in other people's code it's easy to step past where you want to be.
You can use node-codein for inspection. It won't do runtime breakpoints but it should ease the inspection process.
https://github.com/ketamynx/node-codein/
Also worth noting.. vscode has a great debugger for node.
https://code.visualstudio.com/
Available on Mac, Linux, & Windows.
It does runtime breakpoints (without the need of writing debugger; statements),
supports variable watches, and even has a call stack window (very nice).
Everything is so automated, it is now my goto over sublime text when using nodejs (and I LOVE sublime).
This is built in now including saving breakpoints. I just tested it in node 7.3.0.
node --inspect --debug-brk app.js
This prints a url like this
To start debugging, open the following URL in Chrome:
chrome-devtools://devtools/bundled/inspector.html?experiments=true&v8only=true&ws=127.0.0.1:9229/c3d5d93e-9d27-41b9-a4da-607e43c9d4f8
Put that in Chrome and you're good to go.
If you want to skip copy/pasting the url, do this:
npm install -g inspect-process
inspect --debug-brk app.js
Unfortunately the inspect-process method doesn't retain the breakpoints :-(.
Here's a video I made: https://youtu.be/rtZKUnks6jI