I have a binary file made with nasm -f which I want to do some debugging, or close enough. So far I know, nasm doesn't generate proper symbols for debugging to a binary file, right? which approach could I use to e.g, see each value passed on register/memory a time? I have an "array" in a assembly program that I want to see each value of. Is there any tool would help to perform this task?
If you are on linux, you should use nasm -f elf -F dwarf to get debug information, and make sure you are not stripping them during linking.
Also, to see register or memory contents you don't need debug info.
Related
This is an open ended question, but essentially, I wrote a program in x86 assembly and compiled it to an executable. I accidentally ran the command cp program program.s while attempting to move files around, and I overwrote my asm source code with the binary. I am trying to recover the source file in its original form
I want to note that I also am working in a wsl linux environment and using vscode, and so maybe it's possible to directly recover the file through other ways, like I don't know if vscode saves some kind of cache in case this happens, and please let me know if this train of thought is viable, but I figure my best bet is to disassemble the binary.
I know I can do objdump -d program and get the assembly, but it is not in gas form, and there are a lot of other information in this output, so it would be a lot of manual labor to recover the original .s file with the output of this command. Are there any other ways to better disassemble an exe into the original assembly file?
Thanks
i want to analyse each memory block content produced by a particular process. So what i did was using "gcore pid" to get a core dump of the process, but i do not know how to retrieve the content out, can anyone help?
In general, the good tool to analyze a core dump is the gdb debugger.
So you should compile all your code with the -g flag passed to gcc or g++ or clang (to have DWARF debug information inside your ELF executable).
Then, you can analyze the (post-mortem or not) core dump of your program myprog with the command gdb myprog core. Learn how to use gdb. Notice that gdb is scriptable and extensible (in Python and Guile).
You could (but probably should not) analyze the core file otherwise (without gdb). Then you need to understand its detailed format (and that could require months of work). See elf(5) and core(5).
BTW, valgrind could also be useful.
You could even use gdb to analyze a core dump from a program compiled without -g but that is much less useful.
Starting from an elf file that contains all information needed to fully debug my application, I would like to make an elf that contains only some symbols.
I managed to do this with GNU binutils strip tool :
strip -F elf32-big -p -s -K myFunc1-K myFunc2 -K myVar1 -K myVar2 myApp.elf
My concern here is that myVar1 and myVar2 are structured variables and the debugger cannot dig into them because 'strip' removed the .debug_info section from the elf (.debug_info is where the structure definitions are stored, I understood).
Ideally, I would keep in the elf only whats necessary for the debugger to parse my variables. I played with the options of 'strip'. I played with other binutils (readelf, objcopy, objdump...) after I read this thread. But it gave nothing satisfactory.
How would you do that?
I don't know of a tool that already does what you want.
If I was asked to do this, first I would push back. Rather than trying to strip parts of the debuginfo, I would wonder why we couldn't use the existing split debuginfo approach. Coupled with build-ids this has the nice property that one can ship stripped executables but still get full debugging when needed -- just by pointing gdb to the debuginfo ELFs.
That said, if I did have to write it, I would say, first define exactly what you want to keep. Then, write a program to read the DWARF (say, using the elfutils libraries for this) and then write out new DWARF with just the desired information.
This is not extremely hard (see the "dwz" tool for an example of a DWARF manipulator...) but also not all that easy, either.
If I try to disassem Linux kernel, it takes quite long time due to the big size of Linux elf-binary.
Is there a way to only disassem a function or a symbol, for instance start_kernel function?
What I don't want is to use grep, since it anyway takes very long time.
Unless you have compiled kernel with debugging symbols included, there are no symbols for objdump to use. It is highly unlikely the kernel binary has debugging symbols included, unless you've specifically compiled it with such options.
In case your kernel binary does have debugging symbols, they can be found using nm -g and then further used with objdump -j <symbol>.
You can not disassemble particular function or symbol alone but instead of full kernel image, you can disassemble specific object file.
ex.
objdump -DS XYZ.o > XYZ.S
Really quick question here. I'm working in Ubuntu, I have a simple "Hello World!" program in assembly which I have assembled into x86 assembly. Now I want to turn that machine code into an ELF executable which my computer can run. I am aware that I could just assemble directly to ELF, the purpose of my inquiry is to discover how to make ELF binaries out of assembled machine code.
Thanks!
Final ELF executable files are typically built out of other ELF files, reorganized by the linker. The easiest way, of course, would be to specify ELF as the output format of your assembler.
1) If you really want to do this, you could start with an "empty" ELF file (that you get from compiling or assembling nothing, etc.). Then you could use objcopy --add-section, which allows you to add an arbitrary file as a section in an existing ELF file.
This will create a minimal ELF file:
$ echo "" | gcc -c -o empty.out -xc -
2) Alternatively, you could include your raw binary into another assembly file using something like nasm's incbin, which would then need to be assembled as an ELF.
3) A third option (the best so far) would be to provide your raw binary to the linker, and use a custom linker script to tell it what section to put it in (determined from the input file name). The -b flag before an input file will tell ld what type of file it is. This should let you use your flat binary file.
One of the first obstacles you're going to face is getting the entry point to point to your code. Off the top of my head I'm not sure how to edit that.
There is a Python library, pyelftools that may help you in your quest.
If it's really assembled, then it's already in the ELF format (compilers targeting Linux generally store the object code in ELF object files as well).
However, if you want a fully-functioning executable, you have to feed the object file to a linker.