用crc彩虹表反向B站弹幕“匿名”？我不想浪费内存，但是要和彩虹表一样快！

前情提要：

弹幕发送者不再是个谜

B站弹幕公开使用的api中，每个弹幕都有他对应的发送者信息

只不过这个信息并不是发送者id的明文，而是id经过crc32哈希后的结果。

 

然而crc32对数字hash才有多少种结果？太容易爆破了

于是我即时跑20000000个id的crc32的值，wow，只要90多毫秒就跑完了。

然而这种速度上线是非常危险的，当年没有办法

而FB使用redis存好了彩虹表，查找只要几ms，然而这需要使用数以GB记的内存。

 

现在我们重新考虑一下这个事情

对于crc32这个函数

DWORD crc32(char *input, unsigned int len)
{

register DWORD crcstart = 0xFFFFFFFF;
for (register unsigned int i = 0; i < len; ++i)
{
DWORD index = (crcstart ^ (unsigned char)*(input++))&0xff;
crcstart = (crcstart >> 8) ^ crctable[index];
}
return crcstart ^ 0xFFFFFFFF;
}

每一次循环就是利用与输入异或后的crcstart这个值的末8位，作为index，

将crcstart末8位隐藏后与利用index查表后得到的值进行异或，输出结果

 

考虑 crctable

00000000 77073096 ee0e612c 990951ba 076dc419 706af48f e963a535 9e6495a3
0edb8832 79dcb8a4 e0d5e91e 97d2d988 09b64c2b 7eb17cbd e7b82d07 90bf1d91
1db71064 6ab020f2 f3b97148 84be41de 1adad47d 6ddde4eb f4d4b551 83d385c7
136c9856 646ba8c0 fd62f97a 8a65c9ec 14015c4f 63066cd9 fa0f3d63 8d080df5
3b6e20c8 4c69105e d56041e4 a2677172 3c03e4d1 4b04d447 d20d85fd a50ab56b
35b5a8fa 42b2986c dbbbc9d6 acbcf940 32d86ce3 45df5c75 dcd60dcf abd13d59
26d930ac 51de003a c8d75180 bfd06116 21b4f4b5 56b3c423 cfba9599 b8bda50f
2802b89e 5f058808 c60cd9b2 b10be924 2f6f7c87 58684c11 c1611dab b6662d3d
76dc4190 01db7106 98d220bc efd5102a 71b18589 06b6b51f 9fbfe4a5 e8b8d433
7807c9a2 0f00f934 9609a88e e10e9818 7f6a0dbb 086d3d2d 91646c97 e6635c01
6b6b51f4 1c6c6162 856530d8 f262004e 6c0695ed 1b01a57b 8208f4c1 f50fc457
65b0d9c6 12b7e950 8bbeb8ea fcb9887c 62dd1ddf 15da2d49 8cd37cf3 fbd44c65
4db26158 3ab551ce a3bc0074 d4bb30e2 4adfa541 3dd895d7 a4d1c46d d3d6f4fb
4369e96a 346ed9fc ad678846 da60b8d0 44042d73 33031de5 aa0a4c5f dd0d7cc9
5005713c 270241aa be0b1010 c90c2086 5768b525 206f85b3 b966d409 ce61e49f
5edef90e 29d9c998 b0d09822 c7d7a8b4 59b33d17 2eb40d81 b7bd5c3b c0ba6cad
edb88320 9abfb3b6 03b6e20c 74b1d29a ead54739 9dd277af 04db2615 73dc1683
e3630b12 94643b84 0d6d6a3e 7a6a5aa8 e40ecf0b 9309ff9d 0a00ae27 7d079eb1
f00f9344 8708a3d2 1e01f268 6906c2fe f762575d 806567cb 196c3671 6e6b06e7
fed41b76 89d32be0 10da7a5a 67dd4acc f9b9df6f 8ebeeff9 17b7be43 60b08ed5
d6d6a3e8 a1d1937e 38d8c2c4 4fdff252 d1bb67f1 a6bc5767 3fb506dd 48b2364b
d80d2bda af0a1b4c 36034af6 41047a60 df60efc3 a867df55 316e8eef 4669be79
cb61b38c bc66831a 256fd2a0 5268e236 cc0c7795 bb0b4703 220216b9 5505262f
c5ba3bbe b2bd0b28 2bb45a92 5cb36a04 c2d7ffa7 b5d0cf31 2cd99e8b 5bdeae1d
9b64c2b0 ec63f226 756aa39c 026d930a 9c0906a9 eb0e363f 72076785 05005713
95bf4a82 e2b87a14 7bb12bae 0cb61b38 92d28e9b e5d5be0d 7cdcefb7 0bdbdf21
86d3d2d4 f1d4e242 68ddb3f8 1fda836e 81be16cd f6b9265b 6fb077e1 18b74777
88085ae6 ff0f6a70 66063bca 11010b5c 8f659eff f862ae69 616bffd3 166ccf45
a00ae278 d70dd2ee 4e048354 3903b3c2 a7672661 d06016f7 4969474d 3e6e77db
aed16a4a d9d65adc 40df0b66 37d83bf0 a9bcae53 debb9ec5 47b2cf7f 30b5ffe9
bdbdf21c cabac28a 53b39330 24b4a3a6 bad03605 cdd70693 54de5729 23d967bf
b3667a2e c4614ab8 5d681b02 2a6f2b94 b40bbe37 c30c8ea1 5a05df1b 2d02ef8d

可以发现每个首8位都是不一样的（原因查看crc原理，这个表的生成方法）

于是可以制作一个crc反向表

用于记录0-255的首8位在crctable里的序号

00 41 c3 82 86 c7 45 04
4d 0c 8e cf cb 8a 08 49
9a db 59 18 1c 5d df 9e
d7 96 14 55 51 10 92 d3
75 34 b6 f7 f3 b2 30 71
38 79 fb ba be ff 7d 3c
ef ae 2c 6d 69 28 aa eb
a2 e3 61 20 24 65 e7 a6
ea ab 29 68 6c 2d af ee
a7 e6 64 25 21 60 e2 a3
70 31 b3 f2 f6 b7 35 74
3d 7c fe bf bb fa 78 39
9f de 5c 1d 19 58 da 9b
d2 93 11 50 54 15 97 d6
05 44 c6 87 83 c2 40 01
48 09 8b ca ce 8f 0d 4c
95 d4 56 17 13 52 d0 91
d8 99 1b 5a 5e 1f 9d dc
0f 4e cc 8d 89 c8 4a 0b
42 03 81 c0 c4 85 07 46
e0 a1 23 62 66 27 a5 e4
ad ec 6e 2f 2b 6a e8 a9
7a 3b b9 f8 fc bd 3f 7e
37 76 f4 b5 b1 f0 72 33
7f 3e bc fd f9 b8 3a 7b
32 73 f1 b0 b4 f5 77 36
e5 a4 26 67 63 22 a0 e1
a8 e9 6b 2a 2e 6f ed ac
0a 4b c9 88 8c cd 4f 0e
47 06 84 c5 c1 80 02 43
90 d1 53 12 16 57 d5 94
dd 9c 1e 5f 5b 1a 98 d9

通过这张表，我们可以计算出任意一个crc值的最后使用的4个index值是多少

得到的四个index 8f 22 5a 36

于是在暴力跑crc值时就可以少跑3位，在倒数第四位时就可以一次性验证这个id的真伪。

最后，验证0-20000000这么多的id也只需要不到1ms啦。

这个算法现在完全可以转写到前端，不用后端跑了。