Background

dmidecode utility is able to create a raw binary dump using --dump-bin option:

root@here:~$ dmidecode --dump-bin foo.dump

which can be re-used on another machine, producing effect as if dmidecode is running on the original machine:

me@elsewhere:~$ dmidecode --dump-bin foo.dump
# dmidecode 2.12
SMBIOS 2.7 present.
68 structures occupying 2688 bytes.
Table at 0xBAE9D000.
[...]

I do have these binaries from some machines and use them for testing a script that wraps around dmidecode (hence, I need to simulate dmidecode behavior as if the hardware setup was different).

Problem

But from a several machines, I don't have the raw binary, but do have copy of /sys/firmware/dmi/tables as exposed by 4.* kernel. Docs at kernel.org say:

[...]
The dmi/tables provides raw SMBIOS entry point and DMI tables
through sysfs as an alternative to utilities reading them
from /dev/mem. The raw SMBIOS entry point and DMI table are
presented as binary attributes and are accessible via:

/sys/firmware/dmi/tables/smbios_entry_point
/sys/firmware/dmi/tables/DMI

The complete DMI information can be obtained using these two
tables.

Question

Is it possible to use the /sys/firmware/dmi/tables files to re-construct (in a Bash/Python/Perl/... script) the raw binary dump so that it can be re-used as in first example?

I tried to just cat the files together but I was not successful (Invalid entry length (0). DMI table is broken! Stop.).

If you compare a hex dump of smbios_entry_point with the binary output of dmidecode, you'll see it is similar to bytes 0-31 of dmidecode's output. Likewise, DMI matches bytes 32+. Byte 32 is missing; I assume it's always null.

It looks close enough that I had hopes of it working.

echo -en '' >NUL
sudo cat /sys/firmware/dmi/tables/smbios_entry_point NUL /sys/firmware/dmi/tables/DMI >table
dmidecode --from-dump table

However, dmidecode crashes with the following output:

# dmidecode 2.12-dmifs
Reading SMBIOS/DMI data from file table.
SMBIOS 2.8 present.
Bus error (core dumped)

The SMBIOS/DMI spec is available on the internet (pdf); it shouldn't be too hard to determine acceptable dummy values for the header. I'm leaving that as an exercise for the reader, at least for the moment ;)