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

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]。

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指針。

這幾天整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 …

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

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

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

題目：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 的值。

環境：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，異或結果等於其本身。