HorridModz

discord.gg/moonsec

The script has been patched, but @Michael1541went through a lot of effort to make an updated version for the community! Switch to that one instead: PG3D Lottery and Sets script updated - LUA scripts - GameGuardian

Yes, I know this is possible and I've done it myself. But my theory for why this functionality is not included is that Enyby does not want it to be easy. It's impossible to prevent this from happening because you can use hooking, but it's more difficult when it's not baked into gameguardian. Also, please be respectful. The moderators on this site are very sensitive, and this post could easily get you a warning (which would give you a warning point that showed on your profile forever and reminded people you weren't a very nice guy).

This would be useful, but I believe gameguardian specifically does not want us to run our own code because of security. That's why lua scripts are sandboxed and have certain functionality, eg: file access, limited / entirely removed. Adding an option to inject assembly code would be begging for someone to come along and make a malicious script. Personally, I am in support of this. But AFAIK the gameguardian admins aren't.

This is great @Sysadmin, but can you also shoutout Moonsec? I feel like they deserve a shoutout just as much. Moonsec also has an awesome obfuscator that's free - and it comes with an anti-log feature. In addition, they have a paid obfuscator and a tool called LuaAuth that allows users to manage access to scripts by ip addresses.

That sounds great. Since pg3d has lots of protections and anticheat, it may be more satisfying for you to mod an easier game, such as an offline game, or maybe even a mono game (mono is what unity games were made with before 2017, it made app apks come with the source code so you could easily edit the source code however you pleased). Personally, I remember when I edited the source code of an offline game with no protection that was built with mono. I trivially modified a lot of stuff in only a few hours, then I installed the modified game and got to enjoy all the mods I had created. It was really cool and gave me a lot of motivation. I recommend trying that to give yourself courage, but if you want to stick to pg3d, feel free to. I just hope you don't get frustrated. Also, make sure to follow a tutorial every once in a while. In my opinion, that's the best way to learn new things as well as to build onto your current skills. I recommend watching a couple of PMTDVA's tutorials.

Tell me where anyone said this was an xp spoofer. You just did the equivalent of walking into a furniture store and asking if they sold shoes. I don't plan to update this script. Sorry.

I don't think there's any bp scripts that currently exist. You'll have to make your own. The reason bp scripts are almost extinct is because the game has been obfuscated since version 16.6.1, and most modding has been achieved by comparing 16.6.1 with the current version to deobfuscate the game's code and find hacks. The pixel pass was not a thing in version 16.6.1, so all the pixel pass code is obfuscated and almost impossible to deobfuscate. This makes it very difficult to find battle pass hacks.

Thanks so much! Where in the heck did you find this? Correction: This says paying, not playing (meaning whether you are an f2p player or you have spent money or the game before) I believe the script is working again in 22.8, but I have not verified this myself.

Most tutorials on hex patching do not explain how hex patching works. I'll explain exactly what hex patching is and how it works, from the very beginning. @MainCand @BadCasedid a great job explaining, but they didn't go in-depth. To understand what the libil2cpp.so file is, you have to understand how the game's libil2cpp.so file is generated. All games with libil2cpp.so files are made with Unity's Il2cpp Backend. Unity is a game engine where you write your code in the C# programming language, and the engine compiles it into an apk. Most of the game's code, such as the 'headshot' method, is converted from C# to IL (Intermediate Language) to C++. This C++ code is then compiled to assembly code, which is encoded into hex and stored in the libil2cpp.so file. Different devices use different assembly languages (called architectures) - android has armv7 (32bit) and armv8 (64bit). There is a libil2cpp.so file for each architecture. In most Unity games, there is armv7, armv8, and sometimes x86 support. In armv7, armv8, and x86, all assembly instructions are 4 bits long when encoded into hex. When the game executes a method like the 'headshot' method, the hex for the headshot method is taken from the libil2cpp.so file for the device's respective architecture, decoded back into assembly code, and run. This is not the exact process, but I left some information out and simplified some stuff. To visualize this, I like comparing c code to assembly code to hex. Arm Hex Converter Online can be used to converted between assembly code and hex, and Compiler Explorer can be used to convert c code to assembly code. There is currently no way to perfectly convert from assembly code back to c code, so you will have to learn assembly code to understand it. So what does Mov R0, #1 bx lr mean? I like looking at it in c. This is the same as: return(1) There are multiple ways to write this in assembly, so compiler explorer might contradict us. But Mov R0, #1 bx lr is the simplest way to do it. Let's make up an example of how we would use hex patching and walk through it step by step. Say that the offset for the 'headshot' method is 0x67AB0AB. This means that the function's code begins at the 67AB0AB's byte of the libil2cpp.so file. The offsets are usually in hexadecimal - this is what most hex editors use, and what most tools / resources like dnspy and Il2cppDumper use. This represents the decimal (base10) number 108703915. So, we know that the function begins at the 108703915th byte of the libil2cpp.sp file. If we go to this offset in our hex editor (most hex editors use hexadecimal offsets, so we go to offset 67AB0AB, the first 8 bytes are 06 00 00 15 00 88 FC BF. Each assembly instruction is 4 bytes, so we are looking at the first 2 assembly instructions of the function. We edit this to our hex (if we want to working with armv7, and we want the function to always return 1, we use the hex 01 0 0A0 E3 1E FF 2F E1, which decodes to Mov R0, #1 bx lr . We only have to edit the first 8 bytes (2 instructions) of the function because if we always edit the first instructions to return, the function will always return before it executes any other instructions. This is how return statements work in almost all programming languages. For this reason, we edit only two instructions and do not have to overwrite the whole function. We need to edit two instructions and not just one because return(1) takes two instructions in assembly. If we want to return a number that cannot be expressed in one statement (ex: for armv8, the maximum number you can directly use is 65535, or 0xffff in hexadecimal), or we want to do something more complicated than always returning a number, we may need more than two instructions. In this case, we overwrite as many instructions as we need. If our new function is very complex, it might be longer than the original function. This will rarely happen, but just in case, you should use workarounds when your new function is long. I do not currently know how to find where a function ends, only how it starts. A .so file is a linux shared library file (armv7, armv8, and x86 architectures use linux), so if anybody wants to try to find out an easy way to find out where a function ends, or even better, a way to list all of the functions in a given .so file, (it would be awesome if somebody does this!), this is a starting point to start researching. Hopefully this is a helpful guide and it explains hex patching in-depth! Sorry I wrote so much, I got a little carried away NOTE: In most assembly languages, including armv7, armv8, and x86, the numbers 1 and 0 are used respectively instead of true and false. The hexadecimal representations of 1 and 0 (0x1 and 0x1) can also mean true and false respectively.

I use a rooted android emulator with gameguardian. I am not an expert at setting up gameguardian or rooting, so don't ask me if you are having issues - there are many great tutorials on youtube that explain better than I can.

You can try running the pc version of the game, using ProcMon to find where the metadata is accessed, then setting a breakpoint. This will make sure you dump the metadata at the correct time (referencing this tutorial). There is also the possibility that the dumped metadata is a decoy.

If no tools are working, I think the only option is (of course) to manually reverse engineer it. Good luck!

Glad this was fixed, but I just want to say that while@MAARS's solution works, it is not very clean. This is because if not will also be true if the value is false, not just if it is nil. if not works, but it is not clean code because it is not clear whether a boolean value is expected or not. You should also try to make your code as clean and understandable as possible. For example, look at this code: variable = false if not variable then alert("Variable is nil!") else alert("Variable is not nill!") end

I don't have the time to analyze this, but here are some notes: -Just because the 4 magic bytes are there does not mean the metadata is not encrypted (like in this game: https://katyscode.wordpress.com/2021/01/15/reverse-engineering-adventures-league-of-legends-wild-rift-il2cpp/) -You can try using Il2cppInspector to dump the game -You can try opening the game in ida pro and comparing with the old versions to see what has been changed -You can try forcing the il2cpp version in the config.json file for il2cpp dumper - maybe this game switched the version of il2cpp to an older one for some reason However, I do think the problem is that there is some protection in the libil2cpp.so file - this seems to be the most likely explanation.

Nice description