下载文件elf文件，运行输入flag，用ida打开逆向算法：

不是很复杂，可以看出flag长度需要24，最终会和已给出dword_601060进行比较，
一致则成功，那么现在只需要看上面的sub_4005B6()函数了：

跟进两个地址进去看一下，发现有已经给出的处理所需数据，只是比较多，有15000个，想了想最后还是决定把数据提出来（其实是没其他办法了==）

最后是逆推py脚本：

那个15000的数组太长了，不好复制，要导出在一个文档里，才能复制完

tmp=[1,  16,  37,   3,  13,  10,   2,  11,  40,   2 ]    //太长了只写前十个 

final=[196, 52, 34, 177, 211, 17,   151, 7,   219,   55,
       196, 6,  29,  252, 91, 237, 152,  223, 148,  216,
       179,  132,   204, 8]
i = 14997
while i>0:
v0 = tmp[i]
v3 = tmp[i+2]

result =  tmp[i+1]
if v0 == 1:
    final[result] -= v3
elif v0 == 2:
    final[result] += v3
elif v0 == 3:
    final[result] ^= v3
elif v0 == 4:
    final[result] /= v3!
elif v0 == 5:
    final[result] ^= final[v3]

final[result]&=0xFF     //需要注意的地方，因为ascii字符码范围为0~127，可能发生越界
i -= 3

for x in final:
    print(chr(x), end = '')

得到flag：nctf{Embr4ce_Vm_j0in_R3}

如果不加final[result]&=0xFF 这句话就会越界，如图：

&0xFF到底是什么意思

举个简单的例子:

byte[] b = new byte[5];

b[0] = -12;

byte 8位二进制 = 1个字节 char 2个字节 short (2个字节) int（4个字节） long（8个字节） float （4个字节） double（8个字节）

计算机存储数据机制：正数存储的二进制原码,负数存储的是二进制的补码。 补码是负数的绝对值反码加1。

比如-12，-12 的绝对值原码是：0000 1100 取反： 1111 0011 加1： 1111 0100

byte –> int 就是由8位变 32 位 高24位全部补1： 1111 1111 1111 1111 1111 1111 1111 0100 ;

0xFF 是计算机十六进制的表示： 0x就是代表十六进制，A B C D E F 分别代表10 11 12 13 14 15 F就是15 一个F 代表4位二进制：可以看做 是 8 4 2 1。

0xFF的二进制表示就是：1111 1111。 高24位补0：0000 0000 0000 0000 0000 0000 1111 1111;

-12的补码与0xFF 进行与（&）操作 最后就是0000 0000 0000 0000 0000 0000 1111 0100

转换为十进制就是 244。

byte类型的数字要&0xff再赋值给int类型，其本质原因就是想保持二进制补码的一致性。

当byte要转化为int的时候，高的24位必然会补1，这样，其二进制补码其实已经不一致了，&0xff可以将高的24位置为0，低8位保持原样。这样做的目的就是为了保证二进制数据的一致性。

有人问为什么上面的式子中b[0]不是8位而是32位，因为当系统检测到byte可能会转化成int或者说byte与int类型进行运算的时候，就会将byte的内存空间高位补1（也就是按符号位补位）扩充到32位，再参与运算。