Dynamic analysis 44 273 WeChat and 2 721 Baidu Mini-Programs revealed 1 834 cases of implementation curve of OAuth-like authorization - 619 applications contained a combination of several holes simultaneously (Shi et al., "MiniCAT: Understanding and Detecting Outhe Access Control Threats in Mini-Programs", USENIX Security 2024). Among the victims are state services and medical Mini-Programs, through which national IDs and medical records of Chinese citizens were leaked. The results are confirmed by the assignment of CNVD/CNNVD identifiers (specific IDs are not disclosed publicly).
In the Russian-speaking space, this theme is a white spot. All existing materials are spinning around the standard OAuth 2.0: redirect_uri bypass, token theft via Slack and Facebook - a general overview of these and other authentication compromising techniques is collected in Manuals on Authentication Attacks. But the proprietary protocol of super-applications is a completely different beast, and no one disassembled it. Below are three specific account takeover vectors in WeChat Mini-Programs: from the threat model to PoC logic and dynamic analysis tools.
How to get authorization in WeChat Mini-Programs and why it’s not standard OAuth 2.0
The developers are accustomed to name the entry mechanism into Mini-Programs "OAuth", but this is misleading. WeChat uses a proprietary protocol - OAuth-based Authentication (OBA), and it is fundamentally different from RFC 6749.
The classic OAuth 2.0 stream involves three parties: Resource Owner, Authorization Server and Client Application. The client receives a authorization code through redirect_uri, exchanged it for access_token with the help of client_secret and then goes with the token to the API of the resource server. Basic attack surface - manipulation redirect_uri (Open Redirect -> Token Theft), absence or predictability state-parameter, weak validation of PKCE.
WeChat Mini-Programs architecture is different. Mini-Program is performed inside the already authenticated super-application (Tentent for Q3 2024 report - about 1.38 billion combined MAU Weixin/WeChat). Workflow OBA:
1. Frontend Mini-Program calls wx.login(), getting temporary one-time code(not authorised code in terms of OAuth 2.0 - it has another lifecycle)
2. Backend of the developer sends codetogether with appidand appsecretthe WeChat Endpoint code2Session(server-to-server)
3. WeChat returns openid(a unique user ID within a specific Mini-Program), unionid(identifier within all applications of one developer) and session_key(Tensize cryptographic key to decrypt user data)
4. Backend of the developer creates a session and sends the front-end session token
Critical Difference: redirect_uri No here - Mini-Program lives inside WebView super-apps. Standard OAuth Audit Notes (test redirect_uri, state, PKCE) is useless. Attack surface shifts to processing session_key and openid on the backend side of the developer, client-server interaction between the front-end Mini-Program and the developer server, as well as cryptographic operations with user data.
The proprietary nature of the protocol makes WeChat OBA a blind spot for those accustomed to the standard OAuth 2.0. And this is not an academic problem - it's a real attack surface that few people check.
Threat model: who attacks and what is available to him
[Applicable: external min-Program, black-box / bug booty]
Before analyzing the vectors - a model of threats. The attacker is in the position of an external researcher without access to the developer’s server infrastructure.
The attacker can: create your own Mini-Program and get appid/appsecret; intercept HTTPS traffic between the victim’s Mini-Program front and developer backend (through mitmproxy/Burp Suite with a configured trust store on a reprouted device); analyze and modify the client’s Mini-Program client code (through WeChat Devols or jadx for debfusion); squeeze arbitrary requests to API.
The attacker cannot (with correct implementation): Intercept traffic between developer backend and WeChat servers (server-to-server call code2Session); forge code from wx.login() - it is one-time, TTL about 5 minutes according to the code2Session documentation, tied to appid Mini-Program and the session wx.login(), validated after the first call code2Session (re-call returns errcode 40163 - code is used, see sc.weixin.qq.com/miniprogram/dev/ip-ibackend/open-api/enjob/in/a. session_key directly from WeChat without knowledge appsecret.
The whole attack surface occurs due to errors on the side of third-party developers, not the WeChat platform. The platform provides API - developers implement them crookedly. The fundamental difference from standard OAuth vulnerabilities, where the problem is often in the Authorization Server itself.
Vector 1 - Client-Side Identity Forgy: leaking credentials to frontend
Essence: Backend of the developer returns openid and/or session_key directly in the HTTP answer to the front-end Mini-Program. The attacker intercepts this data and exposes openid Victim for authorization under someone else's account.
The Vulnerability Mechanics. In the correct implementation of the challenge code2Session is server-to-server: backend receives openid + session_key from WeChat, creates a session and returns the frontend of only the opaque session token (cookie or JWT). The frontend never sees openid, neither session_key.
In vulnerable implementation, the backend leaks this data directly in the body of the answer:
JSON:
{
"status": "ok",
"openid": "oXyz123abc456def789",
"session_key": "tK8dN2sLm...",
"user_token": "eyJhbGciOi..."
}
When I first saw this in traffic, I didn’t believe it. But according to MiniCAT, this is the most common vector of three.
Chain of operation. The attacker launches the target Mini-Program, logs out and intercepts its own openid from the answer. In further requests to API, the backend sees that openid is transmitted as an authentication parameter (in the POST or query-parameter). Substitution of someone else openid leads to authorization on behalf of the victim - if the backend does not tie openid to the server session, the request passes without additional checks.
Predictions: backend transmits openid on the frontend in response to the login request; openid used as the only user identifier without reference to the server session; there is no additional verification (request signature, binding to the device fingerprint).
When the technique is NOT working: the developer has implemented a server session management and does not disclose openid client; Mini-Program does not have its own backend (purely static information applications); backend checks code with each request, and does not rely on the previously received openid.
By MITRE ATT&CK - A combination of Steal Application Access Token (T1528, Credential Access): Interception openid/session_key from traffic, and Valid Accounts (T1078): Use of the stolen identifier as validation accounts.
Vector 2 - Static identifiers and permanent account capture
Essence: Mini-Program uses a static identifier for authentication (openid or unionid) instead of the dynamically generated session token. The attacker, once upon a time learning the victim’s identifier, gets permanent access to the account – without time limit.
openid does not change between sessions for one user in one Mini-Program. If the backend accepts openid directly as an authentication key (instead of a short session token), the attacker gets permanent access. In fact, an eternal password that cannot be changed.
The situation becomes worse when using unionid - an identifier in common for all Mini-Programs of one developer. Compromising unionid in one application gives access to all the applications of this developer. It's not just a takeover account - it's an object movement through Application Access Token.T1550.001) within the farm of one vendor.
Difference with Vector 1: in the first case, the problem is a leak openid through network traffic. The problem is deeper: even if openid received in a legitimate way (base leak, social engineering, intercepting the traffic of another Mini-Program of the same developer through unionid), the lack of rotation of sessions makes it the eternal key to the account.
Predictions: openid or unionid used as the only authentication factor; no server session with token rotation; the backend does not tie authentication to session_key (which is updated at every call wx.login())
When the technique is NOT working: the developer has implemented a normal session management with short-lived JWT/cookie, tied to session_key; backend requires fresh code from wx.login() with every critical effect; Mini-Program does not store user data.
By OWASP - A05:2021 Security Misconfiguration: architectural error when designing auth-flow.
Vector 3 - Cryptographic defect: session_key leak through Initialization Vector
Essence: Platform defect allows you to restore session_key through the analysis of Initialization Vector (IV) in encrypted user data. This opens the transcript of sensitive data (phone number, profile) and forgery of identity.
The Vulnerability Mechanics. When Mini-Program requests sensitive data (phone number through getPhoneNumber. profile information), WeChat returns them in encrypted form - AES-128-CBC session_key as a key. The data is transmitted together with encryptedData and iv.
In the correct cryptographic implementation, IV should be generated by chance and be independent of the key. The study found that on the Baidu platform (about 600-700 million MAU) IV Reuses part of session_key instead of generating a random value. What it means in practice: the attacker receives IV from the answer (it is transmitted openly), IV contains information about session_key, and the brute space for the restoration of the full key is significantly reduced. A beautiful wrapping fanatic - and inside the tip to the key. By OWASP - A02:2021 Cryptographic Failures.
For WeChat, the situation is somewhat better - IV is generated separately from session_key. But if session_key The leak through Vector 1, the attacker decrypts all user data, including the phone number - and this is the vector for the account takeover through SMS-confirmation on other platforms or inside WeChat.
Predictions: for Baidu - access to encrypted data from IV (traffipation); for WeChat - leakage session_key through Vector 1 or 2; Mini-Program requests sensitive data (phone, profile).
When the technique is NOT working: defect with IV is found on Baidu, not on WeChat. For WeChat Mini-Programs, this vector only works in combination with leakage session_key - It is not exploited by itself. By MITRE AT&CK - Exploitation for Credential Access (T1212)
Comparison of vectors and place in kill chain
Kill line position. All three vectors run on Initial Access and Credential Access:
• Initial Access: T1190 (Exploit Public-Facting Application) - operation of a vulnerable Mini-Program backend
• Credential Access: T1528 (Steal Application Access Token) - Interception openid/session_key; T1212 (Explotication for Credential Access) - operation of crypto defect
• Lateral Movement: T1550.001 (Application Access Token) - use unionidto access other Mini-Programs of the same developer
• Persistence: T1078 (Valid Accounts) - static openidprovides constant access without rotation
What happens after account takeover? Capturing a Mini-Program account is not the end point. Depending on the functionality: financial Mini-Programs give access to the balance sheet and transactions, medical - to national IDs and medical records (confirmed by the study), state services - to personal data of citizens, e-commerce - to delivery addresses and related payment methods.
Cross-platform painting. Similar mys configurations are reproduced not only in WeChat, but also in Baidu, Alipay and TikTok Mini-Programs. This is a systemic problem of the superapplication environment, where the platform provides an API, and thousands of third-party developers with different levels of competence collect authorization independently.
Dynamic Analysis of Mini-Programs: Tools and Methodology
Adjustments to the environment:
• OS: Windows 10/11, macOS 12+, or Ubuntu 22.04+
• RAM: minimum 8 GB (16 GB is recommended for simultaneous operation of emulator and proxy)
• WeChat DevTools: current version (developers.weixin.quq.com)
• Burp Suite Professional >= 2024.x (Community Edition is limited in custom extensions for wx-payload)
• mitmproxy >= 10.x
• jadx >= 1.5 for decompiling obhocced JavaScript
• Python 3.10+ (requests, pycryptodome for working with AES)
• Android device with root or emulator (to intercept WeChat traffic)
• Network conditions: online (you need access to WeChat servers and backend of the tested Mini-Program)
Why Static Analysis Cannot Be Coped Researchers of the MiniCAT framework (Shi et al., USENIX Security 2024, USENIX Security '24) - one of the first specialized tools for large-scale analysis of OBA-misfoli - showed that static analysis of the JavaScript code Mini-Program (files .js, .wxml, .wxmss) misses most vulnerabilities for two reasons. The first is obfuscation: production Mini-Programs is mined, jadx restores the structure in part, but it is difficult to pull out the business logic of authorization from the static code. The second is runtime-nature of vulnerabilities: OBA-miconfigurations are manifested only when the client interacts with the server. What data backend returns in response to code2SessionHow to process openid with repeated authentication, this is only visible in traffic. SAST is dead.
Methodology of the manual pentest Mini-Program OBA:
1. Configuring proxy. On Android, installing a CA certificate in the system trust store requires root - Android 7+ with targetSdkVersion>=24 by default does not trust the user-installed CA (Network Security Config), and WeChat is collected with this limitation. Alternative: Frida script to disable SSL verification in WeChat runtime (works without a system store, but requires root/jailbreak). On iOS - configuration profile via Settings.
2. Identification of OBA Requests. Open the target Mini-Program and filter in the proxy queue logge containing parameters code, openid, session_key, encryptedData, iv. Marker OBA-flow - POST-request immediately after downloading Mini-Program with codefrom wx.login()in the body.
3. Leakage check (Vector 1). Analyze the backend response to the login-request. If there are keys in JSON openidor session_key- vulnerability is confirmed. Automation via mitmproxy addon:
Python:
from mitmproxy import http
import json
def response(flow: http.HTTPFlow):
if not (flow.response and flow.response.content): return
try:
data = json.loads(flow.response.content)
leaked = {k: data[k] for k in ("openid","session_key","unionid") if k in data}
if leaked: print(f"[OBA LEAK] {flow.request.url}: {leaked}")
except: pass
1. Substitution testing (Vector 2). In Burp Repeater repeat the request for reasonable authentication openid. If the server returns the data of another user without additional checks - Vector 2 is confirmed.
2. Verification of cryptography (Vector 3). If Mini-Program requests a phone number - intercept encryptedDataand iv. Compared IV between sessions: static IV or correlation with session_keyindicates a cryptographic defect.
Limitations of the tools: WeChat DevTools allows you to run Mini-Program in debugging mode, but does not emulate a full OBA-flow (there is no real wx.login()) For full testing, you need a real device with a WeChat installed one. Burp Suite Community Edition does not support custom extensions to decode WeChat specific payload - Professional version is required for a serious audit.
In the Russian-speaking space, this theme is a white spot. All existing materials are spinning around the standard OAuth 2.0: redirect_uri bypass, token theft via Slack and Facebook - a general overview of these and other authentication compromising techniques is collected in Manuals on Authentication Attacks. But the proprietary protocol of super-applications is a completely different beast, and no one disassembled it. Below are three specific account takeover vectors in WeChat Mini-Programs: from the threat model to PoC logic and dynamic analysis tools.
How to get authorization in WeChat Mini-Programs and why it’s not standard OAuth 2.0
The developers are accustomed to name the entry mechanism into Mini-Programs "OAuth", but this is misleading. WeChat uses a proprietary protocol - OAuth-based Authentication (OBA), and it is fundamentally different from RFC 6749.
The classic OAuth 2.0 stream involves three parties: Resource Owner, Authorization Server and Client Application. The client receives a authorization code through redirect_uri, exchanged it for access_token with the help of client_secret and then goes with the token to the API of the resource server. Basic attack surface - manipulation redirect_uri (Open Redirect -> Token Theft), absence or predictability state-parameter, weak validation of PKCE.
WeChat Mini-Programs architecture is different. Mini-Program is performed inside the already authenticated super-application (Tentent for Q3 2024 report - about 1.38 billion combined MAU Weixin/WeChat). Workflow OBA:
1. Frontend Mini-Program calls wx.login(), getting temporary one-time code(not authorised code in terms of OAuth 2.0 - it has another lifecycle)
2. Backend of the developer sends codetogether with appidand appsecretthe WeChat Endpoint code2Session(server-to-server)
3. WeChat returns openid(a unique user ID within a specific Mini-Program), unionid(identifier within all applications of one developer) and session_key(Tensize cryptographic key to decrypt user data)
4. Backend of the developer creates a session and sends the front-end session token
Critical Difference: redirect_uri No here - Mini-Program lives inside WebView super-apps. Standard OAuth Audit Notes (test redirect_uri, state, PKCE) is useless. Attack surface shifts to processing session_key and openid on the backend side of the developer, client-server interaction between the front-end Mini-Program and the developer server, as well as cryptographic operations with user data.
The proprietary nature of the protocol makes WeChat OBA a blind spot for those accustomed to the standard OAuth 2.0. And this is not an academic problem - it's a real attack surface that few people check.
Threat model: who attacks and what is available to him
[Applicable: external min-Program, black-box / bug booty]
Before analyzing the vectors - a model of threats. The attacker is in the position of an external researcher without access to the developer’s server infrastructure.
The attacker can: create your own Mini-Program and get appid/appsecret; intercept HTTPS traffic between the victim’s Mini-Program front and developer backend (through mitmproxy/Burp Suite with a configured trust store on a reprouted device); analyze and modify the client’s Mini-Program client code (through WeChat Devols or jadx for debfusion); squeeze arbitrary requests to API.
The attacker cannot (with correct implementation): Intercept traffic between developer backend and WeChat servers (server-to-server call code2Session); forge code from wx.login() - it is one-time, TTL about 5 minutes according to the code2Session documentation, tied to appid Mini-Program and the session wx.login(), validated after the first call code2Session (re-call returns errcode 40163 - code is used, see sc.weixin.qq.com/miniprogram/dev/ip-ibackend/open-api/enjob/in/a. session_key directly from WeChat without knowledge appsecret.
The whole attack surface occurs due to errors on the side of third-party developers, not the WeChat platform. The platform provides API - developers implement them crookedly. The fundamental difference from standard OAuth vulnerabilities, where the problem is often in the Authorization Server itself.
Vector 1 - Client-Side Identity Forgy: leaking credentials to frontend
Essence: Backend of the developer returns openid and/or session_key directly in the HTTP answer to the front-end Mini-Program. The attacker intercepts this data and exposes openid Victim for authorization under someone else's account.
The Vulnerability Mechanics. In the correct implementation of the challenge code2Session is server-to-server: backend receives openid + session_key from WeChat, creates a session and returns the frontend of only the opaque session token (cookie or JWT). The frontend never sees openid, neither session_key.
In vulnerable implementation, the backend leaks this data directly in the body of the answer:
JSON:
{
"status": "ok",
"openid": "oXyz123abc456def789",
"session_key": "tK8dN2sLm...",
"user_token": "eyJhbGciOi..."
}
When I first saw this in traffic, I didn’t believe it. But according to MiniCAT, this is the most common vector of three.
Chain of operation. The attacker launches the target Mini-Program, logs out and intercepts its own openid from the answer. In further requests to API, the backend sees that openid is transmitted as an authentication parameter (in the POST or query-parameter). Substitution of someone else openid leads to authorization on behalf of the victim - if the backend does not tie openid to the server session, the request passes without additional checks.
Predictions: backend transmits openid on the frontend in response to the login request; openid used as the only user identifier without reference to the server session; there is no additional verification (request signature, binding to the device fingerprint).
When the technique is NOT working: the developer has implemented a server session management and does not disclose openid client; Mini-Program does not have its own backend (purely static information applications); backend checks code with each request, and does not rely on the previously received openid.
By MITRE ATT&CK - A combination of Steal Application Access Token (T1528, Credential Access): Interception openid/session_key from traffic, and Valid Accounts (T1078): Use of the stolen identifier as validation accounts.
Vector 2 - Static identifiers and permanent account capture
Essence: Mini-Program uses a static identifier for authentication (openid or unionid) instead of the dynamically generated session token. The attacker, once upon a time learning the victim’s identifier, gets permanent access to the account – without time limit.
openid does not change between sessions for one user in one Mini-Program. If the backend accepts openid directly as an authentication key (instead of a short session token), the attacker gets permanent access. In fact, an eternal password that cannot be changed.
The situation becomes worse when using unionid - an identifier in common for all Mini-Programs of one developer. Compromising unionid in one application gives access to all the applications of this developer. It's not just a takeover account - it's an object movement through Application Access Token.T1550.001) within the farm of one vendor.
Difference with Vector 1: in the first case, the problem is a leak openid through network traffic. The problem is deeper: even if openid received in a legitimate way (base leak, social engineering, intercepting the traffic of another Mini-Program of the same developer through unionid), the lack of rotation of sessions makes it the eternal key to the account.
Predictions: openid or unionid used as the only authentication factor; no server session with token rotation; the backend does not tie authentication to session_key (which is updated at every call wx.login())
When the technique is NOT working: the developer has implemented a normal session management with short-lived JWT/cookie, tied to session_key; backend requires fresh code from wx.login() with every critical effect; Mini-Program does not store user data.
By OWASP - A05:2021 Security Misconfiguration: architectural error when designing auth-flow.
Vector 3 - Cryptographic defect: session_key leak through Initialization Vector
Essence: Platform defect allows you to restore session_key through the analysis of Initialization Vector (IV) in encrypted user data. This opens the transcript of sensitive data (phone number, profile) and forgery of identity.
The Vulnerability Mechanics. When Mini-Program requests sensitive data (phone number through getPhoneNumber. profile information), WeChat returns them in encrypted form - AES-128-CBC session_key as a key. The data is transmitted together with encryptedData and iv.
In the correct cryptographic implementation, IV should be generated by chance and be independent of the key. The study found that on the Baidu platform (about 600-700 million MAU) IV Reuses part of session_key instead of generating a random value. What it means in practice: the attacker receives IV from the answer (it is transmitted openly), IV contains information about session_key, and the brute space for the restoration of the full key is significantly reduced. A beautiful wrapping fanatic - and inside the tip to the key. By OWASP - A02:2021 Cryptographic Failures.
For WeChat, the situation is somewhat better - IV is generated separately from session_key. But if session_key The leak through Vector 1, the attacker decrypts all user data, including the phone number - and this is the vector for the account takeover through SMS-confirmation on other platforms or inside WeChat.
Predictions: for Baidu - access to encrypted data from IV (traffipation); for WeChat - leakage session_key through Vector 1 or 2; Mini-Program requests sensitive data (phone, profile).
When the technique is NOT working: defect with IV is found on Baidu, not on WeChat. For WeChat Mini-Programs, this vector only works in combination with leakage session_key - It is not exploited by itself. By MITRE AT&CK - Exploitation for Credential Access (T1212)
Comparison of vectors and place in kill chain
Kill line position. All three vectors run on Initial Access and Credential Access:
• Initial Access: T1190 (Exploit Public-Facting Application) - operation of a vulnerable Mini-Program backend
• Credential Access: T1528 (Steal Application Access Token) - Interception openid/session_key; T1212 (Explotication for Credential Access) - operation of crypto defect
• Lateral Movement: T1550.001 (Application Access Token) - use unionidto access other Mini-Programs of the same developer
• Persistence: T1078 (Valid Accounts) - static openidprovides constant access without rotation
What happens after account takeover? Capturing a Mini-Program account is not the end point. Depending on the functionality: financial Mini-Programs give access to the balance sheet and transactions, medical - to national IDs and medical records (confirmed by the study), state services - to personal data of citizens, e-commerce - to delivery addresses and related payment methods.
Cross-platform painting. Similar mys configurations are reproduced not only in WeChat, but also in Baidu, Alipay and TikTok Mini-Programs. This is a systemic problem of the superapplication environment, where the platform provides an API, and thousands of third-party developers with different levels of competence collect authorization independently.
Dynamic Analysis of Mini-Programs: Tools and Methodology
Adjustments to the environment:
• OS: Windows 10/11, macOS 12+, or Ubuntu 22.04+
• RAM: minimum 8 GB (16 GB is recommended for simultaneous operation of emulator and proxy)
• WeChat DevTools: current version (developers.weixin.quq.com)
• Burp Suite Professional >= 2024.x (Community Edition is limited in custom extensions for wx-payload)
• mitmproxy >= 10.x
• jadx >= 1.5 for decompiling obhocced JavaScript
• Python 3.10+ (requests, pycryptodome for working with AES)
• Android device with root or emulator (to intercept WeChat traffic)
• Network conditions: online (you need access to WeChat servers and backend of the tested Mini-Program)
Why Static Analysis Cannot Be Coped Researchers of the MiniCAT framework (Shi et al., USENIX Security 2024, USENIX Security '24) - one of the first specialized tools for large-scale analysis of OBA-misfoli - showed that static analysis of the JavaScript code Mini-Program (files .js, .wxml, .wxmss) misses most vulnerabilities for two reasons. The first is obfuscation: production Mini-Programs is mined, jadx restores the structure in part, but it is difficult to pull out the business logic of authorization from the static code. The second is runtime-nature of vulnerabilities: OBA-miconfigurations are manifested only when the client interacts with the server. What data backend returns in response to code2SessionHow to process openid with repeated authentication, this is only visible in traffic. SAST is dead.
Methodology of the manual pentest Mini-Program OBA:
1. Configuring proxy. On Android, installing a CA certificate in the system trust store requires root - Android 7+ with targetSdkVersion>=24 by default does not trust the user-installed CA (Network Security Config), and WeChat is collected with this limitation. Alternative: Frida script to disable SSL verification in WeChat runtime (works without a system store, but requires root/jailbreak). On iOS - configuration profile via Settings.
2. Identification of OBA Requests. Open the target Mini-Program and filter in the proxy queue logge containing parameters code, openid, session_key, encryptedData, iv. Marker OBA-flow - POST-request immediately after downloading Mini-Program with codefrom wx.login()in the body.
3. Leakage check (Vector 1). Analyze the backend response to the login-request. If there are keys in JSON openidor session_key- vulnerability is confirmed. Automation via mitmproxy addon:
Python:
from mitmproxy import http
import json
def response(flow: http.HTTPFlow):
if not (flow.response and flow.response.content): return
try:
data = json.loads(flow.response.content)
leaked = {k: data[k] for k in ("openid","session_key","unionid") if k in data}
if leaked: print(f"[OBA LEAK] {flow.request.url}: {leaked}")
except: pass
1. Substitution testing (Vector 2). In Burp Repeater repeat the request for reasonable authentication openid. If the server returns the data of another user without additional checks - Vector 2 is confirmed.
2. Verification of cryptography (Vector 3). If Mini-Program requests a phone number - intercept encryptedDataand iv. Compared IV between sessions: static IV or correlation with session_keyindicates a cryptographic defect.
Limitations of the tools: WeChat DevTools allows you to run Mini-Program in debugging mode, but does not emulate a full OBA-flow (there is no real wx.login()) For full testing, you need a real device with a WeChat installed one. Burp Suite Community Edition does not support custom extensions to decode WeChat specific payload - Professional version is required for a serious audit.
