Information pending...

[NeoAnderson]

Here you can see a screenshoot of an attempt stil running...


TEXT INPUT = first 5379 characters of DATA_000.ZED
PARAMETERS = AES 128 bit
COST regular expression = <File Name="

TEXT OUTPUT = if you look with attention you can see that the software already found some values that make the text start with "<fiL"

Interesting is the ESTIMATED END = "in a galaxy far, far away..." and the REMAINING TIME = "incalculable"

[Xander9009]

Ok, so it turns out the number isn't incalculable. It also won't be in a galaxy far, far away. It'll be in a vast void of nothingness or a whole new universe, depending on how you think the universe will end. It'll take something like 7188598349704212053797386.5 years to test all possible combinations if it's running at 1.5 million keys per second (that's what I'm averaging while you're averaging 2/3rds that). Unfortunately, it doesn't matter how small we make the file. What matters is how long the key is. The key's length is the only factor here except for exceptions: it won't contain the same number more than 2-digit hex number more than 8 times, probably since that would make it half the key. But since we don't know any exceptions, that doesn't help. (Sorry for those of you who already knew this. I'm not well versed in encryption, I'm just figuring this out from the math. This will already be common knowledge to those in the know, I imagine.)

[NeoAnderson]

I know the brute force is a no sense action with so few information that could reduct the calculations.
Anyway i enabled the OPENCL to use video card GPU to calculate the Keys, it is passed from 1 million with CPU to 38 Millions KEYS/SEC.
I also see that there is a configuration to create P2P network calculations, probably if we collect 100.000 users and we make a parallel calculation we could finish before the Universe BIG-CRUNCH..

[Xander9009]

I was just thinking (I'm heading to bed, so of course my brain's is active now ). 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?

[RiiakShiNal]

Unfortunately, that's not true. It could be present in the executable or some other file in plain text, but it could also be reversed, in binary, compressed, separated, encoded, shifted, or present in some other way. That of course assumes it is a traditional key to a traditional encryption/decryption algorithm.

[Xander9009]

Unfortunately, that's not true. It could be present in the executable or some other file in plain text, but it could also be reversed, in binary, compressed, separated, encoded, shifted, or present in some other way. That of course assumes it is a traditional key to a traditional encryption/decryption algorithm.

Yeah, I realized it might be obfuscated. Even so, considering the program can apparently try 38 million per second and it only takes 10 minutes or so to extract all possible 32-digit combinations (I already did it once, but there were a few spaces left it, messing stuff up), might as well try it. We just to find a way to get the program to try a list of keys.

EDIT: Because I have no life, I ran some numbers and the time it would take to check every number if you were using a computer that could process 50000 per second would be 174 years. Not nearly as infinite as originally thought. This is taking into account our current rate of technological expansion: doubling speed every 2 years. And of course, our rate of advancement will decrease at some point relatively soon because of the lack of anything small enough to store or process the data at some point. Oh, well.

Also, after removing all duplicates, there are 1.5 million potential keys.

[thefiremind]

I haven't really looked into 2015 for some time because I've been updating Kieran's mod with pics and info but I do remember seeing something about 'IBM' related to the .ZED file password.

I'm not sure about what Tejahn meant with that, but did someone already try to use 'IBM' as decryption key (I don't know for which algorithm, though), just to be sure that we didn't have the answer all along?

[NeoAnderson]

I am still walking into the "Dark Valley of unawareness", so i have HEX edited the Dotp_D15.exe searching for some relevant terms i found this part that could be interesting for the kind of encryption used (supposing it is referring to the ZED encryption)
"'NameValuePairs: type mismatch for '', stored '', trying to retrieve 'unknownClone() is not implemented yet.CryptoMaterial: this object contains invalid valuesBufferedTransformation: this object is not attachableCryptoMaterial: this object does not support precomputationPK_MessageAccumulator: TruncatedFinal() should not be calledPK_MessageAccumulator: DigestSize() should not be calledAlgorithmParametersBase: parameter "" not usedMGF1PK_MessageEncodingMethod: this signature scheme does not support message recoverySHA-1RSA)AllocatorBase: requested size would cause integer overflow(PSSR-/āµˆTtTہT„vT˜vTfTyTÈrÂá{TzzTzzTïxT6yT}yTMÇI¯RU||¼qT°qTà}ÂYƒTîT¬vT$€Tb€Tj€T‹€TMÇI˜€TŒTCUŸ+U…DU×+U.,UTEUk,UʁT¬€TbTbTÜrÂ{ƒTtTmtTàyT‰tT˜tT³tT´vTèÂIýÁIýÁI½tTÝtTøtTõvTuTÕ"U;uTÖ„T,Ѐ¼qT°qT~Â݈TÐ:Ut<U6wTFQUÍxTÞxT]QURUx¼qT°qT@uÂ#|TÐ:Ut<U6wTÙÜYÍxTÞxTÙÜYÙÜYpƒTõ€T>T±FUHU˜tT+HU¬€TZT§€TýÁI½tTÝtTøtT8HUuTÕ"U;uTÅ€TýÁI°€TŠIU^Tî€T4vÂňTÙÜYÙÜYÙÜYµuTÖTâTMÇI"

I can see some infos as like : (usedMGF1PK_MessageEncodingMethod), or (precomputationPK) or (recoverySHA-1RSA)
These words seems to be references to encryption method.
Searching on internet "MGF 1 PK" we could find some link talking about RSA Cryption algorythm.

So nothing of consistent i would just to share with you guys maybe someone who knows something more about encryption could use these infos.

UPDATE ANOTHER INTERESTING SECTION :
" inflate 1.2.2 Copyright 1995-2004 Mark Adler StringNarrow: wcstombs() call failedAAD exceeds the maximum of : IV length is less than the minimum of : IV length : this object requires an IV: this object cannot use a null IV: footer length Cryptographic algorithms are disabled before the power-up self tests are performed.: message length Cryptographic algorithms are disabled after a power-up self test failed. exceeds the maximum of : header length exceeds the maximum of : this object does't support a special last block exceeds the maximum of KeySize byte digest to HashTransformation: can't truncate a bytes--0-000-StringNarrow: wcstombs() call failedStringNarrow: wcstombs() call failed0-StringNarrow: wcstombs() call failed: ciphertext length of : this key is too short to encrypt any messages for this key doesn't match the required length of -TF_SignerBase: this algorithm does not support messsage recovery or the key is too short0TF_SignerBase: the recoverable message part is too long for the given key and algorithm: message length of for this public key exceeds the maximum of StringNarrow: wcstombs() call failed-0StringNarrow: wcstombs() call failedInvertibleRSAFunction: specified modulus size is too small0-InvertibleRSAFunction: input is not a valid RSA private keyInvertibleRSAFunction: input is not a valid RSA private keyInvertibleRSAFunction: computational error during private key operationInvertibleRSAFunction: invalid public exponentStringNarrow: wcstombs() call failed0-NodeSizeByteQueue: size specified for UndoLazyPut is too largeValueNames;ValueNamesStringNarrow: wcstombs() call failed0-ÿÿÿÿÿÿÿÿStringNarrow: wcstombs() call failedMinMaxInteger: Min must be no greater than MaxInteger: missing Max argumentInteger: Min must be no greater than MaxMaxBitLengthModMinRandomNumberTypeEquivalentTo0-Integer: invalid RandomNumberType argumentInteger: invalid EquivalentTo and/or Mod argumentMontgomeryRepresentation: Montgomery representation requires an odd modulusRandomNumberTypeEquivalentToModStringNarrow: wcstombs() call failed0-StringNarrow: wcstombs() call failed˜/ŠB‘D7qÏûÀµ¥Ûµé[ÂV9ññY¤‚?’Õ^«˜ªØ
[ƒ¾…1$Ã}Ut]¾rþ±Þ€§Ü›tñ›ÁÁi›ä†G¾ïƝÁÌ¡$o,é-ª„tJÜ©°\ÚˆùvRQ>˜mÆ1¨È'°ÇY¿óàÆG‘§ÕQcÊg))…·'8!.üm,M8STse»jv.Ɂ…,r’¡è¿¢Kf¨p‹K£QlÇè’Ñ$™Ö…5ôp jÁ¤l7LwH'µ¼°4³9JªØNOÊœ[óo.htoc¥xxÈ„ÇŒúÿ¾ëlP¤÷£ù¾òxqÆ"®(ט/ŠBÍeï#‘D7q/;MìÏûÀµ¼Û‰¥Ûµé8µHó[ÂV9жññY›O¯¤‚?’mÚÕ^«B£˜ªؾopE
[ƒŒ²äN¾…1$â´ÿÕÃ}Uo‰{òt]¾r±–;þ±Þ€5Ç%§Ü›”&iÏtñ›ÁÒJñžÁi›äã%O8†G¾ïµÕŒ‹ÆÁeœ¬wÌ¡$u+Yo,é-ƒä¦nª„tJÔûA½Ü©°\µSƒÚˆùv«ßfîRQ>˜2´-mÆ1¨?!û˜È'°äï¾ÇY¿Â¨=óàÆ%§“G‘§Õo‚àQcÊpng))ü/ÒF…'&É&\8!.í*ÄZüm,Mß³•8SÞc¯‹Tse¨²w<»jvæ®íG.Ɂ;5‚…,r’dñL¡è¿¢
0B¼Kf¨‘—øÐp‹KÂ0¾T£QlÇRïÖè’Ñ©eU$™Ö* qW…5ô¸Ñ»2p jÈÐÒ¸Á¤S«AQl7™ëŽßLwH'¨H›áµ¼°4cZÉų9ËŠAãJªØNsãcwOÊœ[£¸²Öóo.hü²ï]t`/Coc¥xr«ð¡xÈ„ì9dÇŒ(c#úÿ¾é½‚ÞëlP¤yƲ÷£ù¾+SrãòxqÆœa&êÎ>'ÊÂÀ!Ǹ†ÑëàÍÖ}ÚêxÑnîO}õºorªgð¦˜È¢Å}c®
ù¾˜?G5q„}#õwÛ(“$Ç@{«Ê2¼¾É¾ž<LœÄgC¶B>˾ÔÅL*~eüœ)YìúÖ:«oË_XGJŒDl-PSSR_MEM: message recovery disabled00123456789ABCDEF!B„
HPð 0@P`p€ °ÀÐàð
!1AQaq‘¡±ÁÑáñ"2BRbr‚’¢²ÂÒâò#3CScsƒ“£³ÃÓãó$4DTdt„”¤´ÄÔäô%5EUeu…•¥µÅÕåõ&6FVfv†–¦¶ÆÖæö'7GWgw‡—§·Ç×ç÷(8HXhxˆ˜¨¸ÈØèø )9IYiy‰™©¹ÉÙéù
*:JZjzŠšªºÊÚêú+;K[k{‹›«»ËÛëû,<L\l|Œœ¬¼ÌÜìü-=M]m}­½ÍÝíý.>N^n~Žž®¾ÎÞîþ/?O_oŸ¯¿Ïßïÿ€@À  `àPÐ0°pðˆHÈ(¨hè˜XØ8¸xø„DÄ$¤dä”TÔ4´tôŒLÌ,¬lìœ\Ü<¼|ü‚BÂ"¢bâ’RÒ2²rò
ŠJÊ*ªjêšZÚ:ºzú†FÆ&¦fæ–VÖ6¶vöŽNÎ.®nîž^Þ>¾~þ
AÁ!¡aá‘QÑ1±qñ ‰IÉ)©ié™YÙ9¹yù…EÅ%¥eå•UÕ5µuõMÍ-­mí]Ý=½}ýƒCÃ#£cã“SÓ3³só‹KË+«kë›[Û;»{û‡GÇ'§gç—W×7·w÷OÏ/¯oïŸ_ß?¿ÿ@€ÀPÐ ` à0p°ðD„ÄT”Ô$d¤ä4t´ôHˆÈX˜Ø(h¨è8x¸øLŒÌ\œÜ,l¬ì<|¼ü
AÁQ‘Ñ!a¡á1q±ñE…ÅU•Õ%e¥å5uµõ I‰ÉY™Ù)i©é9y¹ùMÍ]Ý-m­í=}½ýB‚ÂR’Ò"b¢â2r²òF†ÆV–Ö&f¦æ6v¶ö
JŠÊZšÚ*jªê:zºúNŽÎ^žÞ.n®î>~¾þCƒÃS“Ó#c£ã3s³óG‡ÇW—×'g§ç7w·÷K‹Ë[›Û+k«ë;{»ûOÏ_Ÿß/o¯ï?¿ÿError decoding compressed text"

Doing some searchs on internet i see that Mark Adler is one of the programmer of Zlib, going forward i connected Zlib to decryption and i found Crypto++ and i was wondering could be this tool able to decode the ZED?? ( If yes i think we still need the KEY )

[spirolone]

I'm working on Zed files decryption and I would like to share my first concrete results. I found that final part of Data Zed file is "encrypted" in same way that Movie Zed file is (yes, it also has an "encrypted" part!). It's sufficient to do a bitwise Xor between any byte and precedent one to obtain readable strings! I upload "decrypted" final part of Data_000.ZED (Update1 version), so that you can see what I mean, but we still need to work on. Sorry if I share only a partial result, but I didn't want someone waste time with approaches that MIGHT be unnecessary...

[RiiakShiNal]

Well, the "PK" there usually indicates zip compressed content. Because it is repeating in the partial binary given my guess is that fields are individually compressed.

[thefiremind]

Well, the "PK" there usually indicates zip compressed content. Because it is repeating in the partial binary given my guess is that fields are individually compressed.

This would make me think about a structure where there's [filename 1][zipped file 1][filename 2][zipped file 2] etc., but looking at the binary parts containing "PK" they seem more or less the same size (or exactly the same size, I didn't check). Even after zipping I would expect the sizes to vary if they really were different files individually zipped, especially by comparing XMLs with TDXs, the latter being already compressed and so hard to compress much further.

[spirolone]

Actually I'm looking at MOVIES_000.ZED and I noted that first part (<files>...</files>) is redundant and then unnecessary. I think that ZED files should be handled in this way: read last 8 bytes and do a Xor between first and second byte, third and fourth, etc...; you'll obtain a 4 byte offset. "Decrypt" since that offset as I said and you'll have list of files in that ZED archive (after about 238 bytes that I still don't understand). Every "entry" has a string with name of file; after that, there are 9 long integer (last 6 ones are "LowDate" and "HightDate" repeated 3 times each); before file name there is a long integer with offset where that file data starts in ZED file.
Next step, I think, it's understanding how data is stored; for example, a txt file isn't readable inside archive: is it encrypted or simply compressed?

[NeoAnderson]

Actually I'm looking at MOVIES_000.ZED and I noted that first part (<files>...</files>) is redundant and then unnecessary. I think that ZED files should be handled in this way: read last 8 bytes and do a Xor between first and second byte, third and fourth, etc...; you'll obtain a 4 byte offset. "Decrypt" since that offset as I said and you'll have list of files in that ZED archive (after about 238 bytes that I still don't understand). Every "entry" has a string with name of file; after that, there are 9 long integer (last 6 ones are "LowDate" and "HightDate" repeated 3 times each); before file name there is a long integer with offset where that file data starts in ZED file.
Next step, I think, it's understanding how data is stored; for example, a txt file isn't readable inside archive: is it encrypted or simply compressed?

Nice work, As i was saying we need someone who better know how to manage encrypted files!
ANyway looking your BIN files i could agree with Riiak that problably there are compressed file, probably the structure of each declaration has the same size because is a kind of "headers" section where the info about each compressed file is stored. So it doesn't matter the kind of file is stored it just reports the info about the archive.
I also think that they are PKZIP archives about the encryption probably you can check this table structure of PKZIP files:
The structure of a PKZip file

I copy here a part of that url :
Local file headers
Each local file header has the following structure:

Signature The signature of the local file header. This is always '\x50\x4b\x03\x04'.
Version PKZip version needed to extract
Flags General purpose bit flag:
Bit 00: encrypted file
Bit 01: compression option
Bit 02: compression option
Bit 03: data descriptor
Bit 04: enhanced deflation
Bit 05: compressed patched data
Bit 06: strong encryption
Bit 07-10: unused
Bit 11: language encoding
Bit 12: reserved
Bit 13: mask header values
Bit 14-15: reserved
Compression method 00: no compression
01: shrunk
02: reduced with compression factor 1
03: reduced with compression factor 2
04: reduced with compression factor 3
05: reduced with compression factor 4
06: imploded
07: reserved
08: deflated
09: enhanced deflated
10: PKWare DCL imploded
11: reserved
12: compressed using BZIP2
13: reserved
14: LZMA
15-17: reserved
18: compressed using IBM TERSE
19: IBM LZ77 z
98: PPMd version I, Rev 1
File modification time stored in standard MS-DOS format:
Bits 00-04: seconds divided by 2
Bits 05-10: minute
Bits 11-15: hour
File modification date stored in standard MS-DOS format:
Bits 00-04: day
Bits 05-08: month
Bits 09-15: years from 1980
Crc-32 checksum value computed over file data by CRC-32 algorithm with 'magic number' 0xdebb20e3 (little endian)
Compressed size if archive is in ZIP64 format, this filed is 0xffffffff and the length is stored in the extra field
Uncompressed size if archive is in ZIP64 format, this filed is 0xffffffff and the length is stored in the extra field
File name length the length of the file name field below
Extra field length the length of the extra field below
File name the name of the file including an optional relative path. All slashes in the path should be forward slashes '/'.
Extra field Used to store additional information. The field consistes of a sequence of header and data pairs, where the header has a 2 byte identifier and a 2 byte data size field.

Example
Our sample zip file starts with a local file header:

00000000 50 4b 03 04 14 00 00 00 08 00 1c 7d 4b 35 a6 e1 |PK.........}K5..|
00000010 90 7d 45 00 00 00 4a 00 00 00 05 00 15 00 66 69 |.}E...J.......fi|
00000020 6c 65 31 55 54 09 00 03 c7 48 2d 45 c7 48 2d 45 |le1UT....H-E.H-E|
00000030 55 78 04 00 f5 01 f5 01 0b c9 c8 2c 56 00 a2 92 |Ux.........,V...|

This results in the following fields and field values:
Signature '\x50\x4b\x03\x04'.
Version 0x14 = 20 -> 2.0
Flags no flags
Compression method 08: deflated
File modification time 0x7d1c = 0111110100011100
hour = (01111)10100011100 = 15
minute = 01111(101000)11100 = 40
second = 01111101000(11100) = 28 = 56 seconds
15:40:56
File modification date 0x354b = 0011010101001011
year = (0011010)101001011 = 26
month = 0011010(1010)01011 = 10
day = 00110101010(01011) = 11
10/11/2006
Crc-32 checksum 0x7d90e1a6
Compressed size 0x45 = 69 bytes
Uncompressed size 0x4a = 74 bytes
File name length 5 bytes
Extra field length 21 bytes
File name "file1"
Extra field id 0x5455: extended timestamp, size: 9 bytes
Id 0x7855: Info-ZIP UNIX, size: 4 bytes

If someone had time and want to read all the ZIP documentation can find it here :
PKWARE Inc. - ZIP File Format Specification

[thefiremind]

(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.

[NeoAnderson]

(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.