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:

Removal of combining diacritical marks from text

Unicode standard describes method for applying of combining diacritical marks to modify other characters.

Given a text from user, some characters can be treated as combination of regular character and combining diacritical marks.

One could have ability to obtain text filtered from combining diacritical marks.

This is how it could be done for Hebrew niqqud, for instance.

Removal of Hebrew niqqud marks from text

To see chart of Hebrew diacritic marks, open this document: Hebrew Unicode block (PDF).

I'll use Ruby language for demonstration.

At first, lets define ranges in Unicode:

HEBREW_WHOLE_UNICODE_RANGE = 0x0591..0x05F4
HEBREW_DIACRITICS_UNICODE_RANGE = 0x0591..0x05C7
HEBREW_LETTERS_UNICODE_RANGE = 0x05d0..0x05ea

Here is how we remove niqqud marks from following Hebrew text

בְּרֵאשִׁית בָּרָא אֱלֹהִים אֵת הַשָּׁמַיִם וְאֵת הָאָרֶץ

Code in Ruby:

text.
  unpack('U*').
  delete_if {|c| HEBREW_DIACRITICS_UNICODE_RANGE.include?(c)}.
  pack('U*')

Here "text.unpack('U*')" means "unpack Unicode characters to array of code points"

text.unpack('U*')

 => [1489, 1468, 1456, 1512, 1461, 1488, 1513, 1473, 1460, 1497, 1514, 32, 1489, 1468, 1464, 1512, 1464, 1488, 32, 1488, 1457, 1500, 1465, 1492, 1460, 1497, 1501, 32, 1488, 1461, 1514, 32, 1492, 1463, 1513, 1468, 1473, 1464, 1502, 1463, 1497, 1460, 1501, 32, 1493, 1456, 1488, 1461, 1514, 32, 1492, 1464, 1488, 1464, 1512, 1462, 1509]

 After applying filter we applying pack('U*') to array of code points to obtain character representation.

Finally we have following text:

בראשית ברא אלהים את השמים ואת הארץ

Просмотр составных документов .odc (Oberon/F) в Linux

Файлы .ODC, представляющие из себя составные документы, являются родным форматом файлов для программы Blackbox (Component Builder). Такие документы могут содержать как обогащённый текст (rich text), так и различные объекты, будь то изображение, элемент для сворачивания блоков кода, линейки для выравнивания объектов (табуляции), ресурсы для отображения форм, OLE-объекты или любые другие отображаемые объекты.
Упрощённо можно провести аналогию со страницей HTML со множеством Java-апплетов.


В основу среды разработки Blackbox заложена возможность редактирования составных документов ODC. Для того, чтобы показать содержимое документа из файлового менеджера, потребуется запустить ассоциированное с ним приложение, а именно blackbox.exe (не без помощи wine). При этом Blackbox загрузит программный каркас со всеми необходимыми компонентами для работы. Это не очень удобно и эффективно, особенно по той причине, что программа запускается при помощи программной прослойки wine.

Как-то случайно наткнувшись на утилиту odcread я подумал: а почему бы не использовать её для отображения файлов ODC в Linux как в терминале, так и в программе с GUI?

Для этого скомпилируем программу и самостоятельно установим (скопируем) исполняемый файл odcread в директорию /usr/local/bin (при помощи sudo).

Просмотр в программе Midnight Commander (mc)

Открываем в текстовом редакторе файл ~/.config/mc/mc.ext и добавляем туда следующие строки:

# .odc
regex/\.odc$
    View=%view{ascii} /usr/local/bin/odcread %f

Вуаля! Теперь у нас есть возможность просматривать файлы ODC и в mc (в режиме parsing - F8).

На этом можно остановиться, но я хотел получить возможность просмотра файлов прямиком из файлового менеджера Nautilus (GNOME).

Для того, чтобы просмотреть содержимое документов в файловом менеджере, нужно было каким-то образом отобразить. И я решил воспользоваться принципом конвейерной обработки данных, взяв stdout программы odcread за входные данные (stdin). Так я написал GTK+ просмотрщик текстовых файлов gpipeview.

Просмотр текстовых данных в gpipeview

Простенькая программа gpipeview на C с использованием библиотеки GTK+ получает поток данных через stdin и выводит содержимое в окне. Поддерживается буфер обмена, так что текст/код легко скопировать в другую программу.

Код программы находится по адресу https://gist.github.com/romiras/b89b9dc371c998402bd5
Компилируется так:

gcc -o gpipeview gpipeview.c  -Wall `pkg-config --libs --cflags gtk+-2.0`

Перед компиляцией следует установить все библиотеки GTK+, необходимые для компиляции. Просмотреть их список можно лишь запустив

pkg-config --libs --cflags gtk+-2.0

Скомпилировав программу, скопируем её в директорию /usr/local/bin , затем создадим такой Shell-скрипт для запуска из командной строки (назовём его odcview):

#!/bin/sh

VIEWER=/usr/local/bin/gpipeview

if [ -n "$1" ];then
    odcread $1 | $VIEWER &
else
  echo "First argument must be path to Oberon/F .ODC file."
  exit 2
fi

Таким образом, мы получаем возможность просмотра документов в графическом виде из командной строки:

odcview StdDialog.odc

Всё вроде как неплохо, но напрягает необходимость запуска просмотрщика из командной строки, ведь так?
Вот поэтому лучше зарегистрировать наш новый просмотрщик в системе.

Регистрация просмотрщика odcview в системе

Воспользуемся пакетом xdg-utils.

Для регистрации нового MIME типа создадим в текстовом редакторе файл x-oberon-f.xml

<?xml version="1.0" encoding="UTF-8"?>
<mime-info xmlns="http://www.freedesktop.org/standards/shared-mime-info">
    <mime-type type="application/x-oberon-f">
        <comment xml:lang="en">Oberon/F compound document</comment>
        <magic priority="50">
            <match type="string" value="CDOo" offset="0"/>
        </magic>
        <magic priority="30">
            <match type="string" value="Documents.StdDocument" offset="11"/>
        </magic>
        <glob pattern="*.odc"/>
        <icon name="BlackBox_doc.png"/>
    </mime-type>
</mime-info>

Затем, открыв терминал в той же директории, запустим команду

xdg-mime install x-oberon-f.xml

Теперь надо ассоциировать с этим MIME типом нашу пиктограмму

(взял с дистрибутива Blackbox, конечно)
таким образом:

xdg-icon-resource install --context mimetypes --size 32 BlackBox_doc.png

Далее, создаём в текстовом редакторе файл ~/.local/share/applications/odcview.desktop с таким содержанием:

[Desktop Entry]
Encoding=UTF-8
Type=Application
Categories=Development;

Name=odcview
Name[de]=odcview

Exec=/usr/local/bin/odcview %U
Terminal=false
Icon=BlackBox_doc.png

# Register additional MIME types here:
#MimeType=application/x-oberon-f

и регистрируем нашу программку в системе:

xdg-mime default odcview.desktop application/x-oberon-f

update-mime-database    ~/.local/share/mime
update-desktop-database ~/.local/share/applications

Проверяем что всё зарегистрировано как положено и тип распознаётся системой:

xdg-mime query filetype testfile.odc

Должен быть такой вывод:

application/x-oberon-f

Окончательно, открываем в Nautilus папку с файлами ODC. При выборе правой кнопкой любого документа должен появиться пункт

Open With odcview

Теперь любой ODC документ можно просмотреть в файловом менеджере Nautilus без необходимости запускать каркас BlackBox в wine.