This is an early work in progress, as far as i can tell this is correct however needs a lot more information and testing before it can be considered safe

After spending a fair amount of time reversing the update utility i have found the following information about the firmware update process.

The firmware update process uses DirectIOControl with SCSI_PASS_THROUGH_DIRECT in order to send scsi commands directly to a seemingly hidden scsi targetID, therefore as far as i can tell this is unable to be done on linux as you are unable to specify a different targetID in any of the SCSI API's for linux.

The FU uses a storage property to find out the size of the window available for sending data and then proceeds to send a 12-byte SCSI CMB this contains the opcode 0x7A and as far as i can tell only contains all 0's apart from the opcode.

The 0x7A opcode is technically in a reserved range so is potentially being abused in this situation as technically they should be using the Vendor codes.

Along with this it sends a command which is what is shown in the log files that are produced by the FU. These are always a minimum of 32 bytes which appears to be some sort of header,

the command header appears to be: (all little-endian)

• 0x00(4) Length of additional data (not including the 32-byte header)
• 0x04(2) something to do with mpunct:do_frac_digits (this always appears to be 0x1)
• 0x06(2) Command (detailed below)
• 0x08(1) Direction (1 == device→host ; 0 == host→device)
• 0x09(1) Unknown (always 0?)
• 0x0A(2) Sequence (this starts at 0 and increases for each packet that is sent resetting at 0x10000) the rest of the bytes always appear to be 0x00 so i am unsure what they are required to do

The following commands are handled in libupdaterufp.so

The Commands are:

• 0x0001 Init
• 0x0010 Check Guard
• 0x0020 Query Version
• 0x0030 Switch Mode
• 0x0040 Write Firmware
• 0x0100 Complete
• 0x0200 Get State