is there a working dds extractor?

[Matehret]

is there a working dds extractor?

[esq]

yes try

theres a plugin for dds you can find in the plugin archives.



im useing it right now looking for the dds file for random portals if you find it please let me know where it is.

[Matehret]

no i was talkting for an Tool that extract the effect files from Eudemons, to get all Effects and Textures

[picadilly]

If you mean DNP extractor, then no - there was one, but it is outdated.
It could extract specific file given its name.
I made my own tool that just unarchives the DNP - that is pretty easy if you don't need specific file names. Not giving it out here because that is just a junk soft I made while trying to figure out DNP archive algorithm. If you need it, I can explain overall DNP structure and how to extract files from it without knowing what is actually in there.

If you are talking about DDS files, then I use WTV - DDS file viewer to view files, DDS Converter 2.1 to convert them to other format and ATI Compressanator to encode them back to DDS.

[-Deyo-]

Originally Posted by picadilly

If you mean DNP extractor, then no - there was one, but it is outdated.
It could extract specific file given its name.
I made my own tool that just unarchives the DNP - that is pretty easy if you don't need specific file names. Not giving it out here because that is just a junk soft I made while trying to figure out DNP archive algorithm. If you need it, I can explain overall DNP structure and how to extract files from it without knowing what is actually in there.

If you are talking about DDS files, then I use WTV - DDS file viewer to view files, DDS Converter 2.1 to convert them to other format and ATI Compressanator to encode them back to DDS.

well there are a lot of Dnp unpacking programmes in the p server hosting sections put the proplem isnt in that its that u cant reback them so u can get the files and edit put u wont be able 2 check them or use them xD

[unknownone]

Originally Posted by picadilly

If you mean DNP extractor, then no - there was one, but it is outdated.
It could extract specific file given its name.
I made my own tool that just unarchives the DNP - that is pretty easy if you don't need specific file names.

I released the source with my original DNP extractor, has the structure and extraction method (including the filename hash algorithm). I'm sure most of it still works, may need a few edits.
If it's the filename hash that has changed and nobody has figured that out yet, lemme know via PM and I'll reverse it again.

Originally Posted by -Deyo-

well there are a lot of Dnp unpacking programmes in the p server hosting sections put the proplem isnt in that its that u cant reback them so u can get the files and edit put u wont be able 2 check them or use them xD

I was under the impression that the client does a directory search first, and if the file in question isn't found in the directory, it searches the pack file afterwards. (Is this right?).
If that's not the case, you could use a couple of quick fixes. Edit the .ini or .ani file that points to your modified file and give it a slightly different name or path. You could also modify the pack and remove files you've edited so it searches the directory instead. And, of course, the DNP structure is well understood, so repacking is an option.

[picadilly]

I reversed it - the hash algorithm is still the same, the problem for me is I don't have VC++, tried to recreate it using Delphi, but it gave me wrong IDs as the result, probably because I incorrectly prepared name for hashing or Borland compilator works differently from MS.

2 things that have changed - file offset and size. It looks masked now and direct reading is incorrect. Should be easily cracked if only I could link IDs with names - all I can do for now is to scan whole archive looking for DDS and C3 file headers and extract them - that way I get file sizes and initial seed for offset and size cracking, however I am not sure which ID corresponds to which file.

[unknownone]

Use another C++ compiler, mingw for instance.
I reccomend getting
Grab Code::Blocks too if you need an IDE.

Or, post your Delphi code and I'll see if I can spot the problem. (Although It'll be purely observational, since I don't have Delphi to build it).

[picadilly]

The code is basically the same assembler. I guess there might be something incorrect how i prepare for the hashing.

Pascal also is a bit unhandy for byte operations, so I might be converting the string to array incorrectly too.

I will try to describe how I do it, see if you can spot anything incorrect.
Say, I start with file name, e.g. Paladin5/effect/skill/newskill380/1.c3
1. Change to lowercase
2. Change slashes
so I end up with paladin5\effect\skill\newskill380\1.c3
Now copy it to array, then run those bit operations.

But at the end it gives me ID I cannot find in paladin5.dnp

There are 2 things I amd not sure of:
1. If the package name should be removed from file name or not - i.e., should the name be paladin5\effect\skill\newskill380\1.c3, \effect\skill\newskill380\1.c3 or effect\skill\newskill380\1.c3
2. How C++ threats DWORD array when casted as char*

If given that initial Paladin5/effect/skill/newskill380/1.c3, can you explain me how the filename is prepared and how the array looks like just before starting that ASM part (including adding of those magical 0x9BE74448 and 0x66F42C48 to array). I have tried it several ways and it always gives me ID which I cannot find in DNP.

Say:
- Paladin5/effect/skill/newskill380/1.c3 converted to
- paladin5\effect\skill\newskill380\1.c3
- the byte code is 70 61 6C 61 64 69 6E 35 5C 65 66 66 65 63 74 5C 73 6B 69 6C 6C 5C 6E 65 77 73 6B 69 6C 6C 33 38 30 5C 31 2E 63 33
- thus DWORD array is 70616C61 64696E35 5C656666 6563745C 736B696C 6C5C6E65 77736B69 6C6C3338 305C312E 63330000
- if those 2 extra values added, final arry before bit manipulations is 70616C61 64696E35 5C656666 6563745C 736B696C 6C5C6E65 77736B69 6C6C3338 305C312E 63330000 9BE74448 66F42C48 (with the rest of elements equal to 0, values shown in HEX, not in reverse format)

So, at the end it gives me id of 1533477478, which I cannot find in DNP.

[unknownone]

Alright. Sorry I don't have the means to test and run it. Long time since I've had Eudemons or Delphi installed. One thing I've just spotted comparing my code to yours is, I've commented out the switching of slashes to backslashes, but I'm not sure whether this was done before or after I built it. I originally wrote the code for Conquer's WDF files, and as I recall, the hash was the same, but the file prepare method was different. Try removing that line and see if it works.
I'm not sure how LowerCase[] works getting the first element, but apparently AnsiLowerCase is preferred due to mixed encodings. Doubt that's the cause of the problem though. The rest of the code looks ok, but as you mentioned, the bit work with pascal makes it trickier to read. You could use pointers and match up with the C code line exactly though.

If you need to, attach OllyDbg to a running instance of Eudemons and stick a breakpoint on the string2id function. You'll be able to see the prepared filename on the stack to see what it should look like, and compare that to how yours looks. You might also wanna try building a DLL with the C code, using the __stdcall convention and call it from your pascal application.

Oh, and if it may help. Here's the algorithm written in C#, without assembly.

        private static UInt32 CalculateStringHash(string filename)
        {
            UInt32 Hash=0xF4FA8928;
            UInt32 A=0;
            UInt32 B=0;
            UInt32 dwTemp1=0x37A8470E;
            UInt32 dwTemp2=0x7758B42B;
            UInt32 dwTemp3=0;
            UInt64 Carrier;
            UInt32 Carry;
            int fileNameIntCount,j=0;
	        
            UInt32[] fileNameInts = new UInt32[70];
            byte[] fileNameBytes = Encoding.ASCII.GetBytes(filename.ToLower());
            byte[] fileNameAdjusted = new byte[fileNameBytes.Length + (fileNameBytes.Length % 4 == 0 ? 0 : 4 - fileNameBytes.Length%4)];
            fileNameBytes.CopyTo(fileNameAdjusted, 0);           
            BinaryReader reader = new BinaryReader(new MemoryStream(fileNameAdjusted, false));
            
            for (fileNameIntCount = 0;fileNameIntCount < fileNameAdjusted.Length / 4; fileNameIntCount++)
            {
                fileNameInts[fileNameIntCount] = (UInt32)reader.ReadInt32();
            }
            
            fileNameInts[fileNameIntCount++] = 0x9BE74448;
            fileNameInts[fileNameIntCount++] = 0x66F42C48;
            
            for (j=0;j<fileNameIntCount;j++)
            {
                dwTemp3=0x267B0B11;
                Hash = (( Hash << 1) | (Hash >> 31) );
                dwTemp3 ^= Hash;
                A=fileNameInts[j];
                dwTemp1 ^= A;
                dwTemp2 ^= A;
                B = dwTemp3;
                B += dwTemp2;
                B = B | 0x2040801;
                B = B & 0xBFEF7FDF;
                Carrier = B;
                Carrier *= dwTemp1;
                A = (UInt32)(Carrier);
                B = (UInt32)(Carrier >> 32);
                if (B!=0) A += 1;
                Carrier = A;
                Carrier += B;
                A = (UInt32)(Carrier);
                Carry = (UInt32)(Carrier >> 32);
                if (Carry!=0) A += 1;
                B = dwTemp3;
                B += dwTemp1;
                B = B | 0x804021;
                B = B & 0x7DFEFBFF;
                dwTemp1 = A;
                Carrier = dwTemp2;
                Carrier *= B;
                A = (UInt32)Carrier;
                B = (UInt32)(Carrier >> 32);
                Carrier = B;
                Carrier += B;
                B = (UInt32)(Carrier);
                Carry = (UInt32)(Carrier >> 32);
                if (Carry!=0) A += 1;
                Carrier = A;
                Carrier += B;
                A = (UInt32)Carrier;
                Carry = (UInt32)(Carrier >> 32);
                if (Carry!=0) A += 2;
                dwTemp2 = A;
            }

            Hash = dwTemp1 ^ dwTemp2;
            return Hash;
        }

If you're still having trouble and you've built & tested the original code, I'll DL the client again and resolve it.

[picadilly]

Thanks, will check it through and see how it fits with my part, although looks the same so far.
Will come back with my results.

Update
Well, tried it all ways, still giving me ID I cannot find in DNP. Either there is a catch with filename preparation or the ID in DNP is coded as well.
I attached paladin5.dnp with its contents and header dumps, would appreciate if you can check it.
I cannot debug the client cause all I can do is to run it and leave at login prompt - external connections are all firewalled.

[unknownone]

Well, clear difference I notice in this file compared to when I wrote the original code, is the file details are all messed up. (offsets & sizes). They appear to be xor 0x99589958 and xor 0x96120059 respectively. Under those circumstances it may be reasonable to assume the filename hash has a similar modification.

Print me a list of all filenames you have that point to the paladin5 file (leave them in the case they are in the ini files). I'll run the hash on each of them and compare the results the actual hashes in the paladin5 file, see what's going on.

[picadilly]

The file names are in that archive too - they might not be in the same order as in package (Paladin5_packed_files.txt), but the list is full - 86 files pointing to Paladin5, 86 files in DNP package.

[unknownone]

Ah, missed that sorry.
Well, had a look, tried doing a compare, but no luck by observing. I'll download the client and do it the easy way.

[mostafa_m_f_m]

thanx