Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[CynicalRyan]

Good news: MonoDevelop clearly does have an integrated debugger, I'm just blind.

Another tip: Microsoft offers Visual Studio Express Editions for the "official" .NET languages (so, no Iron*). For free. You have to register to get an activation keys to use it longer than 30 days, though. Just an option to look at, if you already know Visual Studio from work, or so.

[AxelDominatoR]

Visual Studio doesn't run under linux

I'm making progresses with my little utility. Maybe I'll have some news tomorrow. Good luck to all

[kutulu]

Good news: MonoDevelop clearly does have an integrated debugger, I'm just blind.

Another tip: Microsoft offers Visual Studio Express Editions for the "official" .NET languages (so, no Iron*). For free. You have to register to get an activation keys to use it longer than 30 days, though. Just an option to look at, if you already know Visual Studio from work, or so.

I would quite likely be willing to kill someone if it would get me a copy of Visual Studio that ran on Linux, especially the Team Edition I "conveniently acquired" from work.  But MonoDevelop and SharpDevelop are pretty good and improving, and the lack of a debugger was entirely my fault, so I'm no longer prone to complain.

--Mike

[Belathus]

Projects like these make me wish I were a better programmer.  I've been wanting a Linux native Dwarf Manager for a while.

[CautionToTheWind]

Many of us have! Keep working guys!

[kutulu]

Just for anyone who's keeping score, I'm making good progress now that I'm back to working on this.  I located the creature vector and the language/translation tables and can reliably find them, at least on 40d11, every time.  My current obstacle seems to be that the object layout isn't even the same as it was under Windows, in particular, the Race index isn't where it should be -- what's in that spot is a string that is NULL in most cases.  Also, managed string layout is different, which we already figured would be the case, so I'm trying to piece that together.

More to come...

--K

[0x517A5D]

Would you show me the addresses of CreatureVector and the start of .bss for a few sample runs, please?

[kutulu]

For 40d11, the CreatureVector so far has always been at 0x093016b0, which so far has always been .bss + 0x00af96b0.  The .text segment starts at 0x08048000, and .bss at 0x08808000.

For most of the creatures, I can follow the chain to a string representation of the creature name:

Code: [Select]

CreatureVector:
.Start: [0x093016b0 (.bss + 0x00af96b0)] = 0x0a009ca8
.End  : [0x093016b4 (.bss + 0x00af96b4)] = 0x0a00a05c
.Count: (0x0a00a05c - 0x0a009ca8) / 4 = 237
[0]   : [0x0a009ca8] = 0x09d2a7e0
[233] : [0x0a00a050] = 0x0a11c840

At 0x09d2a7e0:
.FirstName  = [0x09d2a7e0 + 0x00] = 0x09e3b784 -> TOAD\0

At 0x0a11c840:
.FirstName  = [0x0a11c840 + 0x00] = 0x0a11bb64 -> CAVE_SWALLOW_MAN\0
.LastName   = [0x0a11c840 + 0x38] = 0x0a11f5b4 -> cave swallow man hatchlings\0
.Profession = [0x0a11c840 + 0x88] = 0x088075bc -> NULL
.Race       = [0x0a11c840 + 0x8c] = 0x088075bc -> NULL

The offsets I'm pulling from the memory layout used by 40d11 under Windows, but I'm 99% sure it's not right, for two reasons:  a) the Race offset appears to be a pointer which is almost always NULL, but in rare cases points to a string, while I expected it to be an integer, and b) not one creature in the whole vector has a Race value matching the dwarven race index.

As far as the strings go, so far the short ones appear to point directly at a NULL-terminated char array, but I don't see anything near that address that looks like a string, and for longer ones (presumably the Dwarf names) the data doesn't make much sense.  I know where the dwarf nicknames are in memory but I've tried following pointers from the nickname backwards and from the creature vector forwards and they never seem to meet in the middle.

I'll try to find somewhere to host my memory dumps, as I don't see a way to attach data to these posts.

--Mike

[AxelDominatoR]

Comparing memory dumps would definitively help here, I think...

On my tests,

Code: [Select]

"TOAD\0" is at: 0x9A312D4
CreatureVector.Start is at

Code: [Select]

Offset: 0x0154FEC8 ( Heap starts at 0x08808000, so absolute address is 0x09D57EC8 )
CreatureVector.End is at

Code: [Select]

Offset: 0x0155027C ( Heap starts at 0x08808000, so absolute address is 0x09D5827C )

[kutulu]

Comparing memory dumps would definitively help here, I think...

On my tests,

Code: [Select]

"TOAD\0" is at: 0x9A312D4
CreatureVector.Start is at

Code: [Select]

Offset: 0x0154FEC8 ( Heap starts at 0x08808000, so absolute address is 0x09D57EC8 )
CreatureVector.End is at

Code: [Select]

Offset: 0x0155027C ( Heap starts at 0x08808000, so absolute address is 0x09D5827C )

Other than the address of the CreatureVector.Start, all of those values change every time you launch the app.  If you take the value in CreatureVector.Start (at address 0x093016b0), that should point to the first entry in the vector, which will be a pointer.  If you read the value pointed to by that memory address, it will point to the first creature in your list.  The first 4 bytes of the creature should be a pointer to the first name, which should be a string.  So in my case, I have:

Code: [Select]

0x093016b0 (CreatureVector.Start) -> 0x0a009ca8
  0x0a009ca8 (CreatureVector[0]) -> 0x09d2a7e0
    0x09d2a7e0 (Creature #1) -> 0x09e3b874
      0x09e3b874 (Creature #1 FirstName) -> TOAD\0

Does that also work for you?   One thing I'm concerned about is that I am running the 32-bit app on a 64-bit OS, so I don't know if that will change the memory layout, though my .bss starts at 0x08808000 as well, which is a good sign.

--Mike

[AxelDominatoR]

kutulu:

I just made a fine re-check of everything. It was my fault. Following your procedure I can indeed find "TOAD" following your Creature.Start address, so I confirm that. I'm on 40d11, Gentoo Linux 32bit.

[kutulu]

Yay -- tons of progress!

First off, a big correction for anyone working through this on their own:

Code: [Select]

0f bf 15 ? ? ? ? 66 85 d2 78 18 8b 0d ? ? ? ? a1 ? ? ? ? 29 c8
(...)

The second group is the address of the CreatureVector.Start.  And the third is the address of CreatureVector.End, which is 4 bytes above CreatureVector.Start.

This is incorrect, as I eventually figured out.  The address I find in that spot is the address of the Race vector, one entry per known race (DWARF is always #166 in mine), not the Creature vector.

The good news: I can now reliably ReadString() from the running process.  gcc std:strings are apparently much simpler than VC++ ones.  They're similar to Pascal's refcounted strings: The value stored in the string variable is always a pointer to a null-terminated char array, with the length at offset -12 and the ca at offset -8.  Not sure what's at offset -4, it looks like a boolean (so far it's always 0 or -1) so perhaps some sort of COW flag.

The actual layout of the Dwarf object isn't the same, either, so the actual offsets in the XML data are wrong.  I've found the firstname, nickname, and custom profession.  Lastname is tricky because it's not just stored as a string, so I have to confirm that I have the right place for that, then figure out where the labor and skill vectors are.

More to come...

[0x517A5D]

Code: [Select]

0f bf 15 ? ? ? ? 66 85 d2 78 18 8b 0d ? ? ? ? a1 ? ? ? ? 29 c8
(...)

The second group is the address of the CreatureVector.Start.  And the third is the address of CreatureVector.End, which is 4 bytes above CreatureVector.Start.

This is incorrect, as I eventually figured out.  The address I find in that spot is the address of the Race vector, one entry per known race (DWARF is always #166 in mine), not the Creature vector.

Urk.  Terribly sorry.  I'm glad you figured it out though.

[kutulu]

Code: [Select]

0f bf 15 ? ? ? ? 66 85 d2 78 18 8b 0d ? ? ? ? a1 ? ? ? ? 29 c8
(...)

The second group is the address of the CreatureVector.Start.  And the third is the address of CreatureVector.End, which is 4 bytes above CreatureVector.Start.

This is incorrect, as I eventually figured out.  The address I find in that spot is the address of the Race vector, one entry per known race (DWARF is always #166 in mine), not the Creature vector.

Urk.  Terribly sorry.  I'm glad you figured it out though.

Actually, it was ultimately helpful.  Since the race object is much simpler than the dwarf object (it looks to be just a series of short strings) I was able to verify that I could decode string data by dumping the whole race table, and confirm that dwarf race index was always the value where the DWARF entry way.  It also gave me a known vector I could compare to between runs to confirm that my vector walking code worked.

I should have figured it out sooner, though, since the vector always had exactly 237 entries in it, even after I had acquired dozens of new dorfs, I just wasn't paying attention.

Now I just need to locate the real CreatureVector address, but given what I know about RaceVector it should just be three hops backwards from the first name of my first dorf.  If all goes well I'll get the same answer fro all 5 of my memory dumps

--Mike

[DaveT]

Just to let you know that I'm looking forward to you getting this working! Maybe even when my finals finish in a couple of weeks if you've got bored of making it work I'll have a play.