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)
The following commands are handled in libupdaterufp.so
The Commands are: