Analysis of Samsung Kies / Smart Switch backup files, part II

In previous article I made analysis of Samsung Kies backup files.
Thanks to researchers who made research [1] before me, I was able to figure out how data is arranged inside. Indeed, each such file represents container encrypted by symmetric encryption AES 256 CBC.

CBC mode uses initial vector (IV) and encryption key for encryption. Both should be known prior to decryption. Fortunately they present in source code [1] and can be also found in strings extracted from SmartSwitch 2.5 setup executable.

After decryption of file we can see that file represents following structure:

1. Header: XML file
2. Data (optionally): packed content

XML file

XML file is padded from end with 0x10 (DLE control code) to fixed size 512 bytes.
XML tag "HeaderData" has attribute "xmlns" with value "Kies.Common.Data".
XML tag "version" has values "Kies3" (for Samsung Kies) or "Kies4" (Smart Switch).
XML tag "zipType" has values "GZip" (if Kies3) or "ZLib" (if Kies4). Value "GZip" means that packed file will contain binary stream compressed as gzip file format. Value "ZLib" means that packed file represents ZIP file format.

In most simple case unpacked file consists of 512 bytes with XML file:

Packed content

This file represents packed content as described above. This section also padded from end with 0x10 (256 size block?).

Source code

I developed simple scripts in Ruby for extraction of content from EBK files.

References

[1] Samsung Kies .SSC / .SPB decrypter

Analysis of Samsung Kies/Smart Switch backup files, part I

One day I wanted to restore contacts from backup of Samsung smartphone. Since I didn't wanted to install Kies software on my computer, another option was to look on Internet whether there are any open source software able to read phone backups. Unfortunately I did not find anything suitable, therefore I've started to investigate backup files myself.

While older backups included variety of files with different extensions like SPB, SPBA, SME, SMEA etc, which were created by Samsung Kies, more recent backups were created by Smart Switch and had extension EBK.

First attempt was to detect file type with tool "file" in Linux distribution. This tool reads first bytes from file and tries to detect type according to "magic" numbers.
file didn't succeed to detect format and returned just type "data" (unknown format).

Second attempt was tool TrID. Surprisingly, despite library of numerous known formats, this tool returned just "Unknown!".

When I compared hex dump of arbitrary backup files with extension EBK, I've found all they had same magic number 6b39a474 at offset 0. This is a good sign for us.

I've picked most small file which has extension EBK and size 544 bytes and looked onto his hex dump. When I found 4 consecutive sequences of hex 10101010 at offset 256 bytes and same sequence at offset 528 (last 16 bytes). These sequences may represent end of block or even used for padding for blocks with fixed size.
Other file above 544 bytes also contained these sequences at end of file.

Content of file looks quite "random", at least either compressed or encrypted.

Among set of observed files were files with same size and all sizes are multiples of 2. Yet same size doesn't means same content! We had 2 files with same size but different content.

Another observation showed that first 256 bytes of all EBK files was same (by md5sum):
  for f in `find backup -type f -name '*.ebk'`; do head -c 256 $f | md5sum; done

Another observation showed that first 256 bytes of SPBA files are same as of EBK files.

Yet another observation showed that 10101010 sequences are repetitive across files: