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


Groups > comp.arch.embedded > #32143

Re: Patch fixed strings in .hex file

From David Brown <david.brown@hesbynett.no>
Newsgroups comp.arch.embedded
Subject Re: Patch fixed strings in .hex file
Date 2024-01-17 13:54 +0100
Organization A noiseless patient Spider
Message-ID <uo8im6$20hfg$1@dont-email.me> (permalink)
References <uo5s8d$1cjl8$1@dont-email.me> <l0o0kcFat0kU1@mid.dfncis.de> <uo80im$1t6mh$1@dont-email.me> <uo8a1l$1v1eq$1@dont-email.me> <uo8f5k$1veo9$1@dont-email.me>

Show all headers | View raw


On 17/01/2024 12:54, pozz wrote:
> 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.
> 

I thought you were storing serial numbers?  But okay, if you need 10 
strings you need 10 strings.  The number is just a detail.  (But if the 
number were 200 strings for supporting different languages, you might do 
things differently.)

> 
>> 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.
> 

Fair enough.

> 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?
> 

You do so because it makes live much easier.  It is the same reason you 
write your patching script in Python, rather than C.

> 
>> 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?

You figure it out /once/ - using one of many possible methods.  Counting 
with static asserts to check, or looking at the binary after putting 
canaries in the sample data.

If you think that you might change the struct often, you can use 
separate variables and put them all in the same section, then look at 
the map file.  In practice you rarely need to do something like that.

> 
> 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.
> 

Static assertions are your friend here.

> 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.
> 

I doubt it is simpler.  But of course it is possible, and what is 
simpler for me is not necessarily the same as simpler for you.

>  From another post of mine:
> 
> readelf -s output.elf | grep string_to_patch | sed -e 's/^ *//' | sed -e 
> 's/  */ /g' | cut -d " " -f 2
> 

You are using a Python script to do the patching.  Use pyelftools and do 
this all in the one Python script.  That way, future you who has to 
maintain this system will not build a time machine to go back and 
strangle the past you that thought this monster made sense.  These kinds 
of pipes can seem elegant, but they are write-only and a maintainer's 
nightmare.

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