Many resources state that Firmware image is an ELF file/format. I've checked that by executing file command using several firmware images (.bin), the outcome of this command doesn't mention anything related to ELF. Unlike when I executed the same command over ELF files, where I was receiving something like ELF 32-bit LSB executable, Renesas SH, version 1 (SYSV), statically linked, not stripped.
The reason I'm asking about that, I want to test an approach for detecting malicious ELF files, I already have the ELF malicious files, but I don't have benign ELF files, therefore was thinking if I can use Firmware images as benign ELF files.
Most Firmware will be in a binary format, referred to as a bin file.
So these bin files would not be useful for your test.
Here is an answer discussing the difference between the two formats.
https://stackoverflow.com/a/2427229/7275012
Related
For background, my eventual hardware target is a custom ASIC with several MCUs and DSPs, and I need to make a single "boot" file from that.
Our codebase is modularized, and can support building each appropriate target for each processor.
CMake is configured with the target architecture and output in ./build/. The CMake scripting handles choosing the right source files when a module has specific source files for a given processor and building the appropriate libraries and to executable images/elf files.
What I haven't quite resolved is how to have an 'uber' CMake project that builds each architecture, then takes the appropriate elf files from each architecture and incorporates them in the "bootfile" to be downloaded to the target. I want to make sure that when I change the source in one of the DSP source files, the affected libraries rebuild for that, and the executable rebuilds, then that executable triggers a rebuild of the bootimage generation. (or maybe the cortex image depends on a generated header file or something).
Can anybody point to some examples of something like this? Or maybe the appropriate CMake functions to use?
I know I can do it in bash/bat/powershell but I'd like to be able to do this so it integrates well with VSCode and the CMake Tools extension.
Eg:
/home/gem5/build/X86/gem5.opt --debug-flags=TLB,Cache
/home/gem5/configs/example/se.py --cpu-type=DerivO3CPU --caches
--mem-type=SimpleMemory -I 10000 -c out --options="1 in_16.txt out.txt" >> test2.txt
The bold part in the SE CLI for Gem5 shows my input to it. How exactly does Gem5 process this and obtain the instructions to be simulated? Which files should I be looking into for this? As far as I know, no tutorials mention this.
out is a regular ELF userland executable, e.g. a C hello world, just like the ones you would run on your Linux host.
Usage of dynamically linked executable is described at: How to run a dynamically linked executable syscall emulation mode se.py in gem5? so generally statically linking is easier.
gem5 parses the ELF format, places memory into the right locations, puts the PC in the right location, and kicks off simulation, just like the exec syscall of the Linux kernel would.
Several runnable examples are available here.
As we all know, GRUB can boot an ELF executable kernel. But here, in source code of GRUB, in which file and/or directory, the source of ELF loader resides? Also which file contains source code of Stage1 and Stage2?
Why are there separate objdump binaries for different toolchains, something like arm-none-eabi-objdump?
Why can't the objdump executable be used alongwith the particular switch? For example -marm to get the dump about the arm binary?
The binary files for different architectures are interpreted in a different way. So the same binary code will interpret into totally different machine instructions on different CPU architectures. As for objdump, the most clear example can be shown with --disassemble switch, which is instructing it to convert the binary into assembly instructions. But the assembly instructions are totally different for different architectures, so the objdump utility has to know the right one.
When it comes to using the terminal to build libraries manually and such I unfortunately do not have much experience and I'm stuck a bit here.
I've downloaded a library for objective-c which came with makefiles and such.
I can see that the folder also contains an executable file called "libtool", I did some searching and I suppose this is the program I have to use to build the neccessary .a files? Unfortunately I couldn't really find any useful article for this that seemed to work.
The folder for the library contains some .sh files, .pc files and also some .la files, but I'm a bit unsure of which ones I have to use as input to the libtool program to compile them into a .a file.
So my question is what files do you have to input into libtool to compile them into the necessary .a file? And what commands do you use exactly to accomplish this?
Thank you all for your time :)
First a little introduction to static libraries:
Static libraries in Unix environments (like Mac OSX, and Linux too) are actually just an archive of object files created by the ar command line program.
That is what the .a extension stands for: Archive.
To create a static library with some object files you can use the command like this:
ar crv libmy_library.a objectfile1.o objectfile2.o
As for your actual question, libtool should be called automatically from the makefile, creating the library, which is the file ending in .la. However, this is not the real library, the real library is in a hidden directory. You can find it by doing e.g.
find . -name '*.a'
But like I said, the makefile should already take care of everything, including installing the correct library in the correct place when you do e.g. make install.
For information about libtool, see this site.