перехват сискола читающего содержимое директории в ядре linux
сабж. необходимо написать руткит для курсача.
на данный момент пытаюсь заставить работать код взятый из старых источников вроде "хакера". если конкретнее, то я хочу воспользоваться функцией скрытия каталогов. но на ядре 2.6.39, которое я взял для курсача, этот код не работает. в то же время, если верить копирайтам, исходник linux/fs/readdir.c не менялся с 2005 года. так что мне кажется странным то, что "патч" которому уже лет 5, не работает с исходниками которым лет 15. довольно отвлечённых разговоров, вопросы:
1 для того что бы скрыть все каталоги с именем abcde нужно перехватить системный вызов. самым лучшим вызовом для перехвата является getdents64 или можно сделать проще?
2 если я хочу написать свою реализацию getdents64 и снабдить её "фильтром", то где мне найти описание оригинального getdents'а?
3 можно ли сделать некий враппер для getdents64? я много пытался, но ничего не вышло. наверное из-за того что если это вообще можно, то есть какая-то специальная методика?
4 есть ли литература которая затрагивала бы программирование ядра в целом и работу с файловой подсистемой ядра linux в частности? ну или про руткиты. на нашем, буржуйском, испанском или французском языках.
ещё на всякий случай напишу, что:
я знаю, что ядро развивается очень динамично и что копирайты могут врать.
с ядром я работаю впервые.
- Для комментирования войдите или зарегистрируйтесь
Тут дело в том что копирайты
Тут дело в том что копирайты не врут, просто изменения в коде не затрагивают дату создания файла(2005 год это скорее всего год инициирующего коммита этого файла, копирайт с того времени даже после внесения изменений не менялся, потому и текст никто менять не стал)
По поводу литры есть вот такое http://www.ozon.ru/context/detail/id/3589107/ и ее даже пытаются держать в более или менее актуальном состоянии(хотя я не уверен в этом, только листал ее)
Я бы попробовал таки разобраться в исходниках самому. Если что старшие товарищи есть и на rsdn.ru ну и тут я думаю могут помочь. Ну и таки про сообщество не забывайте, если есть навыки общения то можно найти нужного человека и он что-нить да раскажет )
Я попробую вечером поковырятся может чем-то помогу)
semlanik написал(а): По
увы
да и в исходниках я пытаюсь разобраться )) но пока не могу даже найти реализацию этого самого getdents64. вообщем верю, надеюсь, работаю.
Реализация лежит либо в libc
Реализация лежит либо в libc либо в glibc, не в ядре точно. В ядре есть только перхват и обработка сигнала, из списка который внизу привел шлепнога.
Собствено вот и имплементация:
glibc-2.12.2.tar.bz2:./sysdeps/unix/sysv/linux/powerpc/getdents64.c
Беглый осмотр привел меня примерно к этому INLINE_SYSCALL (getdents, 3, fd, CHECK_N(buf, nbytes), nbytes);
Теперь вернемся к руткиту. Насколько я понимаю текущая задача постепенно приобретает рамки:
Написать подключаемый модуль ядра, который будет перехватывать getdents вызывать настоящий getdents получать от него буффер и подменять его своим.
Написать скрипт компиляции с поиском исходного кода ядра и дальнейшим modprobe этого модуля.
Тут я думаю мы можем сделать вот как-то так:
http://www.opennet.ru/base/dev/intercept_lnx.txt.html
и перехватить наш getdents.
UPD: "как-так" не вышло ноя не даюсь ) сейчас получим норм модуль )
примерно так и сделал.
примерно так и сделал. пришлось немножко адаптировать код. теперь он выглядит вот так: http://pastebin.kde.org/147308/
У меня не получается
сам напарил сам решил ) сорри )
Теперь я вас распрошу) не
Теперь я вас распрошу) не объясните как оно работает find_syscall_table? Я понимаю что оно делает но не понимаю как )
Как я понял вы шерстите память ядра на момент нахожения поинтера на sys_close, откуда вы его взяли и как? в смысле что syscall_table начинается именно с sys_close? Тут какой-то феерический мерж был(видимо баг форума) и таки потерлось что этот вызов вгоняет мое ядро в панику.
таки проверку на 0 добавьте а то как-то совсем не удачно выходит. У меня возвращается 0 в find_syscall_table, а следовательно функция по какой-то причине не работает. Я сейчас пробую со значением взятым из System.map. Может чего интересное выйдет.
так... если сделать grep -e
так...
если сделать grep -e sys_call_table -e memcmp -e sys_close -e loops_per_jiffy /boot/System.map, то можно будет увидеть, что таблица сисколов находится между memcmp и loops_per_jiffy, адреса которых не сложно узнать. так же просто найти и sys_close. и по скольку нам известно смещение sys_close от начала таблицы, то знаю эти три параметра, можно про шерстить память между memcmp и loops_per_jiffy циклом for(ptr = (unsigned long)&memcmp; ptr < (unsigned long)&loops_per_jiffy; ptr += sizeof(void *)). и найдя sys_close по адресу смещённому на __NR_close от начала таблицы if(p[__NR_close] == (unsigned long) sys_close), можно сразу получить указатель на начало таблицы sctable = (unsigned long **)p; просто отбросив смещение от указателя p. просто нужно помнить что __NR_close это константа, а p указатель ))
1. ни разу не программер 2.
1. ни разу не программер
2. глибц, ядро
3. да, можно; надо менять таблицу сиколлов syscall number table ( ядро опериует номерами сисколлов, а не их именами) - старый вариант http://bluemaster.iu.hio.no/edu/dark/lin-asm/syscalls.html; смотри arch/x86/kernel/syscall_table_32.S как пример
4. есть; начиная от "Программирование боевого софт под линукс" ;) до серьезной литературы по каждой подсистеме.
П.С рекомендую разобратся с lsm, оно как раз умеет скрывать директории
Compute:
Bosch M2.8.1 -> custom Bosch M2.8.3 clone from Russia.
Speed about 260 km,Ram 2 pers.,HDD - 70 kg,210 FLOPS ;)
по третьему пункту. а как? я
по третьему пункту. а как? я нашёл таблицу сисколов, подменил указатель на оригинал адресом своей функции и из неё пытался вызвать оригинальный сискол. и получил проблему. по скольку я "очень далеко переместил оригинальную функцию в памяти", то при передаче параметров, которые должны были быть переданы настоящему сисколу, этот сискол возвращал мне EFAULT. когда же я попытался скопировать эти параметры сначала внутрь враппера, я не смог выделить память - с ними ядру требовалось изыскать примерно 128мб оперативки всего лишь для размещения там структуры cwd-шки с дюжиной файлов.
видел я это боевой софт. код как будто студент-недоучка писал. а вот серьёзную я не встречал, можешь подсказать что нибудь?
А почему бы не ptrace() ? :)
А почему бы не ptrace() ? :)
MSR:
http://habrahabr.ru/blogs/linux/110369/
unsigned char *ptr; for (ptr=system_call, i=0; i<500; i++) { if (ptr[0] == 0xff && ptr[1] == 0x14 && ptr[2] == 0xc5) return (void*)(0xffffffff00000000 | *((unsigned int*)(ptr+3))); ptr++; }Compute:
Bosch M2.8.1 -> custom Bosch M2.8.3 clone from Russia.
Speed about 260 km,Ram 2 pers.,HDD - 70 kg,210 FLOPS ;)