AutoGDB
Beta 1.0.0
AutoGDBは、逆エンジニアリングのバイナリ爆発ジョブにChatGPTの力を組み合わせることに焦点を合わせました。このプロジェクトには以下が含まれます。
/plugin GDBがサーバーに接続するために必要なプラグイン/server FastApi BackEnd Serverは、お客様の情報とGPTを処理するために使用し、間の橋のように機能します/autogdb autogdb pipパッケージAutoGDBの紹介をご覧!!!：https：//www.youtube.com/watch?v=fypdtcc71ggをご覧ください
AutoGDBを初めて使用する場合は、最初にプロジェクトをクローンしてください！
git clone https://github.com/retr0reg/AutoGDB.git && cd AutoGDB
chmod +x ./install.sh && ./install.sh
python3 -m pip install -r requirements.txt install.sh 、gdbプラグインとして~/.gdbinitにplugin/gpt.pyを追加します。または、 ~/.gdbinitを手動で編集することでそれを行うことができます。
echo " /YOUR/PATH/TO/autogdb/plugin/gpt.py " >> ~ /.gdbinit gdbまたはpwndbgでは、実行できます。
pwndbg > autogdb < YOUR_SERVER_IP > < YOUR_SERVER_PORT >YOUR_SERVER_IP ：バックエンドサーバーのIPYOUR_SERVER_PORT ：このサーバーのポートchat.pyを実行し、自分のautogdbとチャットしてください！
python3 chat.py
usage: AutoGDB [-h] [--serverless] [--clue CLUE] [--clean-history]
Enable GPT in your reversing job with GDB.
options:
-h, --help show this help message and exit
--serverless Run AutoGDB without bulit-in server
--clue CLUE Possible provided clues or helpful description of this challenge?
--clean-history Clear previous commandline history of AutoGDB.
私たちのプロジェクトを開発したい場合は、私たちのすばらしいと心のあるautogdb_demo.pyをチェックしてください、それはすべてを説明してください！ python3 autogdb_demo.pyで実行します
GDBで、最初にプログラムとCTRL-Cを実行するように停止することを確認してから、AutoGDBコマンドを入力してください
GPT4、Openaiによる分析の1つの素晴らしい例があります
> Entering new AgentExecutor chain ...
To determine if the binary has a vulnerability , I need to start by analyzing the binary with GDB to check for any obvious signs of insecure patterns or practices such as unsafe functions , lack of bounds checking , or any other potential security weaknesses .
Action : gdb
Action Input : info functions
Observation : "All defined functions: n n Non-debugging symbols: n 0x0000000000000610 _init n 0x0000000000000640 printf@plt n 0x0000000000000650 read@plt n 0x0000000000000660 strcmp@plt n 0x0000000000000670 setvbuf@plt n 0x0000000000000680 __cxa_finalize@plt n 0x0000000000000690 _start n 0x00000000000006c0 deregister_tm_clones n 0x0000000000000700 register_tm_clones n 0x0000000000000750 __do_global_dtors_aux n 0x0000000000000790 frame_dummy n 0x000000000000079a main n 0x0000000000000830 __libc_csu_init n 0x00000000000008a0 __libc_csu_fini n 0x00000000000008a4 _fini n "
Thought : The list of functions provided does not immediately suggest a vulnerability , as these are standard functions that one might expect to find in a binary . However , the presence of functions like `printf` and `read` could potentially be of interest , as they can be involved in vulnerabilities if not used correctly ( e . g ., format string vulnerabilities or buffer overflows ). To proceed , I should examine the `main` function to understand how these functions are used within the program .
Action : gdb
Action Input : disassemble main
Observation : "Dump of assembler code for function main: n 0x000000000000079a <+0>: t push rbp n 0x000000000000079b <+1>: t mov rbp,rsp n 0x000000000000079e <+4>: t mov rax,QWORD PTR [rip+0x20087b] # 0x201020 <stdout@@GLIBC_2.2.5> n 0x00000000000007a5 <+11>: t mov ecx,0x0 n 0x00000000000007aa <+16>: t mov edx,0x2 n 0x00000000000007af <+21>: t mov esi,0x0 n 0x00000000000007b4 <+26>: t mov rdi,rax n 0x00000000000007b7 <+29>: t call 0x670 <setvbuf@plt> n 0x00000000000007bc <+34>: t mov rax,QWORD PTR [rip+0x20086d] # 0x201030 <stdin@@GLIBC_2.2.5> n 0x00000000000007c3 <+41>: t mov ecx,0x0 n 0x00000000000007c8 <+46>: t mov edx,0x2 n 0x00000000000007cd <+51>: t mov esi,0x0 n 0x00000000000007d2 <+56>: t mov rdi,rax n 0x00000000000007d5 <+59>: t call 0x670 <setvbuf@plt> n 0x00000000000007da <+64>: t mov edx,0x64 n 0x00000000000007df <+69>: t lea rsi,[rip+0x20085a] # 0x201040 <buf> n 0x00000000000007e6 <+76>: t mov edi,0x0 n 0x00000000000007eb <+81>: t mov eax,0x0 n 0x00000000000007f0 <+86>: t call 0x650 <read@plt> n 0x00000000000007f5 <+91>: t lea rsi,[rip+0xb8] # 0x8b4 n 0x00000000000007fc <+98>: t lea rdi,[rip+0x20083d] # 0x201040 <buf> n 0x0000000000000803 <+105>: t call 0x660 <strcmp@plt> n 0x0000000000000808 <+110>: t test eax,eax n 0x000000000000080a <+112>: t jne 0x813 <main+121> n 0x000000000000080c <+114>: t mov eax,0x0 n 0x0000000000000811 <+119>: t jmp 0x826 <main+140> n 0x0000000000000813 <+121>: t lea rdi,[rip+0x200826] # 0x201040 <buf> n 0x000000000000081a <+128>: t mov eax,0x0 n 0x000000000000081f <+133>: t call 0x640 <printf@plt> n 0x0000000000000824 <+138>: t jmp 0x7da <main+64> n 0x0000000000000826 <+140>: t pop rbp n 0x0000000000000827 <+141>: t ret n End of assembler dump. n "
Thought : The disassembled main function shows several key operations . The program is setting up buffer handling with `setvbuf` for both `stdin` and `stdout` , which is a normal operation to control buffering . It then reads up to 0x64 ( 100 ) bytes from file descriptor 0 ( which is ` stdin ` in Unix - like systems ) into a buffer located at `0x201040` . After reading the input , it compares this buffer with a string located at an offset from the current instruction pointer ( the address is not shown in the disassembly but is referenced as `0x8b4` ). If the `strcmp` result is zero ( meaning the strings are equal ), it takes one branch ; otherwise , it prints the buffer using `printf` and then loops back to read more input .
The use of `read` with a fixed size is not immediately indicative of a buffer overflow , as we don ' t know the actual size of the buffer at `0x201040` . However , the use of `printf` with the buffer as a format string is potentially dangerous because if the buffer contains format specifiers ( e . g ., `%s` , `%x` ), they could be used to leak memory contents or cause a crash , which indicates a format string vulnerability .
To confirm the size of the buffer and see if there is a potential for buffer overflow , I need to examine the memory layout of the program , specifically the `.bss` section where uninitialized data like buffers are typically stored .
Action : gdb
Action Input : info variables
Observation : "All defined variables: n n Non-debugging symbols: n 0x00000000000008b0 _IO_stdin_used n 0x00000000000008c0 __GNU_EH_FRAME_HDR n 0x0000000000000a04 __FRAME_END__ n 0x0000000000200da0 __frame_dummy_init_array_entry n 0x0000000000200da0 __init_array_start n 0x0000000000200da8 __do_global_dtors_aux_fini_array_entry n 0x0000000000200da8 __init_array_end n 0x0000000000200db0 _DYNAMIC n 0x0000000000200fa0 _GLOBAL_OFFSET_TABLE_ n 0x0000000000201000 __data_start n 0x0000000000201000 data_start n 0x0000000000201008 __dso_handle n 0x0000000000201010 __TMC_END__ n 0x0000000000201010 __bss_start n 0x0000000000201010 _edata n 0x0000000000201020 stdout n 0x0000000000201020 stdout@@GLIBC_2.2.5 n 0x0000000000201030 stdin n 0x0000000000201030 stdin@@GLIBC_2.2.5 n 0x0000000000201038 completed n 0x0000000000201040 buf n 0x00000000002010a8 _end n "
Thought : The `info variables` command in GDB lists global and static variables , including those in the `.bss` section . The buffer `buf` is located at `0x201040` , and the next variable `completed` is at `0x201038` . This suggests that the buffer `buf` is located just before `completed` . The difference in addresses between `buf` and `_end` ( which marks the end of the `.bss` section ) is `0x10a8 - 0x1040 = 0x68` bytes ( 104 bytes in decimal ).
This is a critical observation : the `read` function is called with a length of `0x64` ( 100 bytes ), and the buffer `buf` is 104 bytes long . Therefore , there is no direct buffer overflow vulnerability since the `read` call does not exceed the size of the buffer . However , there is very little space for a null terminator , and if the input does not contain a null byte , this could lead to issues with string handling , although this is not confirmed from the current information .
The potential format string vulnerability identified earlier is still a concern because the `printf` function is called with the buffer as the format string . If an attacker can control the contents of the buffer and include format specifiers , they could exploit this vulnerability .
To confirm the format string vulnerability , I should check the arguments passed to `printf` . If the buffer is directly used as the format string without any additional arguments , this would confirm the vulnerability .
Action : gdb
Action Input : disassemble main
Observation : "Dump of assembler code for function main: n 0x000000000000079a <+0>: t push rbp n 0x000000000000079b <+1>: t mov rbp,rsp n 0x000000000000079e <+4>: t mov rax,QWORD PTR [rip+0x20087b] # 0x201020 <stdout@@GLIBC_2.2.5> n 0x00000000000007a5 <+11>: t mov ecx,0x0 n 0x00000000000007aa <+16>: t mov edx,0x2 n 0x00000000000007af <+21>: t mov esi,0x0 n 0x00000000000007b4 <+26>: t mov rdi,rax n 0x00000000000007b7 <+29>: t call 0x670 <setvbuf@plt> n 0x00000000000007bc <+34>: t mov rax,QWORD PTR [rip+0x20086d] # 0x201030 <stdin@@GLIBC_2.2.5> n 0x00000000000007c3 <+41>: t mov ecx,0x0 n 0x00000000000007c8 <+46>: t mov edx,0x2 n 0x00000000000007cd <+51>: t mov esi,0x0 n 0x00000000000007d2 <+56>: t mov rdi,rax n 0x00000000000007d5 <+59>: t call 0x670 <setvbuf@plt> n 0x00000000000007da <+64>: t mov edx,0x64 n 0x00000000000007df <+69>: t lea rsi,[rip+0x20085a] # 0x201040 <buf> n 0x00000000000007e6 <+76>: t mov edi,0x0 n 0x00000000000007eb <+81>: t mov eax,0x0 n 0x00000000000007f0 <+86>: t call 0x650 <read@plt> n 0x00000000000007f5 <+91>: t lea rsi,[rip+0xb8] # 0x8b4 n 0x00000000000007fc <+98>: t lea rdi,[rip+0x20083d] # 0x201040 <buf> n 0x0000000000000803 <+105>: t call 0x660 <strcmp@plt> n 0x0000000000000808 <+110>: t test eax,eax n 0x000000000000080a <+112>: t jne 0x813 <main+121> n 0x000000000000080c <+114>: t mov eax,0x0 n 0x0000000000000811 <+119>: t jmp 0x826 <main+140> n 0x0000000000000813 <+121>: t lea rdi,[rip+0x200826] # 0x201040 <buf> n 0x000000000000081a <+128>: t mov eax,0x0 n 0x000000000000081f <+133>: t call 0x640 <printf@plt> n 0x0000000000000824 <+138>: t jmp 0x7da <main+64> n 0x0000000000000826 <+140>: t pop rbp n 0x0000000000000827 <+141>: t ret n End of assembler dump. n "
Thought : The re - examination of the `main` function ' s disassembly confirms that the `printf` call at address `0x081f` uses the buffer at `0x201040` directly as the format string ( `rdi` register holds the first argument to functions in the x86_64 calling convention , which is the format string for `printf` ). There are no additional arguments being pushed onto the stack or loaded into registers for this `printf` call , which means that any format specifiers in the buffer will be interpreted by `printf` and could potentially be exploited .
Given this information , it is clear that the binary has a format string vulnerability because it uses uncontrolled input as the format string for `printf` . This could allow an attacker to read from or write to memory locations , depending on the contents of the format string they provide .
Thought : I now know the final answer .
Final Answer : The binary has a format string vulnerability due to the use of an uncontrolled buffer as the format string argument for `printf` .
> Finished chain .AutoGDB1.2バージョンの後、サーバーサイドセッティングはchat.py内で行われます。AutoGDBサーバーの問題がある場合は、 python3 chat.py --serverless実行できます.server_cache_autogdb.json
AutoGDBのサーバー側は、Dockerを使用してプルして使用できます。
docker pull retr0regd/autogdb-server:latest
docker run -p 5000:5000 retr0regd/autogdb-server:latestこの後、サーバーは127.0.0.1で5000ポートで実行されます
または、単にpython3を使用してインストールすることもできます。
python3 -m pip install -r requirements.txt && chmod +x ./run.sh要件をインストールした後、 ./run.shでサーバーを実行できます
