trancer
18.12.2005, 18:26
Заранее приношу извинения администрации сайта за выбранный метод комментирования, но
а) я так и не понял как можно добавить комментарий к статье
б) данный комментарий слишком длинный
посему решил создать тему на форуме(надеюсь что раздел правильно выбрал...)
>>MOV EAX, EBXM
правильно: MOV EAX, EBX
>>В интернете я встречал только одну статью, которую друг у друга украли тысячи сайтов.
можно ссылку? или хотя бы кусок текста из статьи для гугля? Лично я встречал просто море статей про переполнение
буфера, так что пребываю в состоянии весьма сильного удивления от вышеприведенной фразы...
>>Win32 - cmd.exe, command.com, Linux - /bin/bash, /bin/sh и др.
Имхо правильней WinNT - cmd.exe, Win9x - command.com, ибо обычно под Win32 понимают всю линейку Вин
>>проблема пока отпадает, ведь адрес fl() – 0x00401090, а запишем мы 0x90104000
Поскольку 0x00401090 и 0x90104000 Совершенно РАЗНЫЕ числа то лучше было бы не вводить никого
в заблуждение и написать так: проблема пока отпадает, ведь адрес fl() – 0x00401090, а РЕАЛНО ЗАПИШЕТСЯ 90 10 40 00
>>Открываем сервер отладчиком (я использую OllyDBG) и находим ее адрес.
имхо тут одно из ... либо обьясняем на пальцах как находили адрес, либо отсылаем на какой-нибудь cracklab.ru за
доками, либо обьясняем как трейсить прогу, и как обойти start-up код VC++ уповая на то что потом и сами разберуться,
либо сервак пишем используя только WinApi, отключив библиотечный код и start-up код(впринципе второе входит
в первое, но не суть важно) чтобы трейсить и находить нужные ф-ции было проще
>>Эти последнии четыре будут содержать "перевернутый" адрес 00401090.
>>Почему "перевернутый" - я говорил, что специфика стека такова, что данные должны
>>записываться наоборот, т.к. они и извлекаются оттуда наоборот. Это просто логика.
шЫдевр!!! автор браво!!! Это не специфика стека а специфика хранения двордов в памяти присущая IA-32 архитектуре
процессоров(младший байт хранится по младшему адресу). Со стеком это НИКАК не связано.
>>Я делаю так - в EIP пишу адрес команды (точнее набора байтов,
>>т.к. реально эти байты не для выполнения) JMP ESP в какой-нибудь
>>системной библиотеке. Например, найдем в ntdll.dll.
А можно рецепт зелья которое помогает посредством мысли находить нужные байты в файле?
Я это к тому что неплохо бы обьяснить как найти нужные байты... ну например хиевом,
а то так и предвкушаю поток вопросов как же их все-таки находить...
>>ESP указывает на 109-байты-нашей строки
Гы-гы откуда в строке char buffer[100]; 109-й байт?
правильнее так: ESP указывает на 109 байт от начала нашей строки в стеке
>>Используется в нем архитектура SEH - завершения.
>>Существуют ещё PROCESS и THREAD. Код в OllyDBG выглядит так:
И после этого код для получения второй части шелкода, а где же код
с "SEH - завершением" ;)
>>0012FAD6 E8 B55B9671 CALL WS2_32.recv >>>>>>>> ВЫЗОВ <<<<<<<<
это что, калл по hardcoded адресу ф-ции WS2_32.recv? Ну ну... во первых call address
зависим от текущего EIP,а пара push address / ret - нет(это к тому что а вдруг в атакуемой системе стек расположится
совсем по другому адресу - 3.14дец сплоиту! ... в недостатках метода - в стек еще нужно занести верный eip для
возврата, но это не сложно(hint: google->virii vx delta offset)), во вторых в эксплоите придется таскать помимо
адреса JMP ESP в ntdll.dll еще и адреса recv в WS2_32.
для лучшей переносимости лучше call по этому адресу:
004014C0 $-FF25 34634200 JMP DWORD PTR DS:[<&WSOCK32.#16>] ; WSOCK32.recv
Т.к. в данном случае адрес для калла зависит не от версии ОС, а от версии проги.
а нужный адрес система и сама подставит в таблицу импорта(точнее в IAT) при загрузке сервера.
>>http://int3.net
Прикол с бывшим в оригинале(см. архив) http://int13.net меня просто доконал %))))))))
А вообще как долго писалась эта статья? Интересуюсь т.к. int3.net не поднимается по-моему уже не меньше полугода...
Имхо Для начинающих лучше советовать те же cracklab.ru / xtin.km.ru.
И еще, не следует путать RE с Cracking'ом которому и был посвящен проэкт int3.net в свои лучшие дни.
----
В общем и целом же статья неплоха, расчитана на уже хоть немного, но подготовленного читателя,
а также выгодно отличается от кучи статей с тестовыми самописными прогами хотябы наличием кода для bindshell'a
P.S. надеюсь автор не обидится за столь придирчивое отношение к статье, как уже говорилось все это ИМХО
P.P.S. к шеллкодам в архиве не приглядывался, смотрел только статью
P.P.P.S. Надеюсь что все доступно обьяснил, что непонятно - спрашивайте
а) я так и не понял как можно добавить комментарий к статье
б) данный комментарий слишком длинный
посему решил создать тему на форуме(надеюсь что раздел правильно выбрал...)
>>MOV EAX, EBXM
правильно: MOV EAX, EBX
>>В интернете я встречал только одну статью, которую друг у друга украли тысячи сайтов.
можно ссылку? или хотя бы кусок текста из статьи для гугля? Лично я встречал просто море статей про переполнение
буфера, так что пребываю в состоянии весьма сильного удивления от вышеприведенной фразы...
>>Win32 - cmd.exe, command.com, Linux - /bin/bash, /bin/sh и др.
Имхо правильней WinNT - cmd.exe, Win9x - command.com, ибо обычно под Win32 понимают всю линейку Вин
>>проблема пока отпадает, ведь адрес fl() – 0x00401090, а запишем мы 0x90104000
Поскольку 0x00401090 и 0x90104000 Совершенно РАЗНЫЕ числа то лучше было бы не вводить никого
в заблуждение и написать так: проблема пока отпадает, ведь адрес fl() – 0x00401090, а РЕАЛНО ЗАПИШЕТСЯ 90 10 40 00
>>Открываем сервер отладчиком (я использую OllyDBG) и находим ее адрес.
имхо тут одно из ... либо обьясняем на пальцах как находили адрес, либо отсылаем на какой-нибудь cracklab.ru за
доками, либо обьясняем как трейсить прогу, и как обойти start-up код VC++ уповая на то что потом и сами разберуться,
либо сервак пишем используя только WinApi, отключив библиотечный код и start-up код(впринципе второе входит
в первое, но не суть важно) чтобы трейсить и находить нужные ф-ции было проще
>>Эти последнии четыре будут содержать "перевернутый" адрес 00401090.
>>Почему "перевернутый" - я говорил, что специфика стека такова, что данные должны
>>записываться наоборот, т.к. они и извлекаются оттуда наоборот. Это просто логика.
шЫдевр!!! автор браво!!! Это не специфика стека а специфика хранения двордов в памяти присущая IA-32 архитектуре
процессоров(младший байт хранится по младшему адресу). Со стеком это НИКАК не связано.
>>Я делаю так - в EIP пишу адрес команды (точнее набора байтов,
>>т.к. реально эти байты не для выполнения) JMP ESP в какой-нибудь
>>системной библиотеке. Например, найдем в ntdll.dll.
А можно рецепт зелья которое помогает посредством мысли находить нужные байты в файле?
Я это к тому что неплохо бы обьяснить как найти нужные байты... ну например хиевом,
а то так и предвкушаю поток вопросов как же их все-таки находить...
>>ESP указывает на 109-байты-нашей строки
Гы-гы откуда в строке char buffer[100]; 109-й байт?
правильнее так: ESP указывает на 109 байт от начала нашей строки в стеке
>>Используется в нем архитектура SEH - завершения.
>>Существуют ещё PROCESS и THREAD. Код в OllyDBG выглядит так:
И после этого код для получения второй части шелкода, а где же код
с "SEH - завершением" ;)
>>0012FAD6 E8 B55B9671 CALL WS2_32.recv >>>>>>>> ВЫЗОВ <<<<<<<<
это что, калл по hardcoded адресу ф-ции WS2_32.recv? Ну ну... во первых call address
зависим от текущего EIP,а пара push address / ret - нет(это к тому что а вдруг в атакуемой системе стек расположится
совсем по другому адресу - 3.14дец сплоиту! ... в недостатках метода - в стек еще нужно занести верный eip для
возврата, но это не сложно(hint: google->virii vx delta offset)), во вторых в эксплоите придется таскать помимо
адреса JMP ESP в ntdll.dll еще и адреса recv в WS2_32.
для лучшей переносимости лучше call по этому адресу:
004014C0 $-FF25 34634200 JMP DWORD PTR DS:[<&WSOCK32.#16>] ; WSOCK32.recv
Т.к. в данном случае адрес для калла зависит не от версии ОС, а от версии проги.
а нужный адрес система и сама подставит в таблицу импорта(точнее в IAT) при загрузке сервера.
>>http://int3.net
Прикол с бывшим в оригинале(см. архив) http://int13.net меня просто доконал %))))))))
А вообще как долго писалась эта статья? Интересуюсь т.к. int3.net не поднимается по-моему уже не меньше полугода...
Имхо Для начинающих лучше советовать те же cracklab.ru / xtin.km.ru.
И еще, не следует путать RE с Cracking'ом которому и был посвящен проэкт int3.net в свои лучшие дни.
----
В общем и целом же статья неплоха, расчитана на уже хоть немного, но подготовленного читателя,
а также выгодно отличается от кучи статей с тестовыми самописными прогами хотябы наличием кода для bindshell'a
P.S. надеюсь автор не обидится за столь придирчивое отношение к статье, как уже говорилось все это ИМХО
P.P.S. к шеллкодам в архиве не приглядывался, смотрел только статью
P.P.P.S. Надеюсь что все доступно обьяснил, что непонятно - спрашивайте