这是一个创建于 1071 天前的主题，其中的信息可能已经有所发展或是发生改变。
其中 data 参数是加密过的 Wm6Vh1V3Yy3Pzo%2fTYBhUxaUTUArUbSqrwzxIx%2f2mxAK1r8bi%2fOj2nOnq%2fUj%2fJCXE4GVqA70CEFGNC2jMcudEyA%3d%3d
urldecode 后得到 Wm6Vh1V3Yy3Pzo/TYBhUxaUTUArUbSqrwzxIx/2mxAK1r8bi/Oj2nOnq/Uj/JCXE4GVqA70CEFGNC2jMcudEyA== 看起来像哈希
已知条件：
1.data 的格式猜测是 uid=761607&xxx=123&yyy=678 （ 761607 是确定的）
2.如果是同一个用户，则这段加密参数 urldecode 的前面不变的，后面会变动； Wm6Vh1V3Yy3Pzo/TYBhUxSo2nBTv/87yiu5bbpuf1Dvz3n3GEY6CdYGJZ4XaxLGhtXnvkRh3mkC53YhgQFADyw==
Wm6Vh1V3Yy3Pzo/TYBhUxaUTUArUbSqrwzxIx/2mxAK1r8bi/Oj2nOnq/Uj/JCXE4GVqA70CEFGNC2jMcudEyA==
Wm6Vh1V3Yy3Pzo/TYBhUxWXWOrHlajdHjBlrNOxbUfbmZ+7rWI0WpHuk8qC0osJfi6s/X0gNDriu/P7V7yJ9Zg==
3.这段加密参数肯定是可以在服务端解密，然后保存到数据库，所以是可逆加密算法
4.response 返回值：{"status":"ok","uid":761607,"xxx":39135736} xxx 为打码
看的出来是用什么方式加密吗？
 | 1 ThirdFlame 2022-11-09 09:15:59 +08:00 base64 编码后的加密数据（长度 64 字节，符合现代密码学分组加密的规范）。 具体加密算法和密码 看是看不出来的。但是估计密钥和 iv 都没有变化过。 |
 | 2 momox OP @ThirdFlame 很有启发，感谢 |
 | 3 Eiden 2022-11-09 09:21:50 +08:00  1 你还不如把网址发出来, 说不定谁摸鱼的有空给你看看 js, 猜哪能猜出来 |
 | 4 swulling 2022-11-09 09:22:51 +08:00 via iPhone 反编译客户端，把密钥找出来 |
 | 5 gollwang 2022-11-09 09:26:25 +08:00 自己去看 js ，前端一定存了密钥的，加密方式也在 js 里面 |
 | 6 yolee599 2022-11-09 09:43:08 +08:00 把网址发出来大伙瞅瞅 |
 | 7 rb6221 2022-11-09 09:53:16 +08:00 5 做爬虫也要白嫖网友的点子是吧 |
 | 8 Alias4ck 2022-11-09 09:56:26 +08:00 一眼 RSA 加密 不过你需要一个 public_key 大概率这个 key 它有一个 api 去生成 |
| 9 momox OP 是一个 Unity 游戏，不是普通 web+js |
 | 12 xkang66 2022-11-09 10:50:06 +08:00 根据已知条件 2： 1 、去除密文前不变字段无法 base64 解码，故不是拼接密文 2 、该加密不可能是 RSA ，RSA 每次加密密文都是变化的 3 、推断是对称算法，建议首先查看 AES |
 | 13 66beta 2022-11-09 11:05:45 +08:00 居然不是 https |
 | 14 fkdtz 2022-11-09 11:17:43 +08:00 @Alias4ck 这是从哪看出来是 RSA 加密的，文中提到同一用户加密结果中，前面是不变的，而 RSA 每次计算结果相差很多的吧 |
 | 15 fkdtz 2022-11-09 11:20:55 +08:00 非对称加密貌似用在认证比较多，而在数据传输上用的比较少，因为性能不高。 猜测就是简单的对称加密，而且设置可能用的是最简单的 ECB 模式，因为明文不变的部分，密文也不变。 |
| 16 Alias4ck 2022-11-09 11:45:24 +08:00 @fkdtz 哈哈哈 我瞎猜的 因为之前碰到过类似的 加密 先是 RSA 再用 base64 套了一层 那个 js 套用的是这个库 jsencrypt( https://github.com/travist/jsencrypt) 所以就随口一说 具体情况得分析一下哈 原谅我的不专业捏 |
 | 17 areless 2022-11-09 11:45:51 +08:00 via Android 这是通过后端密码混淆加密。前端不负责解密，只负责原封不动的返回后端。前面一样是因为要判断解密头，头不一致返回 false 。比如密文是 abcde ，密码是 123 ，加密后就是 a1b2c3d1e2 。混的是 ascii 码，加上偏移量***后就类似是 ab1cde2 这样，混入位置根据偏移量的，我经常用这种办法取代 https ，破解方法呢...呵呵 |
| 18 areless 2022-11-09 12:01:01 +08:00 via Android 上面方式还不能叫加密，只能算混淆。用其上原理密码偏移量 ascii 码做 xor 运算，最后 base64 编码。缺点就是加密后密文不变，不能抵御重放攻击，没有偏移量的话利用重放能...a 输入 密文是*** b 输入密文是***，那 ab 密文就是******了 |
 | 19 dearmymy 2022-11-09 12:24:25 +08:00 你可以提示下这段包大概业务逻辑 通常发送量不大，但是重要情况下才会 rsa ，实际上一般公司都不会选择 rsa 。太麻烦。自己数据也没那么重要。 如果常规需要大量发包。aes 这种加密多些 你这种同一用户前面固定值，肯定不是 rsa 。 猜测 key+data ，解 data 的 key 就是前半部分。 你可以先试试重放攻击能成功不 这种解密不去逆向加密过程是不可能的 |
 | 20 ultlu 2022-11-09 12:49:39 +08:00 标准化 base64 后做了 urlencode, base64 前是个 64 个字节的不可见字符。 |
 | 21 Picmen 2022-11-09 16:00:09 +08:00 可能是分组密码，用的 ECB 模式，或者 CBC 模式不变 IV 。 |
 | 22 fank99 2022-11-09 16:04:12 +08:00 发网址出来逆向，猜是猜不出来的 |
 | 23 ttwxdly 2022-11-09 18:16:19 +08:00 像 AES CBC |
 | 24 7d6a4 2022-11-10 17:01:26 +08:00 三个 data 都是长为 88 的字符串 >猜测 base64 编码 三个 data 假设都经过 base64 encode  他们对应的 hex 为 `5A6E95875577632DCFCE8FD3601854C52A369C14EFFFCEF28AEE5B6E9B9FD43BF3DE7DC6118E827581896785DAC4B1A1B579EF9118779A40B9DD8860405003CB` `5A6E95875577632DCFCE8FD3601854C5A513500AD46D2AABC33C48C7FDA6C402B5AFC6E2FCE8F69CE9EAFD48FF2425C4E0656A03BD0210518D0B68CC72E744C8` `5A6E95875577632DCFCE8FD3601854C565D63AB1E56A37478C196B34EC5B51F6E667EEEB588D16A47BA4F2A0B4A2C25F8BAB3F5F480D0EB8AEFCFED5EF227D66` 特点为前 32 位 hex 都相同 三个 hex 长度都是 128 猜测 AES128 > 猜测密钥与前 32 位可能有关 也可能与 uid 有关 根据 贴中所述 data(明文)总长应该在(48, 64] |
Select Language