Как прописать инструкцию ассемблера в память процесса, используя gdb?

[жучара]

Друзья! Цель- изучить gdb. Прописывать будем эту псевдоинструкцию: aabbccddee. Из пяти байт, лишь бы была.

Сырец:

section .text
global _start
_start:
mov rax, 60
mov rdi, 0
syscall

Собираем так:

Shell

$ nasm -g -f elf64 -o hello.o hello.asm
$ ld -o hello hello.o
$

Загружаем в gdb (gdb -q hello) и смотрим, что есть:

Shell

(gdb) set disassembly-flavor intel
(gdb) b 1
Breakpoint 1 at 0x401000: file hello.asm, line 4.
(gdb) x/i 0x401000
0x401000 <_start>: mov eax,0x3c
(gdb)
0x401005 <_start+5>: mov edi,0x0
(gdb)
0x40100a <_start+10>: syscall
(gdb)

Ну, я думаю, пропишем 5 байт по адресу 0x401005, самое то будет.

----------------------------------------------------------------------------

Теперь как прописывать- чёрт его знает, как. Вот на этой страничке
https://www.sourceware.org/gdb/onlinedocs/gdb/Concept-Index.html#Concept-Index_cp_letter-X
Если мы будем искать "patching binaries" или "writing into corefiles", то это всё приведёт нас вот на эту страничку.
https://www.sourceware.org/gdb/onlinedocs/gdb/Patching.html#Patching

Shell

(gdb) set write on

скомандуем, а дальше не знаю, что делать.

----------------------------------------------------------------------------

Как-то я узнал, что память можно прописать вот так. По крайней мере, ошибок не выдаёт.
set {char*}0x401005 = (char*)0xaabbccddee
Вообще не помню, где я это взял. "help set" ничего подобного не выдаёт, как и эта страничка.
https://www.sourceware.org/gdb/onlinedocs/gdb/Concept-Index.html#Concept-Index_cp_letter-S
Но продолжим.

Итак, по логике вещей, если aabbccddee пропишется по нужному нам адресу, то она именно в таком порядке и должна прописаться, это ведь строка всё-таки.

Командуем и смотрим, что получилось (только прежде почему-то нужно запустить, чтобы бряк сработал):

Shell

(gdb) r
Starting program: /home/userd/Desktop/asm/hello

Breakpoint 1, _start () at hello.asm:4
4 mov rax, 60
(gdb) set {char*}0x401005 = (char*)0xaabbccddee
(gdb) dump memory dump.txt 0x401005 0x40100a
(gdb)

В соседней консоли смотрим dump.txt

Shell

$ hexdump -C dump.txt
00000000 ee dd cc bb aa |.....|
00000005
$

Занавес. Как ещё указать gdb-у, что мне нужно записывать последовательность байт "as is", а не по его дурацкому порядку, я не знаю. Спасибо, кто откликнется.

[IMB]

Я конечно могу ошибаться, но есть такое понятие как порядок байт достаточно часто именуемый как big-endian и little-endian. Думается в данном случае Вы его и наблюдаете.

[жучара]

Я конечно могу ошибаться, но есть такое понятие как порядок байт достаточно часто именуемый как big-endian и little-endian. Думается в данном случае Вы его и наблюдаете.

естессно. Но я потому и пишу char*, чтобы его не наблюдать. Но наблюдаю.

[Bizdelnick]

(char[5]){0xaa, 0xbb, 0xcc, 0xdd, 0xee}

[жучара]

(char[5]){0xaa, 0xbb, 0xcc, 0xdd, 0xee}

Shell

(gdb) show write
Writing into executable and core files is on.
(gdb) set 0x401005 = (char[5]){0xaa, 0xbb, 0xcc, 0xdd, 0xee}
evaluation of this expression requires the program to have a function "malloc".
(gdb) set {char*}0x401005 = (char[5]){0xaa, 0xbb, 0xcc, 0xdd, 0xee}
evaluation of this expression requires the program to have a function "malloc".
(gdb) set {int*}0x401005 = (char[5]){0xaa, 0xbb, 0xcc, 0xdd, 0xee}
evaluation of this expression requires the program to have a function "malloc".
(gdb)

[olecya]

Может быть так:

Shell

(gdb) set *(char[6]*) 0x401005 = "abcde"
(gdb) x/5c 0x401005
0x401005 <_start+5>: 97 'a' 98 'b' 99 'c' 100 'd' 101 'e'

gdb_zhuchara.png

[olecya]

Так как записан и машинный ноль:

Shell

x/s 0x401005
0x401005 <_start+5>: "abcde"

Добавлено (15:56):

Заголовок на самом деле напомнил мне что через gdb можно фактически подключатся к выполняемому процессу и делать изменения и подмены:

Код: Выделить всё

gdb -p <номер_процесса>

Добавлено (16:33):

С фигурными скобками лаконичней:

Shell

(gdb) set {char[12]} 0x401005 = "hello world!"
(gdb) x/s 0x401005
0x401005 <_start+5>: "hello world"

[жучара]

Так как записан и машинный ноль:

Shell

x/s 0x401005
0x401005 <_start+5>: "abcde"

Добавлено (23.08.2022 15:56):

Заголовок на самом деле напомнил мне что через gdb можно фактически подключатся к выполняемому процессу и делать изменения и подмены:

Код: Выделить всё

gdb -p <номер_процесса>

Добавлено (16:33):

С фигурными скобками лаконичней:

Shell

(gdb) set {char[12]} 0x401005 = "hello world!"
(gdb) x/s 0x401005
0x401005 <_start+5>: "hello world"

так это вы строчку записываете, а мне нужно записать байты 0xaa, 0xbb, 0xcc, 0xdd, 0xee, один за другим. Какие им символы соответствуют- чёрт его знает. Например, символ, который 0xdd, это не понять что такое. Естественно, на клавиатуре мне его не набить

Shell

set *(char[5]*) 0x401005 = {0xaa, 0xbb, 0xcc, 0xdd, 0xee}

решило

[olecya]

Какие им символы соответствуют- чёрт его знает.

Да, выводить лучше побайтово в шестнадцатеричном виде:

Shell

(gdb) x/5xb 0x401005
0x401005 <_start+5>: 0xaa 0xbb 0xcc 0xdd 0xee

По этому адресу записались две новые инструкции.
В моей программе они занимают 5 байт. То есть была 1 инструкция длиной 5 байт и она перезаписалась на 2:

Shell

(gdb) x/3i 0x401005
0x401005 <_start+5>: stos %al,%es:(%rdi)
0x401006 <_start+6>: mov $0x48eeddcc,%ebx
0x40100b <_start+11>: mov $0x402000,%esi

Шестой байт - начало третьей инструкции. При следующем шаге новые инструкции вывелись в окошке tui:

gdb_inst.png

[olecya]

А, нет прихватило почему-то еще один байт 0x48. Да, вторая инструкция начиналась с <_start+10>, сейчас третья с <_start+11> и она изменилась с moveabs на move, то-есть пострадала. Похоже gdb добавил ко второй инструкции один байт от третьей чтобы не получить ошибку.

[жучара]

А, нет прихватило почему-то еще один байт 0x48. Да, вторая инструкция начиналась с <_start+10>, сейчас третья с <_start+11> и она изменилась с moveabs на move, то-есть пострадала. Похоже gdb добавил ко второй инструкции один байт от третьей чтобы не получить ошибку.

ну это псевдоинструкции были, так что не будем строго относится к gdb, может, он, увидя их, начал работать в аварийном режиме.