Version strings — display, sources and gating¶

What the System Information screen shows¶

Stock NAV SMEG5.43.A.R2, read from decompiles and disassembly. Nothing in this section was executed, and none of it has been checked on the car.

Where the values come from. C_BCM_VERSION::Init (0x0158e010) builds a list of version entries (TB_SW, BR, CD, UBOOT, Renesas, GUI, DbDwnl, Gruppo; plus Display, added by UpdateDataBase). On every boot, UpdateDataBase (0x0158ce38) runs DELETE FROM versions; and re-inserts them all as (ID, Name, Version, Date). The stock seed versions.sqlite is empty (read).

What is shown. C_HMI_CONFIG_SystemInformation_M3Z_Z1 lists four items: TB_SW, MGR_BT, DbDwnl (NAV units only) and GUI. For the selected item it queries versions and shows (read):

• field 5000: that item's Version (the DbDwnl item shows its database versions instead);
• field 6000: the CD row's Version, on every item page. This is the observed cd 26482;
• field 7000: the TB_SW row's Date, on every item page except DbDwnl.

smeg.inf's VER: is not read by this screen. The package-root media.inf and the media partition's Data_base/media.inf are byte-identical in stock (VER:26482), so either looks like the source of cd; the code reads the media partition's copy.

Is GUI_VER visible?¶

By the code, GUI_VER is shown in field 5000 of the GUI item's page (read). Which on-screen label is the GUI item is not known: the labels are in the undecoded GUI text strings (#62). A build with GUI_VER 32.01 has been flashed and 32.01 was not seen on the one page looked at, while cd 26482, which is on every page, was (observed; see Hardware verification). That page was most likely not the GUI item's (inferred).

The cheap car check, with no new build. On the current stock-GUI_VER build, open each System Information item in turn and note which shows 32.00, and where 19-09-17 appears. If 32.00 is on an item page, GUI_VER (media.gui_ver in a build manifest) already works as a media-only build marker.

A candidate marker in the application image (not shipped)¶

If GUI_VER turns out not to be visible, the TB_SW date can become the marker. Change only Init's three loads of the g_MBSW_* globals into immediates, so the displayed date shows a chosen value while the globals, and the CAN frame built from them, stay stock:

For example 38800028, 38a00009, 38c00026 would show 28-09-26. The format is %02x, so any two hex digits work. CANDIDATE: the replacements were decoded with capstone (executed, decoding only); nothing was emulated or flashed, and it is not a patches/*.json. Only Init and InitAfterInstance read these globals (read, full-image scan), and the edit touches Init alone. Residual risk: something the scan missed may read the versions table's TB_SW date, and whether field 7000 is on the page you look at is not known; the car check above settles that too.

What must not be changed¶

• The SMEG5.43.A.R2 literal or the g_MBSW_* globals. They also reach the CAN version frame and SYSTOOL_SetVersion (the spy and panic logs) (read).
• The CD value (media.inf VER). It is visible, but it also goes to the diagnostic DID and the CAN frame (read), and it is very likely what the updater compares a stick's media.inf against (inferred). Raising it could make a later stock package look like a downgrade and be refused, which would block a rollback. See the gates below.

The updater gates on these strings¶

From upgrade.out strings:

(UpgradeTask) The version on media.inf not allows an upgrade
(UpgradeTask): Actual BSP (%f) is very old... The new version of the BSP need to format the NAND.
(GetUBootVersionMedia): field 'VER:' not found!
(ManageHarmoniesVersions) Harmonies are not compatibles, new Harmony must be erased
(ManageRenesasUpdateAndReboot) Renesas version '%s' == Mot. File version '%s'
manageBootRomUpdateAndReboot: BootRom already done.
ManageBigQuickUpdate: '%s' is a cantidate!

So versions are compared, and the comparisons drive more than "update or skip":

• media.inf has an explicit gate — "not allows an upgrade" — so a wrong value there can block the package.
• UBoot versions are parsed numerically (%02d.%02d) and a missing/unparsable VER: is an error, so an invented series is not guaranteed to parse.
• Harmony compatibility and BSP age are version-driven, and those branches do destructive things (erase the harmony images, format the NAND).

Why not to invent a version¶

• Bumping smeg.inf VER: to e.g. 5.43.A.R3 makes the application look newer, so the updater applies it — but it changes nothing visible (the screen does not read it) and nothing functional (content is whatever was patched).
• An unrecognised series such as 5.43.X.R1 may not parse, landing on the "not allows an upgrade" path or, worse, triggering a harmony/BSP re-flash.
• media.inf is the one with the hard gate; do not edit it as a marker.