iscc_obfuscation and encode
没事做了一道iscc的逆向题，题目还是有点意思的。首先ida反汇编。
发现有两个关键的函数fencode()和encode()，输入的字符串通过这两个函数，最后转换成s1与字符串”lUFBuT7hADvItXEGn7KgTEjqw8U5VQUq”进行比较。先进入到fencode()里看一看。
打开之后惊了，数了一下大概11层循环嵌套，也许这就是代码混淆吧，我还是自己分析了一下这个代码的逻辑，边上课边看代码效率不是太高，花了大概 一个小时才把逻辑理顺，先找到关键的语句，大部分的跳转语句可以先不理会。
第一处
第二处
可以发现它将我们的输入和m数组进行分组相乘得到v10，再将v10%127得到的新的字符。只要耐心分析这段代码，其实实际上的代码逻辑就只有几行。以下我用for循环进行了还原。
t=0
len=len(a1)
if(len==24){
for(int i=0;i<6;i++)
for(int j=0;j<4;j++){
for(int k=0;k<4;k++)
v10+=*(a+4*i+k) * *(m+4*j+k)
a2+(t++)=v10%127
v10=0
}
return 1
}
return 0实际上输入的字符每4个一组和m数组的十六个字符组成了四元一次方程组，按理说解个方程就可以求出这四个字符，但实际上，最后经过这个函数输出的每个字符都进行了%127的处理所以我们这样做还是有点问题的。这个函数基本就分析完了。接下来分析encode()函数。
这个函数依旧被混淆成了很多层的循环嵌套。但是发现了一些标志，比如61，和三个字符一组一次生成4个字符。于是猜测是进行了base64编码。一开始直接最后的字符串进行base64解码了，后来在动态调试跟到这个函数的时候发现不太对，于是点开了程序中的alpha_base数组，发现这个数组和标准的base64编码方式并不相同。猜测base64被魔改了。假设程序只改了这个编码数组。网上找了一个c语言实现的base64，把编码数组改成了程序中的数组”FeVYKw6a0lDIOsnZQ5EAf2MvjS1GUiLWPTtH4JqRgu3dbC8hrcNo9/mxzpXBky7+”，动态调试发现确实只改了这一个地方。于是就把最后比较的那串字符串进行解码。得到编解码前的数组。d[37,192,59,166,31,175,76,165,203,139,164,155,59,225,40,133,38,38,22,231,17,9,7,38]。发现一个奇怪的地方是编码前的数组，存在比127还大的数，这是因为在之前%127的时候，有一个类型转换，将int类型的转成char型的导致溢出成负数，所以对127取模的结果就会出现一些问题。所以不好确定%127之前的数到底是多少，而且m数组里也有很大的数，运算时很容易溢出，所以解方程不太好做所以还是决定爆破。因为一组只有4个字符所以并不是很困难。 写得脚本。
#include<stdio.h>
int cipher[24]={37,192,59,166,31,175,76,165,203,139,164,155,59,225,40,133,38,38,22,231,17,9,7,38};
int main(void){
for(int x=0;x<6;x++){
for(int i=0;i<=127;i++)
for(int j=0;j<=127;j++)
for(int k=0;k<=127;k++)
for(int m=0;m<=127;m++)
{ int a=2*i+2*j+4*k+0xfffffffb*m;
int b=i+j+3*k+0xfffffffd*m;
int c=0xffffffff*i+0xfffffffe*j+0xffffffffd*k+4*m;
int d=0xffffffff*i+0xfffffffe*k+2*m;
if(((char)(a)%127&0x000000ff)==cipher[x*4+0]&&((char)(b)%127&0x000000ff)==cipher[x*4+1]&&((char)(c)%127&0x000000ff)==cipher[x*4+2]&&((char)(d)%127&0x000000ff)==cipher[x*4+3])
printf("%c%c%c%c",i,j,k,m);
}
}
return 0;
}