Hello trid users,
Some days ago i helped a friend with his computer. I run Pirisoft ccleaner and
it complains about unused 7 byte file name extension AEDTHEME. These samples
are part of Ashampoo Burning Studio 2019. That is a CD-ROM burning application.
The inspected samples are found in sub directory themes\autoruneditor inside
program directory "c:\Program Files (x86)\Ashampoo\Ashampoo Burning Studio
2019". The current version is called Burning Studio 24. There the samples files
are also found and also in same directory.
Unfortunately this program fails in category "nice shine only". So all
internals are not revealed for users. Unfortunately i found no information
about AEDTHEME and the used file format.
A few information can be found in Ashampoo Burning Studio Burning Studio 2023
manual. This was not included as part of standard installation. The program
help function directs to online manual on support server of ashampoo.com web
sites. Have people nothing learned from putins war od corona virus crisis.
When your internet connection is down for such reasons you can not read program
help.
The thirteen header item in manual is called "New Disc + Autostart". This is
used as reference URL. This is expressed by line like:
<RefURL>
https://support.ashampoo.com /hc/en-us/articles/9511402587538-Burning-Studio-2023-Manual#TOC_13
</RefURL>
When you select this burning variant then on the CD-ROM a well known
autorun.inf is created. When you select the "Interactive Menu" variant then
this starts autorun.exe in directory .autorun. Apparently this executable use
ZIP container in this directory with name content.aed. Obviously the
product.xml member contains graphic names like autorun.ico or image0.png.
Furthermore it contains instructions (by keywords like bounding-box width
height rotation) how to arrange the layout with the images. The text part is done
by additional text1.xml with more instruction (by key words like fontface
fontweight leftindent paragraph text) how to arrange the text.
After setting the product name and background music (which does not work for
me) on next page of autorun wizard you can arrange the layout for the autorun
program. There you can select a theme layout template like Ash, Autumn, Beach,
or "Halloween Night". Apparently these layout are stored inside ZIP containers
with same layout name and file name suffix AEDTHEME.
I have not found a registered mime type for such AEDTHEME samples. So these
should get at least the mime type of ZIP archives, that is used for AEDTHEME
samples. That is expressed by line like:
<Mime>application/zip</Mime>
Instead standard ZIP suffix use their own suffix. So that is expressed by line
like:
<Ext>AEDTHEME</Ext>
When running TrID on such AEDTHEME examples i get an expected generic output.
All examples are with highest rate described generic as "ZIP compressed
archive" by ark-zip.trid.xml. So no sub classification is done here and so file
name extension is wrong (See appended output/trid-v-old.txt)
For comparison reason i check these examples by file command utility. When
running file command (version 5.44) here all examples are also described
generic as "Zip archive data" (See appended output/file-5.44.txt) and correct
generic mime type application/zip (See appended output/file-i-5.44.txt). Here
also the correct file name suffix AEDTHEME is not recognized (See appended
output/file-ext-5.44.txt).
For comparison reason i also run the file format identification utility DROID
(See
https://sourceforge.net/projects/droid/). This identifies all examples
also only generic "ZIP Format" by PUID x-fmt/263 and complains about name
extension AEDTHEME (EXTENSION_MISMATCH see appended droid-aedtheme.csv).
For comparison reason i generate ZIP archive listing by running 7-zip unpacking
utility (See appended 7z-l-slt.txt 7z-l.txt).
After running tridscan to generate new definition aedtheme.trid.xml i began to
refine the definition because it is based only on few dozen samples. First XML
construct looks like:
<Bytes>504B0304140000000800</Bytes>
<ASCII> P K</ASCII>
<Pos>0</Pos>
According to page ZIP (file_format) on Wikipedia that is the 4 byte signature
"PK\3\4" of the first ZIP local header. At offset 4 the version needed to
extract is stored as 1 byte little endian integer. In my examples in found only
version 2.0. So decimal version number is major version number multiplied by 10
and added minor version number. That is 20 or hexadecimal 14. At offset 5 host
OS type is stored. 0 here means minimal DOS host type to extract. At offset 6
the General purpose bit flags are stored 2 byte little endian Integer. Here i
get 0 in my inspected samples. At offset 8 the compression method is stored as
2 byte little endian integer. In my examples in found only deflate (=8). I do
not know if this Observed facts are always true. So i mention this in the
remark line.
At offset 18 the compressed data length is stored as 4 byte little Endian of
first archive member. In my examples i get "low" values. or
expressed in other words the 2 upper bytes are nil. That was expressed by XML
construct like:
<Bytes>0000</Bytes>
<Pos>20</Pos>
Assuming that theoretical higher values are possible this construct will vanish
When file size is reaching upper 4 GB limit. So i delete this.
At offset 22 the uncompressed data length is stored as 4 byte little endian of
first archive member is stored. In my examples i get "low" values. or
expressed in other words the 2 upper bytes are nil.
At offset 26 the File name length (n) is stored as 2 byte little endian of
first archive member. In my examples i get always value 10. That is byte
sequence 0A00.
At offset 28 the extra field length (m) is stored as 2 byte little endian of
first archive member. In my examples i get always value 0. That is byte
sequence 0000. That means first archive member has no extra field.
At offset 30 the File name is stored. In my inspected samples this was always
image0.png.
These facts were expressed by XML construct like:
<Bytes>00000A000000696D616765302E706E67</Bytes>
<ASCII> . . . . . . i m a g e 0 . p n g</ASCII>
<Pos>24</Pos>
Assuming that theoretical higher values are possible this construct will vanish
when uncompressed size is reaching upper 4 GB limit. So this shrink and become
like:
<Bytes>0A000000696D616765302E706E67</Bytes>
<ASCII> . . . . i m a g e 0 . p n g</ASCII>
<Pos>26</Pos>
If m value is 0 then this has some side effects. Then after filename next ZIP
fragment starts with PK magic. According to ZIP listing the samples contain
always 9 numbered PNG images. This is expressed inside global strings section
by lines like:
<String>IMAGE10.PNGPK</String>
<String>IMAGE0.PNGPK</String>
<String>IMAGE2.PNGPK</String>
<String>IMAGE3.PNGPK</String>
<String>IMAGE4.PNGPK</String>
<String>IMAGE5.PNGPK</String>
<String>IMAGE6.PNGPK</String>
<String>IMAGE7.PNGPK</String>
<String>IMAGE8.PNGPK</String>
<String>IMAGE9.PNGPK</String>
The image number one is stored in some samples also as PNG with name
image1.png. But in some samples this is stored in JPEG format with name
image1.jpg. So this is expressed inside global strings section by line like:
<String>IMAGE1.</String>
Apparently the layout (with keywords like height width rotation center) of
theses images is stored inside an XML file with name theme.xml. So this
information is expressed inside global strings section by line like:
<String>THEME.XMLPK</String>
The layout can also contains some text information (with keywords fontsize
fontstyle fontweight fontunderlined fontface alignment leftindent
linespacing). This information is also stored inside a XML file. This has names
(like text11.xml text12.xml text14.xml text15.xml text16.xml text24.xml). So
this information is expressed inside global strings section by line like:
<String>TEXT</String>
Because the images are stored as PNG so i get phrase which are characteristic
for PNG chunk. A valid PNG image must contain an IHDR chunk, one or more IDAT
chunks, and an IEND chunk. So this information is expressed inside global
strings section by lines like:
<String>IDATX</String>
<String>IEND</String>
<String>IHDR</String>
Then there exist one other line. Apparently this is also a PNG chunk name. This
lines looks like:
<String>SBIT</String>
So that apparently are the main characteristics that are the differences
between AEDTHEME samples from ordinary ZIP archives.
With the new trid definition now all AEDTHEME examples are described (see
appended output/trid-v-new.txt). TrID definitions and output are stored in
archive autoruneditor.zip. I hope that my XML file can be used in future version of
triddefs.
With best wishes Jörg Jenderek
