Date: Sun, 30 May 2021 17:49:29 +0200 From: Tomasz CEDRO <tomek@cedro.info> To: Christoph Kukulies <kuku@kukulies.org> Cc: Morten Bo Johansen via freebsd-questions <freebsd-questions@freebsd.org> Subject: Re: Including a binary file into an .elf file - ld expert around? Message-ID: <CAM8r67AUwNS306vazpxy%2ByrQ_Yyce5J5wYNrmR2OsWg1N=ac%2BQ@mail.gmail.com> In-Reply-To: <81A08357-DD92-416E-B397-8A15EE7D5B7D@kukulies.org> References: <81A08357-DD92-416E-B397-8A15EE7D5B7D@kukulies.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, May 30, 2021 at 4:40 PM Christoph Kukulies <kuku@kukulies.org> wrote: > I’m linking an object file to a .elf binary for downloading into an STM32F407-DISC1 target. Normally I could flash the binary (.bin) file. > But when I want to debug it, .ELF format comes into the scene. I am working with ZEPHYR RTOS for MCU firmware development (I used ARM MBED for some time but left it behind). You may find some hints over there: https://docs.zephyrproject.org/latest/guides/build/index.html I am using gcc-arm-embedded package that contains all necessary tools for compile, debug, link, etc. Then I am using pyOCD to flash and debug firmware. Usually build process results in HEX BIN MAP and ELF generation. Most important is ELF because it can be loaded into arm-none-eabi-gdb in order to debug firmware, also it can be easily converted to HEX. You can convert ELF to HEX with: % arm-none-eabi-objcopy -O ihex firmware.elf firmware.hex Then you can flash it with: % pyocd flash firmware.hex You are now sure that ELF is in sync with HEX. pyOCD even allows you to flash ELF directly :-) In order to debug firmware you launch pyocd as debugserver on one console: % pyocd gdb Then you attach to it with gdb in remote mode: % arm-none-eabi-gdb firmware.elf (gdb) target remote localhost:3333 (gdb) monitor reset halt (gdb) break main (gdb) c You should jump into the breakpoint main() now. You can set a breakpoint in any source file line with `break main.c:<line_number>`. `arm-none-eabi-gdb -tui` comes handy with ncurses based window showing you the source code directly. arm-none-eabi-objdump and arm-none-eab-objcopy are part of binutils and comes really handy in various binary files analysis and conversion. I am not sure if I understand your problem correctly - you want to add some token into the resulting firmware binary after compilation as part of device provisioning? If you use Zephyr or any other RTOS that allows you to define Flash Map as partitions you can simply create a partition for your provisioning data: https://docs.zephyrproject.org/latest/reference/storage/nvs/nvs.html More generic approach would probably imply using linker map script in order to create you own region (or .data or .bss) of some size located at some address then fill that memory region with data or linking them at build time. Also you would have to map that region to some sort of const or dynamic data type that will be used in your firmware application (i.e. use that token as char[] holding the token). When you know where excatly the data will be located in the firmware image (that also implies target device memory) you can also write over the BIN file in that place as part of provisioning. With linker script you can create area that will be always present at some specific address (and you can assume anyone interested will also know the location). You can also obtain address for each created binary and then fill that part of memory / firmware image if you want its location to change somehow between builds and make reverse-engineering a bit harder. Another approach is to create a self-test-and-provision routine as part of your firmware, using non-volatile-memory-storage to store keys/tokens, also you would have a self-test to verify device operations any time. You could run that routine on first device run after production in order to both provision device with unique data and obtain self-test results - process can be automated and results can be stored in the device database. If you do not want this kind of stuff to occupy your flash memory you can build such self-test-and-provsion to run from RAM, inject it and launch with pyOCD over JTAG/SWD, it will provision and test your device, but it will disappear after power-off. In any case if you provision your devices you may also want to think of some sort of firmware checksum dedicated to each image after token is placed inside :-) https://wiki.osdev.org/Linker_Scripts https://hydrasky.com/malware-analysis/elf-file-chapter-2-relocation-and-dynamic-linking/ https://stackoverflow.com/questions/1563760/aligning-static-arrays-in-the-bss-section-of-linker-file Hope any of this helps :-) Tomek -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAM8r67AUwNS306vazpxy%2ByrQ_Yyce5J5wYNrmR2OsWg1N=ac%2BQ>