實驗吧 逆向 小練習

阿拉丁神燈

迷得很，還以爲需要真正的逆向，就是找到關鍵字符串…第一下就不合常理…

看來所有的逆向之前還是看一下段啊字符串什麼有沒有藏東西，或者看到返回的關鍵字爆搜一下嗯

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有什麼特徵呢？所以還是見識太少了。