Comments 32
Ух ты. Если вы и правда девушка, выходите за меня замуж.
1) sys_call_table не просто так перестали экспортировать как символ из ядра, подмена адресов чревата паникой, если один и тот же сискол перехватывают два модуля, а потом они выгружаются в том же порядке, что и были загружены, а не в обратном.
2) в /boot этого файла может и не быть, имеет смысл смотреть /proc/kallsyms, причём, возможно, даже не на этапе компиляции, а из самого модуля.
3) перехват сискола — это не подмена обработчика прерываний, а лишь замена одной из функций, на которую передаёт управление обработчик инструкции sysenter, прерывания же для входа в режим ядра давно не используются.
2) в /boot этого файла может и не быть, имеет смысл смотреть /proc/kallsyms, причём, возможно, даже не на этапе компиляции, а из самого модуля.
3) перехват сискола — это не подмена обработчика прерываний, а лишь замена одной из функций, на которую передаёт управление обработчик инструкции sysenter, прерывания же для входа в режим ядра давно не используются.
спасибо, я приму к сведению.
Первая проблема на самом деле имеет три решения:
1) (деревянное) Отказываться выгружать модуль при наличии более поздних изменений в sys_call_table
2) (костыль) Менять адрес не на адрес своей функции, а на адрес сгенерированной заглушки, первоначально содержащей безусловный переход на свой код, а при выгрузке модуля менять адрес перехода на оригинал, не трогая при этом sys_call_table. Поскольку эта заглушка так и останется висеть в памяти после выгрузки модуля, мы гарантируем, что никак не влияем на то, что было загружено после нас.
3) (правильное) Соорудить отдельный модуль, занимающийся подобными цепочками перехватчиков, выложить на гитхаб, вывести в топ гугла по «linux intercept syscall».
1) (деревянное) Отказываться выгружать модуль при наличии более поздних изменений в sys_call_table
2) (костыль) Менять адрес не на адрес своей функции, а на адрес сгенерированной заглушки, первоначально содержащей безусловный переход на свой код, а при выгрузке модуля менять адрес перехода на оригинал, не трогая при этом sys_call_table. Поскольку эта заглушка так и останется висеть в памяти после выгрузки модуля, мы гарантируем, что никак не влияем на то, что было загружено после нас.
3) (правильное) Соорудить отдельный модуль, занимающийся подобными цепочками перехватчиков, выложить на гитхаб, вывести в топ гугла по «linux intercept syscall».
Не, серьёзно, вы решили совсем другую задачу, не имеющую отношения к подмене обработчика прерываний.
я уж думал, что никому мой пост не пригодится, и он сгинет в анналах истории
отличная попытка, о небритый чувак в полосатом свитере)
зря вы так…
У вас удивительная способность тупить или ну чересчур жирный троллинг. А ведь профайл автора в линкедин находится в несколько секунд, с фотографией:
Печально будет, если module_exit вызовут во время исполнения newwrite. // и это не говоря о гонках в случае одновременной замены обработчика. Попробуйте «lock xchg»
P.S. я мог всё позабыть, но если объявить extern void *sys_call_table — оно не свяжет само как надо? Ну или заиспользовать find_sym( «sys_call_table» )?
P.P.S. а почему unlockWP очищает бит, а lockWP инвертирует?
P.S. я мог всё позабыть, но если объявить extern void *sys_call_table — оно не свяжет само как надо? Ну или заиспользовать find_sym( «sys_call_table» )?
P.P.S. а почему unlockWP очищает бит, а lockWP инвертирует?
2. Признаюсь, не пробовала.
3. с защитой делала как здесь
3. с защитой делала как здесь
3. Я бы вообще обошёлся без lockWP, сохранив старое значение cr0, благо свободных регистров уйма.
4. Ещё меня смущает «call far rax». Я, конечно, не знаток x64, но разве он не должен принимать 2+8 байт, дабы перезагрузить cs:rip (впрочем, зачем нам cs перегружать, мы ж уже в правильном). А судя по «Instruction Set Reference» принимать регистр может только near call.
4. Ещё меня смущает «call far rax». Я, конечно, не знаток x64, но разве он не должен принимать 2+8 байт, дабы перезагрузить cs:rip (впрочем, зачем нам cs перегружать, мы ж уже в правильном). А судя по «Instruction Set Reference» принимать регистр может только near call.
3. значение cr0 в регистр не хотелось пихать потому, как значение то в регистре могу забыть и подпортить, а так наверняка нужный бит сниму и установлю.
4. А вот тут я не скажу, я сама, как и в статье писала, с ассемблером 64-битным до этого не встречалась вообще, так что знатоком его быть также не являюсь. call rax не заработало, поэтому и «впаяла» far, таить не буду)
4. А вот тут я не скажу, я сама, как и в статье писала, с ассемблером 64-битным до этого не встречалась вообще, так что знатоком его быть также не являюсь. call rax не заработало, поэтому и «впаяла» far, таить не буду)
если объявить extern void *sys_call_table — оно не свяжет само как надо?
Связалось бы, если бы sys_call_table был экспортирован.
или заиспользовать find_sym
Не даёт доступа к большему количеству символов ядра, просто позволяет линковаться с заранее неизвестным символом.
extern void *sys_call_tableЯдро с определённой версии этот символ не экспортирует. Причём довольно давно.
Молодец, у меня одногруппницы все пытались только где то купить все курсовые и лабы…
Не хотите испытать удачу в настоящем ассемблерном проекте? Мы как раз сейчас ищем студентов на подработку на лето: board.kolibrios.org/viewtopic.php?f=23&t=2326
Спасибо за предложение, но боюсь, что знаний не хватит
Вы себя недооцениваете :-)
Я знаю раз в 10 меньше Вашего, что не мешает мне помогать проекту по мере своих сил.
Плюс ко всему, Вам будет на кого равняться!
Я знаю раз в 10 меньше Вашего, что не мешает мне помогать проекту по мере своих сил.
Плюс ко всему, Вам будет на кого равняться!
Sign up to leave a comment.
Подмена обработчика системного вызова