Login Register
MoHH2 Legendz

Legends of Medal of honor:Heores 2.. Never forgotten RiP in piece


    You are not connected. Please login or register

    View previous topic View next topic Go down  Message [Page 1 of 1]

    Post: #1on Sun Sep 18, 2011 1:08 pm

    avatar

    FoodFx

    Senior Member


    Hello all,

    It seems to me that most tutorials in this section give nice descriptions of how to use some particular method to deal with DMA, but not many (if any at all) spend time explaining the concepts. Personally I think this approach is short-sighted. Sure, it gets people going quickly and can give good results, but if something goes wrong, someone new to MIPS won't find much help.

    In this thread I'm going to attempt to explain the concept of DMA. I will also explain the theory of some of the common "DMA defeating" methods that are employed in this forum.

    What is DMA?
    As you've probably heard thrown around, DMA stands for Dynamic Memory Allocation. In technical terms, that means that the memory is allocated when it is needed at run time.

    Why is DMA used?
    Some people will say game developers use DMA to make your job as a coder harder. While I can see how this is possible, I think it's more likely a matter of efficient coding.

    If there were no DMA, everything would need to have a place in memory reserved for it. Nothing else would be able to take that space (or nothing would know how to find anything else).

    Lets say you were playing a first person shooter. With no DMA there would need to be a place reserved in memory for things like health, ammo, your location, your loadout, etc.
    But what if you were in a lobby? None of that information is necessary, yet it still has a reserved spot in memory. That space is being wasted.

    With DMA, however, that space doesn't need to be reserved. Something else can fill that space. In this situation nothing has a reservation, it's just put where ever it fits in the mess of other data that's being stored. While that may seem disorganized, it does save a significant amount of memory (since the program won't need to allocate memory for every possible situation all the time).

    Some games tend to use DMA more than others, I think this is just due to the coding philosophies of the people writing it.

    Why isn't everything DMA?
    DMA isn't a "cure all." Things that cannot or should not change are better suited to being static because you never plan on giving that space to anything else. In addition, static memory isn't necessarily a bad thing.

    How does DMA keep track of things?
    Some of you may be wondering how a program keeps track of data if it's all just put where ever it will fit. This is where pointers are used. A pointer "points" to the data that is desired. A pointer usually has an address where it can always be found, but it's value changes so that it points to the data that it is supposed to.

    But if the pointer has a reserved address, why not just give reserve that address for the data that's jumping all over memory?

    Generally pointers don't point to one single piece of data. They usually point to a structure of data (such as your players information on health, ammo, location, etc.). Therefore you can have one address reserved, but keep track of hundreds of other pieces of data when you need to.

    Pointers usually point to the start of a block of reserved data, it is then the job of the offset to get any one specific piece.

    Pretend I had this bunch of letters stored dynamically:
    adjebgi

    My pointer would tell me where to find the letter 'a'
    but what if I wanted to know where to find 'e'? I would add an offset(4) to my pointer.
    the place where my pointer points + 4 = where to find 'e'

    Offsets are generally constant. If your data is 8 bytes offset from the start of the data structure, it will always be 8 bytes offset from the start of the data structure (this is important to many theories of finding pointers for codes)

    Double DMA
    Sometimes pointers don't point directly to data, but point to another pointer. If that's confusing, don't worry, you're not alone.

    If you know c/c++/java a simple example of this is a char**.

    If you've never dealt with char** an example would be if I wanted to store the sentence:
    The quick brown fox jumps over the lazy dog.

    The first pointer would direct me towards each word, where I would find other pointers to each letter.

    At this point, you should have a general idea what DMA is, why its used, and be somewhat familiar with the terms pointer and offset.

    DMA and PSP codes
    As many of you have probably experienced, a DMA code will work one time and then never again. This is because the data has moved, but you're still looking for it in the same spot.

    In order to make a code work perfectly everytime, the pointer that points to the structure that contains your code must be found. This isn't enough on its own, you also must find the offset from the start of the data structure.

    I feel that I should clarify something here. People usually talk about pointers in game codes as if they only exist so that the game can find the code you are working on. This is probably not true. The pointer probably points to a structure containing many, many pieces of information. The problem is that most of this data is not relevant to your code or any code that you would want to make.

    The way pointers are stored as data is pretty simple. On address has a value that is equal to another address. EX:
    0x000000fc 0x000001fc

    0x000000fc is a pointer that points to the address 0x000001fc
    simple right?

    How pointers and offsets are found for psp games

    DMAhunter method (as made famous by SANiK)
    The DMA hunter method relies on the idea that offsets don't change.

    We know that the value of a pointer (p1) + some offset(o) will equal the address of our code (c1)
    that is:
    p1 + o = c1

    we also know that when the data moves in memory, the offset will not change, but the value of the pointer will change (to reference the new location of the data) and a new address for the code will have to be found.
    that is:
    p2 + o = c2

    by whatever algebraic method you see fit, it says that
    p1-p2 = c1-c2

    If we take the first code address we found and subtract the second, that must be equal to the first value of the pointer - the second value of the pointer.

    If we have a memory dump of both codes, we can go through address by address and look for every instance in which the value of any given address changed by (c1-c2). Any address where this happens is the potential pointer address for this code.

    to find the offset, we can use either
    o = c1 - p1
    o = c2 -p2

    REMEMBER p1 and p2 refer to the VALUE of the pointer (not the address), but c1 and c2 refer to the ADDRESS of the code (not the value). Hopefully that's not too confusing.

    PROS of this method:
    Very likely find the pointer
    With limitations in place as for which addresses to search, you will probably only get a few possible pointers.

    CONS of this method:
    May be thwarted by double DMA (if the pointer address changes between dumps this method is useless)
    Without limitations as to which addresses to search, there could be many possible pointers.
    Requires finding the code twice

    DAMGhetto Method (as made famous by NoEffex)
    This method is a little more clever than the previous, but not as robust.

    In this method you find the code's address once and make a dump.
    using the same idea as before:
    p + o = c
    (there's only one p and one c in this case though).

    Now the method makes the user guess a little. If o < r (where r is a relatively small number)
    then
    r > c - p

    This tells us that we can specify an arbitrary value for r (NoEffex' original function used r = 0x600 by default).

    Now we've taken a problem with 2 unknowns and simplified it to an inequality with 1 unknown:
    c - r < p
    we now what c-r is equal to, so we need only compare it to the value at every address in our dump. If it satisfies the above inequality, it could be the pointer we're looking for.

    Once we've found p, we can get the offset again by using
    c - p = o

    PROS of this method
    It doesn't require you to go through the searching process twice
    Cannot be completely thwarted by Double DMA (you can use this method again to try to find the second pointer, but use the first pointers address as c)

    CONS of this method
    if r is too small, you won't find the right pointer
    if r is too large, you might find many possible pointers (one of which will be right).

    PS2DIS method
    This is my own personal go to solution for DMA. I'm sure others know of this idea, but this is presented the way I independently developed it.

    This method doesn't rely on the same ideas as the others.

    rather than the equation
    p + o = c

    this method relies on the hope that if it exists, something is looking for it :p
    note: this does require a knowledge of MIPS

    For example health. If it is being stored, something must update it, right?

    To do this method one must open their dump in ps2dis and go to the address of the code they found.

    Next the user invokes the analyzer.
    If some function is accessing the code you're looking at, you will generally be able to find it by using referrers.

    When you find a referrer look back in the routine to find the last place that fresh data was loaded into that register (usually a lw).

    Find out where it was loaded from. (that is the pointer's address).

    Next look for any arithmetic done on that register between when it was loaded and when your code was accessed (generally addiu's). That is your offset

    NOTE: the assembler used by a lot of these games is not very good. Sometimes you will see something like
    addiu a0 a0 $0030
    addiu a0 a0 $0020

    The offset is 0x50... The assembler just doesn't do it in one step for some reason.

    This method requires a significant amount of logic and reading MIPS routines. It is not an easy one to follow a guide on. If you fully understand how MIPS works and how data moves around it should be understandable and doable with a few tips.

    PROS
    Only requires 1 set of searching
    Only gives 1 result (the right one)
    Can potentially give pointers for multiple levels of DMA in one step (analysis of the routine is key here)

    CONS
    Doesn't work all that often.

    The PS2DIS analyzer is not omniscient. It won't help you if the pointer is passed as an argument from another function. It also cannot track all forms of data manipulation so if the function happens to load the pointer in some odd way, the analyzer may miss it. If it fails, try one of the other methods.



    I hope those of you who aren't thinking "OMG WTF TL;DR" learned something :lulz:

    Please give me comments/criticism.
    I wrote all of this in one sitting so I'm expecting to need revision/clarification

    Happy DMA coding Smile


    Post: #2on Sun Sep 18, 2011 8:57 pm

    Brian-1337-

    Senior Member


    i know a method to find function if the code is not DMA. but it will be very hard to teach anyone easily i will be getting more information about that to teach everyone.





    Thanks to "Red" in BIH Forum's.

    Thanks to "TyMan202" in PSVMods Forum's.
    http://www.facebook.com/Mips.Brian1337

    Post: #3on Sun Feb 12, 2012 5:26 pm

    avatar

    Linblow

    Member


    This tutorial is from OneHitGamer.com, it was made by Almost.


    Post: #4on Sun Feb 12, 2012 5:34 pm

    avatar

    Vet

    Elite Member


    Linblow wrote:This tutorial is from OneHitGamer.com, it was made by Almost.
    Obviously Laughing
    Food didn't take any credit pro




    ______________________                                                            
                                      [You must be registered and logged in to see this link.]
    ______________________

    Post: #5on Sun Feb 12, 2012 5:55 pm

    avatar

    Linblow

    Member


    Well, I didn't say he did lol, I said it's from OHG :O


    Post: #6on Sun Feb 12, 2012 6:43 pm

    avatar

    Vet

    Elite Member


    Linblow wrote:Well, I didn't say he did lol, I said it's from OHG dafuck?
    We know that Rolling Eyes




    ______________________                                                            
                                      [You must be registered and logged in to see this link.]
    ______________________

    Post: #7

    Sponsored content





    View previous topic View next topic Back to top  Message [Page 1 of 1]

    Permissions in this forum:
    You cannot reply to topics in this forum