hahbiubiubiu

解题思路简单浏览下程序思路，可以发现程序的输入，但程序的结果比较过程则没有发现。 通过网上搜索，在sub_402770的函数中Block部分应该也是一个函数，我猜测具体过程是由前一句sub_401C40函数生成的，因此直接在这下断点，直接动态调试。 程序的比较过程还是比较明显的，但还是调试了我半天，具体过程就不贴图了。 第一个过程对input[i]进行异或4，然后当 i % 3 == 1时，还将input[i]与一串字符串第（3 * i）位异或（但根据该字符串来进行解题时，出现的结果不太对，因此我直接记录进行异或的字符，直接异或了） 第二个过程对sub_4017B0函数生成的字符串进行处理。 由于程序的进行，处理后的字符串可以直接读取，因此不用管过程，直接得到结果。 str1 = "e4bdtRV02" 后面的字符被第十位的 0 截断了，因此只有9位了。 第三个过程将变化后的input[i]与sub_401BD0（i）所得到的返回值 + 2 进行异或。 同时如果input的前九位与str1的前九位相加。 解题脚本12345678910 ...

解题思路思路主要参考网上writeup，一步步做出来的。 png中隐藏着exe文件 MZ文件头，即（4D5A9000…)，从这开始到最后的字节都提取出来，为一个exe文件。此时的exe文件因为缺少PE头无法被ida识别，因此加一个PE头 50 45 00 00 也可以通过010editor在模板中修改 用ida打开该exe文件 判断这是一个解密过程，即 为部分字节数据进行异或解密，用脚本进行解密。 1234567891011with open(r"C:\Users\hahbiubiubiu\Downloads\file\bingo.exe", 'rb') as f: data = f.read() data = list(data) text_segment_size = 0x3E000 - 0x1000 # 0x3E000是大小 # 0x1000是偏移 key = 0x22 for i in range(0x1000, 0x1000 + text_segment_size): data[i] ^= key wit ...

解题思路该题主要是参照其他大佬writeup的思路，即找到输入，下断点，根据最后所得到的比较等式来一步步调试得到的。 VM该函数应该是使用vm函数的地方 因此在这个地方下了断点之后，一步步开始调试，看看程序的执行流程 首先，程序的执行到这个地方，会不断重复执行，然后根据调用的函数来获取输入、进行比较、执行输出。 在前几次的执行中，包含了获取输入的函数，得到我们的输入。 比较过程获取输入后，程序开始执行比较，其中我也不太清楚部分操作的流程，可能是获取数据或者解析数据什么的，因此省略了。 获取input[i]的字符更新为input[i]-9。 sub dex,ecx 获取操作数 0x26。 将input[i]与上一个函数获取的0x26异或，即input[i] = input[i] ^ 0x26。 xor edx,ecx 获取程序之前生成的Welcome字符串的第i个字符。 将获取Welcome字符串的字符和之前变化后的input[i]进行异或。 xor edx,ecx 执行add [eax], esi, 将上一步异或得到的的字符加上6。 add [eax], esi ...

解题过程首先，看MainActivity，猜测b中handleMessage是判断最终条件，onClick是检验flag方法 然后查看引用输入字符串obj的a类中，doInBackground应该是对输入字符串进行解密 查看doInBackground引用的b类 可以看出这是对字符串的一个异或 再去看a类中的onPostExcute方法，以及除了a、b类以外的c类，猜测这是一起为最后为检测结果进行判定的方法 c类，可以看出这是一个比较结果的方法 程序逻辑输入flag–>进入a类不断进入b类进行循环–>进入c类进行结果比较 解题脚本由于按照程序原本的逻辑，我写出的脚本无法生成flag，且网上暂时没有该题的writeup，我只好使用另一种方法。 程序的逻辑是将字符串不断地进行异或，最后的结果其实相当于进行一次异或，而这一次异或的数字是未知，因此可以写一个循环去爆破它。 1234567891011121314151617181920212223242526272829303132final = ['z', 'p', '& ...