Jump to content

AngelWolf

Contributor
  • Posts

    179
  • Joined

  • Last visited

  • Days Won

    29

AngelWolf last won the day on November 16

AngelWolf had the most liked content!

Additional Information

  • Android
    10.x
  • Device
    Redmi 5 Plus Custom ROM (Resurrection OS Google Pixel 5)

Recent Profile Visitors

15,172 profile views

AngelWolf's Achievements

  1. its because LUA bytecode are version specific, the game uses LUAC from windows, so you cant recompile it on termux/android or it'll resulting bad format or bad chunk error, on my github repo i uploaded the LUAC that uses by corona engine itself no, because events are hard checked by either local time or server time, and it prefers the server time and cached it, and more so youre forced to boot the game with internet too iirc, so cant escape the check beside having mod the game itself
  2. ; - ; because x64 allows backport of x32, bruh, it all depend on the emulator or the phone itself, usually emulator depends on the dekstop arch too iirc, maybe wrong idk, but to see if you're x64 or not, GG will appends [x64] beside the process
  3. What's yall yappin about, if the game runs in x86 lib then the phone architecture only support x86 or 32bit, same applied to x64, you cant force it, the x64 usually allows backport if the game itself doesnt have x64 libs, but if the phone itself cant do x64 then it basically cant run anything in x64, correct me if im wrong, but that what i can understand about x64 and x86 architecture about
  4. for my script, i just do these 1. Save the value to search on a server 2. to get the value, it requires auth 3. the script only do search, write, replace 4. had the script obfuscated to unreadable state, while still be able accessed normally, i know encrypting a script is a no use, since GG have LogCat and Search History, so best thing i do just do weird search behavior and keep the searched value to temporary memory/variable. anyone who just want to see the source will probably question how it works, but whoever had a lot of time,can reverse engineer the script, what i do just extend that time so its not worth the time to reverse it
  5. Depends on the game itself, some game, have the server just accept anything without validating, such example is Day R Survival and on the other hand, some game validate everything on the server or fully server side, such example is Clash of Clans and for what MrSx refering not using GG is, literally hacking the game server (maybe) and that's outside the scope of GG and preferably dont do it, cuz that's literally a crime lmao
  6. for the 2nd, it gave me "bad precompiled chunk" Dec_VIP-Script.lua
  7. https://gameguardian.net/forum/topic/19033-day-r-survival/?do=findComment&comment=149726
  8. they save your device ID, so even if you play with another account, if it match the same ID, it'll be crossbanned
  9. for tagged pointer, idk much about it, since i dont understand much about pointer in GG I dont think the offset is 100, its 3 address up before the length of the words
  10. why everyone keeps asking about "is it fixed/patches", i already told this countless time, it wont get fixed anytime soon, and if you using my premium script, it will crash your game since emulator uses x86_64 while the script made on aarch64, or you just replace everything, this can cause instablity because there's might be just a types you accidentally replaced and caused NULL REFERENCE and the LuaVM confused and just crash
  11. what there's to be hacked? There's nothing new in emba 2.0 you want floppy disk hack? just do function swap between spendCurrency and addCurrency,
  12. you can just modify the constant value, to 1, instead of Jump Time, 10 minute is 600 second, so 600 double ask whoever made GameGuardian, me personally never used unrandomizer
  13. just look older post bruh
  14. there's no faster way than finding it's groups, and then see the memory tab to find the addreses, if i remember correcty, you can group them with :200 or :241, not sure exact, because its different each time, and also every crafting recipe always be in same memory region lets says Torch, it have 3 recipe, 1 output, the game will have 3 address, offset like 10 or so before/after will have a pointer to the Item ID, and after these 3 addresses, there's 4th which is the Output and near it, there'll be a pointer to that item too, and then maybe 20 ish after you'll find the next recipe addresses and it goes on for a bit until it reach some end of memory allocation for that, and then it;ll continue on other memory region, and to replace the output item, you just replace the pointer value of the output item to address of the item you targeted, example (output Qword value): 13472364658358334 (target item address(makesure take the ID's address): 487188DF just replace it to "487188DFh" with QWORD type, and click other recipe and go back to update the UI, and change the ouput as much as you want, usually 100k is decent, i mostly do 1k ========= also you can find required amount using mass edit, like Torch, wood 1, rags 1, gas 500 search 500, then editAll, open more, and increment by 1 and apply, and update the UI, then find the value, save it to SaveList, click Remove all but revert all, and then work all the other requirement from memory tab from that gasoline value
  15. i havent check the source for later version, but aint no way they'll patch a function name, nor change the state, like the input will be always positive, and the function already had checks to calculate if the input is positive, and beside the Caps hack is simply function swap, soo to patch it, they need to literally rename the addCaps and spendCaps, what you encountering here, probably just how different architecture handle pointers, my phone uses aarch64 basically ARM architecture, and i already tested one with x86_64 or x86 (MeMu Emulator) and the script i made completely broke, so in short, the pointer mapping is different, so the offest might be different, in my phone every pointer always offested by 10, idk on other archs
×
×
  • 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.