Onveilige Relocation Fixups in Asset Loaders

Tip

Leer en oefen AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Leer en oefen GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Leer en oefen Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Ondersteun HackTricks

Waarom asset-relocations saak maak

Baie legacy game engines (Granny 3D, Gamebryo, ens.) laai komplekse assets deur:

  1. Ontleed ’n header en section table.
  2. Ken ’n heap-buffer per afdeling toe.
  3. Bou ’n SectionArray wat die basispointer van elke afdeling stoor.
  4. Pas relocation-tabelle toe sodat pointers ingebed binne die section-data gepatched word na die regte teiken-afdeling + offset.

Wanneer die relocation-handler blindelings op aanvaller-beheerde metadata vertrou, word elke relocation ’n potensiële arbitrary read/write primitive. In Anno 1404: Venice, granny2.dll lewer die volgende helper:

`GrannyGRNFixUp_0` (ingekort) ```c int *__cdecl GrannyGRNFixUp_0(DWORD RelocationCount, Relocation *PointerFixupArray, int *SectionArray, char *destination) { while (RelocationCount--) { int target_base = SectionArray[PointerFixupArray->SectionNumber]; // unchecked index int *patch_site = (int *)(destination + PointerFixupArray->SectionOffset); // unchecked offset *patch_site = target_base ; if (target_base) *patch_site = target_base + PointerFixupArray->Offset; ++PointerFixupArray; } return SectionArray; } ```

SectionNumber word nooit range-checked en SectionOffset word nooit teen die huidige section size gevalideer. Deur relocation entries met negative offsets of oversized indices te skep, kan jy buite die section wat jy beheer beweeg en allocator metadata soos die section pointer array self oorstamp.

Stage 1 – Writing backwards into loader metadata

Die doel is om die relocation table van section 0 entries van SectionContentArray te laat oorskryf (wat SectionArray weerspieël en reg voor die eerste section buffer gestoor word). Omdat Granny’s custom allocator 0x1F bytes aan die voorkant voorvoeg en die NT heap sy eie 0x10-byte header plus alignment toevoeg, kan ’n aanvaller vooraf die afstand bereken tussen die begin van die eerste section (destination) en die section-pointer array.

In die getoetste build veroorsaak dit dat, deur die loader te dwing om ’n GrannyFile strukture van presies 0x4000 bytes te allokeer, die section-pointer arrays net voor die eerste section buffer land. Om dit op te los

0x20 (header) + 0x20 (section descriptors)
+ n * 1 (section types) + n * 1 (flags)
+ n * 4 (pointer table) = 0x4000

gee n = 2720 sections. ’n herlokasie-inskrywing met SectionOffset = -0x3FF0 ( 0x4000 - 0x20 - 0x20 + 0x30 ) los nou op na SectionContentArray[1] al dink die bestemmingsafdeling dat dit interne pointers patch.

Fase 2 – Deterministiese heap-indeling op Windows 10

Windows 10 NT Heap stuur toewysings ≤ RtlpLargestLfhBlock (0x4000) na die gerandomiseerde LFH en groter eenhede na die deterministiese backend allocator. Deur die GrannyFile metadata effens bo daardie drempel te hou (met die 2720 sections truuk) en verskeie kwaadwillige .gr2 assets voor te laai, kan jy:

  • Toewysing #1 (metadata + section pointer arrays) laat land in ’n >0x4000 backend chunk.
  • Toewysing #2 (section 0 contents) laat land onmiddellik na toewysing #1.
  • Toewysing #3 (section 1 contents) laat land reg ná toewysing #2, wat ’n voorspelbare teiken vir volgende herlokasies gee.

Process Monitor het bevestig dat assets op aanvraag gestroom word, so herhaaldelike versoeke vir vervaardigde units/buildings is genoeg om die heap-indeling te “prime” sonder om die uitvoerbare image aan te raak.

Fase 3 – Om die primitief in RCE te omskep

  1. Corrupt SectionContentArray[1]. Section 0 se relocation table oorskryf dit deur die -0x3FF0 offset te gebruik. Rig dit na enige skryfbare area wat jy beheer (bv. later section data).
  2. Recycle the corrupted pointer. Section 1 se relocation table behandel nou SectionNumber = 1 as watter pointer ook al jy ingesit het. Die handler skryf SectionArray[1] + Offset na destination + SectionOffset, wat jou ’n arbitraire 4-byte write gee vir elke herlokasie-inskrywing.
  3. Hit reliable dispatchers. In Anno 1404 was die gekose teiken die granny2.dll allocator callbacks (geen ASLR, DEP gedeaktiveer). Deur die function pointer wat granny2.dll vir die volgende Malloc/Free oproep gebruik oor te skryf, lei dit onmiddellik uitvoering na aanvaller-beheerde kode wat van die getrojaniseerde asset gelaai is.

Omdat beide granny2.dll en die ingespuite .gr2 buffers op stabiele adresse woon wanneer ASLR/DEP gedeaktiveer is, reduseer die aanval na die bou van ’n klein ROP chain of rou shellcode en die callback daarheen wys.

Praktiese checklys

  • Soek asset loaders wat SectionArray / relocation tables handhaaf.
  • Diff relocation handlers vir ontbrekende grense op indekse/offsets.
  • Meet die allocator headers wat deur beide die spel se allocator wrapper en die onderliggende OS heap bygevoeg word om terugwaartse offsets presies te bereken.
  • Dwing deterministiese plasing deur:
    • metadata te verhoog (baie leë sections) totdat die toewysingsgrootte > RtlpLargestLfhBlock;
    • herhaaldelik die kwaadwillige asset te laai om backend-gate op te vul.
  • Gebruik ’n twee-stadium relocation table (eers om SectionArray te herrig, dan om writes te spray) en oorskryf function pointers wat tydens normale rendering sal afgevuur word (allocator callbacks, virtual tables, animation dispatchers, ens.).

Sodra jy ’n arbitraire file write kry (bv. via die path traversal in die multiplayer save transfer), gee die herverpakking van RDA archives met die gemaakte .gr2 jou ’n skoon afleweringsvektor wat outomaties deur remote clients gedekomprimeer word.

Verwysings

Tip

Leer en oefen AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Leer en oefen GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Leer en oefen Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Ondersteun HackTricks