Добрый день. сейчас начал разбираться в модификации /dev/mem в Linux ( думаю , те кто в теме, понимают зачем ) Возникли некоторые затруднения с этим вопросом. Пробую изменить работу функции printf: Через dlsym получаю адрес функции ,и вывожу несколько первых байт. 55 89 E5 53 E8 46 F2 FC FF 81 C3 5B 6D 10 00 83 EC 0C 8D 45 0C 89 44 24 08 8B 45 08 89 44 24 04 8B 83 2C FF FF FF 8B 00 89 04 24 E8 90 60 FF FF 83 C4 0C 5B 5D C3 через IDA дизассемблирую libc-2.9.so нахожу функцию printf Как видите, некоторые байты не совпадают. ( сверху я выделил не соответствующие байты, считанные мной из /dev/mem ) Пытаюсь найти в памяти функцию printf через hexedit ( начинаю поиск HEX значение..а он мне всегда находит только ASCII ) ( глюк программы???!! ) ... Больше ни через, что не могу открыть /dev/mem (если кто знает каким редактором помимо hexedit можно просмотреть файл памяти, отпишите нзвание) Хотел узнать, почему не совпадают байты функции printf найденые мной, и дизассемблированные IDA ? И маленькое примечание. через dlopen открываю libc.so.6 а он ссылается на libc-2.9.so (потому и дизассемблирую его)
Потому что файл в памяти подвержен релокации, а на диске оригинал. Смотрите внимательнее в каких именно местах несовпадают байты и на сколько различаются
Folk Acid Запускаю linux версию IDA /dev/mem читаю через hexedit (у которого проблемы с поиском сигнатуры!, сместо hex данных всегда ищет ASCII ) bsnake байты изменены в двух call ... тут не совсем мне понятно. первый call заносит в ebx значение с esp .. что это значит, ясно. но не ясно, всё-же почему вызывается код расположенный в либе по одному адресу, а в памяти находится по другому. ( как понимаю......... из либы на диске, код загружает в память запрошенную функцию страницей (в данном случаи 4096) , а затем считывает с диска функцию запрошенную функцией которая уже загружена в память. , считывает с диска ещё 4096 байт и располагает их в произвольном месте в памяти. Затем заносит в call в первой функции? адресс второй(которая была токачто загружена в /mem ).. ) Я правильно понял????? А насчёт не соответствия байта 6D могу предположить, что он обозначает размер данных (но пока не понял каких...наверно % )... при переходе по заданному смещению в IDA находится это call xprt_register чесн слово, впервые с этим call сталкиваюсь ... что это за вызов? Поправьте , где ошибаюсь.
n0name Не знаю как в *nix, но в msdn так же написано что-то насчет стандартных виртуальных адресов для стандартных библиотек. Хотя, в *nix может быть код через относительную адресацию, а релоцируются только точки входа, можете объяснить?
после ldsym printf_address : B7EC7290h vfprintf : B7EBD350h адреса стоят друг от друга на расстоянии 9F40 47590 адрес printf показанный в IDA (в libc-2.9.so ) 3D630 адрес vfprintf показанный в IDA (в libc-2.9.so ) стоят друг от друга на 9F60.... Почему есть различие между расположением в libc-2.9.so и в /dev/mem ?
n0name Очень сильно боюсь показаться глупым.. но, симлинк libc.so ? в ida вижу только эту информацию Interpretor: /lib/ld-linux.so.2 Needed library: ld-linux.so.2 Shared name: lib.so.6
featurelles Посмотри релоки в файле $ readelf -r <prog> И заголовки $ readelf -l <prog> Ах, да только сейчас увидел /dev/mem это физическая память, может вам надо /proc/<pid>/mem ?
как бы обычно в линухе библиотеки имеют более сложное имя файла. и для удобства создаются симлинки. "la -la libc.so"
Так обо всем по порядку: Код (Text): call sub_164DF add ebx, (offset loc_....) Это вычисление адреса GOT. Что такое GOT и PLT советую почитать в спецификации Elf от Sun (http://wasm.ru/baixado.php?mode=doc&id=135). Все релоки обычно находятся в GOT. Это специально для того, что бы все библиотеки разделяли одни и теже кодовые страницы. Поэтому обычно в секции кода, релоков нет. Что бы читать /dev/mem вполне годится dd + hexdump Код (Text): $ dd if=/dev/mem skip=10240 bs=1024 count=1000 | hexdump -C | grep ELF /dev/mem это физическая память и вроде в последних версиях ядер запрещено туда писать (но я могу ошибаться) В приложение грузится библиотека, которая указа в dynamic section ELF файла. Код (Text): $ readelf -d /bin/ls | grep libc 0x00000001 (NEEDED) Shared library: [libc.so.6] $ ls -la /lib/libc* -rwxr-xr-x 1 root root 1302708 2007-09-27 04:00 /lib/libc-2.6.1.so* lrwxrwxrwx 1 root root 13 2008-06-25 01:52 /lib/libc.so.6 -> libc-2.6.1.so* Видим, что libc.so.6 это символьная сыллка на библиотеку libc-2.6.1.so. Это используется для того, что бы можно было использовать несколько разных версий библиотек, обновлять их и .т.п
bsnake md5sum /lib/libc.so.6 e7d3756cae1148e49cf0765fc65343f8 /lib/libc.so.6 md5sum /lib/libc-2.8.90.so e7d3756cae1148e49cf0765fc65343f8 /lib/libc-2.8.90.so Он в IDA открывал когда симлинк не активен, что ли? Или IDA подругому открывает файлы нежели md5sum?
Снова пробую найти printf в /dev/mem . Моя програмка, действует всё также, как и в самом первой сообщении этой темы. Код (Text): 55 89 E5 53 E8 46 EF FC FF 81 C3 5B [b]6A[/b] 10 00 83 EC 0C 8D 45 0C 89 44 24 08 8B 45 08 89 44 24 04 8B 83 2C FF FF FF 8B 00 89 04 24 E8 70 60 Заменяю 55 на С3 ... эффекта НОЛЬ. Прихожу к выводу, что это память ida. (так как сигнатуры..да и вообще все байты вокруг этой функции , совпадают с данными из libc.so.6 дизаасемблированной идой. ). Через dlsym получаю адрес функции ,и вывожу несколько первых байт. 55 89 E5 53 E8 46 F2 FC FF 81 C3 5B 6D 10 00 83 EC 0C 8D 45 0C 89 44 24 08 8B 45 08 89 44 24 04 8B 83 2C FF FF FF 8B 00 89 04 24 E8 90 60 FF FF 83 C4 0C 5B 5D C3 Поиск в mem не даёт никакого результата по данной сигнатуре)... даже если искать по вот этой FCFF81C35B6D100083EC Думаю косяк не в коде программы..но всёже вот он. Код (Text): int PAGE_SIZE = sysconf( _SC_PAGE_SIZE ); // пробовал 0x1000 ...... signature_in_dev_mem // указывает на сигнатуру в libc while(tmp_count++< PHUS_MEM_MAX) { // читаем по одной странице в memory_page_buff_mem if (!memcmp(&memory_page_buff_mem[((unsigned int)signature_in_dev_mem) % PAGE_SIZE], signature_in_dev_mem, SIGNATURE_MIN_BYTES_SIZE)) { printf("FIND\n"); printf("\n\n"); } } Ума не приложу... да гдеж эту сигнатуру то искать?? Ведь в памяти должна находиться сигна 55 89 E5 53 E8 46 F2 FC FF 81 C3 5B 6D 10 00 83 EC 0C 8D 45 0C 89 44 24 08 8B 45 08 89 44 24 04 8B 83 2C FF FF FF 8B 00 89 04 24 E8 90 60 FF FF 83 C4 0C 5B 5D C3 ......а её всё нету))............ ( косяк в коде?? )
