WELCOME TO INFOCHEATS.NET

INFOCHEATS is a community-driven platform focused on free game cheats, cheat development, and verified commercial software for a wide range of popular games. We provide a large collection of free cheats shared by the community. All public releases are checked for malicious code to reduce the risk of viruses, malware, or unwanted software before users interact with them.

Alongside free content, INFOCHEATS hosts an active marketplace with many independent sellers offering commercial cheats. Each product is discussed openly, with user feedback, reviews, and real usage experience available to help you make informed decisions before purchasing.

Whether you are looking for free cheats, exploring paid solutions, comparing sellers, or studying how cheats are developed and tested, INFOCHEATS brings everything together in one place — transparently and community-driven.

Question Roblox — Locating _G Globals Table on lua_State (Build version-26c90be22e0d4758)

byte_corvus

Newbie
Newbie
Newbie
Newbie
Status
Offline
Joined
Mar 3, 2026
Messages
546
Reaction score
7
Anyone currently digging into the latest Roblox internal builds?
Working on a UNC executor against the version-26c90be22e0d4758 build. Module stomping via SEC_IMAGE into mfcore.dll is hitting correctly. The L acquire through the ScriptContext to ExtraSpace chain is perfectly stable (L+0x18 -> global validates), but I'm hitting a wall with the globals table.

The Blocker
Currently unable to locate the _G Table to register new UNC functions via luaH_set. The internal structure seems to have shifted or I'm misinterpreting the pointer chain.

  1. L+0x48 (Upstream LuaState::gt) — The pointer reads fine, but the first byte is 0x00, not 0x06 (LUA_TTABLE).
  2. index2adr(L, -10002) at RVA 0x41B0950 — This returns a TValue whose value field points to global_State (G), NOT the _G Table.
  3. Closure.env (+0x10) check — Testing across 13 discovered CClosures shows env=0 or env with tt=0x00.

Current Progress & Technical Stack
Despite the gt issue, the following offsets and functions are already resolved and verified:
  1. ptrenckey offset:
    Code:
    0x4B8
  2. luaF_newCclosure, luaS_newlstr, luaH_set/setstr logic.
  3. Core struct offsets for Closure, TValue, Proto, and TString.

The dumper is failing to resolve lua_setfield and lua_pushcclosurek because the standard "not enough memory to allocate C closure" anchor is stripped from .rdata. Surviving anchors include: "_VERSION", "The metatable is locked", "delay function requires", and "attempt to index".

Technical Questions for the RE Crowd
  1. Where is gt sitting on the lua_State in this specific build? Has it moved from 0x48?
  2. Is there a more reliable path to reach _G from the current known offsets?
  3. Does anyone have a fresh signature for lua_setfield or lua_pushcclosure for this version?

I'm happy to drop the full list of offsets I've successfully dumped if we can get this global table resolved. Drop your findings or crash logs if you're hitting the same segment.
 
Top