Author Topic: apexbackup.trid.xml for Android Apex Launcher backup *.apexbackup  (Read 1131 times)

jenderek

  • Sr. Member
  • ****
  • Posts: 375
Hello trid users,

some days ago i wanted to restore my saved Android setting created by Apex
Launcher on a new smartphone, but i get some trouble.

Inside the settings menu of the Apex Launcher is a item with name like
"backup & restore" (or "Backup & Wiederherstellen" with German language
settings). When i select there item like "Create a new backup" (or "Ein
neues Backup erstellen" with German) i can changed proposed file name
(derived from date and time and looking like YYYYMMDD-HH-MM-SS) and and
directory (the default location is in folder apexlauncher beneath directory
Android/data). The backup files have 9-byte file name extension
apexbackup. That is expressed inside TrID definition by line like:
   <Ext>APEXBACKUP</Ext>

When i run TrID on such examples these are described generic as "ZIP
compressed archive" by ark-zip.trid.xml (see appended
output/trid-v-old.txt).  So APEXBACKUP examples are just simple ZIP
archives. Therefor these get the same mime type that is expressed inside
TrID definition by line like:
   <Mime>application/zip</Mime>

So i run tridscan to generate definition apexbackup.trid.xml for Android
Apex Launcher backup. So we found here at the beginning a magic pattern,
that is characteristic for ZIP archives. That is expressed inside front
block by XML construct like:
   <Bytes>504B0304140008080800</Bytes>
   <ASCII> P K</ASCII>
   <Pos>0</Pos>

Now according to ZIP specification this can be interpreted in details. At
offset 0 is 4 byte magic string PK\3\4. At offset 4 2 byte little endian
integer is stored. Here i found hexadecimal value 1400. That is minimal
version 2.0 to extract. At offset 6 general purpose flag is stored as 2 byte
little endian integer. Here value is hexadecimal 0808. That means bit number
3 and 11 are set. The last means filename and comment field are encoded as
UTF-8. At offset 8 the compression method is stored as 2 byte integer. Here
value is hexadecimal little endian 0008. That mean deflate compression is
used.

When i look in listing of 7z or unzip the backups apparently always contain
2 archive members with file names apex_data.bak and apex_settings.bak (see
appended output/7z-l-slt.txt output/unzip-Zlv.txt). That facts are expressed
in global strings section inside definition by lines like:
   <String>APEX_SETTINGS.BAKPK</String>
   <String>APEX_DATA.BAKPK</String>

The apex_settings.bak is apparently stored as first item. So that name
appears near the beginning. That is expressed in Front Block section by XML
construct like:

 <Bytes>00000000000000000000000011000000617065785F73657474696E67732E62616B</Bytes>
 <ASCII> . . . . . . . . . . . . . . . . a p e x _ s e t t i n g s . b a k</ASCII>
 <Pos>14</Pos>

Now according to ZIP specification this can be interpreted in details.  The
CRC32 data checksum, the compressed and uncompressed file size are stored at
offset 14 as 4 byte integers. Here values are all zero, because general
purpose bit 3 is set. That means the correct values are stored after the
compressed data and not in the local file header. Afterwards at offset 26
the file name length (n) is stored. The value here is hexadecimal 0011. That
is decimal 17. That is the length of the first file name apex_settings.bak
stored as string at offset 30. Before that name the extra field length (m)
is stored as 2 byte integer. Here value is 0. That means no extra field.
That means that after the file name the next ZIP fragment with starting PK
string begins. So i mentioned the observed information inside a remark line
like:
   <Rem>
   ZIP compressed archive (
   minimal version 2.0 to extract,
   UTF-8 encoded,
   Deflated,
   no CRC32 and file sizes in local header,
   no extra field) with name like
   YYYYMMDD-HH-MM-SS.apexbackup and 2 members
   apex_settings.bak with XML (ASCII) and SQLite 3.x
   database apex_data.bak
   normally located in folder apexlauncher beneath directory Android/data
   </Rem>

The web site for this tool is referenced by line like:
   <RefURL>http://www.apexlauncher.com/</RefURL>

Unfortunately that is not a real web site. Instead it redirects to site
"Apex Launcher Classic" inside Google play store.

With the new TrID definition all of my inspected APEXBACKUP examples are now
described more precisely as "Android Apex Launcher backup" (see appended
output/trid-v-new.txt).

TrID definition and output are stored in archive apexlauncher.zip.

With best wishes
Jörg Jenderek

Mark0

  • Administrator
  • Hero Member
  • *****
  • Posts: 2730
    • Mark0's Home Page
Re: apexbackup.trid.xml for Android Apex Launcher backup *.apexbackup
« Reply #1 on: February 26, 2022, 12:50:32 PM »
Thanks Jörg!