[原创] 破授权登录验证： TARGET_APP 葫芦侠登录流程分析

## 一、研究目标

本文分析一个自建 .NET Demo 的登录状态机，重点说明：
- 如何确认样本版本
- 如何区分 UI 跳转与真正认证成功
- 如何验证 token 和心跳接口
- 如何建立可复现的测试记录

## 二、环境

系统：Windows 11 x64
运行时：.NET Framework 4.8
工具：IDA、dnSpyEx、ProcMon、PowerShell
样本：TARGET_APP-Demo.exe
SHA256：填写实际 Demo 哈希

## 三、先建立版本基线

```powershell
$target = "TARGET_APP-Demo.exe"
$item = Get-Item $target
$ver = $item.VersionInfo

[pscustomobject]@{
    Path = $item.FullName
    Size = $item.Length
    FileVersion = $ver.FileVersion
    ProductVersion = $ver.ProductVersion
    SHA256 = (Get-FileHash $target -Algorithm SHA256).Hash
}

版本、大小和哈希必须先记录。文件夹名称不能作为版本依据。

四、认证状态机

程序实际流程是：

输入账号密码
-> POST /api/login
-> 服务端返回 token
-> 客户端保存 token
-> 定时发送 heartbeat
-> 主界面加载业务数据

最容易误判的是窗口已经切换，但 token 为空，随后 heartbeat 仍然返回“需要先登录”。

五、Demo 中的验证逻辑

public sealed record AuthResult(bool Success, string? Token);

public async Task<AuthResult> LoginAsync(
    HttpClient client, string account, string password)
{
    var body = new
    {
        account,
        password
    };

    using var response = await client.PostAsJsonAsync(
        "/api/login", body);

    var result = await response.Content
        .ReadFromJsonAsync<AuthResult>();

    return result ?? new AuthResult(false, null);
}

验证重点不是按钮颜色，而是：

• HTTP 状态
• 返回字段
• token 是否保存
• 后续 heartbeat 是否成功
• 主业务接口是否返回数据

六、动态验证记录

示例日志：

login_request status=200
login_result success=true token_present=true
heartbeat status=200
main_api status=200

失败样例：

login_result success=false token_present=false
heartbeat status=401 error=AUTH_REQUIRED

七、回归测试

$required = @(
  "login_result success=true",
  "token_present=true",
  "heartbeat status=200",
  "main_api status=200"
)

$log = Get-Content ".\run.log" -Raw

foreach ($text in $required) {
    if ($log -notmatch [regex]::Escape($text)) {
        throw "Missing evidence: $text"
    }
}

"PASS"

八、结论

本次分析证明：UI 状态变化不等于认证成功。可靠结论必须同时满足版本一致、token 存在、心跳成功和业务接口可用。