[CTF/Reverse] Simplestuff simplestuff最近抓到了一段简单恶意代码和其发出的流量，你能破解他吗？流量包全是TCP流量, 看不出来什么, 从二进制开始分析字符串里的crontab和flag引起了我的注意, 跟一跟在引用了flag的函数里发现了这个东西, 把TCP包有用的部分截下来XOR一下得到这个, 不过后半部分是乱码, 看看后半部分. 这个文件里有多处InterlockedCompareExchange, 让我怀疑是不是还有其他线程, 尝试动调一下吧惊讶的发现源文件没了, 只留下了一个0字节的文件, 但是crontab里没有新增项...疑惑啊..再来一次注意main要进到这个函数需要是五秒整倍左右, 可以动调改数, 直接进行一个0的改这一串函数会设定一些值, 先忽略sample是我自己写的, 这说明这一段确实是读的flag说明中间还是改动了, 但是我没跟到但是从PseudoCode上看异或结束直接去Label8了, 中间不应该有变动. 无妨, 我们再来一次我自己的sample正常异或结果应该是这个3e 06 16 11 0b 01 65 46 18 0e 47 1f 16 09 19 03 13 00 10 3a 0f 2c 16 41 19 1f 4c 01 3d 07 1c 11 2b 14我们看看哪里开始不一样了哦原来dbapp后面还应该有个\0.....

[CTF/Reverse] [FlareOn3]unknown [FlareOn3]unknown32位WinPE一个参数, 要过401020的检测这里v20 Xor 定值需要是 v6, v6是过2760的参数感觉有点像37进制读入 改名atoi_b37, 注意到这个程序基本都是双字节char, 那些WORD来WORD去的都写成uint16就行 (后来脑瓜一闪反应过来这不是哈希么..)要求0x1B个v13里的内容等于v11, v11在这长104个Byte应该是注意cmptable经过了一个thiscall函数改过, 有个长256的表, 这个换表操作让我感觉是现成的加密算法, 是不是有点像..RC4?同时这个表也输入相关, 但是好像只和输入长度有关v16-v4大概就是一个输入长度相关量, 另外这里也和v20有点关系, 结合循环变量0x1B, 我觉得基本能推测输入长度是27, 每次取出1位放到v23[0], v23其他的值都是固定/可测的, 这个东西被atoi_b37之后要和cmptable相同. 我们试一下len=27的cmptableunsigned char cmptable[] = { 0xE9, 0x67, 0xFD, 0xB2, .... 0xF5, 0xEA, 0x6D, 0xE1 };而v23则是input[j], 0x60+j, 0x46, 0x4C, 0x41, 0x52, 0x45, 0x20, 0x4F, 0x6E, 0x21后面量是上面能找得到的, 就是FLARE On!这样四位一比长度应该是26的, 直接爆破一下unsigned char cmptable[] = { 0x1F, 0xD0, 0x24, 0x4C, 0xEA, 0x1D, 0xDA, 0xAE, 0x57, 0x05, 0x2B, 0x4E, 0xAE, 0x68, 0xC7, 0x4D, 0xF0, 0x6A, 0x42, 0x79, 0x2B, 0x80, 0xC4, 0x39, 0xD9, 0x8C, 0xE2, 0xCD, 0x32, 0x5E, 0x77, 0x23, 0x54, 0xC4, 0x31, 0x36, 0x2E, 0x8D, 0x50, 0xDA, 0x48, 0x79, 0x43, 0xE9, 0xA6, 0x11, 0xE2, 0x56, 0xB0, 0x6A, 0x05, 0xE6, 0xF4, 0x8F, 0x1C, 0xC2, 0x29, 0x8B, 0x95, 0x32, 0xF9, 0x88, 0x66, 0x80, 0x72, 0x2F, 0xF3, 0xCE, 0x56, 0x24, 0xBC, 0xE4, 0x72, 0x6B, 0xFB, 0x52, 0xBF, 0x20, 0x06, 0xCC, 0x8A, 0xEB, 0x00, 0xA9, 0xC6, 0x90, 0x39, 0xAC, 0x4D, 0x50, 0xAC, 0xD2, 0x8B, 0x5C, 0xF9, 0xFA, 0x66, 0x38, 0xAD, 0x12, 0x47, 0x6B, 0xA8, 0x31 }; #include <cstdio> #include <cstdint> int sum(char s[15]) { int res = 0; for(int i = 0; i < 11; i ++ ) { res = s[i] + 37*res; } return res; } int main() { int *p = (int *)cmptable; char s[15] = "a`FLARE On!"; // (0x60+i) * 37 ^ 9 + ch * 37 ^ 10; for(int i = 0; i < 26; i ++ ) { for(int j = 0; j < 0xFF; j ++ ) { s[0] = j; int tmp = sum(s); if(tmp == p[i]) { printf("0x%x, ", tmp); break; } } s[1] ++; } }爆破无果, 那只能是cmptable还有问题, 我们回头看发现这个table竟然和文件名本身有关?? 这个很不美啊.. 我们要尝试找到真正的文件名, 看起来unknown并不是MS编译器往往会有这么一个东西重新提重新爆

[CTF/Reverse] [HackIM2020]year3000 [HackIM2020]year3000一共3000个bin前43个都要是't', 后面4位和unk_2008相同这是bin1的bin2就变成了64位??离谱, 这个是前83位是'N', 后面8位和固定值相同3又回到了32位, 84位的'c', 和4位的固定值, 此外固定值不同.这样我觉得基本可以认为有两种文件, 32位的要比4位, 64位的要比8位, 前面的验证.import subprocess from pwn import * def parse32(elf) : cnt = elf[0x661] ch = elf[0x668] nonce = elf[0x1008:0x100C] # print(cnt, ch, nonce) return (chr(ch) * cnt).encode(encoding='utf-8') + nonce def parse64(elf) : cnt = elf[0x819] ch = elf[0x820] nonce = elf[0x1010:0x1018] # print(cnt, ch, nonce) return (chr(ch) * cnt).encode(encoding='utf-8') + nonce for i in range(1, 3001) : file_name = "./" + str(i) + ".bin" with open(file_name, "rb") as f: content = f.read() if content[4] == 1 : payload = parse32(content) elif content[4] == 2 : payload = parse64(content) p = process(file_name) p.sendline(payload) s = p.recvline() if s != b'Well done\n' : print('Error', i) p.close()脚本倒是写完了, 也全well done了..可是..Flag呢? 长度为3000的flag也不太现实, 难道是把这些二进制串加一起有个新的ELF?, 不妨试试显然, 这东西和ELF没什么关系, 换个思路, 我们把前面的可见字符加一起看看看着就像个Base64然而解了Base64也没什么用, 而且这Base64里竟然一个数字都没有..不是很靠谱啊就这么来到了谜语时间么...苦解谜语10分钟无果, 果断找wp尼玛, 靶机题, 本地打通, 此题做完

[CTF/Reverse] [FlareOn8]MyAquaticlife 本来这题都分析差不多了... WP都在学校, 但是总不能直接跳了, 所以干脆再来一遍upx壳, 直接脱就行最下面可以看到Multimedia Builder, 这东西是个巨古老的所见即所得编程器.一顿乱点之后可以发现这个... 另外也可以发现这好像是个.. 网页? 测试发现是点到中间文字的时候会出现, 基本上可以猜测是正确顺序点鱼, 然后点完了按文字check文件监控发现这东西在Temp下搞了好多东西, Html和dll让我比较感兴趣, 去看看Html里这样的, 就是这里的这些图片, 这些a标签指向了不同的Script, 也不知道是怎么调用的..看了看fathom.dll, 好像没什么用回到Exe, 我本来是在IDA里查的Script, 奈何这种封装程序字符串实在是太多了, IDA非常不方便, 所以Vscode查, 果然发现了Script15/Script3什么的, 每一个Script几乎都对应了一个PartX, 以及它们可能的字符串值, 大概就是parti$="word:nonce"的形式, 稍微整理一下:, 后面跟着的像Base64Script15 p4 = derelict:RTYXAc Script3 p2 = flotsam:DFWEyEW Script5 p2 = derelict:LDNCVYU Script11 p1 = jetsam:SLdkv Script 1 p1 = derelict :MZZWP Script 9 p1 = lagan:rOPFG S7 - p2 = jetsam S8 - p3 = lagan s2 - p2 = lagan s10 - p3 = jetsam s6 - p3 = derelict s12 - p2 = derelict s17 - "PluginFunc19, PlugIn var1$" s14 - p4 = lagan s4 - p1=flotsam s16 - p2 = lagan s13 - p3 = flotsam额, 这怎么这么多p2但是p4不够呢... 管他呢, 随便点一个) 当我随便选了一个单词顺序点完之后就过了), 我感觉有点非预期以下是读完官方WP后的复盘确实非预期了, 正常还要反那个dll, 发现只有jetsam和flotsam用到了, 只要点它们两个就可以了, 但是反正我点对了)逆向嘛, 半猜半调还好我觉得麻烦用的vscode, 这东西只是缀在文件后面了, IDA不会解析, 自然也就查不到了找到Script的常规方法是文件监视器发现它打开了自己, 进而发现读了文件尾, 虽然我意识到了它打开了自己, 但是真的没想到那是读数据, 学到了这题写成WP简单.. 是因为是分析差不多了回头做的, 实际当时做的时候浪费的时间很多很多, 第一步就没想到用文件监视器监控, 还是别的师傅建议试试Flare-on的第4题就这么难了...第10题真的能做么..

[CTF/Reverse] [FlareOn3]DudeLocker Win32程序, 给了一个PE和一个应该是被加密了的doc全是WinAPI, MSDN先备好关注一下预处理, 16是Desktop, Filename是~\Desktop\Briefcase,如果打开失败就说你显然不是Re, 否则进else关闭文件句柄到第42行获取卷序列号, 要求必须是0x7DAB1D35, 下面申请堆就不关注了, 直接关注1940a3就是上面的十六进制, a1是一个明文表, 注意端序, 应该是0x35, 0x1D, 0xAB, 0x7D直接解一下thosefilesreallytiedthefoldertogether1080长这样, WinCrypt, 看上去1180比较重要因为和上面的字符串有关把上面的SHA1掉6610则是AES256, 用哈希值产生一个秘钥, 一层层返回到main的hKey里关注13004030F4是\*, 后面接一起把filename下的所有文件都加密之应该是8003都能背下来了, MD5把传进来的第四个参数Hash之后SetKey, 具体Set的是一个IV,之后没再做别的了, 回main关注1500a1是key, 这瞎猜都能猜到了吧..就是以一个明文SHA1为秘钥生成根, 用CryptoAPI生成一个AES-256的秘钥, IV是文件名的MD5因为本身用Python模仿CryptoAPI生成秘钥挺麻烦的, 分析通了就做到这儿了.