fix(profiles): set MediaTek phys addresses for 6.1.157-android14-11-ga8b0b542991e

[drybrine]

The profile merged in #244 leaves kernel_phys_load / kernel_phys_offset at null. On this kernel the MediaTek fallback derivation resolves to 0x80000000 for the load while phys_offset keeps the Qualcomm P0_PHYS_OFFSET = 0x80000000, so the difference is 0 — correct, but only by coincidence, and the extractor refuses to confirm it:

$ ghostlock-extract boot.img --format conf --out out.conf
info: kallsyms layout pre-6.4 recovered (102601 symbols)
info: (CVE-2026-43499 primitive present (remove_waiter@0x1018844 still uses current)
warning: _text=0xffffffc008000000 does not match the mtk DRAM-base mapping;
         kernel_phys_load left unset so the runtime derives it (pass --phys to override)

Setting both fields explicitly pins the mapping to the measured values instead of relying on that coincidence.

Change

kernel_phys_load   = 1073741824   # 0x40000000
kernel_phys_offset = 1073741824   # 0x40000000

Only the difference reaches the translation (direct = (kernel_phys_load + image_offset - kernel_phys_offset) | P0_PAGE_OFFSET), so delta = 0 and the direct-map alias of an image offset is simply PAGE_OFFSET + offset. This is the MediaTek DRAM-base mapping (text_offset = 0) that tools/extract_rs/src/boot.rs describes: this kernel places _text at MTK_VADDR_BASE + 0x08000000 in the virtual layout, which is what makes the VA-based check above warn, but its physical load offset is 0, not 0x08000000.

Evidence

Device: Infinix X6879, MT6788, kernel 6.1.157-android14-11-ga8b0b542991e-ab15601211 (identical uname -r to the profile).

From /sys/fs/pstore/console-ramoops-0, identical in 33/33 OOPS:

Kernel Offset: 0x22e4c00000 from 0xffffffc008000000
PHYS_OFFSET: 0x40000000

Runtime log from a run on this kernel with both fields at 0x40000000:

[*] p0 kernel_phys_load=0000000040000000 phys_offset=0000000040000000 delta=0000000000000000
[*] === W1: write === target=0xffffff800225b820 value=0x0000000000000000 mode=3
...
[*]   cfg-root: task=0xffffff81351d12c0 init_cred=0xffffff8002031aa8
[*]   cfg-root: real_cred write=8 cred write=8 (orig real=0xffffff80055d8600 cred=0xffffff80055d8600)
[*]   cfg-root: uid=0 euid=0 gid=0
[+]   *** ROOT: uid=0 via task->cred = init_cred ***
uid=0(root) gid=0(root) groups=0(root) context=u:r:kernel:s0

selinux_enforcing (+0x225B820) resolving to 0xffffff800225b820 and init_cred (+0x2031AA8) resolving to 0xffffff8002031aa8 are both PAGE_OFFSET + offset, i.e. delta = 0. With delta = 0x08000000 (the _text VA - MTK_VADDR_BASE assumption) those same writes resolve to 0xffffff800a25b820 and 0xffffff800a031aa8 and miss the targets by 128 MB.

All nine offset.* values in this profile were re-checked against the 102601-symbol kallsyms table recovered from the device's own boot.img by the in-tree extractor and match.

Scope and non-claims

• Only the two phys fields changed; route, offset, task_struct and the include lines are untouched.
• empty_zero_page stays null (only the multicast_waiter route needs it).
• Not claimed: that the tcp_zerocopy primary route is exercised on this SoC. Our on-device verification went through the select_stack fallback (waiter_shift = 1), which the extractor also rates high for this image. I left the route block as merged rather than changing it here.
• No SUPPORTED_DEVICES.md row is added in this PR; I can send that separately with the full log if you want it.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[drybrine]

Device-side evidence for the values this PR pins. ReSukiSU reports the manager up with the KernelSU LKM late-loaded on the exact kernel this profile targets:

Read from the screenshot:

• Device model: Infinix NOTE 60 (X6879, MT6788)
• Kernel Version: 6.1.157-android14-11-ga8b0b542991e-ab15601211 — identical to the profile in this PR
• Android version: 16
• Kernel driver version: v4.2.0-rc3-8770c7e3@ReSukiSU (35203/5)
• Manager Version: v4.2.0-rc3 (35203/5)
• Status: Working · LKM · Jailbreak mode, SuperUser: 2, Modules: 1

How this connects to the two lines in this PR: the credential stage of the run resolved init_cred through the linear map to 0xffffff8002031aa8, i.e. PAGE_OFFSET + 0x2031AA8, and the resulting process reported uid=0. That is delta = 0 — the value pinned here. With the _text VA - MTK_VADDR_BASE assumption (delta = 0x08000000) the same write resolves to 0xffffff800a031aa8 and misses by 128 MB, which is why the profile should not rely on the fallback derivation.

Root here came from the exploit, not from a patched boot image: the bootloader stays locked and boot.img is untouched. The module is late-loaded from the exploit's root context and is not persistent — a reboot drops it and the chain is re-run.

I have deliberately not added a SUPPORTED_DEVICES.md row in this PR. If you want one for this device, say the word and I will send it separately with the full run log.

[drybrine]

Superseded by #315, which carries the same value fix plus the runtime evidence from a real run on Infinix X6879 (MT6788): the resolver reports kernel_phys_load=0x40000000 with delta=0, and the direct-map alias of init_cred resolves to 0xffffff8002031aa8.

Closing this one so there is a single PR for the change. Thanks for taking a look.