i'm just learning how to use GDB.
I'm trying to set a breakpoint for an external binary that is called by my program. I do not have the source of the other binary, so I can't compile it with the -g option.
Both my file and the other (a Framework) are written in Objective-C.
I managed to find the address of the line where I want to set my break, but of course GDB so not allow to use that, since I'm working with my file.
How can I tell GDB to set a breakpoint on that binary file, on that address?
To break at a specific address you can use:
break *0x12345
The "*" tells gdb to interpret the remainder of the "linespec" (see the manual) as an expression.
Often, even without debug info, you can still set breakpoints by name. This will work as long as there are "linker" symbols of whatever flavor in the library, and as long as you know the linkage name.
Related
I want to change where in the elf file execution starts. For example I have a basic hello world program in a elf file. The actual code is located at an offset of 0x1000 bytes into the file. I want to move that code to, lets say, a 0x900 offset and modify the file so that it starts executing at 0x900. I know this sounds kinda useless but it does serve a purpose.
First you compile/assemble (clang/as/...) your program into a hello.o ELF object file. At this point, you would normally let the compiler driver finish the job and emit an ELF executable.
You can instead use the linker (lld/ld/...) and specify the entry point with --entry 0x900. You can also do this with a linker script. Note that if you do this, you have to handle a bunch of stuff that the compiler driver normally handles for you. The warning from the Oracle linker manual says:
When you invoke the link-editor directly, you have to supply every
object file and library required to create the intended output. The
link-editor makes no assumptions about the object modules or libraries
that you meant to use in creating the output.
I was having trouble with the linker for the embedded arm gcc compiler, and I found a tutorial somewhere online saying that I could fix my linker errors in arm-none-eabi-gcc by including the argument -specs=nosys.specs, which worked for me, and it was able to compile my code.
My chip is an ATSAM7SE256 microcontroller, which to my understanding is an arm7tdmi processor using the armv4t and thumb instruction sets, and I've been compiling my code using:
arm-none-eabi-gcc -march=armv4t -mtune=arm7tdmi -specs=nosys.specs -o <exe_name>.elf <input_files>
And the code compiles with no issue, but I have no idea if it's doing what I think it's doing.
What is the significance of a spec file? What other values can you set with -specs=, and in what situations would you want to? Is nosys.specs the value I want for a completely embedded arm microcontroller?
It is documented at: https://gcc.gnu.org/onlinedocs/gcc-11.1.0/gcc/Overall-Options.html#Overall-Options
It is a file containing switches to override standard defaults for various build components such as the compiler, assembler and linker. For example it can be used to replace the default C library.
I have never seen it used; typically bare-metal embedded system builds explicitly specify --nostdlib then explicitly link the required library. It could be used for environment specific build environments to link other default code such as an RTOS I guess. Personally I'd rather make all that explicit on the command line that hiding it in a file somewhere.
Essentially it applies the switches specified in the file as if they were defaults, so can be used to define defaults for specific build and execution environments.
The format of the specs file is documented at https://gcc.gnu.org/onlinedocs/gcc-11.1.0/gcc/Spec-Files.html#Spec-Files
Without seeing both the linker errors and the content of the nosys.specs file in this case it is difficult to say how or why it solved your linker problem. The alternative solution of course would be to apply whatever switches are in the specs file directly.
I have a Config.h file which includes various preprocessor conditionals based on the environment. The project has 2 targets. Via the preprocessor arguments, if the environment is the first target we may have BASE_URL = #"https://firsttarget.com/", whereas if the environment is the second target we may have BASE_URL = #"https://secondtarget.com/".
For legal purposes, if someone were to recompile the assembly, and go hunting to strings etc... we cannot have somebody finding the string #"https://firsttarget.com/" if they were looking into the binary for the second target app.
So my question is... are strings behind preprocessor conditionals removed during Archive if they are not relevant?
Sections in code between #ifdef and #endif (or #else) are not seen by the compiler unless the symbol given on the ifdef line is defined. You can easily show this by writing something that won't compile in such a section. And since the compiler doesn't see that code there is no way the value of that define can end up in the binary.
To see exactly what the compiler will work with you can select an implementation file in Xcode and chose "Product > Perform Action > Preprocess" from the menu. This will show you exactly what the compiler will work with. Of course there will also be the content from all the system .h files that are imported, so your code most likely is at the very end. Your #define lines will be stripped too, so to really check which strings will be used you need to chose a file that actually uses those macros.
And finally you can do the same thing an attacker might do - use the strings utility on the compiled binary and see what's in there. In Xcode build your app and select the "Show in Finder" option for your app bundle from the products group. There select "Show package contents" to open app your actual app bundle. The actual binary is in there with the same name as your bundle but no file extension. Then open a terminal window, type "strings " (that is the word strings followed by a space) and drag the binary on top of this. Then confirm with return. You will get a long list of every readable string from the binary (including every selector).
As the title stated, I want my compiler to fail when I include some header files; for example, <cmath>
Is that possible with just compiler flags? Or do I have to actually delete those headers?
#include <cmath> has nothing to do with any library, and everything to do with a header file. Assuming that you really do mean that you want compilation to fail if you include a particular header file, you should be able to leverage GCC's support for specifying include directories through environment variables.
To do so, create or edit an appropriate environment file. If you are using GNU bash on Debian, for example, you can create a file /etc/profile.d/gcc-include-dirs. Everything readable in /etc/profile.d is sourced when a shell is launched, so it will apply to all shells started after that point. (To be absolutely certain, you may want to log out and back in once, then issue env | grep INCLUDE to confirm.) Create such a file with your favorite editor and add the following to it:
export C_INCLUDE_PATH=/usr/local/include/fail:${C_INCLUDE_PATH}
export CPLUS_INCLUDE_PATH=/usr/local/include/fail:${CPLUS_INCLUDE_PATH}
Make sure the file is readable by everyone (chmod 644 /etc/profile/gcc-include-dirs) and that it is owned by root (chown root:root /etc/profile/gcc-include-dirs).
You can also put the file elsewhere and simply source it when needed, if you only need this behavior at specific times. In that case, logging out from the shell in question and logging back in will restore GCC's normal behavior (you don't need to log out from the entire session, just that particular shell instance). Starting a subshell and sourcing the file from within that subshell will also work nicely in that case; just exit when you are done.
Then create a file /usr/local/include/fail/cmath with the following content:
#error "Failing because you included 'cmath'"
Make sure that file too is readable by everyone and owned by root. #error and its evil twin #warning emit a fatal error and a compilation warning, respectively, so whenever this file gets included, GCC will encounter a #error preprocessor directive resulting in the emission of a fatal error which causes the compilation to fail.
If you want to override this behavior for a single compilation, simply use gcc's -I parameter to specify the path to the directory where the real math.h lives. Since -I takes precedence over $C_INCLUDE_PATH and $CPLUS_INCLUDE_PATH this means that you then include the C library's version. For example, cc -o mathprogram -I/usr/include mathprogram.c will use the math.h in /usr/include when you #include <math.h> regardless of what might be in /usr/local/include/fail, because it looks first in /usr/include.
Since this only affects compilation (and only compilation started through a shell), everything that is already on your system will be completely unaffected (unless they have some weird dependencies to those two environment variables).
For c* headers, you may need to also create the corresponding *.h header with content identical to the c* header. This is because e.g. cmath might simply map to math.h (the name of the same header in C). Simply make another file just like the one above, but complain about math.h instead. (GCC doesn't care, but it makes diagnostics easier.) You may also need to put files in other places (I'm not sure exactly what include directory structure GCC wants for C++ headers); in that case, find / -name cmath (or something similar) will give you an idea of the structure you need to replicate under /usr/local/include/fail.
Do note that this will not stop people simply copying the relevant parts of the header file into their own source code; there is nothing magical about the header files from the compiler's point of view. Depending on exactly what you are trying to protect against, this may be an issue.
What about simply using a pre-processor symbol to omit the library header(s)?
Compiling with the gcc option -DDONT_WANT_LIBS will fail due to the missing library declarations in the library header file.
#ifndef DONT_WANT_LIBS
#include<specific_library_header.h>
#endif
...
...
let us assume that there is a application (i have its executable) that reads a file (of some unknown format). I want to trace the input (e.g. a file) that is parsed by a executable i.e. I want to know when a input is read and how is it "consumed" by the executable. Is there a generic way to setting breakpoints to do so? I asked for a generic method because I may not be using a particular debugger.
thanks
-Sanjay
The generic way for settings the breakpoints could be as follows:
Load the executable in the debugger.
Get a list of all intermodular calls in the executable.
At least some of the calls in the list are Windows API functions. The most common functions that are used for reading a file are ReadFile and ReadFileEx. The executable might also use NtReadFile. Set breakpoints on these functions.