开发者生态
morning
我的健身房强迫我接受社交媒体。所以我对其应用程序进行了逆向工程
摘要
I recently joined a new gym. It’s a pretty good gym, with nice equipment, nice management, nice branding. And an app . Now, it’s not some random shitty vibe-coded app. It’s actually pretty good as a p...
the
app
and
that
out
gym
social
feed
pretty
good
2026-11-06
1 阅读
约6分钟阅读
yewenjie
字号:
我最近加入了一家新健身房。这是一个相当不错的健身房,有很好的设备,很好的管理,很好的品牌。还有一个应用程序。现在,它不再是一些随机的劣质振动编码应用程序。作为一个产品来说,它实际上非常好。它具有非常流畅的 UI/UX 和经过深思熟虑、一致的设计语言。我只发现其中一个错误。但对我来说,唯一的用例是在十字转门处显示二维码以办理入住和退房手续。然而,有一个问题。该应用程序的主屏幕是社交源。结帐后,它会提示您发布会话故事。家庭动态中充满了人们在健身房的自拍照。每次我打开应用程序时,我都会被迫看到一些本质上看起来像 Tinder 的东西。现在,我的朋友认为这是一个天才的商业想法。据她说,锻炼的人确实想炫耀自己的身体,但在普通社交媒体上发布这样的内容会让人不悦。所以这家健身公司确实找到了很好的产品市场契合点。我认为她是对的。然而,我对我无法控制的社交媒体和信息源非常激进。任何向我显示我无法关闭、排序或过滤的提要的应用程序——我认为这是针对我的心理战。我已经有 12 年多没有使用社交媒体了。我非常坚决地屏蔽广告、屏蔽 YouTube 评论、Short 和推荐视频,并清理 YouTube 标题和缩略图。对于我必须使用的东西,比如 LinkedIn,我使用浏览器扩展来完全阻止新闻源。所以我个人认为。我想看看是否可以提取二维码逻辑,而无需应用程序的额外膨胀。所以我开始挖掘。我很快发现代码每 15 秒就会改变一次。屏幕截图也会被阻止在该屏幕上,与 Android 的 FLAG_SECURE 一致。我想知道这是否是某种 TOTP。生成是在服务器端发生的吗?我做了最简单的事情:关闭 Wi-Fi。该应用程序立即告诉我,代码将在 N 天内保持有效,无需重新连接。好的,所以它可以在本地生成它们。我使用 GLM 5.3 和 DeepSeek v4.1 Flash。在我的会议中,GLM 燃烧了大约 10-20 倍的代币成本,但没有取得那么大的进展。 DeepSeek 似乎进展得更快。需要明确的是,我省略了一些细节,以使健身房和我自己保持匿名。我不想失去我的健身房订阅。我其实很喜欢那个健身房。该应用程序是用 Flutter 编写的,大部分逻辑都编译成 Dart 本机代码。我们使用 blutter 来检查,使用 jadx 来检查 Android 端代码,并使用 Android 的 SDK 工具来检查包。后来我们使用OpenSSL和WebCrypto来检查加密,并使用zbar来独立解码二维码。我到处提示 DeepSeek,主要是出于直觉,因为我以前从未这样做过。有时它似乎迷失在一个方向上,我觉得实现必须比这更简单。只是告诉它我的猜测,或者说我认为一定有一种更简单的方法,有助于引导它走向正确的方向。我们很快就明白,二维码是一个包含四件事的 URL:编码的帐户句柄、加密的到期时间戳、随机数和校验和。过期时间使用 AES-128-CTR 进行加密。使用单独的秘密来计算校验和。所以我们的帐户需要这两个秘密。我的第一个想法是让 DeepSeek 驱动 Android 模拟器、登录并提取密钥。但我很快意识到,我从朋友那里借来的已经用了十年的笔记本电脑无法以任何合理的速度处理 Android 软件模拟。 DeepSeek 建议使用已 root 的手机。就在那时,我想起我身边有一部功能齐全、已root的Android手机。我启动了它,通过无线 ADB 连接,然后让 DeepSeek 进行调查。事实证明,该应用程序记录了我们关心的调用的请求和响应负载。关键材料位于手机上的纯文本日志文件中。这个项目的一半是 ripgrep。提取密钥后,我们构建了一个简单的 SvelteKit Web 应用程序来生成二维码。在此过程中存在一些错误的假设。到期时间戳必须以毫秒为单位,而不是秒。编码是base64url,而不是标准base64,并且它保留了填充。我们还有一个不正确的 AES 实现,它通过了自己的往返测试。它加密了一些东西,解密了它,然后取回了原始输入。但两个方向都存在相同的错误,因此并不能证明它是 AES。与 WebCrypto 的比较暴露了差异。 OpenSSL 和已知的测试向量证实了这一点。浏览器应用程序使用 WebCrypto。然后我们检查原始应用程序的实际输出。给定相同的输入,我们的实现生成了一个字节相同的 URL。我们还独立解码了 QR 图像,以检查它是否包含正确的 URL。那时,我们就有了一个工作原型。 Web 应用程序可以根据提取的密钥在本地生成代码。这并没有解决独立登录问题,也没有消除在轮换时获取新密钥的需要,但在健身房尝试一下就足够了。
这篇文章对您有帮助吗?
订阅66必读
每日精选科技资讯,直达你的邮箱