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:

Просмотр составных документов .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.