IDString

[ZNixian]

IDString is a hashing function, converting a string into a uint64_t. This is stored in a userdata (I think, may be a abused light userdata).

A decompiled and cleaned implementation can be found here, and was tested to return the same result as the Lua Idstring function.

https://gist.github.com/ZNixian/54e7a23ff36cc4756cbd783f304d7cd6

[RomanHargrave]

Cool, this reflects most of what I saw when I first went through it.

Though, unless things have changed, I recall that the IDString type that gets passed around between lua and DSL is a pointer to some class/structure instance that includes that hash as well as some other information.

[ZNixian]

According to lua_objlen, IDString objects are 8 bytes long. As the hash is stored in a uint64_t, there is no spare room for other data.

So there are two main possibilities:

• IDString is a light metadata, and points to a full ScriptIDString object/struct.
• Only the hash is stored.

I'll check to see if it's light userdata or not.

[RomanHargrave]

it could have just been a misunderstanding.

The DSL lua subsystem is an enterprise-grade hot mess.

[ZNixian]

Testing shows that it is a full, not light, userdata.

[RomanHargrave]

extensive headaches and shouting at IDA have been shown to reveal that C++ obviates the need for secondary code protection

[ZNixian]

Just found what I believe is the Idstring method - it creates a 8-byte userdata, and puts the hash and only the hash into it.

[ZNixian]

Here's my guess at this:

namespace dsl {
typedef uint8_t idstring;
}

I'll go and try to find a simple-ish method that uses dsl::idstring, and try to check this.

[ZNixian]

Nevermind, dsl::idstring is a class, by the looks of it.

[RomanHargrave]

yeah, and a somewhat complex one at that. I just powered off my IDA VM, but IIRC it has some vcalls.

interacting with MainDB is going to mean that we will need to operate on it.

[ZNixian]

It looks like a complete pain, but hopefully it doesn't have too many fields.

PS: IDA VM? As in, a VM you run IDA in? Doesn't it work with Wine?

[RomanHargrave]

when I do end up using IDA, I use some plugins that don't (didn't, now, maybe) like WINE, plus I don't know if the HexRays edition works well with WINE.

I really only use IDA for Payday. I've used it to look at some other stuff, but Hopper and other tools have usually done a better job in that department. IDA's ability to rename things is nice, though.

[RomanHargrave]

once hopper gets a little more TLC in the UX department, it will probably end up replacing IDA for non-windows platforms, especially since the running price for a copy of IDA that can do what hopper does is about $9,648.

[RomanHargrave]

radare2 is also good, as well as the plethora of other opensource tools that have been popping up since capstone got popular

[ZNixian]

My conclusion after hooking functions using dsl::idstring on both Windows and GNU+Linux is that they are plain uint64_t values.

[RomanHargrave]

What about member functions for idstring?

[ZNixian]

Right, didn't notice my * dereferencing them.

[ZNixian]

I haven't paid much attention to them, as I've mostly been trying to read values. I'm fairly sure the hash functions return these, so that would be a good place to start.

[ZNixian]

VertexColor___idstring = dsl::hash64(&"VertexColor", 0xBuLL, 0LL);

That's in one of the global constructors. The second argument is the string length. I'm fairly sure that the ___idstring variables are actual dsl::idstring objects. As dsl::hash64(str, length, unknown) returns a uint64_t, I strongly suspect that dsl::idstring only has a single variable.