Disclaimer: Messing with the internals of LambdaMOO db files is inherently dangerous, and is not recommended. The following information is to be used at your own risk.
The db file is flat ASCII text organized into lines.
For non-recycled objects:
For each verb:
The next line contains the number of properties defined on this object, N. Following this are N lines of strings containing the name of each property.
Finally, values for all of this object's properties are stored. The values are ordered sequentially, first giving values for each of the properties defined on this object, then values for each property defined on this object's parent, then for the parent's parent, and so on up to the top of the object's ancestry.
The first line contains the total number of property values which follow. For each property value:
For non-clear values:
For a list value, N more data definitions follow (one for each element of the list) in the same form (integer type followed by appropriate additional data.)
Finally, each property value is followed with:
The program code for the verb follows, in source form. The code is terminated by a single dot.
The first line in the queued tasks list is of the form "<num> clocks" (where <num> is a number. This is basically an obsolete aspect of task handling in the earlier days of MOO servers, and is simply reported as "0 clocks" in modern servers. If nonzero, it's followed by <num> lines of clock data which can be ignored anyway.
Following this is a line stating "<num> queued tasks", which is the number of forked tasks in the task queue. Following this are <num> blocks of data containing the state of the MOO for each task, defined variables, and the portion of verb code being executed. Each of these blocks starts with a line of the form:
0 <lineno> <start-time> <task-id>Followed by two more lines which don't mean anything anymore:
0 -111Followed by a line of the form:
<this> -7 -8 <player> -9 <programmer> <verb-location> -10 <debug>(the -7 -8 -9 and -10 spots aren't used for anything anymore) Followed by 4 more unused lines:
No More Parse Infofollowed by the value of the "verb" variable at the current point in time, followed by the name of the actual verb that goes with the verb code being executed.
Next comes information on the runtime environment (variable definitions), then the block of verb code that was forked off, ending in a line with a period by itself.
After all the forked tasks comes a line of the form "<num> suspended tasks", which is followed by <num> blocks of info for the suspended tasks.
While I could go into great detail about the contents of the file from here on it probably wouldn't do many people very much good, as it's nearly impossible to follow all the little details by hand anyway, and I'm not sure why someone would want to for suspended tasks.. If you're just looking through and want to know what you're seeing, there are <num> blocks of data (one for each task). Each of these blocks has data for each point in the callers() stack (in the order of first-executed (shallowest) to currently-executing (deepest)). For each entry in the callers() stack, it lists the verb code of the executing verb, all of the variables defined for that invokation, a block of data similar to that listed for forked tasks (0, -111, this/player/etc line, "No", "More", "Parse", "Info", verb, verb-name), and some other less informational stuff stuck in here and there between them all..
 Object flags: player 0x01 programmer 0x02 wizard 0x04 read 0x10 write 0x20 fertile 0x80  Verb permissions: read 0x01 write 0x02 execute 0x04 debug 0x08 dobj arg 0x30 ("none", "any", "this") iobj arg 0xC0 ("none", "any", "this")  Property permissions: read 0x01 write 0x02 chown 0x04
You might be able to get away with modifying the value of a property if you're very careful. It might be hard to find the actual value in the db file, since it isn't obvious which values are matched with which property names. If the current value is something you could search for (say, if you knew an encrypted password beforehand and could search for it) you might have better luck.
It would be feasible to add a new verb by doing the reverse of this.
0 clocks 0 queued tasks 0 suspended tasksThese lines should immediately follow the last verb program, and should be followed immediately by the end of file.
I shouldn't need to emphasize that editing db files by hand is inherently dangerous. I really don't recommend any amount of significant hacking.
Also, although I am fairly confident the above description is correct, I am by no means making any guarantee about its accuracy, and certainly am not willing to accept responsibility for any damage done to anyone's db as a result of my making this public. Nonetheless, I hope it's useful to some.