USB update logic - galaxy4public/hkmcavn-tools GitHub Wiki

The firmware is running AppDMClient service to handle both FOTA (Firmware Over The Air) and USB based updates. AppDMCLient registers itself with the automounter service to monitor for a new USB mass storage device being mounted. Once such a device is mounted and at least 45 seconds passed since the system has started, the control is passed to AppDMClientEngine::launchAppUpgrade(path) where path is full path to the mounted storage device. From that point on, the logic as implemented by LGe is as follows:

  1. A check is performed on the existence of the AppUpgrade file at the specified path and if there is no such file process terminates with error -2;

  2. The /update/usb/upgrade directory is recursively cleaned up (equivalent to rm -rf /update/usb/upgrade/*) in a preparation for the potential upgrade.

  3. UpdateDecrypt::CheckHashOnce(file) is performed for both AppUpgrade and .lge.upgrade.xml and the status of the checks is saved

  4. If both checks returned "decryption is good", AppDMClient retrieves an RSA encrypted AES128-CBC key and executes DecryptToPIPE to copy AppUpgrade from the mass storage device to the internal filesystem into /update/usr/bin/ (the decryption key is removed once copy is completed);

    => execution continues from step 6.

  5. If UpdateDecrypt::CheckHashOnce(file) returned "CRC32 is good" instead of "decryption is good" for any of the files, then the presence of the /update/disableEncryptionUpdate file is checked and, if the /HU/images/startFromUsb file is NOT present on the mass storage device, AppUpgrade is copied as is from the mass storage device to /update/usr/bin/;

  6. The .lge.upgrade.xml file is copied to /update/usr/bin/ as is;

  7. If the /HU/images/startFromUsb file is present on the mass storage device, then AppUpgrade is executed in place from the mass storage device without copying, otherwise it is executed from /update/usr/bin/

  8. The update process is now handled by the executed AppUpgrade process and AppDMClient returns to its waiting state.

One may think that there is a bypass of the security measures if one would create the /HU/images/startFromUsb file on the mass storage device, but it is not that straightforward since to be able to execute the AppUpgrade from the mass storage device it should be an unencrypted ELF binary, but this would require the presence of the /update/disableEncryptionUpdate file at the time the mass storage device is mounted, otherwise the process will terminate on the "unencrypted updates not supported" condition.

Now, Mobis (or Hyundai/KIA Motor Group) applied several changes on top of the aforementioned logic. Specifically, they optimised calls and introduced several functions such as checking for the checksum and for checking the existence of files. Their code is also introducing a separate update branch using the VarUpgrade binary. All in all, Mobis version of the update logic as observed on 2022 KIA Sportage's firmware is as follows:

TBD