Having recently acquired a Samsung Series 9 laptop, I'd like to update
the BIOS. This is proving rather difficult without Windows.
The first thing you download from the Samsung website isn't actually
BIOS update at all; it's a Windows application which then goes and
finds a BIOS update for your machine.
Some time with a Windows VM, tcpdump and you'll end up at
http://sbuservice.samsungmobile.com/. I'll leave interested
parties to play around at that website, but with a little fiddling you
can find the BIOS you're looking for. In this case, it is
ITEM_20121024_754_WIN_P08AAH.exe
which is the latest version, P08AAH.
Unfortunately, this still won't run in any useful way -- in a
virtual-machine it errors out saying the battery isn't connected. On
previous endeavors such as this, running various incarnations of
zip on the
.exe file has found interesting components, but not
in this case. Not to be deterred, some work with
strings will
yield the following
$ strings ./ITEM_20121024_754_WIN_P08AAH.exe grep Copyright
inflate 1.2.7 Copyright 1995-2012 Mark Adler
deflate 1.2.7 Copyright 1995-2012 Jean-loup Gailly and Mark Adler
Now this is interesting, because it tells us that the components
aren't using some fancy compression scheme we have no hope of figuring
out. Checking
RFC1952 we see
the following header mentioned
Each member has the following structure:
+---+---+---+---+---+---+---+---+---+---+
ID1 ID2 CM FLG MTIME XFL OS (more-->)
+---+---+---+---+---+---+---+---+---+---+
We can easily look for that in the file. Expanding the values, what
we're looking for is
0x1f 0x8b 0x08 0x0 0x0 0x0 0x0 0x0 0x0 0x0
which represents the compressed stream (the
OS byte is
0xb for
NTFS which we can just ignore). A quick
hack
will get that done and give us the offsets we need
$ ./look-for-headers
Found potential header at 455212
Found potential header at 677136
Found potential header at 1293930
Found potential header at 1294980
Found potential header at 2771193
Found potential header at 2779874
Found potential header at 2789142
Found potential header at 2935778
Found potential header at 3078639
Found potential header at 3083039
Found potential header at 3338552
Found potential header at 3339443
Found potential header at 3352440
Found potential header at 3366757
Found potential header at 3391734
Found potential header at 3444255
Found potential header at 3494372
So, we can feed this into a shell script and extract the streams
FILE=ITEM_20121024_754_WIN_P08AAH.exe
for offset in 455212 677136 1293930 1294980 \
2771193 2779874 2789142 2935778 3078639 \
3083039 3338552 3339443 3352440 3366757 \
3391734 3444255 3494372
do
echo "create $offset.gz"
dd if=$FILE bs=1 skip=$offset zcat > $offset.data
done
We don't have to worry about the end-point, because
zcat will
handily stop outputting and ignore junk at the end of the stream.
That will yield the following output files:
$ md5sum *
c014e900b02ae39d6e574c63154809b2 1293930.data
982747cd5215c7d51fa1fba255557fef 1294980.data
942c6a8332d5dd06d8f4b2a9cb386ff4 2771193.data
d98d2f80b94f70780b46d1f079a38d93 2779874.data
33ce3174b0e205f58c7cedc61adc6f32 2789142.data
1d6851288f40fa95895b2fadee8a8b82 2935778.data
3a0a9b2fa9b40bdf5721068acde351ce 3078639.data
fc166141d06934e9c7238326f18a4e68 3083039.data
8cf7f86f84afa81363d3cef44b257d50 3338552.data
85e09e18fd495599041e13b4197e1746 3339443.data
0c72004eae0131d52817f23faf8a46a7 3352440.data
26347f93721e7ac49134a17104f56090 3366757.data
26973e301da4948a0016765e40700e8c 3391734.data
c8e4675cda3aa367d523a471bb205fba 3444255.data
7bf5ea753d4cc056b9462a02ac51b160 3494372.data
a2c6562f7f43aaa0e636cc1995b7ee3d 455212.data
d5c91b007dac3a5c6317f8a8833f9304 677136.data
65c0dcd1e7e9f8f87a8e9fb706eb8768 ITEM_20121024_754_WIN_P08AAH.exe
$ file *
1293930.data: MS-DOS executable
1294980.data: data
2771193.data: PE32 executable (native) Intel 80386, for MS Windows
2779874.data: PE32+ executable (native) x86-64, for MS Windows
2789142.data: PE32 executable (console) Intel 80386 (stripped to external PDB), for MS Windows
2935778.data: PE32+ executable (console) x86-64 (stripped to external PDB), for MS Windows
3078639.data: MS-DOS executable
3083039.data: PE32 executable (GUI) Intel 80386, for MS Windows
3338552.data: ASCII text, with CRLF line terminators
3339443.data: PE32 executable (native) Intel 80386, for MS Windows
3352440.data: PE32+ executable (native) x86-64, for MS Windows
3366757.data: PE32 executable (DLL) (GUI) Intel 80386, for MS Windows
3391734.data: PE32 executable (GUI) Intel 80386, for MS Windows
3444255.data: PE32 executable (GUI) Intel 80386, for MS Windows
3494372.data: PE32 executable (DLL) (GUI) Intel 80386, for MS Windows
455212.data: PE32 executable (DLL) (console) Intel 80386, for MS Windows
677136.data: data
ITEM_20121024_754_WIN_P08AAH.exe: PE32 executable (GUI) Intel 80386, for MS Windows
This is where I get a bit stuck. There is clearly a bunch of WinFlash
stuff that Wine kind-of recognises, but so far I haven't managed to
figure out how I might go about flashing this from a DOS boot disk.
So far I know it's a "Phoenix SecureCore Tiano" based BIOS, and there
is some indication that there is a UEFI app to flash the BIOS, but
unfortunately I didn't set the laptop up with UEFI (note to anyone
setting this up; probably a good idea to do that).
I believe that if you have Windows, you can halt the install part-way
through and see these files extracted in a temp directory. Possibly
if we can put some file-names to the blobs it might help.
There may also be a much easier way to do this that I'm completely
missing. If anything comes up, I'll update this post; hopefully a
future Googlenaut who enjoys BIOS hacking will drop a comment...
Update 2012-11-27 I'm unfortunately less optimistic about being
able to update this.
Certainly the files identified above as
MS-DOS executable are EFI
binaries; however they are both 32-bit binaries. You can easily get
an EFI shell up and running by putting a 64-bit
EFI shell binary
on a FAT formatted USB disk in the
efi/boot/bootx64.efi but it
will not run either of those binaries, presumably because they're
32-bit. A 32-bit EFI binary doesn't seem to be recognised for boot,
so no luck there.
A comment also mentioned some issues with Samsung's and UEFI boot
in
this bug
though it's not clear what models are affected.
Another comment mentioned
binwalk which also does a nice job of
finding the embedded zip streams.
$ strings ./1293930.data
...
RSDS
D:\flash\Source\ENV\src\Efi863\edk\phoenix\edk\Sample\Platform\DUET\ldr16\IA32\oemslp20.pdb
oemslp20.dll
InitializeDriver
2n3u3
$ strings ./3078639.data
en-us;zh-Hans
slp20.marker
slp20.size
slp20.offset
slp20.offset2
read marker fail!
Marker file '%s''s size(%d)!=%d
Not a valided OemMarker!
Update image data error.
marker file is updated.
marker file size too big!
Not a valided OemMarker in ROM.
Update image data error.
SLP marker is reserved.
-PROT
Prot flag is found, mProgFlag is true.
Prot flag is not found, mProgFlag is false.
Please specify input file name.
-PROT
slpFile
OEM Activation 2.0 processing
Failed to Locate Flash Support protocol.
...
D:\flash\Source\ENV\src\Efi863\edk\phoenix\edk\Sample\Platform\DUET\ldr16\IA32\SLP20.pdb