nok1a

Yeah when using searchPointer() you have to specify the regions before you load the results in the result list. The regions at the first line should be the region where you try finding your group search, but i am not sure if your group search is always in the same region. Then when pointer searching you have to only specify the region where the pointer is which i think was region Ca or A.

Your offset is + 0x8 of the pointer, not - 0x8. Also i not know if you saw but the memory region in which your value 256 was located was in region anonymous. So make your pointer searching more accurate by specifying the correct regions when needed...if you where sharing the scripts with multiple people i can understand you use multiple regions. But in this case it's for personal use i guess? See here the regions you can use. When comparing two values they must be of same type as mentioned. You comparing a number type and a string type here. If all the values are in dword no need to use "A" in front of each number. It slowers the search. It's better use the correct data type for each value or just remove the data type of each value and give them all same data type using gg.TYPE_DWORD. You will prevent issues by doing so. As mentioned here. The choice is up to you.

That's right. I also didn't knew about pointers first. Actually this whole GG pointer thing didn't make sense because i didn't knew what where hex, bytes and bits...should have stayed in school longer to get some basics...So i totally get you...it's a pain to come in without knowledge about all this...Was watching some YT tutorials about how or what are bits and bytes and it helped me. Then after some time i understand addresses in memory a little and then pointer concept from a GG point of view made more sense. But also importantly the members in this forum contribute to making it more easy for people like us to understand something which is most likely alien language for us. There is lot's of things to learn i guess. We can use GG and the forum and other sources to learn more.

Yeah you should. Are you sure you did it correctelly though. I performed pointer search more then once...so you have to use go to the pointer more then onces as well in order to get to the groups search.

Your script can not be same because your using different group search, and where you found your group search the structure is different. You only have to do one time a pointer search and your not using any values to filter out irrelevant results. You can remove most of the lines from it, here some example based on your group search and pointer you when't to. gg.setRanges(gg.REGION_ANONYMOUS | gg.REGION_C_BSS | gg.REGION_C_ALLOC) gg.searchNumber("17D;1,075,642,368D;1,900,544D;1,310,728D;589,828D;1,703,957D;1,703,969D;1,376,289D;1,920D;469,762,048D::185", gg.TYPE_DWORD) gg.refineNumber("1,900,544", gg.TYPE_DWORD) print("Group search: ", gg.getResultsCount()) local grp = gg.getResults(gg.getResultsCount()) for i, v in ipairs(grp) do v.address = v.address - 0x4 v.flags = gg.TYPE_DWORD end gg.loadResults(grp) gg.searchPointer(0) local t = gg.getResults(gg.getResultsCount()) for i, v in ipairs(t) do v.address = v.address - 0xC v.flags = gg.TYPE_FLOAT end gg.loadResults(t)

True, but before you can do that 0xC with a script you must first get there through pointer searches. There are some other issues with the script that need to be explained i think. When your doing a pointer search with GG all your doing is searching a value that represent an address in memory. Let's go from the start. You have your health value at address 0x022023EC and you have a pointer 12 bytes away from it, it's at address 0x022023F8 Address 0x022023F8 has the value 8B7D02E0h 8B7D02E0h is a called a pointer because the value represents an address in memory. When you press "go to pointer" it means that GG will bring you to the address 0x8B7D02E0h. I now whent to the pointer, as you can see the highlighted address is 0x8B7D02E0 and under it you have your refined value from the group search 0x8B7D02E4 And that is also the location where you came up with your group search. When you did your group search and refined you had a lot of results left but let's say that you only had one address in the result list that has the value 1,900,544 and it's the correct one it would be looking like this: The value you refined is located at address 0x8B7D02E4 We now need to work backwards to get to or health value and perform a pointer search on the pointer we just whent to. The pointer that we just whent to was 0x8B7D02E0, so it's 4 addresses above the address that holds the value you just refined to, which is address 0x8B7D02E4. So first you have to tell the script to subtract the current address 0x8B7D02E4 - 0x4 and then load it in the result list. That's what local grp = gg.getResults(gg.getResultsCount()) for i, v in ipairs(grp) do v.address = v.address - 0x4 v.flags = gg.TYPE_DWORD end was doing, instead for 1 address in the result list it was doing it for all the addresses in the result list. After it subtracted 0x4 from the address 0x8B7D02E4, so your address became 0x8B7D02E0 (it's the same address you whent to using "go to pointer"), and then you used gg.loadResults(grp) to load the new address in the result list. So now result list will look like this: Now you will ask GG to perform a pointer search on that address(0x8B7D02E0), with that i mean that your telling GG to search in memory for addresses that hold the value 8B7D02E0h And of all the address in memory, which address you know for sure holded the value 8B7D02E0h ? Right, address 0x022023F8 holded the value 8B7D02E0h. The same address of where the address that holds your health value was located 12 bytes above it. So by using gg.searchPointer(0) Your telling GG for search the value 8B7D02E0h in memory. You get perhaps a few results. Now you get a few results but between all those the results the right address is in there 0x022023F8h: You know that 12 bytes above the address the address of your health is located (0x022023EC) so you don't have any reason to perform the searchPointer(0) again because your already at the address you started from. Now you need to tell GG to subtract 12 bytes(0xC) from the address 0x022023F8h and get the value at that new address. Since you have more then one result use a loop. local t = gg.getResults(gg.getResultsCount()) for i, v in ipairs(t) do v.address = v.address - 0xC v.flags = gg.TYPE_FLOAT end gg.loadResults(t) Get the results in a table t, and subtract all the addresses with - 0xC and set the flags as float. Then when you load the table t using gg.loadResults(t) it will load the new address in the result list type float. You gone have multiple addresses loaded because there are many addresses that go to the pointer you whent to, so they all hold the same value (8B7D02E0h) In GG it would look like this if you had a more accurate group search around that address your performing a pointer search on: Since the group search is not that accurate which causes you have to more then 100 results when refining to your value 1,900,544 and you performing pointer search on each of those 100+ addresses that where loaded in the result list you probably gone get something like this, possible they are all health values for different objects but the health value of your character is of course in there at address 0x022023EC: I am not sure if all makes sense?

Why are you doing 0x0C ? Your value 1,900,544 is not 12 bytes away from the pointer you just whent to, it's 4 bytes away. If you enable byte view in the memory viewer you can see every address in memory: Or you can select both addresses and use the offset calculation to see distance from start address to destination address.

Here there was a mistake from my side but @CmP has warned me for that. When comparing 2 values they must be of same type. I tried editing it in my previous posts: but it seems you still uses the script i sended, my fault. Comparison of 2 different types in Lua will cause issues. Correct it to: if sensitivity[i].value == 1.0 then

Make sure that when you do a group search you specify it's data type. When you put Auto in front of it GG will look for all possible data types for that specific value and then needs to match it also with the other values to see if the group search can be found. You could have results you don't need. For example do this: gg.searchNumber("17D;1,075,642,368D;1,900,544D;1,310,728D;589,828D;1,703,957D;1,703,969D;1,376,289D;1,920D;469,762,048D::185", gg.TYPE_DWORD) Or you can ignore the data types next to the value and only use gg.TYPE_DWORD If your only searching 1 value you don't put a data type for that specific value aside from adding the gg.TYPE_DWORD as any normal search.

gg.loadResults({{address = grp[1].address - 0xc, flags = gg.TYPE_DWORD}}) gg.searchPointer(0) print("First Pointer search: ", gg.getResultsCount()) You also will need to change this gg.loadresults() since it only subs 0xC to one address in the result list. But you want it to happen to all the addresses in the result list before you load their new addresses in the result list. So use loop. For example: for i, v in ipairs(grp) do v.address = v.address - 0xC v.flags = gg.TYPE_DWORD end gg.loadResults(grp) gg.searchPointer(0) print("First Pointer search: ", gg.getResultsCount()) gg.searchPointer(0) print("First Pointer search: ", gg.getResultsCount())

Perhaps use the code snippet option when adding code in your post for readability. The script only performs pointer search on 1 address. You have more then 50 results left after refining and probably the first result in the result list is not the right address...but sure the right address is in there . Although it's better to have your group search as accurate as possible to prevent any kind of issues later on. Use local grp = gg.getResults(gg.getResultsCount()) so that all results are selected. Then gg.searchPointer(0) will perform pointer search on all the addresses in the result list instead of 1.

Indeed, just make sure that your using hex and not decimal. 12 bytes = 0xC

LDPlayer Make sure you deleted any installed dead trigger 2 versions from the emulator using the uninstall option in the play store. Sign in to the play store with your google account. Then create new folder in 0/android/obb/ name folder: com.madfingergames.deadtrigger2 and then store the .obb file (main.15020074.com.madfingergames.deadtrigger2.obb) from the modded apk in it. Should resolve the issue.

But i also think that regarding voting it's more efficient to use it as accordingly as possible. Like for example i don't think you have to upvote every comment because you received a solution or want to show gratitude (of course it's appreciated), personally i believe only the solution should be upvoted or liked or answers that answer questions. Multiple answers can answer multiple questions so each of it should receive a vote if all those answers are well detailed enough in a way that the other person understands. (personal opinion)

Thanks for the vote but that's more about status. Account status not that relevant but perhaps it can work as a backbone regarding the reliability of the information provided and as well the individual his contribution in the forum. Positive votes always better then negative ones to. Aside from that most important to me is that the information shared is done good enough in a way that the person communicating to understands it. And of course to use the knowledge obtained for himself and improve so the person becomes a even better person.

It finds all pointers pointing to your address. To use it you need to load the address(es) you want to perform the pointer search on in the result list. gg.loadResults({{address = grp[1].address + 0x4, flags = gg.TYPE_DWORD}}) Adds 4 bytes to the address, 0x9865E5B0 + 0x4 = 0x9865E5B4 and then loads it in the result list in data type dword. gg.searchPointer(0) Does the pointer search in the given ranges. Basically it's like doing: gg.searchNumber(9865E5B4h, gg.TYPE_DWORD) You get a few results. I dunno how gameguardian does it behind the hood but now i use gg.searchPointer(0) again because i want to perform pointer search on each of those addresses...that's why a second time. I have now more results because there are a lot of pointers pointing to those few addresses from previous screenshot. Now i need to filter them out because the health value was one more pointer search away, and the address to pointer search is in this result list. One of those addresses had 4 bytes above it a value 1.0F. That's the same value i asked you to search using 256F;1.0F::16. Sadly it returned no results for you. But the 1.0F value is located 4 bytes above one of those addresses in the result list. So i used that for filter out all these values and to get only 1 address left. local t = gg.getResults(gg.getResultsCount()) local sensitivity = {} for i, v in ipairs(t) do sensitivity[i] = {address = v.address - 0x4, flags = gg.TYPE_FLOAT} end sensitivity = gg.getValues(sensitivity) subtracted 0x4 from all the addresses in the result list and stored it in a new table(sensitivity) with data type float. local healthPointer = {} for i = 1, #sensitivity do if sensitivity[i].value == 1.0 then healthPointer[i] = {address = t[i].address, flags = gg.TYPE_DWORD} end end Checked which address of the table sensitivity contained the value 1.0F using iteration and if it found it should store the address that is 4 bytes under it in the table healthPointer and then load it in the result list using: gg.loadResults(healthPointer) It found a match and loaded the address in result list: Script performs pointer search again. local res = gg.getResults(1) local health = {[1] = {address = res[1].address + 0x4, flags = gg.TYPE_FLOAT, name = "Health"}} Will get 1 result, the health value is 4 bytes under that address...so i add 4 bytes to the address and store in the table health and gave it a name. gg.addListItems(health) gg.loadResults(health) Add the table health in the saved list. And loads it as well in the result list. Adviced to check out the Lua scripting documentation.

Because the address i needed to perform pointer search on was closest (4 bytes) from it. I could use any value of the group search and increment it with the distance to the desired address (0x9865E5B4). Actually i should not have done the refine, it's useless in this case since the group search is accurate.

Value is protected. I dunno how to edit the ARM instructions but perhaps someone more familiar with it could have a look.

Got it. Glad to hear. Thank you to for continuing with it instead of dropping out halfway. Finding group searches for other members through communication of a forum takes time. Requires a bit of Forward and Back communication. People can get demotivated. You pulled through. Group search was possible to find using my emulator and phone. When searching group search for other person or for your self you need to at least have the game on 2 different devices or virtuals to have some confirmation that your group search is possibly a static one. As far i know in gameguardian a pointer is a value that points to an address in the virtual memory of the process. I don't want to tell you wrong info so i keep it with this link: https://en.wikipedia.org/wiki/Pointer_(computer_programming)#:~:text=Pointers are used to store,which objects are dynamically allocated. GameGuardian highlights possible pointers with a colour: https://gameguardian.net/help/help.html#help_hex_colors Pointers are more clear in 64bit games. On 32bit games to many values are highlighted but they aren't all pointers...after some practise you can quickly filter out the none pointers from actual pointers. The pointer represents some object. If you can't find a group search around the value of interest you can follow the pointers which usually will lead to some static values. In lot's of cases the game needs to uses pointer references from an object in order to update for example your health value when you take damage. In GG i used the nearest pointer that had the same distance from the health value on both devices. And kept using "go to pointer" till i saw a block of values that is the same on both devices so i could use it to make a group search. Then what you have to do in the script is use "gg.searchPointer(0)" and this will do the opposite. Instead of going to pointer you will be get all addresses that have a pointer that points to your address. I advice you to check some scripts that uses pointer search and combine it with your manual knowledge on how to use the GG pointer feature. Use the print() feature in the script to slowly debug the script. And use --[[ ]] to ignore code so that you can see line by line what happens.

gameguardian can't find the process of the modded apk mids being hooked to the process. If i restart the app, GG can find it again but then after sometime it's invisible again for GG. mobizen_20240103_202510.mp4 What causes the issue and how to solve?

Could be wrong but it says that there is a character that isn't supposed to be there at line 1. I think you pasted the code in a file and typed some character in it by accident which then caused the error. Please recheck the script. Delete all and past again. If still same error it's odd. Should not be scripts mistake. Perhaps a character got added while copy pasting it. Upload script here if still not work. You can download this one, it's the same script. pointerTest.lua

Execute the script i gave you, and send screenshot of the prompt.

Oke and what about the group search 327,684D;22D;28D;0D;33,554,931D? When you enable all regions and go in match and search. No result? The thing is, the group search and script i have tried on emulator and mobile phone and on both worked. And the values remain same even after restart of the game. So perhaps you have to find your health value and then you have to execute a script i can give you. And then we perhaps find out what for values are at the location of which your supposed to have: 327,684D;22D;28D;0D;33,554,931D. Possible it will be static for you as well. But first check if this group search works when enabling all regions.

Enable all regions

You don't need to be in same mission. search 256;1.0 when the pause menu is visible. And search 257;1.0 when the pause menu is hidden.