In one project I have many quasi-fixed strings that I'd like to keep in
non volatile memory (Flash) to avoid losing precious RAM space.
static const char s1[] = "/my/very/long/string/of/01020304";
static const char s2[] = "/another/string/01020304";
...
Substring "01020304" is a serial number that changes during production
with specific device. It has the same length in bytes (it's a simple hex representation of a 32-bits integer).
Of course it's too difficult and slow to rebuild the firmware during production passing to the compiler the real serial number. I think a
better solution is to patch the .hex file generated by the compiler.
I'm wondering how to detect the exact positions (addresses) of serial
numbers to fix.
The build system is gcc, so I could search for s1 in the elf file. Do
you know of a tool that returns the address of a symbol in the elf or
map file?
Could you suggest a better approach?
In one project I have many quasi-fixed strings that I'd like to keep in
non volatile memory (Flash) to avoid losing precious RAM space.
static const char s1[] = "/my/very/long/string/of/01020304";
static const char s2[] = "/another/string/01020304";
...
Substring "01020304" is a serial number that changes during production
with specific device. It has the same length in bytes (it's a simple hex representation of a 32-bits integer).
Of course it's too difficult and slow to rebuild the firmware during production passing to the compiler the real serial number. I think a
better solution is to patch the .hex file generated by the compiler.
I'm wondering how to detect the exact positions (addresses) of serial
numbers to fix.
Il 16/01/2024 13:51, David Brown ha scritto:
On 16/01/2024 13:19, pozz wrote:
In one project I have many quasi-fixed strings that I'd like to keep
in non volatile memory (Flash) to avoid losing precious RAM space.
static const char s1[] = "/my/very/long/string/of/01020304";
static const char s2[] = "/another/string/01020304";
...
Substring "01020304" is a serial number that changes during
production with specific device. It has the same length in bytes
(it's a simple hex representation of a 32-bits integer).
Of course it's too difficult and slow to rebuild the firmware during
production passing to the compiler the real serial number. I think a
better solution is to patch the .hex file generated by the compiler.
I'm wondering how to detect the exact positions (addresses) of serial
numbers to fix.
The build system is gcc, so I could search for s1 in the elf file. Do
you know of a tool that returns the address of a symbol in the elf or
map file?
Could you suggest a better approach?
In the source code, put the serial number in as "PQRXYZ" or some other
distinct string of characters. Generate bin files, not hex (or
convert with objcopy). Then do a simple search for the special string
to find its position and replace it with the serial number using a
simple Python script or your other favourite tool (awk, sed, perl,
whatever).
I thought about this approach, but is it so difficult to have the same
exact sequence of bytes somewhere else in the output?
Oh, and in the source code, don't forget to make the string "volatile".
Why?
On 2024-01-16, pozz <pozzugno@gmail.com> wrote:
I'm wondering how to detect the exact positions (addresses) of serial
numbers to fix.
Assuming there's a symbol associated with the address, the link map
will tell you what the address is.
In one project I have many quasi-fixed strings that I'd like to keep in
non volatile memory (Flash) to avoid losing precious RAM space.
static const char s1[] = "/my/very/long/string/of/01020304";
static const char s2[] = "/another/string/01020304";
...
Substring "01020304" is a serial number that changes during production
with specific device. It has the same length in bytes (it's a simple hex representation of a 32-bits integer).
Of course it's too difficult and slow to rebuild the firmware during production passing to the compiler the real serial number. I think a
better solution is to patch the .hex file generated by the compiler.
I'm wondering how to detect the exact positions (addresses) of serial
numbers to fix.
The build system is gcc, so I could search for s1 in the elf file. Do
you know of a tool that returns the address of a symbol in the elf or
map file?
Could you suggest a better approach?
In the source code, put the serial number in as "PQRXYZ" or some other
distinct string of characters. Generate bin files, not hex (or convert
with objcopy). Then do a simple search for the special string to find
its position and replace it with the serial number using a simple Python
script or your other favourite tool (awk, sed, perl, whatever).
I thought about this approach, but is it so difficult to have the same
exact sequence of bytes somewhere else in the output?
Oh, and in the source code, don't forget to make the string "volatile".
Why?
I'm wondering how to detect the exact positions (addresses) of serial
numbers to fix.
The build system is gcc, so I could search for s1 in the elf file. Do
you know of a tool that returns the address of a symbol in the elf or
map file?
Could you suggest a better approach?
Un bel giorno pozz digitò:
In the source code, put the serial number in as "PQRXYZ" or some other
distinct string of characters. Generate bin files, not hex (or convert >>> with objcopy). Then do a simple search for the special string to find
its position and replace it with the serial number using a simple Python >>> script or your other favourite tool (awk, sed, perl, whatever).
I thought about this approach, but is it so difficult to have the same
exact sequence of bytes somewhere else in the output?
Extremely unlikely, especially since you use text strings and therefore you actually use 64 bits (eigth ASCII characters) to represent a 32 bit number. Besides, you don't need to use an ASCII string as the placeholder, you can use any 64 bit number.
If for example your binary file is 1 MB, there is one chance over 2.2 trillion to have the same number duplicated somewhere else.
Oh, and in the source code, don't forget to make the string "volatile".
Why?
To avoid that the compiler will optimize the code and "obfuscate" your string. I don't think it is very likely, but it is not impossible,
especially if you use a very aggressive optimization level.
On 16/01/2024 16:24, Grant Edwards wrote:
On 2024-01-16, pozz <pozzugno@gmail.com> wrote:
I'm wondering how to detect the exact positions (addresses) of serial
numbers to fix.
Assuming there's a symbol associated with the address, the link map
will tell you what the address is.
Making the symbol extern linkage (remove the "static") would help with that!
Am 16.01.2024 um 13:19 schrieb pozz:
The build system is gcc, so I could search for s1 in the elf file. Do
you know of a tool that returns the address of a symbol in the elf or
map file?
Last time I needed that, I hacked it up myself; at least back in 32-bit times, ELF was not that hard (but I had to do that anyway to convert ELF
into something the controller could boot).
Am 16.01.2024 um 13:19 schrieb pozz:
The build system is gcc, so I could search for s1 in the elf file. Do
you know of a tool that returns the address of a symbol in the elf or
map file?
Last time I needed that, I hacked it up myself; at least back in 32-bit times, ELF was not that hard (but I had to do that anyway to convert ELF
into something the controller could boot).
Define your memory allocations explicitly. Instead of building a binary
and hacking the strings, place the strings at a fixed address and
regenerate the ELF or .hex file containing them from scratch. Whether
you then give the fixed addresses a name using linker magic, or just
cast pointers, is a matter of taste.
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.
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/
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
Il 17/01/2024 11:27, David Brown ha scritto:
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?
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;
In one project I have many quasi-fixed strings that I'd like to keep in non volatile memory (Flash) to avoid losing precious RAM space.
static const char s1[] = "/my/very/long/string/of/01020304";
static const char s2[] = "/another/string/01020304";
...
Substring "01020304" is a serial number that changes during production with specific device. It has the same length in bytes (it's a simple hex representation of a 32-bits integer).
Of course it's too difficult and slow to rebuild the firmware during production
passing to the compiler the real serial number. I think a better solution is to
patch the .hex file generated by the compiler.
I'm wondering how to detect the exact positions (addresses) of serial numbers to fix.
The build system is gcc, so I could search for s1 in the elf file. Do you know
of a tool that returns the address of a symbol in the elf or map file?
Could you suggest a better approach?
Am 17.01.2024 um 12:54 schrieb pozz:
Il 17/01/2024 11:27, David Brown ha scritto:
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?
It's not you vs. the linker. You co-operate. You need to tell the linker about your chip anyway ("code is from 0x1000 to 0xc000, data is from
0xc000 to 0xd000"). So you can as well tell it "version stamp is from
0xcc00 to 0xd000, data only before 0xcc00".
If you have your identification information in a fixed place, you can,
for example, more easily analyze field returns. It's easy for your field service has to change something, and it's easy to do software updates
that preserve the identification information. You don't need to figure
out which software build is running on the chip and what the address of
the structure happens to be in that one.
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?
By defining the struct in a compatible way. For example....
volatile const struct post_build_data {
 uint32_t serial_number;
 uint64_t mac_address;
...this is a bad idea, because in most (but probably not all) chips,
uint64_t after uint32_t means there's 32 bits of padding, so if you need serial-before-mac, you should at least make the padding explicit. There
also might be endian problems.
Using only char/uint8_t fields gives you a very high chance of identical structure layout everywhere (`uint8_t mac_address[8]`).
On 16/01/2024 13:19, pozz wrote:
In one project I have many quasi-fixed strings that I'd like to keep
in non volatile memory (Flash) to avoid losing precious RAM space.
static const char s1[] = "/my/very/long/string/of/01020304";
static const char s2[] = "/another/string/01020304";
...
Substring "01020304" is a serial number that changes during production
with specific device. It has the same length in bytes (it's a simple
hex representation of a 32-bits integer).
Of course it's too difficult and slow to rebuild the firmware during
production passing to the compiler the real serial number. I think a
better solution is to patch the .hex file generated by the compiler.
I'm wondering how to detect the exact positions (addresses) of serial
numbers to fix.
The build system is gcc, so I could search for s1 in the elf file. Do
you know of a tool that returns the address of a symbol in the elf or
map file?
Could you suggest a better approach?
Another - perhaps more reliable - method would be to put the string in
its own section with __attribute__((section('serial_number'))), and then
have a linker file entry to fix it at a specific known address.
Am 17.01.2024 um 12:54 schrieb pozz:
Il 17/01/2024 11:27, David Brown ha scritto:
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?
It's not you vs. the linker. You co-operate. You need to tell the linker about your chip anyway ("code is from 0x1000 to 0xc000, data is from
0xc000 to 0xd000"). So you can as well tell it "version stamp is from
0xcc00 to 0xd000, data only before 0xcc00".
If you have your identification information in a fixed place, you can,
for example, more easily analyze field returns. It's easy for your field service has to change something, and it's easy to do software updates
that preserve the identification information. You don't need to figure
out which software build is running on the chip and what the address of
the structure happens to be in that one.
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?
By defining the struct in a compatible way. For example....
volatile const struct post_build_data {
 uint32_t serial_number;
 uint64_t mac_address;
...this is a bad idea, because in most (but probably not all) chips,
uint64_t after uint32_t means there's 32 bits of padding, so if you need serial-before-mac, you should at least make the padding explicit.
The build system is gcc, so I could search for s1 in the elf file. Do
you know of a tool that returns the address of a symbol in the elf or
map file?
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 307 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 134:26:28 |
| Calls: | 6,857 |
| Calls today: | 3 |
| Files: | 12,360 |
| Messages: | 5,418,384 |