GL-DEV

ActorDecr Addresses For P—G V3.9:

// GL:
ActorDecr:  0x10613042C
 // KR:
ActorDecr:  0x1062DA8F4
 // VN:
ActorDecr:  0x10607D3FC
 // TW:
ActorDecr:  0x1062B13FC

//by @OOOQG
//shared from @Bubg_dev

Game SDK external https://github.com/saudgl/Pubg-3.9-IOS-SDK-GL/

VNG 3.9 :

GNameFun:  0x1048f04e0
GNameData:  0x10a0ee830
GWorldFun: 0x102a08940
GWorldData:  0x10a791ae0
LineOfsight: 0x105f195a4

ActorDecr: 0x10607d3fc
GUObject:   0x10a57b6c8
//by @saudgl
//shared from @bubg_dev

KernBypass install in IOS after install the copy of KernBypass from Terminal in IPhone or through ssh using Mac

# bash command
# Unofficial (ichitaso) build (iOS 13–14):
su             
preparerootfs  
changerootfs & 
disown %1   


# Official (akusio) build (iOS 12–13):
su
changerootfs &  
disown %1

**after command (changerootfs & ) you must see last line is like :

start changerootfs

if not make new dir

mkdir -p /var/MobileSoftwareUpdate/mnt1

then repeat bash command above (changerootfs & then disown %1 ) NOTE 🚨: install all your tweaks before install Kernbypass caz after it you can not add any tweaks. why ? long answer just do it . https://www.youtube.com/watch?v=PxJK0421bLo&ab_channel=ThomasJadallah

My experiment 📟 Game Crash with JB ?Why? JB Type: unc0ver iOS Version : 13.3 When run game after 10s crash Start searching… Found when stopped AnoSDK..info its work good , but later will get 10m ban caz of data not send. 🚧 So we know it’s about player device info such fingerprints or jailbreak.. Later found its ok if you play with clean device with jailbreak .. ‼️ So they not block jailbreak itself but some tweaks not allowed , and sometimes collecting device fingerprints in somehow get crash of it . And sometimes JB will not allowed at all. So no stable rule 😂. Then tried to clean device from all tweaks and not work .. someone found the function on Angos that make crash . Then I patched it but in game ban 10y caz of integrity check .. The solution: 1- Install Kernbypass (with its cmd’s) and activate on target app. 2- install tweak like A-Bypass or Shadow and activate it on target app. You may face some issues on installing above tweaks.. if you’re interesting: later will shows all installations solutions here.

Hey note that : If you Hooking using fish hook _dyld_image_count and _dyld_get_image_name to hide your injection , they may still detect you with Kernel level to validate dyld 😂. I haven’t checked that with PG but i have seen it in critical app 💰

⭕️If you beginner don’t read it. To start with bypass my own game BubgBattle : 1- bypass cracked version because of iOS resigning. 2- hide your injected framework. 3- hide your objc classes. Or obfuscate it with junk names. And wen goes in real dylib strip your dylib symbols 4- hide your hook method. (For example : if you using pre-hook method hide new section like __Hook__TEXT etc. if you use other also hide based on what you use. 📟📟📟📟 Generate new empty framework for testing. Test each step on real game. ( make other friend reports on you for fast results) If pass for several games move to next step 1 to 4 If you pass it successfully. You almost do it all. Next i will explain the rest. Use your brain and AI. If you’re in JB you will f*k all easy. * The step above not easy for beginners at all. If you’re go learn basics. * if you are Angos player who play with AnoSDK.. cases that not for you. Yes your method may work but not sold as point above. Why ? Caz its solve issue for its roots

🚧 Method 1: Professional and Organized • Very hard and needs deep analysis of the game’s data and behavior • You need to understand how the protection system actually works inside • Takes a long time and requires strong skills in reverse engineering and memory analysis • Usually needs a full team (analysis, tools, testing, etc.) • It’s more expensive and needs organized, structured work • But the results are super accurate and solid — often survive even after game updates ⸻ 🚧 Method 2: Random or Trial-and-Error • Relies on basic or surface-level analysis, like tracking game strings or simple functions • You just try things directly, without really knowing how the whole system works • Sometimes it’s based on exploiting a small bug or temporary glitch • You can do it solo, without needing a team or advanced tools • Cheap and easy to start • But results are often temporary — a small update might break everything • It’s not reliable, and you might waste a lot of time with nothing to show ⸻ Sumup: Both methods have their place. If you want something strong and long-lasting, go for the professional route - even if it’s harder. But if you’re just testing or learning, the random method is a good start… just don’t expect it to last forever.

Today I’m gonna explain in a simple way what “heartbeat” means in iOS games, and how it’s used to detect cheating, hacks, or whatever you wanna call it. — What’s a heartbeat? It’s just signals or pings sent between the game and the server constantly, like every second or so. The point is to make sure the connection is still alive and that the player is playing normally, no messing around. — How do heartbeats work? When you first open the game, the server gives you a token (like a special ID for your session). Then, every few seconds, the game sends a message to the server like, “Hey, I’m still here and the token is fine.” The server checks that token, and if everything’s cool, you can keep playing. — So what happens if you stop the heartbeats? Let’s take Angos as an example: • The game sends stuff like launch data and other things to the server to be analyzed — like to catch aim bots or whatever. • If you stop or block these heartbeats (either by adding something, editing, or blocking the request), here’s what happens: 1. The server waits for the heartbeats for a set amount of time. 2. If nothing comes in, it starts getting suspicious, especially if you’re still moving and playing like normal. 3. It alerts the anti-cheat system, which kills your connection by canceling the token. 4. When the game tries to check the token again, it sees it’s invalid and kicks you out. 5. Now if you did some patching and matched the hash, you just bypassed detection — because you replaced the sketchy data with clean legit data. Except for that last part, you usually get a short ban (like 10 minutes), assuming it’s just a network hiccup. But if it keeps happening, the ban gets worse — could go all the way to a full-on 10-year ban. At that point, the system sees it as straight-up cheating, not just lag. — There’s another trick some players try: Some people go into the game itself and modify it so: • It blocks incoming heartbeats from the server. • The game keeps working like normal, and the server doesn’t realize it’s missing the signals. Some of you might remember people using fishhook and binding it to a button — that method blocks both directions, send and receive. What happens? You can play fine with no ban… for a while. But devs got smarter now. If the game doesn’t get heartbeats for a certain amount of time, it crashes — either freezes or just kicks you out. Bottom line: In that case, some folks go in and patch the crash or exit — and yeah, the hack works. But like I said earlier, it depends on how the patch is done and how tough the game’s protection is. Note: Some people use offsets or hooks and patch the crash, but still get hit with a crash later during gameplay. That’s either because the patch was wrong, or it worked but they forgot to stop the crash function — like I said before, you need another patch just to kill that crash process. — To wrap it up: • Heartbeats are super important in any online game — it’s how they track what’s going on. • If you mess with them the right way, you can get some crazy results. • But anti-cheats these days watch heartbeats super closely, and if stuff gets weird too often, you’re eating a fat 10-year ban. I only gave launch data as an example. Same thing applies to device info, player movement, and more. Tried to break it down as simple as possible, without fancy words. All based on testing and personal digging. If I missed something, my bad.

Injection Detection Checklist (iOS Runtime) “Scan loaded dylibs, check symbols, detect Frida/Substrate, and validate segment protections.” 1. DYLD & Image Inspection • DYLD_INSERT_LIBRARIES env var ≠ nil • Sign of Frida or dylib injection. • Loop over dyld_image_count() → dyld_get_image_name() • Flag anything outside system paths: /System/Library/, /usr/lib/ • Examples to detect: • /Library/MobileSubstrate/ • /usr/lib/frida/ • /var/containers/Bundle/ (non-App Store bundle) • Compare loaded image names against whitelist or hash known-good list. 2. Symbol Hooking Detection • Use dladdr() or dlsym() to get symbol addresses: • Compare runtime address of critical functions (e.g. malloc, objc_msgSend) with expected location. • Detect symbol redirection: • Check if objc_msgSend, UIApplicationMain, or mach_vm_write have been hooked (Frida/Substrate). 3. Segment/Page Protections • Use vm_region() or mprotect() to scan pages: • Look for writable and executable pages (RWX) → sign of shellcode/injection. • Check Mach-O segments: • __TEXT, __LINKEDIT, __DATA should match original protections and sizes. • Unusual segments or entitlements may indicate injected frameworks. 4. Frida Detection (Known Methods) • Look for Frida server port (default: 27042, 27043): • Try connect() to localhost:27042. • Scan loaded symbols for: • frida-agent, gum-js-loop, Interceptor, etc. • Scan memory or loaded images for “Frida” string. 5. Substrate / Tweak Detection • Check for Substrate dylibs: • /Library/MobileSubstrate/MobileSubstrate.dylib • Or scan for known tweak dylibs (.dylib in /Library/ or /var/) • Use objc_getClassList() to look for suspicious classes: • Tweak classes often follow patterns like Tweak_, Sub_, Frida_. 6. Jailbreak or Toolkits (as injection enablers) • Cydia.app path • apt, dpkg, bash, /etc/apt • Sandbox escape detection (write to system paths) ⸻ More Advanced Checks • Syscall Tampering: Verify behavior of ptrace, sysctl, task_for_pid • Timing Side-Channels: Detect overhead from hooking • Checksum of key memory pages at runtime

When resign app how they detected ? Also if injected . 1. On-Device (App-Side) • NSBundle.mainBundle.codesignature vs. stored/original: • Validate entitlements, team ID, provisioning profile presence, etc. • Detect MobileProvision: • Should not exist in App Store builds. Presence = resigned. • Check DYLD_INSERT_LIBRARIES: • Should be empty or undefined. Else: possible injection (e.g., Frida). • Mach-O Segment Inspection: • Ensure __TEXT, __LINKEDIT not patched (manual or via checksum). • Jailbreak Paths: • /bin/bash, /Applications/Cydia.app, /Library/MobileSubstrate/, etc. ⸻ 2. Server-Side Fingerprints • App Binary Hash: • When app launches, compute a hash (e.g. SHA-256 but PB they use CRC) of the binary and send to server for validation. • Bundle ID + Team ID: • Bundle ID spoofing is rare but possible. Team ID is more frequently altered in resigns. • Device Environment Flags: • Capture jailbroken status indicators or hooked symbols (e.g., dlopen, ptrace, sysctl tampering).

BGMI 3.8

GUObject: 0x109a29ba8
GName Function: 0x104256e0c
GName Data: 0x1095a5b90
GWorld Function: 0x10247042c
GWorld Data: 0x109c3fe60
//shared from @Bubg_dev
By @saudgl