实验吧 逆向 小练习

阿拉丁神灯

迷得很，还以为需要真正的逆向，就是找到关键字符串…第一下就不合常理…

看来所有的逆向之前还是看一下段啊字符串什么有没有藏东西，或者看到返回的关键字爆搜一下嗯

FLAG

打开发现是什么输入flag？怎么像WEB？？？然后看到源码中有JS代码
关键的代码太多了，主要就是人工找到突破口吧。其实并不麻烦，因为你观察一下由短到长是有规律的,我倒是觉得是数据分析能力，用一个函数排序，然后一个个试试就行了…

flag{wh47_my5ter10us-do3s,the+phe45ant/c0nta1n}

转瞬即逝

神特么转瞬即逝…名字和题目没有半毛钱关系好吧….

这就很明显了…不解释了…

#_*_coding:utf-8_*_
s='tikp[luX|aoTjaoh'
flag=""
for i in range(len(s)):
    flag+=chr(ord(s[i])^i)
print flag
#this_is_the_flag

有一个程序加密得到如下密文

反汇编一下得到源代码
但是看了半天感觉神了，应该是不知道的某种对称加密，但是这个加密解密过程都给了，尝试解密发现返回是空值，为什么！观察代码发现密文0-9位之间是一个关于时间戳的东西，10-25位是一个md5值，后面都是原密文，然后这个串被一个box盒进行了抑或替换…解密过程也是简单的，仅仅是再做一次轮换然后判断是不是中间的md5值后后面的string有关….有点像AES。按道理加密解密过程不会影响结果（前面分析纯属好奇），但是我们看到了关键的几个限制条件…

解决方法就是把他改成

print True

然后运行解密即可

DUTCTF{2u0_chu_14i_d3_5hi_h3n74i}

babyCrack.exe

这个。。。

hctf{bABy_CtsvlmE_!}

bin100(ebCTF 2013)

大概看了一下，就是所谓的筛子游戏，需要让你筛出一连串的对应的点数嗯，但是这概率很小。总体来说貌似你需要筛出3-1-3-3-7这个顺序，但是这概率很小，所以我们尝试修改程序中的判断流程

随便一改，将匹配值改成7，改成匹配就跳转，然后是永远不可能匹配的，一定不会跳转

ebCTF{64ec47ece868ba34a425d90044cd2dec}

CFG to C

这个这个，选择题？？？

BCDA

Byte Code

看到是.class文件，如何反汇编，找到工具jd-GUI就行了，得到源代码…

import java.io.Console;
import java.io.PrintStream;

class Authenticator
{
  public static char[] key;

  public static void main(String[] paramArrayOfString)
  {
    key = new char[10];
    key[0] = 'A';
    key[1] = 'o';
    key[2] = 'J';
    key[3] = 'k';
    key[4] = 'V';
    key[5] = 'h';
    key[6] = 'L';
    key[7] = 'w';
    key[8] = 'U';
    key[9] = 'R';
    Console localConsole = System.console();
    String str = "";
    while (!str.equals("ThisIsth3mag1calString4458")) {
      str = localConsole.readLine("Enter password:", new Object[0]);
    }
    for (int i = 0; i < key.length; i++) {
      System.out.print(key[i]);
    }
    System.out.println("");
  }
}

答案：AoJkVhLwUR

bitwise

简单题

#_*_coding:utf-8 _*_
verify_arr = [193, 35, 9, 33, 1, 9, 3, 33, 9, 225]
user_arr = []
flag=''
for i in range(10):
    for j in range(30,140):
        if ( (((j << 5) | (j >> 3)) ^ 111) & 255 )==verify_arr[i]:
            flag+=chr(j)
            break
print flag
#ub3rs3cr3t

smali文件分析

用jeb反汇编得到代码

public class Hello {
    public Hello() {
        super();
    }

    public int foo(int arg3, int arg4) {
        return (arg3 + arg4) * (arg3 - arg4);
    }

    public static void main(String[] arg4) {
        System.out.println(new Hello().foo(5, 3));
    }
}

CTF{16}

逆向观察

还是比较明显的，就是再1000个密码中匹配是否存在 sedecrem，但是真的是这个嘛？？？答案是否定的，我们需要注意原来存放src的类型是int型！而我们将它看成char型是必须倒置的！！！
也就是说我们需要在程序中注入一个串和1000个字典中匹配，而且字典中必须存在 mercedes，查看之后发现确实是存在的！那么我们如果动态调试就只需要输入一个满足条件的字符串即可！
最终答案

mercedes

Just Click

Exeinfo Pe进行加壳分析，发现是利用了c#写的，在分析结果中明确提出了应该用.NET Reflector去分析源代码！

真是涨了一波姿势啊，按顺序输入即可

这里还有一个小坑…这里的To要用大写….

simCTF{Easy_To_Get_Flag_From_DotNET}

分道扬镳

非常有意思的题目，但是应该是不难的（要不然我也不可能会的），首先我们看到了由星号和空格组成的字符串，轻易的可以猜测出来应该是一个8*8的地图（因为后面的四种操作很明显）得到地图如下

********
* *    *
* * ** *
* * ** *
* * #* *
* **** *
*      *
********

然后我们还可以轻易地找到了起点是这里

然后后面就是肉眼观察规划路径即可！然后推算得到的输入应该是

jjjjjlllllkkkkkhhhjjjl

我们看函数

里面有一个很诱人的东西….

这个是骗人的，python、脚本搞出来得到

#_*_coding:utf-8_*_
a=[0xF4,0xE8,0xE9,0xF3,0xDF,0xE9,0xF3,0xDF,0xE1,0xDF,0xE6,0xE1,0xEB,0xE5,0xDF,0xE6,0xEC,0xE1,0xE7]
flag=''
for i in a:
    flag+=chr(i+128-256)
print flag
#this_is_a_fake_flag

所以说…答案就是我们最开始得到的顺序

jjjjjlllllkkkkkhhhjjjl

10000000

这个题目某明奇妙的简单，说白了就是非常直白的逆向，总共的代码如下

简单明了，就是一个字符串的匹配，非常简单，直接上代码了

#_*_coding:utf-8_*_
import libnum
a=[0xE7,0xE1,0xEC,0xE6]
a=[0xE6,0xEC,0xE1,0xE7,0xBA,0xF4,0xE5,0xF3,0xF4,0xF4,0xE5,0xF3,0xF4]
flag=''
for i in a:
    flag+=chr(i^0x80)
print flag

该题不简单

真是没想到，一看题目难度说是难…还以为是爆炸，一看为啥全世界都会啊….感觉不对劲，使劲看啊看，发现其实很简单…首先我们试一试，找到关键字密码，顺势找到了判断的位置

就是这个！我开始直接看汇编没看出个所以然，我们反汇编一下看看就非常明显了！关键就是下面那个函数了

然后我们去审核一下那个函数，就是一个匹配就好了…晕死了…

通过其他工具可以知道1000框为用户名输入框，1001为注册码输入窗口。直接上代码解密即可，很简单

#_*_coding:utf-8_*_
import libnum
s='hello'
flag ='Happy@'
for i in range(len(s)):
    flag+=chr((i+i*ord(s[i])*ord(s[i]))%0x42+33)
print flag

证明自己吧

主函数直接了当的

真是可以，关键就在这个4011BA这个验证的函数上了

其实还是一个简单的字符串匹配，轻轻松松写出脚本搞定…

#_*_coding:utf-8_*_
flag=''
a=[0x68,0x57,0x19,0x48,0x50,0x6E,0x58,0x78,0x54,0x6A,0x19,0x58,0x5E,0x06]

for i in range(len(a)):
    a[i]=a[i]-5
for i in range(len(a)):
    flag+=chr(a[i]^0x20)
print flag

wzwzDingDing

首先看到类似和结果有一些联系的string串，然后看整个题目是一个驱动程序。

这个FLAG有点怪

终于解出来了，放给大家链接
http://blog.csdn.net/qq_35078631/article/details/78209447

1000

没什么说的，1000有特殊含义试一下8，在收藏夹下得到一个新文件，写着

G00dTh1sIske

加上一个y即可

CTF{G00dTh1sIskeY}

此处无声

这个题目首先PEiD打开看一下，没发现什么，但是我们用IDA反编译的时候却发现还有壳，进入ODB看一下发现大量的都是动态修改程序，然后动态跑出来的，所以没办法只能动态调试然后dump了。但是这个不是传统的UPX加壳了，我也不知道是什么壳子，所以只用了歪打正着的方法，首先观察一下，输入字符串一般用到了函数GetWindowText这个函数，用ODB下断电，然后F8一路调到一个函数中间，然后将这个函数的开始当做程序的OEP进行脱壳处理。就是这里

然后脱壳以后发现IDA可以成功编译，然后就是静态加上动态分析了，首先运行一下发现运行是不成功的。

有大概的提示，明白了有MD5和RC6算法，但是不知道RC6是啥，需要现查一下…然后我们进入IDA看到了start函数看到了这个

很容易猜测应该就是调用GetWindowTextA获得用户名和用户的激活码吧。然后看到这个sub_401960这个函数一路跟进去看到了函数

啥都不说了，就是MD5的初始化的哪一步吧，我估计就是处理MD5了，第一步提取的是注册用户名字nsfocus。然后我们看一下后面几个函数是干什么的

---

sub_401AA0 此函数之后得到了nsfocus的MD5值b9b7dd1c421e005bc9a7f70b848e3d0e

---

sub_401870 检测输入值是不是32位的，且必须只有0-9和A-E

---

sub_4018C0就是把输入的验证码（32位）两个字符一组拆成16组，然后做了这样的处理

ans +=  chr(第一个字符*16+第二个字符)

这样的处理，这样就变成了一个16长度的字符串，其实就是转换成了hex值…

---

sub_4011F0 不知道是啥，但是16位，所以感觉是16位的密钥，从v3开始，总共取出16位，如下

[0x35,0x47,0x82,0x5c,0x33,0x8c,0x85,0x77,0x9a,0x67,0x45,0x7a,0x6d,0x5c,0x16,0x47]

然后对密钥进行进一步的加工，如果需要程序解密就需要动态把这个东西爬下来了，得到了这个

这个东西IDA有点坑，反编译没出来，需要看汇编才能看出来…要不然感觉密钥给被吃了一样…

---

然后后面的sub_4011F0和sub_4012F0恐怕就是处理RC6的东西了
但是我们拉下了一个重要的参数就是密钥的默认r=20，这个很关键（一般是默认的，但是如果改了就非常坑了）

---

然后我们看判定的条件居然是注册码的RC6和nsfocus的MD5值进行比较。那么我们的32位的注册码如何恢复就很明确了

1.知道密钥，密文是b9b7dd1c421e005bc9a7f70b848e3d0e进行解密
2.对得到的16位进行恢复

但是一直找不到RC6好用的程序额…github上面dump下来修改的结果都不对额…最后找到了网上一个小工具…

终于算是做出来了…首先考察的是脱壳的知识，然后其实算是投机取巧了，如果没有提示MD5算法我能看出来，但是RC6有什么特征呢？所以还是见识太少了。