error while parsing mmap

[jtieri]

It seems I'm getting a bad offset value while trying to parse the mmap of chunks in a Macromedia DIR file.

This is the current output I'm getting logged to stdout.

` Try to parse loader.dcr.dir file. INFO: File format: XFIR INFO: File contains 69314 bytes of information. INFO: Data format: 39VM

INFO: Block type: pami INFO: Block size: 24 IMAP[0]: 1 IMAP[1]: 0 IMAP[2]: 44 IMAP[3]: 1922 IMAP[4]: 0 IMAP[5]: 0 IMAP[6]: 0 WARNING: Unknown block type!

INFO: Block type: pamm INFO: Block size: 4064 MMAP[0]: 24 MMAP[1]: 20 MMAP: Number of files (including nulls) 202 MMAP: Number of files (without nulls) 156 ERROR: Bad nmap padding 152 -1`

I can tell from the code that it is at least that first value 152, which is giving issues.

My first assumption is that it's due to the "WARNING: Unknown block type!" being logged from the imap because if I'm not mistaken imap is a sort of pointer to the mmap where the chunks are all indexed in memory.

Look forward to hearing back from someone, thanks!

Edit: It doesn't seem like that warning should even be being thrown after parsing the imap structure from just looking at the code. I spent a few hours pouring over it and the bit of info I have regarding the spec on Lingo bytecode and I'm officially lost.

[System25]

Hi Justin, I'd like to analyze that loader.dcr.dir. Can you provide me that file? Is a file that you created with Macromedia Director? (what version?) Or is a file extracted from some videogame or other software?

Best regards!

[jtieri]

Sorry for the delay, been dealing with some health complications.

I'll provide a mega link to the file below. The file is from an old videogame client dating back to 2009, possibly earlier. I was able to get a DIR file from the original DCR file that I have for the client.

I have had some success in getting partial Lingo scripts back from various compressed cast files from the client in the past but have never had much luck at all with any DIR files.

https://mega.nz/#F!eq4lnSjS!g2ZhQoC3H_NUynFN2H8lew

Edit: I thought it may be useful to have the original DCR file also and so I have updated the link to include said file. Thanks.

[System25]

Thanks for the files. After a minor fix, the script tries to analyze the first Lingo script but fails because it contains an unknown opcode: 97 (in hexadecimal). If you look at http://fileformats.archiveteam.org/wiki/Lingo_bytecode yo will see that there is no opcode definition between 95 (conditional jump) and E0 (set the someproperty =).

Also I tried to extract one image that there is in the file but the area where the bits per pixel information is supposed to be was 0.

And if it dates from 2009 is a very modern version of Director (I've only used this script with files from a couple of videogames from early 90's).

So I will need some time to investigate all this and try to extract the image and decompile the scripts.

And how did you got the DIR file from the DCR file? (I'm just curious).

Best regards!

[jtieri]

No problem!

I figured there may be some issues due to the fact this file was most likely created with a much newer version of Director than what you were targeting but saw, "Also can extract contents from "updated" Macromedia Director" so figured it was at least worth a shot :P

To get the DIR file from the DCR I used a program created by someone who has supposedly been successful in getting all scripts from both DIR and cast files. It's called unDCR and I have reason to believe it's just another program called DCR2DIR but compiled with the dirapi.dll and other libraries. I'll link to both of these below.

I found http://alex-dev.org/lscrtoscript/ last night and was able to get some scripts from the DIR file I sent you and surprisingly it even spit out a few scripts from a cst of the game client that I stumbled upon online (i don't personally know how to unprotect a cct while keeping the Lingo scripts)

DCR2DIR: https://ufile.io/d6qz9 unDCR: https://ufile.io/nuoma

Thanks!

[Brian151]

@jtieri Yeah, DCR2DIR is made by one of the people who was helping me with my own shockwave efforts It's still far from a magic bullet, though, and some DCRs will not extract

So was projectorrays, although there have been a few forks of it. Had no idea anyone ever uploaded it to an actual website, though

The format of a cast and a movie is virtually identical. If you can successfully extract a given DCR/CCT to DIR/CST, you should, in theory, have access to all of the lingo code. (when these tools are completed, it just won't matter, you can do it directly, then)

Another fun fact is that you can (at least, sometimes) re-compile an extracted DIR if you don't edit the scripts

I don't know how often CCTs were used for code. The majority of the ones I've seen hold assets. There's nothing stopping a CCT from containing code, ofc. I just don't think people did it often. Might be mistaken, though

Version differences absolutely are a problem with trying to unprotect anything director, especially with a tool that's still based in it. The tools being built from scratch, I'm not sure of. There are some version differences to be considered, but it wouldn't be terribly surprising if most of the time, it's not a big deal. (updates to dirapi or similar, vs updates to the format, itself. The latter are probably fairly uncommon)

@System25 The opcodes are not fully documented. As-is, I'm relatively sure that wiki page doesn't even reflect the current knowledge of lingo bytecode

During the earlier days of project Earthquake, particularly when it was called "OpenShockwave" , it was observed some of this documentation might not be accurate, or there may be version differences to address.

Additionally, at the time, compiled JavaScript was not yet understood. I'm not sure yet if any of the various RE projects have really completely cracked it yet. There's been some work towards it, however. I think, luckily, most director/shockwave movies/casts use lingo.

The last nasty pieces are how dependent on every other thing ANYTHING in one of these files is. First, There's a lot that can't be done without chaining multiple chunks together (especially for lookup purposes) Second, XTRAs are required for many of these movies, and most of them, nothing is yet understand besides they exist. Some Xtras would only be required for playback. But many would be required for editing/viewing/decompiling. I am currently looking into three of the formats. It's...pretty painful

This is in stark contrast to flash SWF. There is some lookup involved for a flash sprite, for example, to load any dependencies. But SWF, unlike director, doesn't play the pointers everywhere and lookup by proxy-by-proxy game. Also unlike director, support for some third-party format/function was generally provided through actionscript. You could just use a decompiler and figure-out everything. (given enough time and that the code wasn't heavily obfuscated/encrypted, but the latter is pretty rare) Flash format, and even the AVM, are officially documented (for the most part) by Adobe, and the open source FFDEC is actually very useful for filling the blanks if you want to understand the format for yourself. (however, even with the most detailed/accurate/understandable documentation, director format would be no picnic to re-implement from scratch)