Jump to content

Search the Community

Showing results for 'group size'.

  • Search By Tags

    Type tags separated by commas.
    For example, the common name of the game: PUBG, Free Fire, Rules of Survival, Critical Ops, Mobile Legends: Bang Bang, etc.
  • Search By Author

Content Type


Forums

  • GameGuardian
    • Requests
    • Help
    • Guides
    • Cheats
    • Video Tutorials
    • Unintended Effects
  • General
    • General Discussion
    • Introduce yourself (:
    • Announcements
    • Website suggestions/Bugs
  • Downloads Support
    • Apps
    • LUA scripts
  • Online Multiplayer Mods
    • Altering Online Games with Gameguardian
    • Download Mods
  • Other Hacks
    • Tutorials
    • Non-GameGuardian
  • Archive
    • Archived topics

Categories

  • Official Downloads
  • Virtual spaces (no root)
  • LUA scripts
    • Forward Assault
    • Free Fire
    • PUBG
    • Rules of Survival
    • Templates
    • Tools
  • Test applications
  • Other

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


Device


Discord ID

  1. @EnybyHello, I am reporting a behavior that appears to be a bug in gameguardian. It seems that the "Copy as group search", when used with "UTF-8" and "UTF-16", assumes that the values are consecutive, i.e. one byte apart. However, this is not always the case, causing group searches to sometimes fail. This is best illustrated by examples: Let's search the string "abc" in UTF-8 and save the first 3 results, but leave out the second one: gg.clearResults() gg.setRanges(gg.REGION_ANONYMOUS) gg.searchNumber(":abc", gg.TYPE_BYTE) gg.addListItems(gg.getResults(1)) -- first result - "a" gg.addListItems(gg.getResults(1, 2)) --third result - "c" Now, we have two results: 97 byte, representing the character "a", and 99, representing the character "c". These results are a byte apart - so they do not directly form the string "ac" and would not be searchable as ":ac"; rather, they would be searchable by a group search that accounts for the byte in between: 97B;0~~0B;99B::3. However, the Copy as Group Search function, when I select UTF-8, gives ":ac". This is not the right group search and seems to be a bug. In order to show why this is wrong, here is the situation where I discovered the bug. I had a script that writes a string to memory, like this: function Write_String(mystring) --[[ Allocate memory in Anonymous region and write string to allocated memory ]]-- address = gg.allocatePage(gg.PROT_READ | gg.PROT_WRITE, gg.REGION_ANONYMOUS) values = {} for i = 0, #mystring do values[#values + 1] = {address = address + i, value = ":" .. mystring:sub(i, i), flags = gg.TYPE_BYTE} end gg.loadResults(values) -- must load results before we can edit with setvalues gg.setValues(values) end Write_String("Here is my special string!") If I run this script, I get the string written in consecutive byte values. I use Copy as Group Search for UTF-8, and it gives me the correct search: ":Here is my special string!". But now let's revert what we just did by refreshing the game, change the address spacing to every 2 bytes, so the string is no longer consecutive, and copy it as a group search again: function Write_String(mystring) --[[ Allocate memory in Anonymous region and write string to allocated memory ]]-- address = gg.allocatePage(gg.PROT_READ | gg.PROT_WRITE, gg.REGION_ANONYMOUS) values = {} for i = 0, #mystring do values[#values + 1] = {address = address + i*2, value = ":" .. mystring:sub(i, i), flags = gg.TYPE_BYTE} end gg.loadResults(values) -- must load results before we can edit with setvalues gg.setValues(values) end Write_String("Here is my special string!") We copy it as group search again, and get the exact same thing: ":Here is my special string!". However, now that the addresses are 2 bytes apart, this is wrong and will not work. If we try to search it, nothing comes up. So, this is definitely not working right. I'm pretty sure that it's a bug. My suggestion for fixing this would simply be displaying an error message if the addresses were not consecutive, like this: "UTF-8 [or UTF-16] group search only works for consecutive addresses. Please use a different type of group search." If there's any other information anyone would like, feel free to ask.
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.