thefiremind wrote:(If someone read this post before my edit, screw that: I read the posts too quickly and didn't notice that spirolone probably already discovered how the information is arranged.
)
Now, let's assume that there's no encryption going on, and files are just zipped one by one inside the ZED "archive": what's the fastest way to test that it's true? Can we build a "proper" ZIP file by picking header and data and see if we can open it?
I'm happy: I feel there's progress going on, and I would be more than glad to help building a sort of new "Gibbed Tools" that can read and write ZED files once we understand the format completely.
The data should be arranged following this infos :
"
4.2 ZIP Metadata
----------------
4.2.1 ZIP files are identified by metadata consisting of defined record types
containing the storage information necessary for maintaining the files
placed into a ZIP file. Each record type MUST be identified using a header
signature that identifies the record type. Signature values begin with the
two byte constant marker of 0x4b50, representing the characters "PK".
4.3 General Format of a .ZIP file
---------------------------------
4.3.1 A ZIP file MUST contain an "end of central directory record". A ZIP
file containing only an "end of central directory record" is considered an
empty ZIP file. Files may be added or replaced within a ZIP file, or deleted.
A ZIP file MUST have only one "end of central directory record". Other
records defined in this specification MAY be used as needed to support
storage requirements for individual ZIP files.
4.3.2 Each file placed into a ZIP file MUST be preceeded by a "local
file header" record for that file. Each "local file header" MUST be
accompanied by a corresponding "central directory header" record within
the central directory section of the ZIP file.
4.3.3 Files MAY be stored in arbitrary order within a ZIP file. A ZIP
file MAY span multiple volumes or it MAY be split into user-defined
segment sizes. All values MUST be stored in little-endian byte order unless
otherwise specified in this document for a specific data element.
4.3.4 Compression MUST NOT be applied to a "local file header", an "encryption
header", or an "end of central directory record". Individual "central
directory records" must not be compressed, but the aggregate of all central
directory records MAY be compressed.
4.3.5 File data MAY be followed by a "data descriptor" for the file. Data
descriptors are used to facilitate ZIP file streaming.
4.3.6 Overall .ZIP file format:
[local file header 1] [encryption header 1]
[file data 1]
[data descriptor 1]
.
.
.
[local file header n]
[encryption header n]
[file data n]
[data descriptor n]
[archive decryption header]
[archive extra data record]
[central directory header 1]
.
.
.
[central directory header n]
[zip64 end of central directory record]
[zip64 end of central directory locator]
[end of central directory record]
4.3.7 Local file header:
local file header signature 4 bytes (0x04034b50)
version needed to extract 2 bytes
general purpose bit flag 2 bytes
compression method 2 bytes
last mod file time 2 bytes
last mod file date 2 bytes
crc-32 4 bytes
compressed size 4 bytes
uncompressed size 4 bytes
file name length 2 bytes
extra field length 2 bytes
file name (variable size)
extra field (variable size)
4.3.8 File data
Immediately following the local header for a file
SHOULD be placed the compressed or stored data for the file.
If the file is encrypted, the encryption header for the file
SHOULD be placed after the local header and before the file
data. The series of [local file header][encryption header]
[file data][data descriptor] repeats for each file in the
.ZIP archive.
Zero-byte files, directories, and other file types that
contain no content MUST not include file data."
But i still think that the data is encrypted using PK ENCRYPTION.
Posted: 20 Nov 2014, 02:55
and the REMAINING TIME = "incalculable" 
). Wouldn't the key be stored within the exe or some other file in plain text? I mean, it wouldn't be marked or anything, but it would be in there, wouldn't it? When viewed in a hex editor, there are only 4.2 million digits. Comparing that size to the other files (the dlls), that's roughly 5 million potential keys, which could be further reduced by removing any duplicates. If it were in there in plain text format, then any command line utility which could decrypt a file with aes could be used to check those <5 million in a rather short amount of time. Unfortunately, I'm not sure how to decrypt an AES encrypted file with the command line. Worth a shot?