Quote:
Originally Posted by MalwareEnjoyer
are you doing kernel? I think you are foucsing on the wrong thing. Idk what step you at but doing cr3 isnt useful. You need to go into kernel drivers or at least something that can be applied universally.
Doing cr3 cant be applied to everything. 2ndly, this would fall under a bypass but isn't really a bypass anymore and is just the standard.
kernel mapping is what you wanna know 100%
what are you even working on right now?
writing in advance:
learn driver entries, you can normally see whats happening in 2s and know if its exploitable in 2s. If you look at this and know why its exploitable you in a good area but if not. id drop cr3 and move to drivers and x64 arch:
[Only registered and activated users can see links. Click Here To Register...]
[Only registered and activated users can see links. Click Here To Register...]
[Only registered and activated users can see links. Click Here To Register...]
i know its kinda messy but yeah.
this driver is good for small projects off kdmapper. its safe to run alongside without issues. You can download the driver from dirctio.
if you wanna look into it, thus far ive only got and fixing
0x8011E044, 0x8011E048, 0x8011E04C, 0x8011E050,
0x8011E060, 0x8011E064, 0x8011E068, 0x8011E074,
0x8011E080, 0x8011E084, 0x8011E088, 0x8011E08C,
0x8011E090, 0x8011E094, 0x8011E098, 0x8011E09C,
0x8011E0A0, 0x8011E0A4, 0x8011E0A8,
0x80116054, 0x80116058, 0x8011605C, 0x80116078, 0x8011607C,
0x8011B941
[Only registered and activated users can see links. Click Here To Register...]
doesn't matter really. its like buying clothing. same same
[Only registered and activated users can see links. Click Here To Register...]
|
Basic ESP, DMA Only(GoodFirmware)
/ Fuser/ MAKBox/Kmbox--Will look at this after ESP
Gaming PC runs:
- Game.exe
- Entitas ECS / Il2Cpp runtime
- HDCamera, PositionComponent, ItemDataContext
- GameAssembly.dll (GameContextModule)
- ScanMacro.ahk (auto-move input)
|
Radar PC runs:
- GameECSReader.exe
- VAD heap scan (decoy DTB)
- klass-heap scan (true CR3 phys)
- TypeInfo read (true CR3 phys)
- Upgrade/harvest (class name verify)
- Hot refresh (WorldVector blob)
- client.exe (imgui overlay)
- reads loot_snapshot.json + view_proj matrix → W2S → screen render
No injection. No hooks. No driver. FPGA reads physical memory. Page tables translate.
But yes, Short answer: true CR3 was never the full key but a door to a few more doors. It’s a proof path for when AC splits PE page tables from heap/process DTB.
The VM method was built so after a restart you can:
1. Find Game
2. Get live GA VA + PA
3. Hunt a CR3 that phys-walks that GA with MZ
4. Pin that as SANDECS_DTB / true, keep decoy for heaps
That’s the soft unlock: not permanent, but a reproducible attach after every Game launch.
So what was the point?
Value of true-CR3 / VM method:
Re-find Game + GA after every new PID
Prove PE with MZ (no phantom identity)
Know when dual-DTB is real vs collapsed
When true does walk GA, PE/TypeInfo can be cleaner under AC
Avoid soft-harvest / wrong GA
true CR3 I'm using it to prove decoy is the PE owner this time instead of guessing dead pins from the old PID.
Updated:
HARD_ENTITY
found through verified managed heap object headers , the object has a valid klass pointer (at offset +0x00 → +0x08 → +0x10 klass chain) to a known class name ( "PositionComponent" or "ItemData") via TypeInfo
HD VP =from_hd=true, hd_camera set
live eye=LIVE_CAM while walking (dCamXZ 5–25m)
space lock=player_xyz = cam_xyz
distance=Nearest piles ~9–25m list sorted by eye
Where I go from here?
PHYS_SPINE attach path
Dense ENTITY loot
Dual-DTB upgrade
Biggest issue is a stale GA_PA, I'll include it as a gate and pin field, not as an addressing mode.