Can someone tell me more about unpack clickteam install creator or send me a tutorial video how to unpack it?
I read dr_golova post in --> Link <-- about unpack clickteam install creator but I don't understand what him're saying.
Hope some help me.
Regard.

| Сообщение посчитали полезным:

Please post a direct link to target CT installer. I think it will really help us.
And by the way, if you meant the CT installer secured by password or license key then forget about about "unpacking" - the actual package data is really encrypted by this key, and there is no quick way to get it. Unfortunately.

| Сообщение посчитали полезным:

Thank for reply. Please you make a tutorial how to extract files inside setup made by clickteam install creator.

| Сообщение посчитали полезным:

I think there is no way to create a real static generic unpacker for CT (except sandbox with some AI for clicking buttons =). Authors keep whole storage format aproximately same, but heavily change file headers format in each major version, especially flags. e.g. in one version file with 0x20 flag is uninstaller data, in other version it is directory flag, in third - long file, etc.
BUT all real raw data in CT has been bundled into single compressed token (0x7f7f If I remember correctly). So if you do not need original file names, you can try blindly split this bundle into pieces by formats. But this is realy not easy task too.

If you provide me a specific example of CT file, I can try give you a small description of the format and the flags for _this_ build of CT.

| Сообщение посчитали полезным:

Please give me a small description of the format and the flags for _this_ build of CT.
--> Link example project <--

| Сообщение посчитали полезным:

Like most installers ClickTeam Install Creator package consists of an executable stub and compressed data.
These data usually lie in the PE overlay (just after the last section). But it's better to find a simple 6-byte data signature - {0x77, 0x77, 0x67, 0x54, 0x29, 0x48}

Right after this signature variable count of data blocks begins. Each data block has their own header:



In all cases, what I saw, after block header goes such data:



The first byte in data_stream[] defines compression method:
0 – stored (uncompressed)
1 – deflated (zlib)
2 – bwt (bzip2)

After method byte raw compressed data stream begins.
Enough... I think that this information is more than enough for blocks enumeration

Now about block_id’s. Each block contains certain data - background wallpaper, dialogs, strings, eula, and other crap. We are only interested in these block id's (according to your sample, but id's can change from version to version):

0x143A – package files descriptors
0x143E – project descriptors
0x7F7F – files package block

I think the most significant byte of this id’s word means the installer version (0x14 == 2.0 in decimal), and low byte - real data type (for example in version 1.8 codes were 0x123A, 0x123E, 0x7F7F respectively). But I could be wrong.

NOTE: While files package block (0x7f7f) is always single, there can be several files/project blocks pairs. It means several installation types. For example you can look to click team install creator self installer - it has two descriptors pair - one for free version, second for registered (which require license for installation).

I haven't research project descriptors block (0x143E) deeply, but I think that if the second word of them is non zero, it means that this project is password/license protected (files data is encrypted).

File descriptors block (0x143A) contains all information about embedded files. First DWORD is number of file information nodes. File nodes has variable size and types (and format is changing from version to version). In your example, the file node format is approximately this:


There must be some flags in unknown1[] part of node (I don’t deal with this), they describe at least 3 types of nodes with different content/ For example some nodes contains time-data-stamp for installed file, but some not (uninstaller do not need it). This is probably the most difficult (because it changes frequently) part to reverse.

And last – file bundle block (0x7f7f). As an usual block its prefixed by 4-bytes ‘unpacked’ size (actually it’s fake – this value is same as packed size form block header). Next going a compressed streams for each file one by one. Each of them is prefixed by one byte with compression method id (see above), but the unpacked size absent (it should be taken from file descriptors block).

Sometimes there can quick hack - because zlib/bzip2 able to stop immediately after packed stream we can avoid parsing of file descriptors block, but just unpack streams one by one. Surely in that case we couldn't get real file names but only file content.

I wrote and attach a simple ‘dumper’ works following this scheme. Unfortunately, my code should fail on stored block (due to unknown size) or on first encrypted stream (due to encryption of course).

I hope this information will be useful to you. It is very boring to write such abstruse things in a foreign
language. I waste more than an hour on this post.


daad_09.06.2011_EXELAB.rU.tgz - ct_dump_v1.0.7z

| Сообщение посчитали полезным: _ruzmaz_, skypeaful, slip

Thank DrGolova
Your method is very good but how can we know exactly the name of the files after unpacked?

| Сообщение посчитали полезным:

> Your method is very good but how can we know exactly the name of the files after unpacked?

Reverse files descriptors block (0x143A) and grab names from file nodes
I can't say more specifically - file nodes format changes from version to version. Now I too lazy to deal with this.

| Сообщение посчитали полезным:

Thank. I can get the file name
But there are many file from file0000.bin to file0040.bin. How can we know what is the name for the file?
Example: file0000.bin change to comdlg32.ocx or ApiLoader.exe, ...

| Сообщение посчитали полезным: