[platform] support Linux WMPF 4067695881 (WeChat 4.1.13.9, flatpak) - #272
Open
lnehc wants to merge 1 commit into
Open
[platform] support Linux WMPF 4067695881 (WeChat 4.1.13.9, flatpak)#272lnehc wants to merge 1 commit into
lnehc wants to merge 1 commit into
Conversation
- select the root WeChatAppEx process by checking that its parent is not another WeChatAppEx process; newer builds spawn zygote/renderer/ gpu/utility children whose ppid points at intermediate nodes, so the ppid frequency heuristic could pick a non-root process - fall back to --client_version from /proc/<pid>/cmdline when the embedded ",x.y.z.<version>" literal is missing; the 4.1.13+ runtime no longer contains it, which made findWmpfProcess throw "[frida] error in find wmpf version" - resolve sandbox paths reported by frida (/app/extra/wechat/...) to host paths via /proc/<pid>/root so version detection works when the target runs inside flatpak/bwrap - add addresses.4067695881.json for WeChat 4.1.13.9 (client_version 4067695881) Offsets were derived with a small static-analysis toolchain (rip-rel xref scan + .eh_frame_hdr function boundaries) that was validated by reproducing every value in addresses.14978.json exactly on the known-good 14978 binary (WeChat 4.1.1.8) before being applied to the new binary. Verified end-to-end on flatpak com.tencent.WeChat 4.1.13.9: OnLoadStart fires and rewrites scene 1027 -> 1101, the CDP filter hook patches repeatedly, and DevTools connects.
evi0s
reviewed
Sep 11, 2026
| const relativePath = sandboxPath.slice("/app/".length); | ||
| const flatpakAppRoots = [ | ||
| path.join(os.homedir(), ".local/share/flatpak/app"), | ||
| "/var/lib/flatpak/app", |
Owner
There was a problem hiding this comment.
will this raise permission denied if the process is started by a non-root user?
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Support the Linux WMPF runtime shipped with WeChat 4.1.13.9 (tested with flatpak
com.tencent.WeChat).src/platform/linux.tsWeChatAppExprocess by checking that its parent is not anotherWeChatAppExprocess. Newer builds spawn zygote/renderer/gpu/utility children whose ppid points at intermediate nodes, so the ppid frequency heuristic can pick the wrong process (same root cause as [platform] fix linux findWmpfProcess to select root process #271).--client_versionfrom/proc/<pid>/cmdlinewhen the embedded,x.y.z.<version>literal is missing. The 4.1.13+ runtime no longer contains that literal, which madefindWmpfProcessthrow[frida] error in find wmpf version. Old runtimes still match the literal first, soaddresses.14978.jsonkeeps working (version key viaclient_versionfollows the proposal in [Feature Request] Support for Linux WMPF (WeChat Linux Desktop) #167)./app/extra/wechat/...) to host paths via/proc/<pid>/root(works for flatpak/bwrap), so the binary can be read for version detection.frida/config/linux/addresses.4067695881.json(new){ "Version": 4067695881, "LoadStartHookOffset": "0x900eee0", "CDPFilterHookOffset": "0xdc1c670", "SceneOffsets": [56, 1528, 8, 1464, 16, 456] }How the offsets were derived
Built a small static-analysis toolchain (rip-relative xref scan +
.eh_frame_hdrfunction boundaries, stdlib only) and validated it against the known-good 14978 binary (WeChat 4.1.1.8, sha256c9765e87...as pinned by the flathub manifest) before applying it to the new binary:SendToClientFilterstring xref -> function0xBCB4C400xdc25cd0call, thencmpl $0x6,0x8(%rax)0xBCAAFD00xdc1c670applet_index_container.ccfull-path xref ->OnLoadStart0x83201800x900eee0OnLoadStarttailtest %r14b; mov 0x38(%rbx); mov 0x50(%rbx); mov 0x550(%rax); mov 0x38(%rcx); calltest %r14b; mov 0x38(%rbx); mov 0x40(%rbx); mov 0x5f8(%rax); mov 0x38(%rcx); callSceneOffsets)+8, +0x520, +0x10, cmpl $0x44d,0x1e8->[56,1360,8,1312,16,488]+8, +0x5b8, +0x10, cmpl $0x44d,0x1c8->[56,1528,8,1464,16,456]0x44d= 1101: both runtimes compare the scene value against the debug scene themselves - exactly the value this hook forces.Verified
com.tencent.WeChat4.1.13.9 (--client_version=4067695881), Linux x86_64[hook] scene: 1027(rewritten to 1101) and[patch] CDP filter patchedfires repeatedlydevtools://devtools/bundled/inspector.html?ws=127.0.0.1:62000Note: partially overlaps with #271 (root process selection) - happy to rebase or split if preferred.