Support for "Delores: A Thimbleweed Park Mini-Adventure"?

[neuromancer]

Is it possible to run "Delores: A Thimbleweed Park Mini-Adventure" with engge?

[scemino]

Why not. But as I understood it seems to be a new game engine. It means also that we need to find how to decrypt the data, maybe @atom0s can help?

[neuromancer]

The developers said that they won't port it to Linux "soon". It is also interesting that it fails to work in Proton (or even normal Wine), but it is not clear why. If there is an experimental support, a lot of new users will try engge for that.

[Mac1512]

It would be great if @atom0s could lend a hand.

Thanks @neuromancer for the warning, I did not know that they had released this new mini game :)

[atom0s]

The saved games use the same XTEA encryption setup. The key for this game is:

uint8_t saveKey[16] = {0x93, 0x9D, 0xAB, 0x7A, 0x2A, 0x56, 0xF8, 0xAF, 0xB4, 0xDB, 0xA9, 0xB5, 0x22, 0xA3, 0x4B, 0x2B};

As for the pack data, I don't have enough time to dig into this right now, busy with other things. But a quick glance, I saw a few functions of interest. One being this small xor handler that will decode parts of the pack file in chunks:

__int64 __fastcall sub_1400CB6B0(__int64 a1, unsigned __int64 a2)
{
  unsigned __int64 v2; // rax
  int v3; // er10
  __int64 v4; // r9
  int v5; // ecx

  v2 = 0i64;
  v3 = (unsigned __int8)a2;
  v4 = a1;
  if ( a2 )
  {
    do
    {
      v5 = (unsigned __int8)(v3 ^ *(_BYTE *)(v2 + v4) ^ 109 * v2 ^ byte_14030C040[v2 & 0xF]);
      *(_BYTE *)(v2 + v4) = v5;
      v3 ^= v5;
      ++v2;
    }
    while ( v2 < a2 );
  }
  return v4;
}

byte_14030C040 being a table of xor key values.

[atom0s]

Had some extra time tonight to take another look. The above info I gave was everything needed. The XOR decryption used on the other game works for this one as well, just the key changed. The byte_14030C040 array is the new key for Delores.

\x3F\x41\x41\x60\x95\x87\x4A\xE6\x34\xC6\x3A\x86\x29\x27\x77\x8D\x38\xB4\x96\xC9\x38\xB4\x96\xC9\x00\xE0\x0A\xC6\x00\xE0\x0A\xC6\x00\x3C\x1C\xC6\x00\x3C\x1C\xC6\x00\xE4\x40\xC6\x00\xE4\x40\xC6

(Not all of this is the key, just copied enough to prevent issues.)

I posted a modded QuickBMS script here to handle this: https://zenhax.com/viewtopic.php?p=56657#p56657

[scemino]

Had some extra time tonight to take another look. The above info I gave was everything needed. The XOR decryption used on the other game works for this one as well, just the key changed. The byte_14030C040 array is the new key for Delores.

\x3F\x41\x41\x60\x95\x87\x4A\xE6\x34\xC6\x3A\x86\x29\x27\x77\x8D\x38\xB4\x96\xC9\x38\xB4\x96\xC9\x00\xE0\x0A\xC6\x00\xE0\x0A\xC6\x00\x3C\x1C\xC6\x00\x3C\x1C\xC6\x00\xE4\x40\xC6\x00\xE4\x40\xC6

(Not all of this is the key, just copied enough to prevent issues.)

I posted a modded QuickBMS script here to handle this: https://zenhax.com/viewtopic.php?p=56657#p56657

Cool it worked, now do you know how to decode Delores.dink ?

[atom0s]

That appears to be a custom means of a scripting language. At least not something I've seen/heard of and don't see on any Google searches.

Internally there are some types associated with this:

• Dinky::Compiler
• Dinky::Function
• Dinky::MathExpression
• Dinky::Expression
• Dinky::ExpressionList
• Dinky::ParamDef
• Dinky::ParamList
• Dinky::Symbol
• Dinky::TableCreateExpression
• Dinky::ArrayCreateExpression

And a handful more. So this is some internally handled script language.

.dinky files are the raw script format. .dink files are the bytecode compiled script format.

[scemino]

You don't think it's an archive format ? It seems to contain several files inside (not sure), and I suppose that the script is human readable.

[atom0s]

The .dinky files appear to be potentially bytecode compiled scripts with partial string tables remaining. Similar to how Lua and Squirrel scripting can be compiled.

[Mac1512]

A job as always spectacular @atom0s :)

Although there is a small bug in the quickbms script, since some file does not extract it correctly, among them note.json, which at this point must be given to the R in quickbms and saves it as note.png, missing a part of the header:

01 02 03 04 01 00 00 00

and it should specifically occupy 749 bytes, that is, it should go up to:

... trimmed.version.w.x.y.

or what is the same, up to byte 0x2EC

This in engge would be properly decrypted, since it is only changing the encryption key for the one you have provided us. I only tell you in case you want to modify the script created for quickbms.

Too bad about the new scripting language in Delores.dink

Greetings and thank you very much for your help.

[scemino]

There are also .bank files like MasterBank.bank and MasterBank.strings.bank. which are mysterious. Do you know what it contains @atom0s or how to decrypt it ?

[atom0s]

They appear to be FMOD raw data files. (Music/audio related.) They get loaded from the .ggpack then are processed via:

• FMOD_Studio_System_LoadBankMemory

[scemino]

OK thank you @atom0s , and can you decode the different opcodes in dinky files ? This is the main issue to start to work on Delores.

[atom0s]

I personally don't have time to reverse a custom script engine, sorry.

[scemino]

I understand, do you know someone who can help on this ? Anyway thank you for all your help.

[neuromancer]

I don't have the experience in reversing do it, but at least can someone provide some steps to extract/inspect the .dinky files inside the Delores ggpacks? (perhaps with code in a dolores branch?)

[scemino]

Wow look here https://github.com/grumpygamer/DeloresDev

[atom0s]

Lacks the C++ source currently, but based on their blog post, it seems like he plans to release that eventually too. Dinky script, as mentioned on the repo, is a custom script language he wrote based on Squirrel. So probably best to wait for him to release the src, if he does, for that rather than waste time on reversing it.

[scemino]

Lacks the C++ source currently, but based on their blog post, it seems like he plans to release that eventually too.

I'm not sure... He said

Releasing the engine source (c++) is problematic for a few reasons. The first is that it uses a very large library of mine, most of which is not used in this engine, so I'd have to go though and cull out all the cruft, not to mention all the proprietary console crap. I also use some third party source I don't have the rights to release. It's a big job and would split my main engine off from the released engine, which becomes a merge catastrophe (either that or a million #if's)

He said the same thing about TWP

[atom0s]

From how it's worded, sounds like he may eventually release parts of it. You could reach out and request things like the Dinky scripting stuff specifically and see if he'd share that at least.

[neuromancer]

Perhaps it is enough to invoke @grumpygamer here to make sure he is aware of this discussion and see if he can release only the Dinky scripting stuff specifically.

[scemino]

I had bad experience asking him some question about his engine, my post has been removed. So if anyone else wants to try, he is welcome. That's sad, because I'm a huge fan of his work/games. I don't want to do anything illegal, I just want to understand how the engine works that's it.

[neuromancer]

Welp, no response, but at least he is trying to use to Linux so perhaps he will port his new engine soon.

[neuromancer]

There is (beta) Linux support now: https://www.gamingonlinux.com/2020/09/delores-a-thimbleweed-park-mini-adventure-now-has-a-linux-beta