Some time ago I bought an Alienware M14xR2 as my last laptop broke down. Lately, Alienware published an update for my BIOS that I can't burn in my computer because I only use Archlinux. By googling a bit I quickly found a tool for burning the BIOS in a DOS command line but I would need to have a look to the update package.
Just by executing the update file in a virtual machine in windows I soon figured out it was a self extracting package. I just searched %TEMP% files for the extracted version.
$ file * Ding.wav: RIFF (little-endian) data, WAVE audio, Microsoft PCM, 16 bit, stereo 44100 Hz FlsHookDll.dll: PE32 executable (DLL) (GUI) Intel 80386, for MS Windows FlsHook.exe: PE32 executable (GUI) Intel 80386, for MS Windows FWUpdLcl.exe: PE32 executable (console) Intel 80386, for MS Windows InsydeFlash.exe: PE32 executable (GUI) Intel 80386, for MS Windows iscflash.dll: PE32 executable (DLL) (GUI) Intel 80386, for MS Windows iscflash.sys: PE32 executable (native) Intel 80386, for MS Windows iscflashx64.sys: PE32+ executable (native) x86-64, for MS Windows isflashWin.bin: MS-DOS executable platform.ini: ASCII text, with CRLF line terminators platforms.ini: ASCII text, with CRLF, CR line terminators xerces-c_2_7.dll: PE32 executable (DLL) (GUI) Intel 80386, for MS Windows
Ding.wav is just audio. I suppose it is played when flash is finished. Just by reading the header of the ini files we can guess they are configuration files for the flasher utility. The format is self explained in comments. In line 61 I found that the file I wanted for flashing was isflashWin.bin but after a fast attempt with FreeDOS and the tool I mentioned before I realised that the format was not FD as it should so I googled a bit more. As it turns out, Insyde has released a new update file format and as it seems it isn't documented.
$ strings isflashWin.bin [...] !MV/VZ .text `_TEXT_REI `_TEXT_PR `.rdata @.data .reloc fRfPf fXfZ fRfPf fXfZ ud9F u_;^ 9F t:9F 9F t y[SVWh fPf3 3k4j6t7x7|7 :R<V< $BID01433 $_IFLASH_INI_IMG ;This file is InsydeFlash utility configuration file [CommonFlash] SwitchString=PJMDEN CPVER: FHRST ErrorMsg00=No error! ErrorMsg01=AC detect error! ErrorMsg02=DC detect error! ErrorMsg03=DC gas gauge under 10%! ErrorMsg04=BIOS version compare error! ErrorMsg05=Model name compare error! ErrorMsg10=Not support this version of Flash Common Interface! ErrorMsg11=Show BIOS version string length more then xx bytes. ErrorMsg12=Show model name string length more then xx bytes. [...]
Inside the file I found a section that is exactly the same as the configuration file and it is preceded by a string quite suspicious.
$ strings isflashWin.bin | grep "\$_IFLASH" 5$_IFLASH_DRV_IMG $_IFLASH_BIOSIMG $_IFLASH_INI_IMG $_IFLASH_EC_IMG_
I think these headers separate sections of the file as they are all 16 characters long. By having a look inside Hexedit I found that there is a padding of 8 bytes between the last character and some famous file magic numbers. I've done a simple python script (filesplitter) for splitting this kind of files and continue the analysis.
#!/usr/bin/env python import os import argparse magic = [ b'$_IFLASH_DRV_IMG', b'$_IFLASH_BIOSIMG', b'$_IFLASH_INI_IMG', b'$_IFLASH_EC_IMG_' ] len_tag = 16 len_offset = 8 parser = argparse.ArgumentParser(description="Split Insyde H2O firmware files.") parser.add_argument("-f", "--file", dest="filename", help="File to be processed.", metavar="file") args = parser.parse_args() file = open(args.filename, 'rb') prefix = os.path.dirname(args.filename) + '/' +os.path.splitext(os.path.basename(args.filename)) if not os.path.exists(prefix): os.makedirs(prefix) content = file.read(); s1 = content.find(magic) s2 = content.find(magic) s3 = content.find(magic) s4 = content.find(magic) f1 = open(prefix+'/one', 'wb') f1.write(content[0:s1]) f1.close() f2 = open(prefix+'/two', 'wb') f2.write(content[s1+len_tag+len_offset:s2]) f2.close() f3 = open(prefix+'/three', 'wb') f3.write(content[s2+len_tag+len_offset:s3]) f3.close() f4 = open(prefix+'/four', 'wb') f4.write(content[s3+len_tag+len_offset:s4]) f4.close() f5 = open(prefix+'/five', 'wb') f5.write(content[s4+len_tag+len_offset:]) f5.close() file.close()
$ ./filesplitter -f isflashWin.bin $ cd isflashWin/ $ file * five: data four: ASCII text, with CRLF line terminators one: MS-DOS executable three: Intel serial flash for PCH ROM two: MS-DOS executable
Part number four is clearly the configuration file. If you are trying to tweak parameters in platform.ini note that it wont work, but if you modify this part of the binary file it will. It seems that Insyde is now using the platform.ini only to point to the update file (isflashWin.bin) and then the utility just parses the configuration from there. I had no success in running one and two. I've tried FreeDOS and Windows 98 in DOS mode which should have support for MZ executables but in the best case I got no output and in the worse some memory address exceptions. I found that number three is related to a utility called Flashrom but I don't have much time to investigate. Maybe some readers can point me in the right direction. After having a look to five in Hexedit I think it can be a BIOS image although I don't really know about this topic.
Although I could not flash my BIOS I could find some little information about this new format and I also found that MZ executable signatures weren't in the binary analysis tool I use (binwalk). The latest version of binwalk now looks for MZ executables.