Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.arch.embedded > #32142

Re: Patch fixed strings in .hex file

Show all headers | View raw

Il 17/01/2024 11:27, David Brown ha scritto:
> On 17/01/2024 08:45, pozz wrote:
>> Il 16/01/2024 19:35, Hans-Bernhard Bröker ha scritto:
>>> Am 16.01.2024 um 13:19 schrieb pozz:
>>>
>>>> I'm wondering how to detect the exact positions (addresses) of 
>>>> serial numbers to fix.
>>>
>>> You do not.
>>>
>>> Instead, you set up linker scripts, linker options and/or add 
>>> __attribute(()) to the variables' definitions to _place_ them at a 
>>> predetermined, fixed, known-useful location.
>>
>> Do you mean to choose by yourself the exact address of *each* string? 
>> And where would you put them, at the beginning, in the middle or at 
>> the end of the Flash? You need to calculate the address of the next 
>> string from the address *and length* of the previous string. It seems 
>> to me a tedious and error-prone job that could be done easily by the 
>> linker.
>>
> 
> How many strings do you need here?

They are 10 strings.


> While it is possible to do all this using patching of odd places in your 
> file, using specific locations is often a better choice.  Since you 
> haven't already said "Thanks for the advice - I tried it that way, it 
> worked, and I'm happy" in response to any post, I would say that now is 
> the time to take fixed location solutions seriously.

There are many suggested solutions and I think all of them can be used 
with success. Just for sake of curiosity and studying, I'm exploring all 
of them.

Sincerely I don't *like* solutions where you need to choose a fixed 
location by yourself. Why you should make a job that can be done by the 
linker?


> The way I always handle this is to define a struct type of fixed size, 
> containing all the information that might be added post-build.  That can 
> be version information, serial numbers, length of the image (very useful 
> if you tag a CRC check on the end of the image), etc., - whatever you 
> want to add.  Strings have fixed maximum sizes and space.
 >
> Make a dedicated section, and in the source code have a default instance 
> of the type in that section, with default values.  (This is especially 
> handy when running from a debugger, as your elf file will not have 
> post-build values.)  Empty strings should be all null characters. 
> Remember to declare it "volatile const".  Your linker file specifies 
> that this section goes at a specific known fixed address (perhaps just 
> after interrupt vectors, or whatever is appropriate for your 
> microcontroller).
> 
> Now your post-build scripts have a simple fixed address to patch the 
> binaries.

How the post-build script should know the exact address of a certain 
field in the struct?

volatile const struct post_build_data {
   uint32_t serial_number;
   uint64_t mac_address;
   uint32_t image_size;
   char s1[32];
   char s2[64];
   char s3[13];
} post_build_data __attribute(...);

I know the fixed address of the symbol post_build_data (the only object 
in my custom section), but now I have to calculate the offset of the 
field s1 in the struct. This calculations is error prone.

In my opinion, it's much simpler to use a production script that 
retrieves, without any error or manual calculation, the address of a 
certain symbol directly from the elf.

 From another post of mine:

readelf -s output.elf | grep string_to_patch | sed -e 's/^ *//' | sed -e 
's/  */ /g' | cut -d " " -f 2


>>> And do yourself one favour: have only _one_ instance of that number 
>>> in your code.  Use concatenation or similar to output it where needed.
>>>
>>> Then you can use tools like srecord GNU binutils to stamp your 
>>> desired number into that fixed location in the hex file.  
>>> Professional-grade chip flashing tools for production environments 
>>> can usually do that by themselves, so you don't even have to edit 
>>> your "official" files.
>>>
>>> Details will obviously vary by tool chain.
>>>
>>
>> Patching the .hex or .bin file replacing 8 bytes starting from a known 
>> address is simple. I would write a Python script or would use one of 
>> srecord[1] tools.
>>
>> [1] https://srecord.sourceforge.net/
>>
> 
> Don't bother with hex or srec files.  Use binary files - it makes things 
> easier.

Yes of course, patching an hex file or a binary file isn't the complex 
task here.

Back to comp.arch.embedded | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Patch fixed strings in .hex file pozz <pozzugno@gmail.com> - 2024-01-16 13:19 +0100
  Re: Patch fixed strings in .hex file David Brown <david.brown@hesbynett.no> - 2024-01-16 13:51 +0100
    Re: Patch fixed strings in .hex file pozz <pozzugno@gmail.com> - 2024-01-16 15:42 +0100
      Re: Patch fixed strings in .hex file David Brown <david.brown@hesbynett.no> - 2024-01-16 16:36 +0100
        Re: Patch fixed strings in .hex file pozz <pozzugno@gmail.com> - 2024-01-16 16:57 +0100
      Re: Patch fixed strings in .hex file dalai lamah <antonio12358@hotmail.com> - 2024-01-16 16:47 +0100
        Re: Patch fixed strings in .hex file David Brown <david.brown@hesbynett.no> - 2024-01-16 18:50 +0100
  Re: Patch fixed strings in .hex file Herbert Kleebauer <klee@unibwm.de> - 2024-01-16 15:07 +0100
    Re: Patch fixed strings in .hex file pozz <pozzugno@gmail.com> - 2024-01-16 15:42 +0100
  Re: Patch fixed strings in .hex file Grant Edwards <invalid@invalid.invalid> - 2024-01-16 15:24 +0000
    Re: Patch fixed strings in .hex file David Brown <david.brown@hesbynett.no> - 2024-01-16 16:38 +0100
      Re: Patch fixed strings in .hex file Grant Edwards <invalid@invalid.invalid> - 2024-01-16 18:32 +0000
    Re: Patch fixed strings in .hex file pozz <pozzugno@gmail.com> - 2024-01-16 17:01 +0100
  Re: Patch fixed strings in .hex file David Brown <david.brown@hesbynett.no> - 2024-01-16 16:39 +0100
    Re: Patch fixed strings in .hex file Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2024-01-17 20:19 +0200
  Re: Patch fixed strings in .hex file Stefan Reuther <stefan.news@arcor.de> - 2024-01-16 17:44 +0100
    Re: Patch fixed strings in .hex file Grant Edwards <invalid@invalid.invalid> - 2024-01-16 18:39 +0000
    Re: Patch fixed strings in .hex file Michael Schwingen <news-1513678000@discworld.dascon.de> - 2024-01-16 19:30 +0000
  Re: Patch fixed strings in .hex file Hans-Bernhard Bröker <HBBroeker@gmail.com> - 2024-01-16 19:35 +0100
    Re: Patch fixed strings in .hex file pozz <pozzugno@gmail.com> - 2024-01-17 08:45 +0100
      Re: Patch fixed strings in .hex file pozz <pozzugno@gmail.com> - 2024-01-17 09:07 +0100
      Re: Patch fixed strings in .hex file David Brown <david.brown@hesbynett.no> - 2024-01-17 11:27 +0100
        Re: Patch fixed strings in .hex file pozz <pozzugno@gmail.com> - 2024-01-17 12:54 +0100
          Re: Patch fixed strings in .hex file David Brown <david.brown@hesbynett.no> - 2024-01-17 13:54 +0100
          Re: Patch fixed strings in .hex file Stefan Reuther <stefan.news@arcor.de> - 2024-01-17 17:39 +0100
            Re: Patch fixed strings in .hex file David Brown <david.brown@hesbynett.no> - 2024-01-17 18:28 +0100
            Re: Patch fixed strings in .hex file Grant Edwards <invalid@invalid.invalid> - 2024-01-17 19:00 +0000
            Re: Patch fixed strings in .hex file pozz <pozzugno@gmail.com> - 2024-01-19 09:10 +0100
      Re: Patch fixed strings in .hex file Hans-Bernhard Bröker <HBBroeker@gmail.com> - 2024-01-18 18:49 +0100
  Re: Patch fixed strings in .hex file pozz <pozzugno@gmail.com> - 2024-01-17 09:57 +0100
  Re: Patch fixed strings in .hex file Don Y <blockedofcourse@foo.invalid> - 2024-01-17 10:03 -0700
  Re: Patch fixed strings in .hex file Paul Rubin <no.email@nospam.invalid> - 2024-01-17 21:42 -0800

csiph-web