Board index
Programs with AI or Rules Enforcement
Magic: The Gathering - Duels of the Planeswalkers
New MTG Cards and Decks (2010, 2012, 2013, 2014, 2015, Magic Duels)
2015




Information pending...
Moderator: CCGHQ Admins
Re: Information pending...
by spirolone » 24 Nov 2014, 22:55
Sorry for my english, maybe I have not been clear: I know what are little and big endian! I didn't understand what he is assuming speaking about little and big endian...NeoAnderson wrote:Little endian - used mostly in Intel machines.Little endian number is ...spirolone wrote:However, I didn't understand, then, what are you assuming about little or big endian...![]()
Flags : (00 01) = 0x0100 = 4 enhanced deflation
And I think 0x0100 = 0000 0001 0000 0000 -> bit 8 = 1. Then, it isn't indicating enhanced deflation. Obviously, however, they may use it, but I don't think flags are telling us something usefull...
- spirolone
- Programmer
- Posts: 190
- Joined: 31 Aug 2014, 23:14
- Has thanked: 7 times
- Been thanked: 107 times
Re: Information pending...
by NeoAnderson » 24 Nov 2014, 23:04
Yeah you right my friend, sorry about little and big endian misunderstanding, anyway i posted them so could be useful for other users.spirolone wrote:Sorry for my english, maybe I have not been clear: I know what are little and big endian! I didn't understand what he is assuming speaking about little and big endian...NeoAnderson wrote:Little endian - used mostly in Intel machines.Little endian number is ...spirolone wrote:However, I didn't understand, then, what are you assuming about little or big endian...![]()
Flags : (00 01) = 0x0100 = 4 enhanced deflation
And I think 0x0100 = 0000 0001 0000 0000 -> bit 8 = 1. Then, it isn't indicating enhanced deflation. Obviously, however, they may use it, but I don't think flags are telling us something usefull...
About the flags it's my mystake, Because the Hex : 0100 is 256 decimal so 0000 0001 0000 0000 binary and you're right.
- NeoAnderson
- Posts: 914
- Joined: 10 Sep 2013, 07:49
- Has thanked: 18 times
- Been thanked: 139 times
Re: Information pending...
by NeoAnderson » 25 Nov 2014, 00:04
Ok i can suppose the files are not encrypted with ( AES/DES/3DES/RC4/RC2/RC2-64/non-OAEP key wrapping ) this because if we look closely to the version needed we found (0x14) = 2.0 and if we compare this info with PKWARE specification about the versions :
4.4.3.1 The minimum supported ZIP specification version needed
to extract the file, mapped as above. This value is based on
the specific format features a ZIP program MUST support to
be able to extract the file. If multiple features are
applied to a file, the minimum version MUST be set to the
feature having the highest value. New features or feature
changes affecting the published format specification will be
implemented using higher version numbers than the last
published value to avoid conflict.
4.4.3.2 Current minimum feature versions are as defined below:
1.0 - Default value
1.1 - File is a volume label
2.0 - File is a folder (directory)
2.0 - File is compressed using Deflate compression
2.0 - File is encrypted using traditional PKWARE encryption
2.1 - File is compressed using Deflate64(tm)
2.5 - File is compressed using PKWARE DCL Implode
2.7 - File is a patch data set
4.5 - File uses ZIP64 format extensions
4.6 - File is compressed using BZIP2 compression*
5.0 - File is encrypted using DES
5.0 - File is encrypted using 3DES
5.0 - File is encrypted using original RC2 encryption
5.0 - File is encrypted using RC4 encryption
5.1 - File is encrypted using AES encryption
5.1 - File is encrypted using corrected RC2 encryption**
5.2 - File is encrypted using corrected RC2-64 encryption**
6.1 - File is encrypted using non-OAEP key wrapping***
6.2 - Central directory encryption
6.3 - File is compressed using LZMA
6.3 - File is compressed using PPMd+
6.3 - File is encrypted using Blowfish
6.3 - File is encrypted using Twofish
So if the file are encrypted with basic PKWARE encryption it should be really easy to broken as like there are many tools to recover password from zip files, it should be not so strong....
4.4.3.1 The minimum supported ZIP specification version needed
to extract the file, mapped as above. This value is based on
the specific format features a ZIP program MUST support to
be able to extract the file. If multiple features are
applied to a file, the minimum version MUST be set to the
feature having the highest value. New features or feature
changes affecting the published format specification will be
implemented using higher version numbers than the last
published value to avoid conflict.
4.4.3.2 Current minimum feature versions are as defined below:
1.0 - Default value
1.1 - File is a volume label
2.0 - File is a folder (directory)
2.0 - File is compressed using Deflate compression
2.0 - File is encrypted using traditional PKWARE encryption
2.1 - File is compressed using Deflate64(tm)
2.5 - File is compressed using PKWARE DCL Implode
2.7 - File is a patch data set
4.5 - File uses ZIP64 format extensions
4.6 - File is compressed using BZIP2 compression*
5.0 - File is encrypted using DES
5.0 - File is encrypted using 3DES
5.0 - File is encrypted using original RC2 encryption
5.0 - File is encrypted using RC4 encryption
5.1 - File is encrypted using AES encryption
5.1 - File is encrypted using corrected RC2 encryption**
5.2 - File is encrypted using corrected RC2-64 encryption**
6.1 - File is encrypted using non-OAEP key wrapping***
6.2 - Central directory encryption
6.3 - File is compressed using LZMA
6.3 - File is compressed using PPMd+
6.3 - File is encrypted using Blowfish
6.3 - File is encrypted using Twofish
So if the file are encrypted with basic PKWARE encryption it should be really easy to broken as like there are many tools to recover password from zip files, it should be not so strong....
- NeoAnderson
- Posts: 914
- Joined: 10 Sep 2013, 07:49
- Has thanked: 18 times
- Been thanked: 139 times
Re: Information pending...
by RiiakShiNal » 25 Nov 2014, 00:05
What I'm getting at is if the byte ordering is big-endian instead of the little-endian you are assuming then the value would be 0x0001 instead of 0x0100 which would indicate that bit-0 is set rather than bit-8. If bit-0 is actually set then based on the previously posted flags it would be an bit-0 encrypted file rather than bit-8 unused which would make more sense given the apparent encrypted/obfuscated state of the file. Also since the game can be used on mobile platforms it is more likely that some parts of the program/data will use big-endian stored data. You are likely currently assuming everything is little-endian based on the platform you are working on (which is not necessarily true).NeoAnderson wrote:Yeah you right my friend, sorry about little and big endian misunderstanding, anyway i posted them so could be useful for other users.spirolone wrote:Sorry for my english, maybe I have not been clear: I know what are little and big endian! I didn't understand what he is assuming speaking about little and big endian...
And I think 0x0100 = 0000 0001 0000 0000 -> bit 8 = 1. Then, it isn't indicating enhanced deflation. Obviously, however, they may use it, but I don't think flags are telling us something usefull...
About the flags it's my mystake, Because the Hex : 0100 is 256 decimal so 0000 0001 0000 0000 binary and you're right.
To switch the endianness of a short that has already been read into memory you can do byte swapping like this (I converted to a 4-byte int first to avoid any signed bit shifting issues, though you could also use unsigned variables without changing value size):
- Code: Select all
int nLongValue = nShortValue;
short nSwappedShort = ((nLongValue & 0xFF00) >> 8) + ((nLongValue & 0xFF) << 8);
Just getting started: Xander9009's DotP 2014 Community Wad
Need a deck builder: DotP 2014 Deck Builder
Problems Modding: DotP 2014 Frequent Modding Mistakes
Need a deck builder: DotP 2014 Deck Builder
Problems Modding: DotP 2014 Frequent Modding Mistakes
- RiiakShiNal
- Programmer
- Posts: 2188
- Joined: 16 May 2011, 21:37
- Has thanked: 75 times
- Been thanked: 497 times
Re: Information pending...
by NeoAnderson » 25 Nov 2014, 00:20
- RiiakShiNal | Open
- RiiakShiNal wrote:
What I'm getting at is if the byte ordering is big-endian instead of the little-endian you are assuming then the value would be 0x0001 instead of 0x0100 which would indicate that bit-0 is set rather than bit-8. If bit-0 is actually set then based on the previously posted flags it would be an bit-0 encrypted file rather than bit-8 unused which would make more sense given the apparent encrypted/obfuscated state of the file. Also since the game can be used on mobile platforms it is more likely that some parts of the program/data will use big-endian stored data. You are likely currently assuming everything is little-endian based on the platform you are working on (which is not necessarily true).NeoAnderson wrote:
Yeah you right my friend, sorry about little and big endian misunderstanding, anyway i posted them so could be useful for other users.spirolone wrote:Sorry for my english, maybe I have not been clear: I know what are little and big endian! I didn't understand what he is assuming speaking about little and big endian...
And I think 0x0100 = 0000 0001 0000 0000 -> bit 8 = 1. Then, it isn't indicating enhanced deflation. Obviously, however, they may use it, but I don't think flags are telling us something usefull...
About the flags it's my mystake, Because the Hex : 0100 is 256 decimal so 0000 0001 0000 0000 binary and you're right.
To switch the endianness of a short that has already been read into memory you can do byte swapping like this (I converted to a 4-byte int first to avoid any signed bit shifting issues, though you could also use unsigned variables without changing value size):- Code: Select all
int nLongValue = nShortValue;
short nSwappedShort = ((nLongValue & 0xFF00) >> 8) + ((nLongValue & 0xFF) << 8);
And i have checked the General Purpose Flags doesn't have any note that says : "Stored with Big-Endian" format.
Anyway i Agree with you that should have more sense considering it as 0x0001 "encrypted" the only thing i can be sure is that they haven't used any new Encryption algorythm so if it is encrypted is just basic ZIP encryption or some obfuscating operation.
Another proof of the fact that the file is not Encrypted with AES is the follow test :
I used PKzip to make 3 different zip file with the same 1 Xml file "FILE1.XML".
1. file normal zip not encryted
2. file zipped with AES 128bit encryption
3. file zipped with AES 256bit encryption
Now i copied the Hex values after the file name inside central directory :
HEX NOT ENCRYPTED ZIP
- Code: Select all
0A 00 20 00 00 00 00 00 01 00 18 00 6D D0 B1 64
3C F8 CF 01 F7 B7 E4 98 5D 06 D0 01 F7 B7 E4 98
5D 06 D0 01
- Code: Select all
0A 00 20 00 00 00 00 00 01 00 18 00 6D D0 B1 64
3C F8 CF 01 F7 B7 E4 98 5D 06 D0 01 F7 B7 E4 98
5D 06 D0 01 17 00 0C 00 02 00 0E 66 80 00 01 00
00 00 00 00
Now i copied the values from XOR DATA.000.ZED just one random file from the data
HEX VALUES FROM XOR DATA.ZED
- Code: Select all
0A 00 20 00 00 00 00 00 01 00 18 00 18 6E D4 9D
A9 A2 CF 01 18 6E D4 9D A9 A2 CF 01 18 6E D4 9D
A9 A2 CF 01
The size is exact the same of the unencrypted zip file.
- NeoAnderson
- Posts: 914
- Joined: 10 Sep 2013, 07:49
- Has thanked: 18 times
- Been thanked: 139 times
Re: Information pending...
by RiiakShiNal » 25 Nov 2014, 00:57
It should be noted that AES would fall under strong encryption, but PKZIP also supports other encryption methods (3DES, DES, RC2, RC4, Cast5, IDEA, and Traditional ZIP Password Encryption). So it is quite possible that it is encrypted using one of the other encryption methods that you are overlooking. It is insufficient to list extra fields in only one of the possible methods as proof that the data is not encrypted (it would only show the one method is not used and even then only if they have not violated the standard, which is possible because they obfuscated the trailing central directory without apparently having the proper header and other information).
We don't have enough information to start wholesale saying "it's not using this or that".
We don't have enough information to start wholesale saying "it's not using this or that".
Last edited by RiiakShiNal on 25 Nov 2014, 01:00, edited 1 time in total.
Just getting started: Xander9009's DotP 2014 Community Wad
Need a deck builder: DotP 2014 Deck Builder
Problems Modding: DotP 2014 Frequent Modding Mistakes
Need a deck builder: DotP 2014 Deck Builder
Problems Modding: DotP 2014 Frequent Modding Mistakes
- RiiakShiNal
- Programmer
- Posts: 2188
- Joined: 16 May 2011, 21:37
- Has thanked: 75 times
- Been thanked: 497 times
Re: Information pending...
by NeoAnderson » 25 Nov 2014, 00:59
If you read my post before i already found that (3DES, DES, RC2, RC4,...) are not used because if it was the version needed should be most recent. But as i said before if it is encrypted they just used ZIP password encryption (and can be broken) or they simply obfuscated the files with somekind of operation.RiiakShiNal wrote:It should be noted that AES would fall under strong encryption, but PKZIP also supports other encryption methods (3DES, DES, RC2, RC4, Cast5, IDEA, and Traditional ZIP Password Encryption). So it is quite possible that it is encrypted using one of the other encryption methods that you are overlooking. It is insufficient to list extra fields in only one of the possible methods as proof that the data is not encrypted.
- Current minimum feature versions are | Open
- 4.4.3.2 Current minimum feature versions are as defined below:
1.0 - Default value
1.1 - File is a volume label
2.0 - File is a folder (directory)
2.0 - File is compressed using Deflate compression
2.0 - File is encrypted using traditional PKWARE encryption
2.1 - File is compressed using Deflate64(tm)
2.5 - File is compressed using PKWARE DCL Implode
2.7 - File is a patch data set
4.5 - File uses ZIP64 format extensions
4.6 - File is compressed using BZIP2 compression*
5.0 - File is encrypted using DES
5.0 - File is encrypted using 3DES
5.0 - File is encrypted using original RC2 encryption
5.0 - File is encrypted using RC4 encryption
5.1 - File is encrypted using AES encryption
5.1 - File is encrypted using corrected RC2 encryption**
5.2 - File is encrypted using corrected RC2-64 encryption**
6.1 - File is encrypted using non-OAEP key wrapping***
6.2 - Central directory encryption
6.3 - File is compressed using LZMA
6.3 - File is compressed using PPMd+
6.3 - File is encrypted using Blowfish
6.3 - File is encrypted using Twofish
- Code: Select all
50 4B 01 02 3F 00 14 00 00 01 08 00
I don't think they use AES/DES/3DES... after compressing the archive, but we cannot totally exclude it. My though is if i have to use a library that already complain the strong encryption i directly use that libraries.
Just another question..i have made an XOR version of DATA_000.ZED using VBA but the results seems to be a little bit different comparing with the test file sent by Spirolone, the weird thing is that the most part of the data is the same, only some HEX values are different.
Here is the code i have used :
- VBA MACRO ZED-XOR | Open
- Code: Select all
Sub Macro1()
'
' Macro1 Macro
'
' Scelta rapida da tastiera: CTRL+s
'
Dim intFileNum%, bytTemp As Byte, Prev As Byte, XorByte As Byte
intFileNum = FreeFile
Prev = 0
Open "C:\Users\Neo Anderson\Desktop\Zed experiment\DATA_000.ZED" For Binary Access Read As intFileNum
Open "C:\Users\Neo Anderson\Desktop\Zed experiment\Test_000.BIN" For Binary As #2
Do While Not EOF(intFileNum)
Get intFileNum, , bytTemp
XorByte = bytTemp Xor Prev
Put #2, , XorByte
Prev = bytTemp
Loop
Close intFileNum
Close #2
End Sub
SPIROLONE TEST TEXT :
- Code: Select all
PK?òD“Æ‚Dvœ=$$ |E÷Data_000/Data_PC/Credits/CREDITS.TXT þóÐ8©¢ÏþóÐ8©¢Ï8¾&¡Ï%òí\÷
- Code: Select all
PK?¹ÆDYó³Wr=$$ ¦²ôData_000/Data_PC/Credits/CREDITS.TXT oXnÎÏoXnÎÏP†SéuϸìÊôÓ
- Code: Select all
50 4B 01 02 3F 00 14 00 00 01 08 00 10 8F F2 44
93 C6 82 44 76 17 00 00 9C 3D 00 00 24 00 24 00
00 00 00 00 00 00 20 00 00 00 7C 45 F7 13 44 61
74 61 5F 30 30 30 2F 44 61 74 61 5F 50 43 2F 43
72 65 64 69 74 73 2F 43 52 45 44 49 54 53 2E 54
58 54 0A 00 20 00 00 00 00 00 01 00 18 00 FE F3
D0 38 A9 A2 CF 01 FE F3 D0 38 A9 A2 CF 01 38 BE
1D AD 26 A1 CF 01 25 F2 ED 5C 11 F7 00 13
- Code: Select all
50 4B 01 02 3F 00 14 00 00 01 08 00 B9 01 C6 44
59 F3 B3 57 72 17 00 00 90 3D 00 00 24 00 24 00
00 00 00 00 00 00 20 00 00 00 A6 B2 F4 13 44 61
74 61 5F 30 30 30 2F 44 61 74 61 5F 50 43 2F 43
72 65 64 69 74 73 2F 43 52 45 44 49 54 53 2E 54
58 54 0A 00 20 00 00 00 00 00 01 00 18 00 6F 58
6E CE 13 81 CF 01 6F 58 6E CE 13 81 CF 01 50 1D
86 53 E9 75 CF 01 B8 18 EC CA 11 F4 00 13 D3
- NeoAnderson
- Posts: 914
- Joined: 10 Sep 2013, 07:49
- Has thanked: 18 times
- Been thanked: 139 times
Re: Information pending...
by thefiremind » 25 Nov 2014, 09:10
To be honest I don't know... maybe a bad conversion at some point? Try to output your results at various points in the code and see if you can find where the result starts being different.NeoAnderson wrote:Just another question..i have made an XOR version of DATA_000.ZED using VBA but the results seems to be a little bit different comparing with the test file sent by Spirolone, the weird thing is that the most part of the data is the same, only some HEX values are different.
I'm starting to think that we need either a stroke of luck (one of us finds a test that gives the correct answer out of pure luck) or help from someone who's good at disassembling (looks at what the the executable does from a debugger and understands how ZED files are treated). Some time ago I tried to run the executable from OllyDbg, but I had no clue about where to look at.drleg3nd wrote:awesome that there seem to be some progress with getting into 2015, but since I have no idea what the heck you guys are talking about, are we close to getting an answer to the problem ?
< Former DotP 2012/2013/2014 modder >
Currently busy with life...
Currently busy with life...
-
thefiremind - Programmer
- Posts: 3515
- Joined: 07 Nov 2011, 10:55
- Has thanked: 118 times
- Been thanked: 722 times
Re: Information pending...
by NeoAnderson » 25 Nov 2014, 13:41
No fire, the weird thing is that this happen from the beginning to the end. Obviously i cannot compare the whole file because the test file of Spirolone only contains the part with central directory, but if we compare it are different on each entry. The only reason that make sense is that we started from different DATA_000_.ZED versions.thefiremind wrote:To be honest I don't know... maybe a bad conversion at some point? Try to output your results at various points in the code and see if you can find where the result starts being different.NeoAnderson wrote:Just another question..i have made an XOR version of DATA_000.ZED using VBA but the results seems to be a little bit different comparing with the test file sent by Spirolone, the weird thing is that the most part of the data is the same, only some HEX values are different.
- NeoAnderson
- Posts: 914
- Joined: 10 Sep 2013, 07:49
- Has thanked: 18 times
- Been thanked: 139 times
Re: Information pending...
by thefiremind » 25 Nov 2014, 14:34
That's right, how could I not think about that?NeoAnderson wrote:The only reason that make sense is that we started from different DATA_000_.ZED versions.

< Former DotP 2012/2013/2014 modder >
Currently busy with life...
Currently busy with life...
-
thefiremind - Programmer
- Posts: 3515
- Joined: 07 Nov 2011, 10:55
- Has thanked: 118 times
- Been thanked: 722 times
Re: Information pending...
by NeoAnderson » 25 Nov 2014, 16:40
Following firemind previous topic i downloaded OllyDbg 2.0 and i tried to retrieve some infos..obiously it is too complex but i want to report something...when i have analyzed the DotP_D15.exe the debugger program show me the follow message :

Now we could think that is related to the compressed data, so i decided to do the same with DotP_D14.exe and the message is not displayed.
Maybe that it is related to the Encryption???? Because the warning talk about Compressed. Encrypted or large amount of Embedded Data.
Now D14 should have the same amount of Compressed or Embedded Data maybe that the difference is the Encryption??
I post here some data retrieved from OllyDbg 2.0 i haven't the needed knowledge to use it maybe someone could find something useful.
cryptbase.dll is the Base cryptographic API DLL. Microsoft's CryptoAPI was first introduced in Windows NT 4.0 to provide services that enables developers to secure Windows-based applications using cryptography.Disassembled Instruction :

UPDATE : "cryptbase.dll" is also used by Dotp_D14 so it should be not considered as some cryptographic encryption onto ZED...but the first msgbox is still a mystery.
UPDATE 2 : I have seen that the game cannot load during debug session, i got a steam error. So i tried to remove DATA_000.ZED from the game folder, then i started a new debug session, and i found the same registers operations and the same dll loaded, the debug session is terminated with the same steam error.
So i think that all the infos i get from the debugger are retrieved before the game load the zed files.
I used a 3dmgame version maybe someone who has an official version could check if the game can load into a debug session, so we could try to retrieve infos when the zed are loaded.

Now we could think that is related to the compressed data, so i decided to do the same with DotP_D14.exe and the message is not displayed.
Maybe that it is related to the Encryption???? Because the warning talk about Compressed. Encrypted or large amount of Embedded Data.
Now D14 should have the same amount of Compressed or Embedded Data maybe that the difference is the Encryption??
I post here some data retrieved from OllyDbg 2.0 i haven't the needed knowledge to use it maybe someone could find something useful.
- DotP_D15.exe - Memory map | Open
- Code: Select all
Memory map
Address Size Owner Section Contains Type Access Initial >Mapped as
00010000 00010000 > 00010000 (self) Map >RW RW
00020000 00001000 > 00020000 (self) Priv >RWE RWE
00030000 0000B000 > 00030000 (self) Priv >RWE RWE
00040000 00001000 > 00040000 (self) Img >R RWE Copy>
00089000 00007000 > 00050000 Priv >RW Guar>RW Guar>
0018A000 00001000 > 00090000 Priv >RW Guar>RW Guar>
0018B000 00005000 > 00090000 Stack of main thre>Priv >RW RW
00190000 00004000 > 00190000 (self) Map >R R
001A0000 00001000 > 001A0000 (self) Map >R R
001B0000 00001000 > 001B0000 (self) Priv >RW RW
001C0000 00001000 > 001C0000 (self) Priv >RW RW
001D0000 00001000 > 001D0000 (self) Priv >RWE RWE
001E0000 00067000 > 001E0000 (self) Map >R R \Device\HarddiskVolume1\Windows\System32\locale.nls
00250000 00001000 > 00250000 (self) Map >R R
00260000 0000B000 > 00260000 (self) Priv >RWE RWE
00270000 0000B000 > 00270000 (self) Priv >RWE RWE
00280000 00001000 > 00280000 (self) Map >R R
00290000 00001000 > 00290000 (self) Map >R R
002A0000 00001000 > 002A0000 (self) Priv >RW RW
002B0000 00006000 > 002B0000 (self) Priv >RW RW
00330000 00001000 > 00330000 (self) Priv >RW RW
00340000 00001000 > 00340000 (self) Map >RW RW
00350000 00007000 > 00350000 (self) Map >R R
00360000 00002000 > 00360000 (self) Map >RW RW
00380000 00005000 > 00380000 (self) Priv >RW RW
00400000 00001000 >DotP_D15 00400000 (self) PE header Img >R RWE Copy>
00401000 00716000 >DotP_D15 00400000 .text Code Img >R E RWE Copy>
00B17000 00001000 >DotP_D15 00400000 BINK Code Img >R E RWE Copy>
00B18000 00001000 >DotP_D15 00400000 BINKBSS Img >RW RWE Copy>
00B19000 0015D000 >DotP_D15 00400000 .rdata Imports Img >R RWE Copy>
00C76000 00161000 >DotP_D15 00400000 .data Data Img >RW Copy>RWE Copy>
00DD7000 00001000 >DotP_D15 00400000 BINKDATA Img >RW Copy>RWE Copy>
00DD8000 0004F000 >DotP_D15 00400000 .rsrc Resources Img >R RWE Copy>
00E27000 00063000 >DotP_D15 00400000 .bind SFX Img >R E RWE Copy>
00F00000 00003000 > 00F00000 (self) Priv >RW RW
00F10000 00003000 > 00F10000 (self) Priv >RW RW
00F60000 00013000 > 00F60000 (self) Priv >RW RW
010C0000 00001000 > 010C0000 (self) Priv >RW RW
01170000 00007000 > 01170000 (self) Priv >RW RW
01180000 0001E000 > 01180000 (self) Map >R R
01300000 00003000 > 01180000 Map >R R
01310000 00181000 > 01310000 (self) Map >R R
014A0000 002E8000 > 014A0000 (self) Map >R R
02990000 00002000 > 02990000 (self) Priv >RW RW
029A0000 003A7000 > 029A0000 (self) Map >R R
02E70000 00003000 > 02E70000 (self) Priv >RW RW
02FE0000 00001000 > 02FE0000 (self) Priv >RW RW
560E0000 00001000 >fmodex 560E0000 (self) PE header Img >R RWE Copy>
560E1000 000E0000 >fmodex 560E0000 Img >R E RWE Copy>
561C1000 0003A000 >fmodex 560E0000 Img >R RWE Copy>
561FB000 00051000 >fmodex 560E0000 Img >RW Copy>RWE Copy>
5624C000 0000B000 >fmodex 560E0000 Img >R RWE Copy>
5B4E0000 00001000 >d3dx9_43 5B4E0000 (self) PE header Img >R RWE Copy>
5B4E1000 001C9000 >d3dx9_43 5B4E0000 Img >R E RWE Copy>
5B6AA000 00026000 >d3dx9_43 5B4E0000 Img >RW Copy>RWE Copy>
5B6D0000 0000F000 >d3dx9_43 5B4E0000 Img >R RWE Copy>
63EA0000 00001000 >d3d9 63EA0000 (self) PE header Img >R RWE Copy>
63EA1000 001A8000 >d3d9 63EA0000 Img >R E RWE Copy>
64049000 0000A000 >d3d9 63EA0000 Img >RW Copy>RWE Copy>
64053000 00010000 >d3d9 63EA0000 Img >R RWE Copy>
67A30000 00001000 >d3d8thk 67A30000 (self) PE header Img >R RWE Copy>
67A31000 00002000 >d3d8thk 67A30000 Img >R E RWE Copy>
67A33000 00001000 >d3d8thk 67A30000 Img >RW RWE Copy>
67A34000 00002000 >d3d8thk 67A30000 Img >R RWE Copy>
6FA80000 00001000 >snxhk 6FA80000 (self) PE header Img >R RWE Copy>
6FA81000 0001E000 >snxhk 6FA80000 Img >R E RWE Copy>
6FA9F000 00008000 >snxhk 6FA80000 Img >R RWE Copy>
6FAA7000 0000B000 >snxhk 6FA80000 Img >RW Copy>RWE Copy>
6FAB2000 0000A000 >snxhk 6FA80000 Img >R RWE Copy>
724D0000 00001000 >dwmapi 724D0000 (self) PE header Img >R RWE Copy>
724D1000 0000B000 >dwmapi 724D0000 Img >R E RWE Copy>
724DC000 00002000 >dwmapi 724D0000 Img >RW RWE Copy>
724DE000 00005000 >dwmapi 724D0000 Img >R RWE Copy>
726D0000 00001000 >profapi 726D0000 (self) PE header Img >R RWE Copy>
726D1000 00007000 >profapi 726D0000 Img >R E RWE Copy>
726D8000 00001000 >profapi 726D0000 Img >RW RWE Copy>
726D9000 00002000 >profapi 726D0000 Img >R RWE Copy>
72BB0000 00001000 >webio 72BB0000 (self) PE header Img >R RWE Copy>
72BB1000 00032000 >webio 72BB0000 Img >R E RWE Copy>
72BE3000 0000A000 >webio 72BB0000 Img >RW Copy>RWE Copy>
72BED000 00012000 >webio 72BB0000 Img >R RWE Copy>
72C90000 00001000 >WINHTTP 72C90000 (self) PE header Img >R RWE Copy>
72C91000 0004D000 >WINHTTP 72C90000 Img >R E RWE Copy>
72CDE000 00001000 >WINHTTP 72C90000 Img >RW RWE Copy>
72CDF000 00009000 >WINHTTP 72C90000 Img >R RWE Copy>
733F0000 00001000 >MSACM32 733F0000 (self) PE header Img >R RWE Copy>
733F1000 00010000 >MSACM32 733F0000 Img >R E RWE Copy>
73401000 00001000 >MSACM32 733F0000 Img >RW RWE Copy>
73402000 00002000 >MSACM32 733F0000 Img >R RWE Copy>
73470000 00001000 >WINMM 73470000 (self) PE header Img >R RWE Copy>
73471000 00027000 >WINMM 73470000 Img >R E RWE Copy>
73498000 00003000 >WINMM 73470000 Img >RW Copy>RWE Copy>
7349B000 00007000 >WINMM 73470000 Img >R RWE Copy>
73A30000 00001000 >bink2w32 73A30000 (self) PE header Img >R RWE Copy>
73A31000 0003F000 >bink2w32 73A30000 Img >R E RWE Copy>
73A70000 0000B000 >bink2w32 73A30000 Img >RW Copy>RWE Copy>
73A7B000 00002000 >bink2w32 73A30000 Img >R RWE Copy>
73A7D000 00004000 >bink2w32 73A30000 Img >RW Copy>RWE Copy>
73A81000 00008000 >bink2w32 73A30000 Img >R RWE Copy>
73A89000 00004000 >bink2w32 73A30000 Img >RW Copy>RWE Copy>
73A8D000 00009000 >bink2w32 73A30000 Img >R RWE Copy>
73AA0000 00001000 >steam_api 73AA0000 (self) PE header Img >R RWE Copy>
73AA1000 0001B000 >steam_api 73AA0000 Img >R E RWE Copy>
73ABC000 0000A000 >steam_api 73AA0000 Img >R RWE Copy>
73AC6000 00005000 >steam_api 73AA0000 Img >RW RWE Copy>
73ACB000 00065000 >steam_api 73AA0000 Img >RWE Copy>RWE Copy>
73B30000 00002000 >steam_api 73AA0000 Img >R RWE Copy>
73B60000 00001000 >fmod_event 73B60000 (self) PE header Img >R RWE Copy>
73B61000 0004E000 >fmod_event 73B60000 Img >R E RWE Copy>
73BAF000 00014000 >fmod_event 73B60000 Img >R RWE Copy>
73BC3000 00004000 >fmod_event 73B60000 Img >RW RWE Copy>
73BC7000 00005000 >fmod_event 73B60000 Img >R RWE Copy>
73BD0000 00001000 >XINPUT9_1_0 73BD0000 (self) PE header Img >R RWE Copy>
73BD1000 00005000 >XINPUT9_1_0 73BD0000 Img >R E RWE Copy>
73BD6000 00001000 >XINPUT9_1_0 73BD0000 Img >RW RWE Copy>
73BD7000 00002000 >XINPUT9_1_0 73BD0000 Img >R RWE Copy>
73C10000 00001000 >WSOCK32 73C10000 (self) PE header Img >R RWE Copy>
73C11000 00003000 >WSOCK32 73C10000 Img >R E RWE Copy>
73C14000 00001000 >WSOCK32 73C10000 Img >RW RWE Copy>
73C15000 00002000 >WSOCK32 73C10000 Img >R RWE Copy>
740A0000 00001000 >dbghelp 740A0000 (self) PE header Img >R RWE Copy>
740A1000 000C4000 >dbghelp 740A0000 Img >R E RWE Copy>
74165000 0001C000 >dbghelp 740A0000 Img >RW Copy>RWE Copy>
74181000 0000A000 >dbghelp 740A0000 Img >R RWE Copy>
741B0000 00001000 >gdiplus 741B0000 (self) PE header Img >R RWE Copy>
741B1000 0016B000 >gdiplus 741B0000 Img >R E RWE Copy>
7431C000 00009000 >gdiplus 741B0000 Img >RW Copy>RWE Copy>
74325000 0001B000 >gdiplus 741B0000 Img >R RWE Copy>
75260000 00001000 >VERSION 75260000 (self) PE header Img >R RWE Copy>
75261000 00005000 >VERSION 75260000 Img >R E RWE Copy>
75266000 00001000 >VERSION 75260000 Img >RW RWE Copy>
75267000 00002000 >VERSION 75260000 Img >R RWE Copy>
75270000 00001000 > 75270000 (self) Img >R RWE Copy>
75271000 00003000 > 75270000 Img >R E RWE Copy>
75274000 00001000 > 75270000 Img >RW RWE Copy>
75275000 00003000 > 75270000 Img >R RWE Copy>
75280000 00001000 > 75280000 (self) Img >R RWE Copy>
75281000 0004D000 > 75280000 Img >R E RWE Copy>
752CE000 00005000 > 75280000 Img >RW Copy>RWE Copy>
752D3000 00009000 > 75280000 Img >R RWE Copy>
752E0000 00001000 > 752E0000 (self) Img >R RWE Copy>
752E1000 00038000 > 752E0000 Img >R E RWE Copy>
75319000 00002000 > 752E0000 Img >RW RWE Copy>
7531B000 00004000 > 752E0000 Img >R RWE Copy>
754C0000 00001000 >CRYPTBASE 754C0000 (self) PE header Img >R RWE Copy>
754C1000 00008000 >CRYPTBASE 754C0000 Img >R E RWE Copy>
754C9000 00001000 >CRYPTBASE 754C0000 Img >RW RWE Copy>
754CA000 00002000 >CRYPTBASE 754C0000 Img >R RWE Copy>
754D0000 00001000 >SspiCli 754D0000 (self) PE header Img >R RWE Copy>
754E0000 00016000 >SspiCli 754D0000 Img >R E RWE Copy>
75500000 00001000 >SspiCli 754D0000 Img >RW RWE Copy>
75510000 00001000 >SspiCli 754D0000 Img >R RWE Copy>
75520000 00002000 >SspiCli 754D0000 Img >R RWE Copy>
75530000 00001000 >USP10 75530000 (self) PE header Img >R RWE Copy>
75531000 0005B000 >USP10 75530000 Img >R E RWE Copy>
7558C000 00002000 >USP10 75530000 Img >RW RWE Copy>
7558E000 0003F000 >USP10 75530000 Img >R RWE Copy>
755E0000 00001000 >CFGMGR32 755E0000 (self) PE header Img >R RWE Copy>
755E1000 00022000 >CFGMGR32 755E0000 Img >R E RWE Copy>
75603000 00001000 >CFGMGR32 755E0000 Img >RW RWE Copy>
75604000 00003000 >CFGMGR32 755E0000 Img >R RWE Copy>
756D0000 00001000 >SETUPAPI 756D0000 (self) PE header Img >R RWE Copy>
756D1000 000AF000 >SETUPAPI 756D0000 Img >R E RWE Copy>
75780000 00005000 >SETUPAPI 756D0000 Img >RW Copy>RWE Copy>
75785000 000E8000 >SETUPAPI 756D0000 Img >R RWE Copy>
75870000 00001000 >SHELL32 75870000 (self) PE header Img >R RWE Copy>
75871000 003C9000 >SHELL32 75870000 Img >R E RWE Copy>
75C3A000 00007000 >SHELL32 75870000 Img >RW Copy>RWE Copy>
75C41000 00879000 >SHELL32 75870000 Img >R RWE Copy>
764C0000 00001000 >KERNELBASE 764C0000 (self) PE header Img >R RWE Copy>
764C1000 00040000 >KERNELBASE 764C0000 Img >R E RWE Copy>
76501000 00002000 >KERNELBASE 764C0000 Img >RW RWE Copy>
76503000 00004000 >KERNELBASE 764C0000 Img >R RWE Copy>
76510000 00001000 >IMM32 76510000 (self) PE header Img >R RWE Copy>
76520000 00017000 >IMM32 76510000 Img >R E RWE Copy>
76540000 00001000 >IMM32 76510000 Img >RW RWE Copy>
76550000 00005000 >IMM32 76510000 Img >R RWE Copy>
76560000 00001000 >IMM32 76510000 Img >R RWE Copy>
76570000 00010000 >KERNEL32 76570000 (self) PE header Img >R RWE Copy>
76580000 000C1000 >KERNEL32 76570000 Img >R E RWE Copy>
76650000 00002000 >KERNEL32 76570000 Img >RW Copy>RWE Copy>
76660000 00001000 >KERNEL32 76570000 Img >R RWE Copy>
76670000 0000B000 >KERNEL32 76570000 Img >R RWE Copy>
766B0000 00001000 >ADVAPI32 766B0000 (self) PE header Img >R RWE Copy>
766B1000 00072000 >ADVAPI32 766B0000 Img >R E RWE Copy>
76723000 00004000 >ADVAPI32 766B0000 Img >RW Copy>RWE Copy>
76727000 00029000 >ADVAPI32 766B0000 Img >R RWE Copy>
76790000 00001000 >OLEAUT32 76790000 (self) PE header Img >R RWE Copy>
76791000 00085000 >OLEAUT32 76790000 Img >R E RWE Copy>
76816000 00002000 >OLEAUT32 76790000 Img >RW RWE Copy>
76818000 00007000 >OLEAUT32 76790000 Img >R RWE Copy>
76AE0000 00001000 >USER32 76AE0000 (self) PE header Img >R RWE Copy>
76AF0000 0006D000 >USER32 76AE0000 Img >R E RWE Copy>
76B60000 00001000 >USER32 76AE0000 Img >RW RWE Copy>
76B70000 0005B000 >USER32 76AE0000 Img >R RWE Copy>
76BD0000 00004000 >USER32 76AE0000 Img >R RWE Copy>
76BE0000 00001000 >GDI32 76BE0000 (self) PE header Img >R RWE Copy>
76BF0000 0004A000 >GDI32 76BE0000 Img >R E RWE Copy>
76C40000 00001000 >GDI32 76BE0000 Img >RW RWE Copy>
76C50000 00001000 >GDI32 76BE0000 Img >R RWE Copy>
76C60000 00002000 >GDI32 76BE0000 Img >R RWE Copy>
76C80000 00001000 >sechost 76C80000 (self) PE header Img >R RWE Copy>
76C81000 00013000 >sechost 76C80000 Img >R E RWE Copy>
76C94000 00003000 >sechost 76C80000 Img >RW Copy>RWE Copy>
76C97000 00002000 >sechost 76C80000 Img >R RWE Copy>
76CA0000 00001000 >msvcrt 76CA0000 (self) PE header Img >R RWE Copy>
76CA1000 0009F000 >msvcrt 76CA0000 Img >R E RWE Copy>
76D40000 00007000 >msvcrt 76CA0000 Img >RW Copy>RWE Copy>
76D47000 00005000 >msvcrt 76CA0000 Img >R RWE Copy>
77040000 00001000 >DEVOBJ 77040000 (self) PE header Img >R RWE Copy>
77041000 0000E000 >DEVOBJ 77040000 Img >R E RWE Copy>
7704F000 00001000 >DEVOBJ 77040000 Img >RW RWE Copy>
77050000 00002000 >DEVOBJ 77040000 Img >R RWE Copy>
77060000 00001000 >WS2_32 77060000 (self) PE header Img >R RWE Copy>
77061000 00026000 >WS2_32 77060000 Img >R E RWE Copy>
77087000 00001000 >WS2_32 77060000 Img >RW RWE Copy>
77088000 0000D000 >WS2_32 77060000 Img >R RWE Copy>
770A0000 00001000 >LPK 770A0000 (self) PE header Img >R RWE Copy>
770A1000 00006000 >LPK 770A0000 Img >R E RWE Copy>
770A7000 00001000 >LPK 770A0000 Img >RW RWE Copy>
770A8000 00002000 >LPK 770A0000 Img >R RWE Copy>
770B0000 00001000 >RPCRT4 770B0000 (self) PE header Img >R RWE Copy>
770C0000 00096000 >RPCRT4 770B0000 Img >R E RWE Copy>
77160000 00003000 >RPCRT4 770B0000 Img >R E RWE Copy>
77170000 00001000 >RPCRT4 770B0000 Img >RW RWE Copy>
77180000 00004000 >RPCRT4 770B0000 Img >R RWE Copy>
77190000 00005000 >RPCRT4 770B0000 Img >R RWE Copy>
773C0000 00001000 >SHLWAPI 773C0000 (self) PE header Img >R RWE Copy>
773C1000 00051000 >SHLWAPI 773C0000 Img >R E RWE Copy>
77412000 00001000 >SHLWAPI 773C0000 Img >RW RWE Copy>
77413000 00004000 >SHLWAPI 773C0000 Img >R RWE Copy>
77420000 00001000 >NSI 77420000 (self) PE header Img >R RWE Copy>
77421000 00002000 >NSI 77420000 Img >R E RWE Copy>
77423000 00001000 >NSI 77420000 Img >RW RWE Copy>
77424000 00002000 >NSI 77420000 Img >R RWE Copy>
77480000 00001000 >ole32 77480000 (self) PE header Img >R RWE Copy>
77481000 00145000 >ole32 77480000 Img >R E RWE Copy>
775C6000 00004000 >ole32 77480000 Img >RW RWE Copy>
775CA000 00012000 >ole32 77480000 Img >R RWE Copy>
775E0000 00001000 >MSCTF 775E0000 (self) PE header Img >R RWE Copy>
775E1000 00083000 >MSCTF 775E0000 Img >R E RWE Copy>
77664000 00002000 >MSCTF 775E0000 Img >RW Copy>RWE Copy>
77666000 00046000 >MSCTF 775E0000 Img >R RWE Copy>
778D0000 00001000 > 778D0000 (self) Img >R RWE Copy>
778D1000 00102000 > 778D0000 Img >R E RWE Copy>
779D3000 0002F000 > 778D0000 Img >R RWE Copy>
77A02000 0000C000 > 778D0000 Img >RW Copy>RWE Copy>
77A0E000 0006B000 > 778D0000 Img >R RWE Copy>
77AB0000 00001000 >ntdll 77AB0000 (self) PE header Img >R RWE Copy>
77AC0000 000D6000 >ntdll 77AB0000 Img >R E RWE Copy>
77BA0000 00001000 >ntdll 77AB0000 Img >R E RWE Copy>
77BB0000 00001000 >ntdll 77AB0000 Img >RW RWE Copy>
77BB1000 00001000 >ntdll 77AB0000 Img >R RWE Copy>
77BB2000 00007000 >ntdll 77AB0000 Img >RW Copy>RWE Copy>
77BC0000 00057000 >ntdll 77AB0000 Img >R RWE Copy>
77C20000 00005000 >ntdll 77AB0000 Img >R RWE Copy>
7EFB0000 00023000 > 7EFB0000 (self) Code pages Map >R R
7EFDB000 00002000 > 7EFDB000 (self) Priv >RW RW
7EFDD000 00001000 > 7EFDB000 Data block of main>Priv >RW RW
7EFDE000 00001000 > 7EFDE000 (self) Process Environmen>Priv >RW RW
7EFDF000 00001000 > 7EFDF000 (self) Priv >RW RW
7EFE0000 00005000 > 7EFE0000 (self) Map >R R
7FFE0000 00001000 > 7FFE0000 (self) Priv >R R
80000000 7FFF0000 > 00000000 Kernel memory Kern >
cryptbase.dll is the Base cryptographic API DLL. Microsoft's CryptoAPI was first introduced in Windows NT 4.0 to provide services that enables developers to secure Windows-based applications using cryptography.Disassembled Instruction :
- Code: Select all
CPU Disasm
Address Hex dump Command Comments
00921FDC . B7E6C900 DD OFFSET 00C9E6B7 ; ASCII "$EnumToType@W4ByteOrder@CryptoPP@@$00@CryptoPP@@$0EA@VHashTransformation@2@@CryptoPP@@VSHA1@2@@2@@CryptoPP@@"
- Code: Select all
CPU Disasm
Address Hex dump Command Comments
00A1D948 . E4DFC900 DD OFFSET 00C9DFE4 ; ASCII "@CryptoPP@@"

UPDATE : "cryptbase.dll" is also used by Dotp_D14 so it should be not considered as some cryptographic encryption onto ZED...but the first msgbox is still a mystery.
UPDATE 2 : I have seen that the game cannot load during debug session, i got a steam error. So i tried to remove DATA_000.ZED from the game folder, then i started a new debug session, and i found the same registers operations and the same dll loaded, the debug session is terminated with the same steam error.
So i think that all the infos i get from the debugger are retrieved before the game load the zed files.
I used a 3dmgame version maybe someone who has an official version could check if the game can load into a debug session, so we could try to retrieve infos when the zed are loaded.
- NeoAnderson
- Posts: 914
- Joined: 10 Sep 2013, 07:49
- Has thanked: 18 times
- Been thanked: 139 times
Re: Information pending...
by thefiremind » 25 Nov 2014, 23:44
I have the same problem with 3DM, while the game debugs fine with CODEX, which has never been updated, but I think the interesting part comes before any problem that a non-updated executable may give.NeoAnderson wrote:I used a 3dmgame version maybe someone who has an official version could check if the game can load into a debug session, so we could try to retrieve infos when the zed are loaded.
I uploaded the CODEX files here, remember to make a backup of your files so that you can recover the updated version when you're done with testing.
- Code: Select all
http://www64.zippyshare.com/v/73461251/file.html
- Code: Select all
http://thelegendofrandom.com/blog/archives/115

EDIT: By the way, changing the last 2 bytes of DATA_010 doesn't always prevent the game from loading. Changing them to 88 8A lets the game load, while changing them to C8 CA doesn't let the game load. Making a change that doesn't let the game load can be useful for looking at where the program stops inside OllyDbg... even though I still don't know how to get the information we need from a trace run that stops at that point.

< Former DotP 2012/2013/2014 modder >
Currently busy with life...
Currently busy with life...
-
thefiremind - Programmer
- Posts: 3515
- Joined: 07 Nov 2011, 10:55
- Has thanked: 118 times
- Been thanked: 722 times
Re: Information pending...
by NeoAnderson » 25 Nov 2014, 23:50
I should have also Codex version, i will try to recover that version for testing. Anyway thx for the links i will take a look to that link to better understand How to use OllyDbg, hope you also find something useful.thefiremind wrote:I have the same problem with 3DM, while the game debugs fine with CODEX, which has never been updated, but I think the interesting part comes before any problem that a non-updated executable may give.NeoAnderson wrote:I used a 3dmgame version maybe someone who has an official version could check if the game can load into a debug session, so we could try to retrieve infos when the zed are loaded.
I uploaded the CODEX files here, remember to make a backup of your files so that you can recover the updated version when you're done with testing.I'm also trying to learn something new about OllyDbg from this:
- Code: Select all
http://www64.zippyshare.com/v/73461251/file.html
but it's late now so I'll continue my reading tomorrow.
- Code: Select all
http://thelegendofrandom.com/blog/archives/115
Unfortunately i don't have found a link with the dlc.
- NeoAnderson
- Posts: 914
- Joined: 10 Sep 2013, 07:49
- Has thanked: 18 times
- Been thanked: 139 times
Re: Information pending...
by NeoAnderson » 26 Nov 2014, 01:52
If someone that also know something about assembler would take a look here there is a list of References assembler instruction of DOTP_D15.exe linked to ASCII description. The list is too long for direct put into the msg so you can read the TXT file attached.
- Attachments
-
TEXT STRING REFERENCED DOTP_D15.EXE.TXT
- Dotp Text Strings with ASM code
- (1.57 MiB) Downloaded 8915 times
- NeoAnderson
- Posts: 914
- Joined: 10 Sep 2013, 07:49
- Has thanked: 18 times
- Been thanked: 139 times
Re: Information pending...
by thefiremind » 26 Nov 2014, 12:11
OK, I found the point where the program has the plain version of Header.xml.

...now what?

...now what?

< Former DotP 2012/2013/2014 modder >
Currently busy with life...
Currently busy with life...
-
thefiremind - Programmer
- Posts: 3515
- Joined: 07 Nov 2011, 10:55
- Has thanked: 118 times
- Been thanked: 722 times
Who is online
Users browsing this forum: No registered users and 0 guests