这是一个创建于 778 天前的主题，其中的信息可能已经有所发展或是发生改变。
其中 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
janus77 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