Пробежавшись по абзацам про Thunder, Silver, Ruby, Алана Купера сложилось впечатление, что вы вдохновлялись вот этой статьей. Угадал?
Но мимо этого я не мог пройти:
Спольски убедил команду разработки добавить в язык тип Variant — переменные, которые могли содержать любой другой тип. Это позволяло сохранять содержимое ячейки электронной таблицы в переменной без оператора switch. Также было добавлено позднее связывание (через IDispatch), конструкция ForEach, украденная из С#, и With из Паскаля.
Вы серьёзно? For Each Джоэль позаимствовал не из C-Sharp'а, а из CSH — скриптового языка для написания шелл-скриптов, который появился на 32 года раньше Шарпа. C# и csh это не одно и то же. Да и как можно было допустить мысль, что до си-шарпа такой конструкции ни в одном другом языке не было?
В конце концов, даже если не знать ничего про csh, как при создании Excel Basic'а (который позже стал VBA и VB), которое происходило на рубеже 80-х и 90-х, можно было позаимствовать что-то из C#, до появления которого оставалось ещё 10 лет? Это как писать, что Аристотель позаимствовал что-то из трудов Ленина.
Когда я получал водительское удостоверение и посещал психноневрологический диспансер в рамках медкомиссии, врачи сперва начали провоцировать меня на конфликт. Затем, поняв, что на провокацию я на поддаюсь, и узнав мои профессиональные наклонности, начали задавать какие-то странные и в чём-то нелепые вопросы на тему проблем с компьютером.
До сих пор думаю, что это был такой «экспресс-тест на психопата и неадеквата»; при этом интересно, ко всем ли они применяют такой подход, или что-то в моём поведении или образе им сходу показалось подозрительным.
Уже забыл, как в точности провоцировался конфликт, но общая формула создания конфликтной ситуации примерно следующая:
Подробности общения с врачами
1. Вы заходите в кабинет, и вам говорят «садитесь».
2. Вы окидываете взглядом кабинет, и видите, что рядом со столом, за котором сидит врач и медсестра, нет стула, предназначенного для вас.
3. «Куда садиться?» — спрашиваете вы.
4. «Вот сюда» — вам показывают рукой на то место, где по идее должен стоять стул.
5. «Но здесь нет стула», возражаете вы.
6. «У тебя глаз или нет или как?» — надменно начинает хамить врачиха, перейдя на «ты».
7. «В смысле?»
8. «Ты сюда в кабинет заходил, не видел, что в коридорчике стоит стул?»
9. «Ну...»?
10. «Он тебе что? Не годится??? Или тебе какой-то особенный стул нужен?»
11. «Эээ....»
12. «Ну так пройди тиуда, возьми, переставь его сюда и сядь! В чём проблема? Или мы тебе ещё стулья должны подносить, как барину? Тут лакеев нет, знаешь ли?»
13. Но дальше хамские интонации отключаются и разговор продолжается в более-менее мирном русле.
По-моему ещё был какой-то аналогичный подкол на тему заполнения бумаг (вписать в бланк свои паспортные данные я должен был сам, они бы только подпись поставили), не помню к чему именно относилась фраза по лакеев, но сама фраза запомнилась очень хорошо.
В общем, спектакль заключался в том, чтобы максимально хамски и оскорбительно вести себя по отношению к «пациенту». Я сходу предположил, что прямо сейчас передо мной разыгрывается спектакль и что надо не поддаться на провокации. А так они ведут себя таким образом, чтобы по максимуму вызвать у тебя желание развернуться и, хлопнув дверью, уйти со словами «да подавитесь вы своей справкой».
После нескольких дежурных вопросов, включая вопрос «чем занимаетесь?», разговор продолжился в духе того, что а вот у моей дочки/подруги/сестры есть такие-то проблемы с компьютером. «Чем это может быть вызвано?».
Дальше набор симптомов компьютерной проблемы на ходу переиначивался, дополнялся новыми подробностями, задавались уточняющие вопросы, которые были всё глупее и глупее. Возможно замысел был в том, что если человек выдержал испытание хамством, он может «взорваться» на стадии «тупых и назойливых вопросов».
Исходники далеко не полные. Нет, к примеру, кода oleaut32.dll. Это, конечно, не относится к описанным здесь проблемам, но и части ядерных вещей недосчитаешься.
Ситуация «выделили гигабайт, записали 1 байт» ведь из этой серии? Что-то не верится, что менеджер памяти любой современной ОС настолько глупый, что не может оптимизировать эту ситуацию.
Вы это про Windows или про nix-системы говорите?
Если про Windows, то что сейчас, что 20 лет назад, ничего подобного не практиковалось.
Когда вы выделяете 1 гигабайт памяти с помощью VirtualAlloc, создаётся структура MMVAD (она является узлом дерева, всё дерево хранит всю карту выделенных или зарезервированных областей виртуального АП отдельно взятого процесса, точнее «пользовательской» части всего АП), в которую заносятся параметры выделения (база, размер, параметры защиты страниц).
Никаких страниц физической памяти или файла подкачки, ассоциированных со страницами этого гигабайтного региона, в момент выделения памяти не выделяется.
Единственное, что есть такой счётчик как «page file quota», от которого минусуется количество выделенных страниц — этот счётчик не даёт всем процессам в сумме выделить больше страниц, чем теоретически может обеспечить файл подкачки.
Когда вы попробуете записать тот пресловутый 1 байт, произойдёт page fault, который ОС разрулит незаметным для процесса образом — странице виртуального АП, в которую был записан 1 байт, начнёт соответствовать некая страница физической памяти. Эта страница физической памяти будет выбрана из списка заблаговременно заготовленных занулённых страниц, а если таких готовых страниц на данный момент нет — будет занулена прямо сейчас (что дольше, чем если брать из простаивающих занулённых).
В случае, если ОС будет испытывать недостаток страниц физпамяти, страница физпамяти, соответствующая странице виртуального АП, в которую был записан 1 байт, будет сброшена в файл подкачки, а при необходимости затем подгружена.
Все остальные остальные страницы этого гигабайтного региона по прежнему будут существовать только номинального — не более, чем как числа в структуре MMVAD. Никаких страничных фреймов физической памяти или страничных фреймов файла подкачки им (без необходимости) соответсововать не будет.
32битные ОС поддерживают больше 4Гб через PAE, про который вы кстати и говорите
Я прекрасно знаю об этом, но в XP поддержка физпамяти больше 4 Гб принудительно зарезана. Где только я говорил про PAE, не могу понять? В комментариях к этой публикации я PAE не упоминал — разве что в комментах к другим статьям мог где-то сказать про PAE в рамках развенчания мифа про лимит в 4 Гб для 32-битных систем, налагаемый, якобы, архитектурой.
Вы можете испытывать проблемы из-за того, что упираетесь в ограничение на суммарный объём структур, описывающих всю выделенную память, которые сами располагаются в неподкачиваемой зоне.
Вот я сижу на 32-битной ОС, объём поддерживаемой физпамяти ограничен числом чуть меньшим, чем 4 Гб. При этом у меня огромный файл подкачки, размещённый на специально выделенном ради этого SSD-диске. Естественно у меня процессов, выдеряющих огромные объёмы, сумма которых больше, чем объём всей физпамяти на порядок.
Ладно, оставим без комментариев ваше показное пренебрежение к 32-битному софту и 32-битной архитектуре как таковой.
Вам не приходило в голову, что и 16-битный софт под DOS кому-то может быть интересно или нужно реверсить хотя бы потому, что люди хотят функциональность перенести на более современные рельсы? Вот есть софт под DOS, который управляет станком, а хочется, чтобы был подо что-то современное. Но ни документации, ни исходников, ничего.
Нет, не путаю. MEM_RESERVE — это не резервирование памяти, а резервирование адресного пространства.
Это какая-то терминологическая демагогия пошла. Общепринято, что более гибкий и многозначный термин «память» используют часто как синоним понятия «адресное пространство».
В любом случае, вы написали
Резервировать сразу огромное количество виртуальной памяти — достаточно плохая практика, потому что у нас сразу появляются расходы
Можете сделать процесс, который резервирует 1 Гб (или вообще все свободные регионы) своего адресного пространства (после чего засыпает или зацикливается), и запустить 200 таких процессов. Никакие системные ресурсы не исчерпаются. Будет потрачено 200 фрагментов неподкачиваемого пула ядра на структуры MMVAD_SHORT. Ровно столько же было бы потрачено, если бы процесс закоммитил 200 несмежных 4-килобайтных страниц (800 кб в общей сумме).
Резервировать сразу огромное количество виртуальной памяти — достаточно плохая практика, потому что у нас сразу появляются расходы на хранение таблицы страниц: 32 бит под каждую страницу.
Не могу говорить о всех операционных системах на свете, но к Windows ваши слова точно не применимы.
Во-первых, похоже, что вы путаете резервирование (MEM_RESERVE) и выделение (MEM_COMMIT) страниц. Прочитайте статью об устройстве виртуальной памяти в Windows, которую tyomitch написал в далёком 2006 году. Если не хотите читать, то коротко: разница между резервированием и выделением страниц такая же, как между бронированием номеров в гостинице и заселением в них. Вы не сможете создать дефицит чистого постельного белья в городе, даже если забронируете все номера всех гостиниц в нём (но не станете никем из заселять).
Во-вторых, даже если вы не резервируете, а именно выделяете какое-то количество страниц с помощью VirtualAlloc(), последняя лишь создаёт (или обновляет) структуру MMVAD_SHORT, описывающую диапазон страниц, но совершенно никак не обновляет таблицы страниц, не инициализируя новые PDE или PTE.
Инициализация/создание новых PDE/PTE происходит лишь при первом обращении к соответствующей странице. Когда происходит первый page fault при попытке доступа к ней. То есть каталог страниц обновляется только по мере необходимости (on demand).
Не верите: можете раздобыть утёкшие исходники ядра и прочитать от корки до корки исходники ядерной функции NtAllocateVirtualMemory (VirtualAlloc лишь переходник к ней). Единственным исключением является вызов VirtualAlloc с флагом MEM_PHYSICAL.
видны некоторые прямо таки детские ошибки, так сказать, за автора обидно.
Огласите весь список, пожалуйста :) Если вы пишите «ошибки», значит их много? Отсутствие автосохранения — одна из них?
Ну напрашивается же все это объединить и заставить ваш плагин сохранять данные периодически,
Замысел хороший, но сразу после появления плагина стал очевиден способ спасения данных, описанный в первой половине статьи (перенаправление выполнения на код процедуры MudDoSave из плагина), автосохранение не рассматривалось как нужная фича, без которой нельзя жить и на которую не жалко тратить время. Ну разве что против внезапного отключения электричества или BSOD-а, но таких случаев может и не было вообще.
Но идея хорошая, я подумаю над автосохранением, правда я считаю, что идеологически неверно запихивать эту функциональность в плагин Markup Dumper — это должен быть отдельный плагин, какой-нибудь OllyAutosave.
Странная проблема с недоступностью отладчика, который на отвалившемся диске, что аж пришлось свою утилиту-дампер писать… Не проще ли было установить Olly на тот диск, который у вас был живой?
Странный комментарий. Имеется в виду установить OllyDbg на живой диск заведомо, подозревая диск (на котором живёт том H:\) в нездоровости заранее? Или установить OllyDbg на другой диск уже после того, как диск с томом H:\ отвалился? Я надеюсь, что вы имели в виду второй вариант.
Если так, то вы невнимательно читали статью.
Во-первых, как я по вашему реверсил Insertname() после аппаратного сбоя, если не установил OllyDbg на другой диск? Конечно же OllyDbg был сразу же установлен на другой том другого диска из резервного хранилища, чтобы начать работы по разрешению ситуации.
Во-вторых, утилиту-дампер пришлось писать не потому, что OllyDbg стал недоступным для использования из-за отвала, а потому что был риск, что OllyDbg при подключении к полумёртвому процессу (коим был тоже OllyDbg) запнётся и завершится. А когда отладчик завершается, не вызвав перед этим DebugActiveProcessStop(), отлаживаемый процесс уничтожается вместе с процессом-отладчиком. Тогда бы я окончательно потерял спасаемые данные.
Т.е. утилита-дампер писалась ровно из тех соображений, чтобы воздействие на «коматозный» процесс было минимально инвазивным. Четыре аккуратных и точных вызова ReadProcessMemory должно было стать меньшим из возможных зол. Я даже не был уверен, что ReadProcessMemory() вообще сработает в отношении этого процесса и сможет прочесть хоть что-нибудь. Это сейчас примерно понятно, что произошло, а в тот момент не было уверенности, что адресное пространство сохранилось хотя бы частично (в Windows объект-процесс может существовать, а адресное пространство как совокупность структур PDE+PTE с одной стороны, и MMVAD с другой стороны — могут не существовать; на каких-то этапах жизненного цикла объекта-процесса это так). Кто мог в первые минуты гарантировать, что всё произошло именно из-за аппаратного сбоя, а не потому, что какие-то ядерные структуры были повреждены каким-то глючным драйвером?
Если вы внимательно читали, то видели, что сначала я собирался сдампить все закоммиченные страницы умирающего процесса, разобраться со сбоями, перезагрузиться, а потом уже в дампе находить нужное, не боясь, что вот-вот случится BSOD. Но Process Explorer не мог создать дамп, падал с ошибкой.
Причём было не удивительно, что он падал: если страница нечитаема, потому что механизм подкачки не может её подгрузить, то и ReadProcessMemory, которым пользуется любой дампер, её контент прочитать откуда-то волшебным образом не сможет. Был бы дампер, который читал не все подряд страницы. а только нужные — он бы не падал. Но нужно было знать, какие именно страницы читать, для чего и был начат реверсинг. А если знать, что читать нужно два больших блока плюс маленький кусочек с метаданными, зачем мне было искать подходящий дампер, если быстрее было написать его самому?
Продавать, чтобы Чип-и-Дип для своего хранилища использовал систему, или чтобы он её продавал радиолюбителям?
Если первое, то там масштабы такие, что не кассетницы нужны, а фидеры для pick-and-place-машин, отрезающие нужное количество деталей с катушки с лентой. А второе, то с их накрутками кто такую систему сможет себе позволить?
А отладчик — эт чтобы посмотреть как же там все на самом деле.
Но ведь IDA Pro умеет присоединяться к существующему процессу и выступать отладчиком. Зачем тогда нужна Olly?
Дело в привычке. Я тоже пользуюсь Олей лет 15, и все действия в ней делаю уже как пулемёт. А IDA Pro всегда отталкивала нездоровой атмосферой вокруг Ильфака и его отношением к поддержке и пиратству. Окей, у вас платный продукт, а я воспользуюсь бесплатным инструментом, а для того, что он не умеет, сделаю собственные инструменты — вот так я примерно всегда размышлял.
За 13 лет использования Olly, кстати, не могу припомнить прямо-таки падений-зависаний в ней. Но я ничего и не аннотирую, да
Аннотации не влияют на вероятность зависания и вылета. Правда, длинные аннотации, создаваемые плагинами в нарушение спецификации, могут провоцировать вылеты, об этом я написал.
Просто если не аннотировать, вылеты не так критичны и не воспринимаются, как маленькие трагедии.
А зависания, как я уже писал, происходят по вине win32k.sys, в основном. Например, жмёшь в Olly Ctrl+C и она зависает намертво. Смотришь Process Explorer-ом бэктрейс основного потока — там вызов SetClipboardData из OllyDbg, из неё идёт вызов user32!_NtUserSetClipboardData@12, а это лишь переходничок, делающий SYSENTER. Дальше код уже продолжается в режиме ядра. И где-нибудь там оно висит. Аннотации тут явно не причём. Тут виноваты какие-то system-wide объекты синхронизации. Тот же буфер обмена — если один процесс открыл его с помощью OpenClipboard() и завис, другие процессы сессии не могут работать с буфером обмена.
В подобных случаях не не переключался на отладку ядерной части системы — а то это могло зайти далеко. Был у меня случай, когда я реверсил «железный» музыкальный синтезатор фирмы Roland, и использовал цифровой осциллограф, управляемый с компьютера через SCPI (GPIB), чтобы программировать его на отлов нужных событий, автоматизированно захватывать их анализировать. В реализации SCPI осциллографа была найдена дыра, позволяющая получаь доступ к прошивке осциллографа. Реверс-инжиниринг синтезатора плавно перетёк в реверс-инжиниринг осциллографа. В итоге ни то, ни другое не было доведено до конца.
Спасибо. Есть ли смысл публиковать плагин Markup Dumper, обозревать его применение в контексте ведения распределённого командного реверсинга? Есть смысл публиковать статью об упомянутых ARG-файлах?
как мне кажется, было бы интеренеснее оживить
Честно говоря, мне интереснее было бы доделать собственный инструмент для отладки и реверс-инжиниринга, сделать «отладчик своей мечты», устранив все бесящие и нереализованные моменты Ольки, притащив туда вкусные и желанные фишки из IDA, и т.п.
Собственно говоря, это не эфемерная мечта: у меня уже давно (лет 14 как) лежит написанный классный и быстрый дизассемблирующий/ассемблирующий движок, который может удобно расширяться. Есть к дизассемблирующей половинке этого движка GUI-примочка, показывающая отдельную процедуру либо в плоском виде, как это делает OllyDbg (даже интерфейс скопирован один в один), либо в виде графа, как делает IDA. Есть самописный простенький отладчик (tinydbg), правда у него не графический, а совершенно дубовый текстовый интерфейс (не с использованием псевдографики в консольном окне, а именно сугубо текстовый «диалог» с отладчиком) — его единственное преимущество в том, что антиотладочные приёмы, которые основываются на слабых местах популярных отладчиков, на него не действуют, а так же тем, что любую нестандартную команду или функцию я в него могу добавить сразу же, как возникнет такая необходимость, и мне не надо будет искать нужный плагин или придумать, как ограниченным инструментарием скриптинга реализовать какую-нибудь пошаговую деобфускацию отлаживаемого процесса. Есть собственный вьювер DBG/PDB-файлов, собственный вьювер COFF.
Остаётся только объединить кучу собственных разрозненных и сырых утилит в мощный и доделанный конгломерат.
И конечно, я говорю сейчас о собственном интересе. Так сказать, с точки зрения научного интереса было бы интереснее написать собственный инструмент. Список мастхев фич сформирован уже давно.
А вот с точки зрения практической, конечно, более перспективно возраждать или поддерживать инструмент, у которго уже есть имя, репутация, комьюнити и своя экосистема, чем пробивать дорогу чему-то совершенно новому.
Как вариант, можно реализовать в виде плагина, в нем установить свой VEH обработчик и при возникновении исключения делать дамп.
Непонятно, почему автор OllyDbg не обернул все обращения из хоста в плагины в __try ... __except и сам не сделал какого-нибудь аварийного автосохранения в фильтре необработанных исключений. Даже VirtualDub имеет какой-то нестандартный top-level хендер для исключений, показывающий и контекст потока, и дизасм проблемного места, хотя, казалось бы, мультимедийной утилите такой функционал не обязателен, а вот в коде отладчика уже есть многий инструментарий для реализации подобной плюшки, но самой плюшки и вообще хоть какого-то аварийного процессинга исключений внутри самого себя — нет.
Вообще, писать подобный плагин-автодампер для себя я не вижу особого смысла. У меня есть пара утилит, упомянутых в статье: memdumper.exe и extractor.exe. В случае проблемы достаточно вызвать
memdumper 12345
extractor ./ > emerg-dump.txt
У этого подхода есть один неоспоримый плюс: спасительные утилиты находятся вне зоне поражения сошедшего с ума кода. А вот плагин-спасатель может сам оказаться повреждён, ведь он разделяет с умирающим отладчиком одно адресное пространство.
Не знаю как в первой версии, а во второй функция сохранения в udd принимает указатель на t_module
А в первой версии такой API нет вообще. Но даже если бы была, я ведь упомянул, что есть за OllyDbg грешок тихо портить UDD при сохранении.
Сосед с перфоратором — теперь и на Марсе.
Пробежавшись по абзацам про Thunder, Silver, Ruby, Алана Купера сложилось впечатление, что вы вдохновлялись вот этой статьей. Угадал?
Но мимо этого я не мог пройти:
Вы серьёзно? For Each Джоэль позаимствовал не из C-Sharp'а, а из CSH — скриптового языка для написания шелл-скриптов, который появился на 32 года раньше Шарпа. C# и csh это не одно и то же. Да и как можно было допустить мысль, что до си-шарпа такой конструкции ни в одном другом языке не было?
В конце концов, даже если не знать ничего про csh, как при создании Excel Basic'а (который позже стал VBA и VB), которое происходило на рубеже 80-х и 90-х, можно было позаимствовать что-то из C#, до появления которого оставалось ещё 10 лет? Это как писать, что Аристотель позаимствовал что-то из трудов Ленина.
Чьи требования?
До сих пор думаю, что это был такой «экспресс-тест на психопата и неадеквата»; при этом интересно, ко всем ли они применяют такой подход, или что-то в моём поведении или образе им сходу показалось подозрительным.
Уже забыл, как в точности провоцировался конфликт, но общая формула создания конфликтной ситуации примерно следующая:
2. Вы окидываете взглядом кабинет, и видите, что рядом со столом, за котором сидит врач и медсестра, нет стула, предназначенного для вас.
3. «Куда садиться?» — спрашиваете вы.
4. «Вот сюда» — вам показывают рукой на то место, где по идее должен стоять стул.
5. «Но здесь нет стула», возражаете вы.
6. «У тебя глаз или нет или как?» — надменно начинает хамить врачиха, перейдя на «ты».
7. «В смысле?»
8. «Ты сюда в кабинет заходил, не видел, что в коридорчике стоит стул?»
9. «Ну...»?
10. «Он тебе что? Не годится??? Или тебе какой-то особенный стул нужен?»
11. «Эээ....»
12. «Ну так пройди тиуда, возьми, переставь его сюда и сядь! В чём проблема? Или мы тебе ещё стулья должны подносить, как барину? Тут лакеев нет, знаешь ли?»
13. Но дальше хамские интонации отключаются и разговор продолжается в более-менее мирном русле.
По-моему ещё был какой-то аналогичный подкол на тему заполнения бумаг (вписать в бланк свои паспортные данные я должен был сам, они бы только подпись поставили), не помню к чему именно относилась фраза по лакеев, но сама фраза запомнилась очень хорошо.
В общем, спектакль заключался в том, чтобы максимально хамски и оскорбительно вести себя по отношению к «пациенту». Я сходу предположил, что прямо сейчас передо мной разыгрывается спектакль и что надо не поддаться на провокации. А так они ведут себя таким образом, чтобы по максимуму вызвать у тебя желание развернуться и, хлопнув дверью, уйти со словами «да подавитесь вы своей справкой».
После нескольких дежурных вопросов, включая вопрос «чем занимаетесь?», разговор продолжился в духе того, что а вот у моей дочки/подруги/сестры есть такие-то проблемы с компьютером. «Чем это может быть вызвано?».
Дальше набор симптомов компьютерной проблемы на ходу переиначивался, дополнялся новыми подробностями, задавались уточняющие вопросы, которые были всё глупее и глупее. Возможно замысел был в том, что если человек выдержал испытание хамством, он может «взорваться» на стадии «тупых и назойливых вопросов».
Исходники далеко не полные. Нет, к примеру, кода oleaut32.dll. Это, конечно, не относится к описанным здесь проблемам, но и части ядерных вещей недосчитаешься.
Про стюардессу не поддерживаю
Вы это про Windows или про nix-системы говорите?
Если про Windows, то что сейчас, что 20 лет назад, ничего подобного не практиковалось.
Когда вы выделяете 1 гигабайт памяти с помощью VirtualAlloc, создаётся структура MMVAD (она является узлом дерева, всё дерево хранит всю карту выделенных или зарезервированных областей виртуального АП отдельно взятого процесса, точнее «пользовательской» части всего АП), в которую заносятся параметры выделения (база, размер, параметры защиты страниц).
Никаких страниц физической памяти или файла подкачки, ассоциированных со страницами этого гигабайтного региона, в момент выделения памяти не выделяется.
Единственное, что есть такой счётчик как «page file quota», от которого минусуется количество выделенных страниц — этот счётчик не даёт всем процессам в сумме выделить больше страниц, чем теоретически может обеспечить файл подкачки.
Когда вы попробуете записать тот пресловутый 1 байт, произойдёт page fault, который ОС разрулит незаметным для процесса образом — странице виртуального АП, в которую был записан 1 байт, начнёт соответствовать некая страница физической памяти. Эта страница физической памяти будет выбрана из списка заблаговременно заготовленных занулённых страниц, а если таких готовых страниц на данный момент нет — будет занулена прямо сейчас (что дольше, чем если брать из простаивающих занулённых).
В случае, если ОС будет испытывать недостаток страниц физпамяти, страница физпамяти, соответствующая странице виртуального АП, в которую был записан 1 байт, будет сброшена в файл подкачки, а при необходимости затем подгружена.
Все остальные остальные страницы этого гигабайтного региона по прежнему будут существовать только номинального — не более, чем как числа в структуре MMVAD. Никаких страничных фреймов физической памяти или страничных фреймов файла подкачки им (без необходимости) соответсововать не будет.
Я прекрасно знаю об этом, но в XP поддержка физпамяти больше 4 Гб принудительно зарезана. Где только я говорил про PAE, не могу понять? В комментариях к этой публикации я PAE не упоминал — разве что в комментах к другим статьям мог где-то сказать про PAE в рамках развенчания мифа про лимит в 4 Гб для 32-битных систем, налагаемый, якобы, архитектурой.
Вот я сижу на 32-битной ОС, объём поддерживаемой физпамяти ограничен числом чуть меньшим, чем 4 Гб. При этом у меня огромный файл подкачки, размещённый на специально выделенном ради этого SSD-диске. Естественно у меня процессов, выдеряющих огромные объёмы, сумма которых больше, чем объём всей физпамяти на порядок.
Вам не приходило в голову, что и 16-битный софт под DOS кому-то может быть интересно или нужно реверсить хотя бы потому, что люди хотят функциональность перенести на более современные рельсы? Вот есть софт под DOS, который управляет станком, а хочется, чтобы был подо что-то современное. Но ни документации, ни исходников, ничего.
Понимаете мысль?
Это какая-то терминологическая демагогия пошла. Общепринято, что более гибкий и многозначный термин «память» используют часто как синоним понятия «адресное пространство».
В любом случае, вы написали
Можете сделать процесс, который резервирует 1 Гб (или вообще все свободные регионы) своего адресного пространства (после чего засыпает или зацикливается), и запустить 200 таких процессов. Никакие системные ресурсы не исчерпаются. Будет потрачено 200 фрагментов неподкачиваемого пула ядра на структуры MMVAD_SHORT. Ровно столько же было бы потрачено, если бы процесс закоммитил 200 несмежных 4-килобайтных страниц (800 кб в общей сумме).
Не могу говорить о всех операционных системах на свете, но к Windows ваши слова точно не применимы.
Во-первых, похоже, что вы путаете резервирование (
MEM_RESERVE) и выделение (MEM_COMMIT) страниц. Прочитайте статью об устройстве виртуальной памяти в Windows, которую tyomitch написал в далёком 2006 году. Если не хотите читать, то коротко: разница между резервированием и выделением страниц такая же, как между бронированием номеров в гостинице и заселением в них. Вы не сможете создать дефицит чистого постельного белья в городе, даже если забронируете все номера всех гостиниц в нём (но не станете никем из заселять).Во-вторых, даже если вы не резервируете, а именно выделяете какое-то количество страниц с помощью VirtualAlloc(), последняя лишь создаёт (или обновляет) структуру MMVAD_SHORT, описывающую диапазон страниц, но совершенно никак не обновляет таблицы страниц, не инициализируя новые PDE или PTE.
Инициализация/создание новых PDE/PTE происходит лишь при первом обращении к соответствующей странице. Когда происходит первый page fault при попытке доступа к ней. То есть каталог страниц обновляется только по мере необходимости (on demand).
Не верите: можете раздобыть утёкшие исходники ядра и прочитать от корки до корки исходники ядерной функции
NtAllocateVirtualMemory(VirtualAllocлишь переходник к ней). Единственным исключением является вызовVirtualAllocс флагомMEM_PHYSICAL.Огласите весь список, пожалуйста :) Если вы пишите «ошибки», значит их много? Отсутствие автосохранения — одна из них?
Замысел хороший, но сразу после появления плагина стал очевиден способ спасения данных, описанный в первой половине статьи (перенаправление выполнения на код процедуры
MudDoSaveиз плагина), автосохранение не рассматривалось как нужная фича, без которой нельзя жить и на которую не жалко тратить время. Ну разве что против внезапного отключения электричества или BSOD-а, но таких случаев может и не было вообще.Но идея хорошая, я подумаю над автосохранением, правда я считаю, что идеологически неверно запихивать эту функциональность в плагин Markup Dumper — это должен быть отдельный плагин, какой-нибудь OllyAutosave.
Странный комментарий. Имеется в виду установить OllyDbg на живой диск заведомо, подозревая диск (на котором живёт том
H:\) в нездоровости заранее? Или установить OllyDbg на другой диск уже после того, как диск с томомH:\отвалился? Я надеюсь, что вы имели в виду второй вариант.Если так, то вы невнимательно читали статью.
Во-первых, как я по вашему реверсил
Insertname()после аппаратного сбоя, если не установил OllyDbg на другой диск? Конечно же OllyDbg был сразу же установлен на другой том другого диска из резервного хранилища, чтобы начать работы по разрешению ситуации.Во-вторых, утилиту-дампер пришлось писать не потому, что OllyDbg стал недоступным для использования из-за отвала, а потому что был риск, что OllyDbg при подключении к полумёртвому процессу (коим был тоже OllyDbg) запнётся и завершится. А когда отладчик завершается, не вызвав перед этим
DebugActiveProcessStop(), отлаживаемый процесс уничтожается вместе с процессом-отладчиком. Тогда бы я окончательно потерял спасаемые данные.Т.е. утилита-дампер писалась ровно из тех соображений, чтобы воздействие на «коматозный» процесс было минимально инвазивным. Четыре аккуратных и точных вызова
ReadProcessMemoryдолжно было стать меньшим из возможных зол. Я даже не был уверен, чтоReadProcessMemory()вообще сработает в отношении этого процесса и сможет прочесть хоть что-нибудь. Это сейчас примерно понятно, что произошло, а в тот момент не было уверенности, что адресное пространство сохранилось хотя бы частично (в Windows объект-процесс может существовать, а адресное пространство как совокупность структур PDE+PTE с одной стороны, и MMVAD с другой стороны — могут не существовать; на каких-то этапах жизненного цикла объекта-процесса это так). Кто мог в первые минуты гарантировать, что всё произошло именно из-за аппаратного сбоя, а не потому, что какие-то ядерные структуры были повреждены каким-то глючным драйвером?Если вы внимательно читали, то видели, что сначала я собирался сдампить все закоммиченные страницы умирающего процесса, разобраться со сбоями, перезагрузиться, а потом уже в дампе находить нужное, не боясь, что вот-вот случится BSOD. Но Process Explorer не мог создать дамп, падал с ошибкой.
Причём было не удивительно, что он падал: если страница нечитаема, потому что механизм подкачки не может её подгрузить, то и ReadProcessMemory, которым пользуется любой дампер, её контент прочитать откуда-то волшебным образом не сможет. Был бы дампер, который читал не все подряд страницы. а только нужные — он бы не падал. Но нужно было знать, какие именно страницы читать, для чего и был начат реверсинг. А если знать, что читать нужно два больших блока плюс маленький кусочек с метаданными, зачем мне было искать подходящий дампер, если быстрее было написать его самому?
Если первое, то там масштабы такие, что не кассетницы нужны, а фидеры для pick-and-place-машин, отрезающие нужное количество деталей с катушки с лентой. А второе, то с их накрутками кто такую систему сможет себе позволить?
Да уж, стоило изобретать цифровую шину с поддержкой адресации, чтобы потом мучиться с матрицами.
Это не вам или автору камень в огород, это я просто об абсурдности ситуации.
Но ведь IDA Pro умеет присоединяться к существующему процессу и выступать отладчиком. Зачем тогда нужна Olly?
Дело в привычке. Я тоже пользуюсь Олей лет 15, и все действия в ней делаю уже как пулемёт. А IDA Pro всегда отталкивала нездоровой атмосферой вокруг Ильфака и его отношением к поддержке и пиратству. Окей, у вас платный продукт, а я воспользуюсь бесплатным инструментом, а для того, что он не умеет, сделаю собственные инструменты — вот так я примерно всегда размышлял.
Аннотации не влияют на вероятность зависания и вылета. Правда, длинные аннотации, создаваемые плагинами в нарушение спецификации, могут провоцировать вылеты, об этом я написал.
Просто если не аннотировать, вылеты не так критичны и не воспринимаются, как маленькие трагедии.
А зависания, как я уже писал, происходят по вине
win32k.sys, в основном. Например, жмёшь в Olly Ctrl+C и она зависает намертво. Смотришь Process Explorer-ом бэктрейс основного потока — там вызовSetClipboardDataиз OllyDbg, из неё идёт вызовuser32!_NtUserSetClipboardData@12, а это лишь переходничок, делающийSYSENTER. Дальше код уже продолжается в режиме ядра. И где-нибудь там оно висит. Аннотации тут явно не причём. Тут виноваты какие-то system-wide объекты синхронизации. Тот же буфер обмена — если один процесс открыл его с помощьюOpenClipboard()и завис, другие процессы сессии не могут работать с буфером обмена.В подобных случаях не не переключался на отладку ядерной части системы — а то это могло зайти далеко. Был у меня случай, когда я реверсил «железный» музыкальный синтезатор фирмы Roland, и использовал цифровой осциллограф, управляемый с компьютера через SCPI (GPIB), чтобы программировать его на отлов нужных событий, автоматизированно захватывать их анализировать. В реализации SCPI осциллографа была найдена дыра, позволяющая получаь доступ к прошивке осциллографа. Реверс-инжиниринг синтезатора плавно перетёк в реверс-инжиниринг осциллографа. В итоге ни то, ни другое не было доведено до конца.
Спасибо. Есть ли смысл публиковать плагин Markup Dumper, обозревать его применение в контексте ведения распределённого командного реверсинга? Есть смысл публиковать статью об упомянутых ARG-файлах?
Собственно говоря, это не эфемерная мечта: у меня уже давно (лет 14 как) лежит написанный классный и быстрый дизассемблирующий/ассемблирующий движок, который может удобно расширяться. Есть к дизассемблирующей половинке этого движка GUI-примочка, показывающая отдельную процедуру либо в плоском виде, как это делает OllyDbg (даже интерфейс скопирован один в один), либо в виде графа, как делает IDA. Есть самописный простенький отладчик (tinydbg), правда у него не графический, а совершенно дубовый текстовый интерфейс (не с использованием псевдографики в консольном окне, а именно сугубо текстовый «диалог» с отладчиком) — его единственное преимущество в том, что антиотладочные приёмы, которые основываются на слабых местах популярных отладчиков, на него не действуют, а так же тем, что любую нестандартную команду или функцию я в него могу добавить сразу же, как возникнет такая необходимость, и мне не надо будет искать нужный плагин или придумать, как ограниченным инструментарием скриптинга реализовать какую-нибудь пошаговую деобфускацию отлаживаемого процесса. Есть собственный вьювер DBG/PDB-файлов, собственный вьювер COFF.
Остаётся только объединить кучу собственных разрозненных и сырых утилит в мощный и доделанный конгломерат.
И конечно, я говорю сейчас о собственном интересе. Так сказать, с точки зрения научного интереса было бы интереснее написать собственный инструмент. Список мастхев фич сформирован уже давно.
А вот с точки зрения практической, конечно, более перспективно возраждать или поддерживать инструмент, у которго уже есть имя, репутация, комьюнити и своя экосистема, чем пробивать дорогу чему-то совершенно новому.
Непонятно, почему автор OllyDbg не обернул все обращения из хоста в плагины в
__try ... __exceptи сам не сделал какого-нибудь аварийного автосохранения в фильтре необработанных исключений. Даже VirtualDub имеет какой-то нестандартный top-level хендер для исключений, показывающий и контекст потока, и дизасм проблемного места, хотя, казалось бы, мультимедийной утилите такой функционал не обязателен, а вот в коде отладчика уже есть многий инструментарий для реализации подобной плюшки, но самой плюшки и вообще хоть какого-то аварийного процессинга исключений внутри самого себя — нет.Вообще, писать подобный плагин-автодампер для себя я не вижу особого смысла. У меня есть пара утилит, упомянутых в статье:
memdumper.exeиextractor.exe. В случае проблемы достаточно вызватьУ этого подхода есть один неоспоримый плюс: спасительные утилиты находятся вне зоне поражения сошедшего с ума кода. А вот плагин-спасатель может сам оказаться повреждён, ведь он разделяет с умирающим отладчиком одно адресное пространство.
А в первой версии такой API нет вообще. Но даже если бы была, я ведь упомянул, что есть за OllyDbg грешок тихо портить UDD при сохранении.