Подмена обработчика системного вызова

[pfactum]

Ух ты. Если вы и правда девушка, выходите за меня замуж.

[aronsky]

Интересно, сколько людей написали бы подобный комментарий, если бы ваш не заминусовали?
(Увидев любимую тему оформления окон я и сам готов был написать подобный комментарий, если бы не имена папок кириллицей.)

[aleksandra_pyshko]

был вариант скринов с франкоязычными названиями папок, но тоже не торт :)

[ekungurov]

Интересно, сколько людей написали бы подобный комментарий, если бы ваш не заминусовали

Двенадцать.

[aronsky]

Вы ждали, когда за комментарий нельзя будет голосовать, чтоб написать окончательное число? )

[kekekeks]

1) sys_call_table не просто так перестали экспортировать как символ из ядра, подмена адресов чревата паникой, если один и тот же сискол перехватывают два модуля, а потом они выгружаются в том же порядке, что и были загружены, а не в обратном.
2) в /boot этого файла может и не быть, имеет смысл смотреть /proc/kallsyms, причём, возможно, даже не на этапе компиляции, а из самого модуля.
3) перехват сискола — это не подмена обработчика прерываний, а лишь замена одной из функций, на которую передаёт управление обработчик инструкции sysenter, прерывания же для входа в режим ядра давно не используются.

[aleksandra_pyshko]

спасибо, я приму к сведению.

[kekekeks]

Первая проблема на самом деле имеет три решения:
1) (деревянное) Отказываться выгружать модуль при наличии более поздних изменений в sys_call_table
2) (костыль) Менять адрес не на адрес своей функции, а на адрес сгенерированной заглушки, первоначально содержащей безусловный переход на свой код, а при выгрузке модуля менять адрес перехода на оригинал, не трогая при этом sys_call_table. Поскольку эта заглушка так и останется висеть в памяти после выгрузки модуля, мы гарантируем, что никак не влияем на то, что было загружено после нас.
3) (правильное) Соорудить отдельный модуль, занимающийся подобными цепочками перехватчиков, выложить на гитхаб, вывести в топ гугла по «linux intercept syscall».

[jcmvbkbc]

Не, серьёзно, вы решили совсем другую задачу, не имеющую отношения к подмене обработчика прерываний.

[aleksandra_pyshko]

я уже поняла…

[ultral]

я уж думал, что никому мой пост не пригодится, и он сгинет в анналах истории

[mx2000]

отличная попытка, о небритый чувак в полосатом свитере)

[aleksandra_pyshko]

зря вы так…

[dlinyj]

Не ведитесь на троллей.

А пост бесценный, спасибо вам за информацию к размышлению!

[aleksandra_pyshko]

и вам merci :)

[viktorious]

У вас удивительная способность тупить или ну чересчур жирный троллинг. А ведь профайл автора в линкедин находится в несколько секунд, с фотографией:

[mx2000]

я же говорил, что свитер полосатый!

а если серьезно, вы еще удивитесь, когда узнаете, чей это профиль на самом деле.

[aleksandra_pyshko]

okay

[agmt]

Печально будет, если module_exit вызовут во время исполнения newwrite. // и это не говоря о гонках в случае одновременной замены обработчика. Попробуйте «lock xchg»
P.S. я мог всё позабыть, но если объявить extern void *sys_call_table — оно не свяжет само как надо? Ну или заиспользовать find_sym( «sys_call_table» )?
P.P.S. а почему unlockWP очищает бит, а lockWP инвертирует?

[aleksandra_pyshko]

2. Признаюсь, не пробовала.
3. с защитой делала как здесь

[agmt]

3. Я бы вообще обошёлся без lockWP, сохранив старое значение cr0, благо свободных регистров уйма.
4. Ещё меня смущает «call far rax». Я, конечно, не знаток x64, но разве он не должен принимать 2+8 байт, дабы перезагрузить cs:rip (впрочем, зачем нам cs перегружать, мы ж уже в правильном). А судя по «Instruction Set Reference» принимать регистр может только near call.

[aleksandra_pyshko]

3. значение cr0 в регистр не хотелось пихать потому, как значение то в регистре могу забыть и подпортить, а так наверняка нужный бит сниму и установлю.
4. А вот тут я не скажу, я сама, как и в статье писала, с ассемблером 64-битным до этого не встречалась вообще, так что знатоком его быть также не являюсь. call rax не заработало, поэтому и «впаяла» far, таить не буду)

[agmt]

3. Так с чего ж забудется, если там совсем небольшой код? // вопрос к знатокам: надо ли этот код обрамлять cli/sti (я бы сделал)?
4. Хммм, а вот это странно — видать, причуда nasm. У меня call принял, а call far:«a.S:12: warning: register size specification ignored». nasm 2.10.01.

[aleksandra_pyshko]

3. не знаю)
4. думаю, как вариант

[jcmvbkbc]

если объявить extern void *sys_call_table — оно не свяжет само как надо?

Связалось бы, если бы sys_call_table был экспортирован.

или заиспользовать find_sym

Не даёт доступа к большему количеству символов ядра, просто позволяет линковаться с заранее неизвестным символом.

[kekekeks]

extern void *sys_call_table

Ядро с определённой версии этот символ не экспортирует. Причём довольно давно.

[dezconnect]

Молодец, у меня одногруппницы все пытались только где то купить все курсовые и лабы…

[aleksandra_pyshko]

благодарю)

[yogev_ezra]

Не хотите испытать удачу в настоящем ассемблерном проекте? Мы как раз сейчас ищем студентов на подработку на лето: board.kolibrios.org/viewtopic.php?f=23&t=2326

[aleksandra_pyshko]

Спасибо за предложение, но боюсь, что знаний не хватит

[yogev_ezra]

Вы себя недооцениваете :-)
Я знаю раз в 10 меньше Вашего, что не мешает мне помогать проекту по мере своих сил.
Плюс ко всему, Вам будет на кого равняться!

[aleksandra_pyshko]

Увы, но мне так не кажется)))