Extracting data from a .DLL file: problem with offsets
Page 1 of 1
capretto




Posts: 521
Location: Italy
PostPosted: Thu, 6th Jun 2013 19:10    Post subject: Extracting data from a .DLL file: problem with offsets
So, I'm currently trying to extract some data from a .DLL library - I've figured out the file structure (there are 1039 data blocks compressed with zlib, starting at offset 0x3c00, the last one being the fat table). The fat table itself is divided into 1038 "blocks" (8 bytes + a base64 encoded string - the filename). As far as I've seen, byte 5 is the length of the filename.

My problem is that I can't seem to understand what bytes 1-4 are used for: my first guess was that they were an offset to locate the file block inside the .DLL (mainly because the values are increasing throughout the table), but for instance, in this case, the first "block" is:

Supposed offset: 2E 78 00 00
Filename length: 30 00 00 00
Base64 encoded filename: 59 6D 46 30 64 47 78 6C 58 32 6C 75 64 47 56 79 5A 6D 46 6A 5A 56 78 42 59 33 52 70 64 6D 56 51 5A 58 4A 72 63 31 4E 6F 62 33 63 75 59 77 3D 3D

yet, as I said earlier, the block itself is at 0x3c00, so things don't match. Same goes for the second block (starting at 0x3f0b, whereas the table supposed offset is 0x167e).

Any ideas?


BEST GAMES YOU'VE NEVER PLAYED (click)

Richard Benson: " Durante tutta la mia esistenza, ho avuto sempre un sogno...
(Throughout my whole existence, I've always had a dream...)
Loving fan: "un cazzo 'n culo!"
(A cock deep inside your ass!)
Back to top
[mrt]
[Admin] Code Monkey



Posts: 1340

PostPosted: Sun, 16th Jun 2013 20:21    Post subject:
Sounds like it is an offset but not the one you are expecting.

The odd thing that strikes me is that the file table is at the end of the chain of the compressed blocks. Why? Zlib streams by themselfs do not contain any length information. You probably would have to devulge into the compression algorithm to figure it out. So if the stream itself is variable length and you were looking for a file, you would put the table first.

On the other hand if the 'blocks' were fixed length..its just hard to tell with that little information.


teey
Back to top
capretto




Posts: 521
Location: Italy
PostPosted: Mon, 24th Jun 2013 03:09    Post subject:
I think I got it. The difference between two consecutive offsets does indeed match the length of the corresponding file block - I just got confused by the fact that the first offset didn't match the location of the first encoded block (and I still can't understand why - the first offset seems totally random).

Quote:
The odd thing that strikes me is that the file table is at the end of the chain of the compressed blocks. Why?


Yeah, that's odd in fact. I started this whole decoding thing by following the steps made by another guy who tried to decode a library with a similar format (well, sort of, it was a previous version of the same game engine), but in that case he managed to find lots of useful info (such as the number of files and the offset of the FAT table) in the last six bytes of the file.


BEST GAMES YOU'VE NEVER PLAYED (click)

Richard Benson: " Durante tutta la mia esistenza, ho avuto sempre un sogno...
(Throughout my whole existence, I've always had a dream...)
Loving fan: "un cazzo 'n culo!"
(A cock deep inside your ass!)
Back to top
[mrt]
[Admin] Code Monkey



Posts: 1340

PostPosted: Tue, 25th Jun 2013 16:17    Post subject:
Good job!

The first thing i tried was seeing if the offsets combined matched any of the offsets, but none matched with the given info.

Whats it for btw?


teey
Back to top
capretto




Posts: 521
Location: Italy
PostPosted: Tue, 25th Jun 2013 16:37    Post subject:
[mrt] wrote:

Whats it for btw?


It's the stormex2.dll of a Russian mod for Age of Pirates 2. Since the mod looks pretty damn impressive (but obviously it won't get any english translation), I'm trying to extract the files to google-translate the text.


BEST GAMES YOU'VE NEVER PLAYED (click)

Richard Benson: " Durante tutta la mia esistenza, ho avuto sempre un sogno...
(Throughout my whole existence, I've always had a dream...)
Loving fan: "un cazzo 'n culo!"
(A cock deep inside your ass!)
Back to top
[mrt]
[Admin] Code Monkey



Posts: 1340

PostPosted: Wed, 26th Jun 2013 19:17    Post subject:
Why not patch in-memory? Dump all the strings from the process and translate on the fly.


teey
Back to top
capretto




Posts: 521
Location: Italy
PostPosted: Thu, 27th Jun 2013 20:08    Post subject:
[mrt] wrote:
Why not patch in-memory? Dump all the strings from the process and translate on the fly.


Because I have no idea how to do that, to be honest Very Happy

Also, there may be problems to translate text on the fly, given that the google translate APIs aren't free anymore.


BEST GAMES YOU'VE NEVER PLAYED (click)

Richard Benson: " Durante tutta la mia esistenza, ho avuto sempre un sogno...
(Throughout my whole existence, I've always had a dream...)
Loving fan: "un cazzo 'n culo!"
(A cock deep inside your ass!)
Back to top
Page 1 of 1 All times are GMT + 1 Hour
NFOHump.com Forum Index - Programmers Corner
Signature/Avatar nuking: none (can be changed in your profile)  


Display posts from previous:   

Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB 2.0.8 © 2001, 2002 phpBB Group