Should I use GDB or Radare2 for reversing an executable(I am a beginner)?
I try to programming in C and I got a SegFault. I want to Reverse Engineer it to get experience in Assembly and see where I get the SegFault.
For debugging an executable you built from source yourself, GDB is intended as a debugger. You can use layout reg to get a disassembly + registers view which can help understanding segfaults, if looking at C variables didn't help.
Debug info from compiling with gcc -g means you don't need to reverse-engineer anything, just use a normal debugger. But to get experience in asm, using a debugger both ways (source view and asm view) can help you understand how the compiler used certain asm instructions to implement each C statement. So you definitely want a debugger that can take advantage of debug info. There are some GUI GDB front-ends, like https://www.gdbgui.com that can be easier to use than command-line GDB.
But see also How to remove "noise" from GCC/clang assembly output? for more about seeing how C compiles to asm.
I haven't used radare2. I assume it has features that are good for intentionally-obfuscated executables without source, which is the opposite of what you have from compiling your own C programs with a normal compiler.
I would recommend Radare2 because it's clearer than GDB and easier for beginners ;)
Related
I want to understand how GCC works, therefore would like to know which functions are executed in which sequence. For me, it is hard to understand it by only looking at the GCC source code.
Is there any tool to track the internal functions that are being called by GCC when compiling a c file?
You can use debugger to execute gcc step-by-step, but gcc it is quite complicated piece of software.
I'm compiling code from the command line with g++ on Mac OSX and have an error when I run my code that results in an EXC_BAD_ACCESS
I've seen that the most helpful way to debug this kind of error is with Zombie objects that don't deallocate when released and then complain when code tries to release them.
However, it seems that NSZombie options are available in Xcode/Objective C.
So my question is there any way to use this functionality/equivalent in programs simply compiled code like
g++ file1.cpp -g -o executable
debugged with
gdb executable
Thanks.
Zombie objects are a concept of Objective-C, not C++, and relate to reference counting issues, which C++ doesn't use (unless you count smart pointers and Enabling Zombies won't help you with that anyway).
So, to answer your question; No, there is no way to use that functionality.
If you want to find the issue then you'll need to use a debugger.
assembly programming in Emacs how to?
I want Emacs to do following things
1. assembling
2. run the just before made program inside Emacs
3. debugging with watching flags and registers as like ollydbg or softice
4. decompile executable file for see what assembly codes are made by c
but I don't know how to do this
could somebody let me know ?
Which operating system (and machine architecture) are you using? I think that's quite essential information for questions about assembly programming.
I'll try to answer your four points anyway:
Just run your assembler (e.g. as) from M-x compile.
Run it from a shell buffer or from shell-command (bound to M-!).
Emacs' built-in graphical debugging support is started with M-x gdb. You may have to look for some external debugger support package if GDB is not suitable for your purposes.
For disassembling object code, I'd use GDB. But I think if you have the C sources, it would be better to compile them with the -S flag to see the assembly code emitted by the compiler instead of what can be reconstructed from the machine code.
Since you mention SoftICE, I'm assuming you're on windows.
(Good old times, by the way. If anybody ever used SoftICE on windows 9x, he/she will know what I mean :)
I don't use Emacs, but here's how to get started:
Get the tools you need to assemble your program (ie: at least, the assembler and the linker). On windows, the MASM package comes with everything you need : http://www.masm32.com/
Figure out wich commands you need to compile a simple hello world.
Configure Emacs so that it runs the above commands for you
I'm pretty sure this is possible but I'm not sure how to go about it. I'm very new to building with GCC in general and I have never used FreeRTOS, but I'd like to try getting the OS up and running on a TI ARM Cortex MCU but with a slight twist: I'd like to get it up and running with Pascal. I'm curious:
Is this even possible to get work? If not, the next issues are kind of moot points.
From my Delphi days, I vaguely recall the ability to access functions in C libraries. I'm wondering if I would have access to the C routines in FreeRTOS.
If I use the GCC version (preferable) would I be able to debug using OpenOCD on the target? I'm not quite sure how debug symbols work and if it's more or less language agnostic (hopefully, in this case).
As kind of a bonus question a bit outside the scope of the original query, can I simulate FreeRTOS on an x86 processor (e.g. my development PC) for easier debugging during development? (With a Pascal program, of course..)
I haven't found any documentation on achieving this, so hopefully someone here can shed some light! Any resources would be most helpful. Like I said, I'm very new to this kind of development. I'm also open to suggestions if you think there is a better alternative.
FYI, my preferred host configuration would be something similar to:
Linux (Ubuntu/Debian)
Eclipse IDE for development, unit testing, and hopefully simulation / debugging
OpenOCD for target debugging
GNU Pascal + FreeRTOS on target
FreeRTOS is C source code, so like you say you would have to have some mechanism for linking C with your Pascal programs. Also, FreeRTOS relies on certain registers to be used for things like passing a parameter into a task (as a hypothetical example, the task might always expect the parameter to be in register R0) so you would have to ensure the ABI for the C compiler and the Pascal compiler was the same - or have your task entry in C then have it call a Pascal function (very nasty). Then there is the issue of interrupts, calling inline macros, etc. I would say this would be extremely difficult to achieve.
Both GNU Pascal and Free Pascal support linking to C (gcc) and ARM, as well as calling pascal code from C etc. Writing a header and declaring the prototypes with cdecl is all there is to it.
Macros are a bit bigger problem. Usually I just rewrite them to inline functions (what they should have been anyway). Except for the macro/header issue, the problems are more compiler specific functionality (which you also would have a problem with when porting from one C compiler to the next)
If you prefer TP/Delphi dialect, Free Pascal is the better choice.
I run my old Delphi code fine on my sheevaplug.
There is already an example for FreeRTOS/GCC/OpenOCD on a TI Cortex-M3 (was Luminary Micro Cortex-M3). Be aware though that this is a really old example and both the Eclipse and OpenOCD versions used are out of date.
Although there is an Eclipse project provided, the project is configured as a standard make (as opposed to a managed make) project, so there is a standard makefile that can be just as easily executed from the command line as from within Eclipse.
http://www.freertos.org/portLM3Sxxxx_Eclipse.html
How do I use GDB to debug a program which do not have debugging symbols on a 32-bit x86 processor? Inspecting the function arguments, local variables, resolving pointers would be useful to know how to do.
The intention is not really to use this for reverse engineering, as I'm sometimes just too lazy to install the debugging symbols and would be great to know how to get some basic information out of gdb.
To start out, you can do;
gdb "whatever"
break __libc_start_main
r
that will setup a breakpoint in libc's crt0 code and allow you to break before main, even if the target binary is totally stripped.
That will get you to a running state at a breakpoint before most user code. You can then single step, dissasemble, dump memory etc... to your heart's content.
This works on all platforms, the fact your asking about IA-32 / x86 does not matter.
Without debugging symbols, you can only debug at the ASM level. Ok you get a bit more information, but you're not going to get very far unless you understand a bit of ASM and the code the compiler generates. This will let you do a simple inspection of local variables etc if you know what you're doing.
If you have the source, it's going to be far easier just to recompile it.
All you can do is look at registers and the contents of the stack - you'll have to do everything by inferring what things are used for, as Draemon mentions.
Well, the absolutely most important thing is that you be able to unwind the stack. There are three ways this can be ensured:
Build debugging symbols with -g
On systems that do C++ exception unwinding via tables (probably anything ELF these days?), the -funwind-tables flag will tell it to generate such tables regardless of language, and GDB can use these tables (at least, with x86 linux it can).
Or, failing those, at least make sure that -fomit-frame-pointer isn't enabled