Announcement

Collapse
No announcement yet.

[OTClient] Battle List Tutorial

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #16
    Originally posted by Casky View Post
    Someone had any lucky updating this?

    Look's like the creatures list offset now is 0x264 and the UnorderedMapOffsets->BufferPointer is 0x14, but it doesn't always works, it's kinda random, it works, but if you open the client again it doesn't work at all, or just get like half of the creatures in the list.
    Anyone tried it? xD

    Comment


    • #17
      Thanks for the guide mate. At the moment I'm trying to replicate this in the latest OGL client and I get to step 4, at the getCreatureById step. In CE, it looks quite different for me.

      as you can see the ecx isint mov'ed into some other register and the lea doesnt use the ecx register at all, so I'm kind of confused. Only thing that seem to be happening to ecx register is that its added by 264. Maybe that means the offset is 264? Not sure. If you have time and feel like it, please let me know what's going on

      EDIT: Info I found so far. (Latest OGL client)
      G_MAP_ADDR = 0x572390
      knownCreaturesOffset = 0x264

      From there, I do not know how to find the changed MapOffsets. I tried browsing memory region at: "Medivia_ogl.exe" + 572390 + 264
      which basically is Base + gmapAddress + knownCreaturesOffset

      From there according to the lua
      Code:
      local count = readInteger(address + UnorderedMapOffsets.Count)
      I try reading ints by just increasing the offset manually and viewing the memory viewer. Nothing changes when I go up/down a floor to increase/decrease the amount of creatures in the battlelist.

      EDIT again:
      Basically I'd like to know how you find these:
      Code:
      local UnorderedMapOffsets = {
      	Unknown = 0x0,
      	BufferPointer = 0x4,
      	Count = 0x8
      }
      
      local UnorderedMapBufferOffsets = {
      	NodePointer = 0x0
      }
      
      local UnorderedMapNodeOffsets = {
      	NextPointer = 0x0,
      	PreviousPointer = 0x4,
      	Key = 0x8,
      	Value = 0xC
      }
      Last edited by Tony32; 19-01-2017, 09:43 PM.

      Comment


      • #18
        @Tony32, this tutorial is now a bit outdated for the current iteration of the Medivia client. Mostly due to a bit vague description of how the std::unordered_map is generally implemented. As for previous versions of the Medivia client it seems as if the hash function provided to the unordered_map was doing some wonky things that made all the elements have equivalent hashes which in turn made the collection to always generate collisions which could be seen as just a double linked list. (As described in the tutorial)

        Now for the current iteration it seems as the hash function is now properly generating some what unique hashes for the different elements. As far as the offsets and addresses goes there's no step by step tutorial on how to acquire them but just try to learn about data structures in general and know what to expect and what to look for.

        If all these things about hashes and whatnot confuses you I'd suggest you take a look on HashMap implementations and try to get a feel of how stuff can be laid out in memory if you want to fully understand how to reverse things like this.

        Comment


        • #19
          @ottizy Thanks for the response! I appreciate the long and informative answer. I'm gonna take a closer look tomorrow, at least, regarding the unordered_map.
          Anyway, I finally made it print some of the creatures encountered at least by modifying the provided lua script provided in the first post (for testing)
          The count increases for every monster seen and stays there for what seems permanently (or until very large). Because right now it reads out 26 enemies but only prints 4 and it gets an error. It's because the creaturePointer gets null. So I guess my offsets are still wonky or something other (major) have changed.

          I have a lot to learn and to discover. It's fun, but damn it takes time and psyche.

          Comment


          • #20
            Originally posted by Casky View Post
            Someone had any lucky updating this?

            Look's like the creatures list offset now is 0x264 and the UnorderedMapOffsets->BufferPointer is 0x14, but it doesn't always works, it's kinda random, it works, but if you open the client again it doesn't work at all, or just get like half of the creatures in the list.
            I have the same issue right now. It's very weird.

            Comment


            • #21
              I found this error
              Error:[string "local baseAddress = getAddress("Medivia_OGL.e..."]:71: attempt to perform arithmetic on a nil value (local 'creaturePointer')
              how to fix?

              Comment


              • #22
                Number of creatures: 64
                c: 1, x: 65535, y: 65535, z: 255, id: 268780656, name: Bilbo Baggins
                c: 2, x: 65535, y: 65535, z: 255, id: 268787970, name: Ouh Gas
                c: 3, x: 65535, y: 65535, z: 255, id: 268681464, name: Ullr
                c: 4, x: 65535, y: 65535, z: 255, id: 268672012, name: Natt
                c: 5, x: 65535, y: 65535, z: 255, id: 268773273, name: Syster Maya
                c: 6, x: 65535, y: 65535, z: 255, id: 268710320, name: Groszas
                c: 7, x: 65535, y: 65535, z: 255, id: 268775204, name: Jaum Snow
                c: 8, x: 65535, y: 65535, z: 255, id: 268782188, name: Black Knighter
                c: 9, x: 65535, y: 65535, z: 255, id: 268779220, name: Esy
                c: 10, x: 65535, y: 65535, z: 255, id: 268770210, name: Evil Rook
                c: 11, x: 65535, y: 65535, z: 255, id: 268778028, name: Undead Crazy
                c: 12, x: 65535, y: 65535, z: 255, id: 268778115, name: Jaum Snow
                c: 13, x: 65535, y: 65535, z: 255, id: 268764916, name: Sir Zenithar
                c: 14, x: 65535, y: 65535, z: 255, id: 268776099, name: Ouh Gas
                c: 15, x: 65535, y: 65535, z: 255, id: 268783237, name: Matzii
                c: 16, x: 65535, y: 65535, z: 255, id: 268783576, name: Dinor
                c: 17, x: 65535, y: 65535, z: 255, id: 268763303, name: Blue Core
                c: 18, x: 65535, y: 65535, z: 255, id: 268787177, name: Najlepiej
                c: 19, x: 65535, y: 65535, z: 255, id: 268775440, name: Senhor Polem
                c: 20, x: 65535, y: 65535, z: 255, id: 1074081992, name: Horse
                c: 21, x: 65535, y: 65535, z: 255, id: 268767614, name: Drewnix
                c: 22, x: 65535, y: 65535, z: 255, id: 268771494, name: Yeah Sure
                c: 23, x: 65535, y: 65535, z: 255, id: 268786611, name: Demente Legendary
                c: 24, x: 65535, y: 65535, z: 255, id: 268762749, name: Ehm What
                c: 25, x: 65535, y: 65535, z: 255, id: 268779270, name: Cryx
                c: 26, x: 65535, y: 65535, z: 255, id: 268787802, name: Young Yeyo
                c: 27, x: 65535, y: 65535, z: 255, id: 268771797, name: Drooid
                c: 28, x: 65535, y: 65535, z: 255, id: 268770954, name: Flear
                c: 29, x: 65535, y: 65535, z: 255, id: 268764792, name: Rookhold
                c: 30, x: 65535, y: 65535, z: 255, id: 268761785, name: Torah
                c: 31, x: 65535, y: 65535, z: 255, id: -2147482400, name: Tom
                c: 32, x: 65535, y: 65535, z: 255, id: 268775472, name: Fullpocketofgrass
                c: 33, x: 65535, y: 65535, z: 255, id: 268784288, name: Filhote de Texugo
                c: 34, x: 65535, y: 65535, z: 255, id: 268780131, name: Eqq Eqq
                c: 35, x: 65535, y: 65535, z: 255, id: 268770061, name: Rank One
                c: 36, x: 65535, y: 65535, z: 255, id: 268735770, name: Jaum Snow
                c: 37, x: 65535, y: 65535, z: 255, id: 268772976, name: Kebz
                c: 38, x: 65535, y: 65535, z: 255, id: 268669779, name: Vandarr
                c: 39, x: 32089, y: 32187, z: 7, id: 268774295, name: Dogsu
                c: 40, x: 65535, y: 65535, z: 255, id: 268772990, name: Lua de Cristal
                Error:[string "local baseAddress = getAddress("Medivia_OGL..."]:71: attempt to perform arithmetic on local 'nodePointer' (a nil value)
                I've watched a few videos and read about hashmap, and I think I get it now actually. But what I don't get, is why the nodepointeroffset changes all the time and what it really represents.

                When I've tested, sometimes 0x0 (as in the guide works). I can wait a while in-game or walk around/change floors and w/e and suddenly it wont work at all OR it lists some names and then followed by that error. If I then change the NodePointer offset, the list changes. Sometimes by adding more names, sometimes less, and sometimes none at all.

                I just don't understand what it means in a hashmap structure and how you would know which or what is the correct NodeOffset.

                As I understood from the reading and videos, a hashmap contains indexes. The place where the key and value will be stored is determined by the hash of the object. If the same hash is generated, more objects can be in the same index, but in line after eachother, with the objects inside containing a pointer to the next object if there are any, else they are null. I hope I understood it right, but I just dont know how I would connect that logic to the problems I'm experiencing.

                Hoping for someone that can clear things up if I got the wrong idéa. (not asking for any code)

                BTW, this is one of the videos I watched
                https://www.youtube.com/watch?v=c3RVW3KGIIE

                This one was even better imo.
                https://www.youtube.com/watch?v=MfhjkfocRR0

                So I think I gotta find a way to know how many indexes the hasmap contains so I can loop trough all of them to check if they contain anything and if they do, check if it got multiple after one another (on the same index) and when that index is done, go on to the next index until end of hashmap. Am I thinking right now? Just not sure how to get the amount of indexes in a hashmap. Maybe that's what we get from the countoffset? or can there be more empty indexes than actual counts?
                Last edited by Tony32; 05-02-2017, 09:12 PM.

                Comment


                • #23
                  A hashmap always keeps track of the amount of elements in it and the current capacity i.e. the size of the array where it actually stores the items. You seem to be on the right track but you'll need to check up more on what happens when 2 different elements generate the same hash (collision). If two elements got the same hash it means it needs to be stored in the same index in the array. The usual way to deal with this is to let every array element act as sort of a doubly linked list and store collisions in the linked list.

                  Also generally, hashmaps resizes the array everytime that size >= capacity but for the most of the time that will not be any problems for reading it aslong as you keep track of the capacity. A special case (I think) that comes into the implementation of hashmap that we find in Medivia is in the way how it handles deleted entries so that is a thing you'll have to look into aswell to make sure you are not reading something that has been deleted.

                  Comment


                  • #24
                    Originally posted by ottizy View Post
                    A hashmap always keeps track of the amount of elements in it and the current capacity i.e. the size of the array where it actually stores the items. You seem to be on the right track but you'll need to check up more on what happens when 2 different elements generate the same hash (collision). If two elements got the same hash it means it needs to be stored in the same index in the array. The usual way to deal with this is to let every array element act as sort of a doubly linked list and store collisions in the linked list.
                    Thanks for the reply! I thought I wrote that, but maybe I explained how I understood it wrong x)
                    Very bust at uni right now so gotta try making it work as soon as I have time.. Think I know how it works now. Just not the details, like if there are two elements in same index, is the adr to the next value in there 4 bytes after the value offset? Like if value offset is at 0x8, the address for next element (if any) is at 0xC. Not so sure about that doe.

                    Comment


                    • #25
                      Originally posted by ottizy View Post
                      A hashmap always keeps track of the amount of elements in it and the current capacity i.e. the size of the array where it actually stores the items
                      I've been thinking about this a bit, does this mean the amount of "buckets" (I heard thats what they are called sometimes) or the actual amount of creatures in it in this case?
                      I'm not sure as I heard the default amount of "buckets" or indexes in a hashmap is usually 16. (0-15)
                      Then in each "bucket" there can be multiple entries (creatures in this case).

                      So the question is, is the "count" that's read from memory the amount of creatures or buckets? I guess its creatures right? If that's the case, how would you get the info on the amount of "buckets" the hashmap has?

                      I need to know this because if I should loop through the hashmap I need to check every bucket, right? Then I need to check all creatures within the bucket until one creature doesnt have a pointer to the next creature, move on to the next bucket. Until all buckets are checked.

                      I've googled like a madman about how a hashmap looks in memory or the general structure of it, but I can't find any threads about it. No threads about reverse-engineering and reading a hashmap from memory of another process. So the main problem right now is how to know or calculate the amount of "buckets" in it in the first place. Damnit this is hard! But I wont give up. Please let me know of your thoughts.

                      Comment


                      • #26
                        The amount of buckets and the amount of creatures is stored in memory. And like you said there's a default value and I am going to go out on a limb here and say in this case that default value is 14.

                        Comment


                        • #27
                          Anybody got something new?

                          Comment


                          • #28
                            Hello,

                            I have problem with finding the right address in Medivia OtClient (It seems to be a little modified) I have already a lot of addresses but I still cannot get the most necessary -> battle list address.

                            Can someone help me a little?

                            Here is what I have:

                            http://screenshot.sh/mLbs5TajlKlG1

                            and so by follow "g_map.getCreatureById(id)" this is what I get, and it seems to be different than tutorial example :/

                            http://screenshot.sh/ou2u5E9ZXSyLR

                            Can some one help me solve my problem :?

                            Any help appreciated

                            Comment


                            • #29
                              Hello, I need help with this guide, I wrote this post https://tibiapf.com/forum/bots-and-c...memory-address
                              I hope someone can help.
                              Thanks!

                              Comment

                              Working...
                              X