1. Reversed-Engineering + MITM
2. Reversed-Engineering
3. MITM

• 目前 fun-chp 擋得住 2 3，這個要一直帶著 auth 一直驗
  • Reversed-Engineering
    • 可以知道加密程序
    • 可以拿到對稱式的所有鑰匙跟素材，因為是寫死
    • 無法拿不到用戶即時交互資訊，例如用戶輸入的帳號密碼，因為沒有 MITM
    • 可以偽造竄改請求但無意義，沒有 auth 會被 Server 擋下來 (但現在 Server 沒驗
      • 因為 John 要做 public service，所以目前無法用
    • 既然不能請求自然就沒有解密回應的問題
      • 所以現在就會被解密回應
  • MITM
    • 無法知道加密程序，因為沒有 Reversed-Engineering
    • 無法拿到對稱式的所有鑰匙跟素材，因為被加密了
    • 無法拿不到用戶即時交互資訊，因為被加密了
    • 無法做偽造竄改請求及解密回應
• 另一個思路，這個只要定期用 auth 換鑰匙跟素材
  • Reversed-Engineering
    • 可以知道加密程序
    • 無法拿到對稱式的所有鑰匙跟素材，因為變成動態請求
      • 問題變成誰可以打這支動態請求拿東西，所以變成 auth 保護問題
      • 只要他被 MITM，auth 還是會被劫持
      • 但 Client 被 MITM 已經超過 Server 守備範圍
      • 只要他不被 MITM，那他就只知道加密程序但是拿不到對稱式的所有鑰匙跟素材
    • 無法拿不到用戶即時交互資訊，例如用戶輸入的帳號密碼，因為沒有 MITM
    • 無法做偽造竄改請求及解密回應
  • MITM
    • 無法知道加密程序，因為沒有 Reversed-Engineering
    • 無法拿到對稱式的所有鑰匙跟素材，因為被加密了
    • 無法拿不到用戶即時交互資訊，因為被加密了
    • 無法做偽造竄改請求及解密回應
• 那要怎麼擋住 1？
  • mfa + otp
    • Reversed-Engineering + MITM
      • 可以知道加密程序
      • 可以拿到對稱式的所有鑰匙跟素材
      • 可以拿到用戶即時交互資訊，例如用戶輸入的帳號密碼
      • 可以偽造竄改請求及解密回應
    • mfa + otp 是繞過 MITM 直接進手機
    • 如果在該請求加上 mfa + otp，那即使偽造竄改請求也無意義，Server會驗然後擋
    • 既然不能請求自然就沒有解密回應的問題
    • 唯需要用戶進行互動所以無法程序化，場景較侷限，轉帳那種重要的請求才會用
    • 擋得住1，自然2和3都能輕鬆擋住
    • 但是他只能擋住往 Server，不能擋住回來，所以依然有 Session 劫持的風險
    • 但有沒有可能把 mfa + otp 破掉？
• 如果改成非對稱式會發生什麼事？
  • Reversed-Engineering + MITM
    • 可以知道加密程序
    • 可以拿到非對稱式的公鑰跟素材
    • 可以拿到用戶即時交互資訊，例如用戶輸入的帳號密碼
    • 可以偽造請求
    • 無法竄改請求
    • 可以解密Server所有回應，包含auth session