Open in app

Sign In

Write

Sign In

Ch33_1n'
Ch33_1n'

5 Followers

Home

About

Jul 13, 2021

qwb2021-pwn

Baby_diary libc2.31下的off by null 有add、show、delete函數,漏洞點在myread和addkey過程。 myread會在輸入内容結尾追加 '\x00' 字符,addkey在size+1的位置放置算得的一字節key值(content内容纍加、位移,範圍為0x01~0x0f)。 在offbynull利用的過程中,需要覆蓋size的pre_inuse位為0,以及pre_size位,同時需要僞造fakechunk的fd、bk。既然key值與輸入的内容有關,那麽可以根據所需要覆蓋的值適當調整輸入的内容。如需要覆蓋成 '\x00',則填入全零字節;需要覆蓋成 '\x08\x00'(presize時用到),則填入全零字節和一個 '\x08'。

5 min read

qwb2021-pwn
qwb2021-pwn

5 min read


Jun 12, 2021

【ctf復現】CISCN2021-PWN

拖了一個月emmm LonwlyWolf 程式分析 環境:libc 2.27,tcache有key值(1.3之前沒有) delete函數中存在uaf漏洞:

Pwn

7 min read

【ctf復現】CISCN2021-PWN
【ctf復現】CISCN2021-PWN
Pwn

7 min read


May 25, 2021

【復現】dl_runtime_resolve利用

1. dl_runtime_resolve 1.1 函數流程 作用:對動態鏈接的函數進行重定位,延遲綁定機制中調用。 _dl_runtime_resolve(link_map_obj, reloc_index) 的兩個參數分別是link_map 指針和 got 表中關於 plt 重定位的索引值。主要流程是遍歷所有的link_map,往下取出當前 link_map 的符號表 ELF Symbol Table和字符串表ELF String Table,據此找到對應的符號/函數名。最後往got表寫入查找到的函數地址。具體步驟如下: (1)link_map 訪問 .dynamic,取出 .dynstr、.dynsym、.rel.plt的地址。 (2)當前函數的重定位表項指針 rel = .rel.plt + reloc_index。 (3)當前函數的符號表項指針 sym = .dynsym [(rel->r_info) >>8]。

Pwn

5 min read

【復現】dl_runtime_resolve利用
【復現】dl_runtime_resolve利用
Pwn

5 min read


May 13, 2021

【津門杯2021】pwn復現

1. easypwn 地址泄露 libc2.23的程式,delete 一個 0x80(0x91)的chunk進入unsorted bin就能泄露libc地址。由於show函數加了限制,這裏必須malloc回bin中的chunk才能show。同時由於add函數在content結尾追加 '\x00',得繞過才能打印出地址。根據add的輸入邏輯,輸入size+1時能不追加截斷符,並退出循環: 也就是寫滿size+1的内容,才不會發生'\x00'截斷。爲了main_arena指針殘留在chunk中,可以從unsorted bin中切割最小chunk。如申請0x08,只能寫9個字符,但實際上分配了0x20的空間,bk位置有殘留的main_arena指針。

Pwn

4 min read

【津門杯2021】pwn復現
【津門杯2021】pwn復現
Pwn

4 min read


May 11, 2021

ubuntu18.04環境搭建

這幾天整pwndbg整崩了,重裝幾遍都不行。估計環境變量、軟鏈接啥的已經被我整亂了。18的版本用了快一年,一直很穩定。但可能因爲重複安裝或卸載過一些工具,應該堆了不少垃圾文件。既然如此,直接重裝算了。順便記錄一下… 1. 換源 最最重要的事情 — 換源。這裏我用的清華源: ubuntu | 镜像站使用帮助 | 清华大学开源软件镜像站 | Tsinghua Open Source Mirror Ubuntu 的软件源配置文件是 /etc/apt/sources.list 。将系统自带的该文件做个备份,将该文件替换为下面内容,即可使用 TUNA 的软件源镜像。 本镜像仅包含 32/64 位 x86 架构处理器的软件包,在…mirror.tuna.tsinghua.edu.cn 編輯 sources.list 文件前記得先用tar備份。換完源后: sudo apt-g …

5 min read

ubuntu18.04環境搭建
ubuntu18.04環境搭建

5 min read


Apr 28, 2021

交叉編譯工具鏈

今年1月份的時候在ubuntu上搭建過arm環境,當時只裝了: 也不清楚裝的是什麽,根據名字估計是編譯時需要的庫。搭建完后直接./file或用qemu-arm(需加上-L path)都能運行。但有時gdb調試時,會遇到“符號未定義”的錯誤。 前兩天編譯寫的匯編文件時,直接一堆格式報錯: 這也tcl… 回顧一下整個過程,似乎都沒有涉及到set architecture arm。運行主機是x86的,程式是arm的。即便裝上了arm的依賴庫(按理說是裝全了的,但目前看來并不是),還是會少了些什麽,因此來學下交叉編譯的原理。(希望學完能解決這些問題😢) 1. 概念 1.1 什麽是交叉編譯 (基本上你點開任何一篇深入理解交叉編譯的文章都能看到這個問題) 這個概念是和本地編譯相對的。先來回顧下從源碼至可執行文件的整個過程:編輯 — 編譯— 鏈接。 編輯:就是程序員在編輯器上寫的源程式,產生的是源文件。

Cross Compile

7 min read

交叉編譯工具鏈
交叉編譯工具鏈
Cross Compile

7 min read


Apr 26, 2021

【拆解001】Repoo M10 Plus Wireless Mouse

第一次拆解硬件設備,選了個型號最舊、功能最少、設計最簡單的無綫電鼠。(爲什麽呢… 因爲我看這個電鼠不順眼好久辣!拼不回去也不心疼) process 擰開電池底下的螺絲就可以拆開,PCB板仲可以拆出來。 正面: 這裏的芯片型號是Rapoo S03,顯然是Rapoo自主研發的。是鼠標的光學傳感器,也稱光學引擎。DPI高,反應靈敏,不易丟幀。正是這個東西使得鼠標在無鼠標墊的情況下,也能在不同材質的水平面上正常使用。

Disassembly

3 min read

【拆解001】Repoo M10 Plus Wireless Mouse
【拆解001】Repoo M10 Plus Wireless Mouse
Disassembly

3 min read


Apr 21, 2021

【技能+1】反彈shell

之前聼別人說反彈shell是web的内容,總感覺會在pwn中用的都是全棧大佬。在復現HITCTF2020的時候,發現簽到題dagongren用的就是反彈shell。趁機學1下,很基礎的shell啊原來是… 原理 與Bind Shell的區別 Bind Shell:將bash shell綁定到指定端口(如4444),從攻擊端連接到被控端的該端口。從而攻擊端發送給受控端的cmd都會被執行。 Reverse Shell:攻擊端在監聽目標主機的同時,目標主機啓用了shell並回傳給攻擊端。 測試 這裏用的是debian-mips。首先配置網卡,使兩邊互相ping通。 攻擊端先監聽一個端口:

Pwn

5 min read

【技能+1】反彈shell
【技能+1】反彈shell
Pwn

5 min read


Apr 8, 2021

【ctf復現003】修改TCACHE_MAX_BINS

題目:VNCTF2021-LittleRedFlower 環境:libc2.30,x64,開了沙箱 漏洞:地址任意寫 (該修改的手法對目前有tcache機制的libc版本都可用) TCACHE_MAX_BINS tcache_perthread_struct 是全局的tcache數據結構,存在于每個綫程中。用TCACHE_MAX_BINS 確定 bins 數量,每個 bin 上可存放七個 chunk。從下面的代碼中可以看到,TCACHE_MAX_BINS 默認為 64,即 0x40. 但是在free或malloc的時候,并不會依據 TCACHE_MAX_BINS 來遍歷鏈表。 下面給的是__libc_malloc的代碼。在_int_free中也一樣,對idx是否合法都是依據 mp_.tcache_bins 判斷的(libc2.31和2.32中均是如此,未作修改)。 我們回到mp_結構體的定義中,會發現 .tcache_bins 取的正是TCACHE_MAX_BINS 的值。

Pwn

6 min read

【ctf復現003】修改TCACHE_MAX_BINS
【ctf復現003】修改TCACHE_MAX_BINS
Pwn

6 min read


Apr 5, 2021

【CTF復現002】Libc2.32下的tcache attack

環境:Libc2.32 漏洞:uaf 方法:double free檢測繞過&IOFILE Libc2.32新增保護機制 先看看Libc2.31中的tcache_put函數。相比以往的libc版本新增了key值,指向tcache: 再看2020年8月的Libc2.32版本。很明顯 e->next 的值發生了變化,在2.32中通過 PROTECT_PTR 函數給它賦值。 該函數將next的地址右移12位,與 tcache->entries[tc_idx]作異或后返回結果。也就是最終chunk->fd中寫入的值。 相應地,在 tcache_get 中也加上了對應的 REVEAL_PTR 函數,跟加解密過程相似。 在free的時候會對tcache中的chunk進行檢查,檢查完key就檢查next,用的也是 REVEAL_PTR 函數。 如果next指針被我們修改成其他值,運算得到的結果就不相同。但是當tcache中只有1個bin時,tcache->entries[tc_idx]為0,異或結果等於其本身。

Pwn

3 min read

【CTF復現002】Libc2.32下的tcache attack
【CTF復現002】Libc2.32下的tcache attack
Pwn

3 min read

Ch33_1n'

Ch33_1n'

5 Followers

;) 📑new url: https://7ee1n.github.io/

Following
  • Datafarm

    Datafarm

  • K

    K

  • Hacktivities

    Hacktivities

  • syIsTyping

    syIsTyping

  • Nishant Verma

    Nishant Verma

Help

Status

Writers

Blog

Careers

Privacy

Terms

About

Text to speech