Хардкор это бинарь покрытый скажем Themida не желающий работать под какой-либо виртуалкой, а файл сомнительный и на живой машине реверсить не хочется, а надо!
>>В наличии относительный условный переход, который затрется нашими 5 байтами
Именно по этой причине стараюсь использовать технику сплайсинга как можно меньше!
Куда больше нравится править непосредственно IAT(Import Address Table).
Можно сделать такое:
1) Сохраняется оригинальный адрес в IAT
2) В IAT пишется свой адрес
3) После перехода на код хэндлера мы должны понять: «А это тот кусок кода что мы перехватываем?» На этот вопрос можно получить ответ только когда мы понимаем кто вызвал нашу функцию. Это же в свою очередь можно понять пользуясь технологией SEH, как это делают при раскрутке стека, это не сложно и не накладно по скорости работы! Для 64-битов немного другие правила.
Плюсы:
1) Достаточно быстро патчится
2) Не надо морочиться с корректностью выполнения первых N-байтов где мы поставили свой jmp
3) Код достаточно читабельный и проще сопровождать
Мне-то может и казаться, но давайте-ка посмотрим на это с другой стороны.
К примеру у Вас болит зуб и вы идете к стоматологу, а он принимает решение сделать пломбу. После лечения Вы приходите домой, а зуб все-так и не проходит, более-того он болит еще сильнее. Что Вы будете думать о стоматологе «Вам не кажется что стоматолог тут не причем и это поставщик пломбы виноват?». Возможно, но уверяю, я бы на Вашем месте по началу винил бы стоматолога и только потом, когда бы вылечил зуб в спокойной обстановке подумал и понял бы «А ведь стоматолог не виноват!».
Я к тому что разработчик софта должен понимать, что клиент может быть здравомыслящим, а может с горяча подумать о нем плохо. Нету никакого смысла доказывать кто прав, а кто нет, куда эффективней проверить поддержку самому! Тем более во времена, когда все так и бегут «в облака» поддержка средств виртуализации это уже не стратегическое преимущество, а возможность выжить на рынке.
Ну я ставил на VmWare 9. Возможно в ней, но с другой стороны сколько сейчас реверсеров кинется изучать 8-ку пользуясь исключительно средствами виртуализации и MS должен был об этом подумать.
Касательно процесса перевода:
1) Как он был организован? Agile-практики
2) Как распределялись куски перевода?
3) Проводилось ли аналогичное програмерскому «code-review»? Если да, то как?
4) Был ли предварительно процесс разбит на этапы? Если да, то на какие?
5) Если в п.4 положительно, то был ли получены какие-либо уроки\итоги после каждого этапа и если «да», то какие?
6) Какой конечный итог\урок был вынесен и как бы вы организовали процесс перевода другой технической книги?
Адски глючная, особенно по части отрисовки ГУИ. Вчера решил создать юзера, ну значит в PC Settings, лезу кликаю мышой в левом большом списке «Users», а пиктограма с юзером поверх надписи "… password" вот именно многочие ибо пиктограмма нарисовалась поверх, и вот сиди гадай толи «create», толи «change». Если же стрелками вниз\вверх и Enter то все ок )
Статья весьма дельная и полезная. Однако на мой взгляд Вы забыли упомянуть о том, что в коммерческих приложения логирование может раскрывать секреты и как вывод программист может помогать конкурентам. Было бы здорово, чтобы Вы о таких случаях тоже упомянули.
>>либо для кода, который ты в состоянии быстро и досканально изучить.
А «быстро и досконально» мы чаще можем при не больших по размеру. Другими словами, если в вашем методе слишком много целей, то вынесите достижение каждой цели в отдельный метод и будет вам чуть больше счастья )
>>Вывод один — такой метод хорош
Рафакторим, рефакторим и еще раз рефакторим
1)
>>а способ убедиться
Вы уверены что вы знаете перевод англ. слова 'test' на русский язык?
2)
Вы уверены что вы понимаете в чем заключается «тестирование»?
Отвечу тестирование это процесс нахождения отклонений между «ожидаемым» и «на самом деле», а баг это или фича следует из требований, проекта, документации и в редких случаях слов Product-owner-а.
Мне кажется Вы запутались в формулировках. Попробую пояснить:
«убедиться» — это цель
«новые баги» — это результаты достижения цели. Мы же с Вами понимаем, что отрицательный результат, тоже результат!
Можно успешно разрабатывать не пользуясь отладчиком, но применяя другие техники помогающие находить баги. Банальные примеры: юнит-тесты, assert, отладочный вывод в лог-файл, написание текстуализаторов(о том что такое читать Реймонда) и др. вещи.
То что Вы осветили это материал тянет на «капитанский» уровень. В вашем материале нет ничего того, чтобы Вас выгодно позиционировало. Все обыденно. На мой взгляд Вам нужно копнуть глубже в свою голову и поделиться тем, что реально экономит людям время и не на 1-2 дня, а на неделю!
У Вас же выглядит все так: Чел столкнулся с проблемой — чел почитал документацию — чел подумал — чел написал код. Все что Вы написали это максимум 3 человеко\дня работы и это еще очень завышенная оценка.
Примеры задач, которые, на мой взгляд, имеет смысл рассматривать:
1) С++ программеры, да и не только, часто пишут абстрактные классы для задания интерфейса, а потом сталкиваются с задачей чтобы от него написать потомка. Можно было бы написать скрипт, который парсит хидер с таким базовым классом и создает *.cpp/*.hpp файлы с готовым к наполнению потомком. Это бы многое упростило другим.
2) Часто админы, не важно фрихи или линухов, правят конфиги и часто выливается это в экспериментирование, если есть неясный нюанс. Конечно на боевом сервере это не будут, но и на тестовом тоже нужно затратить время. Можно было бы написать нечто что смотрит на настройки и текущую систему и пишет хинты админу где он накосячил и что можно поправить? Это бы тоже дало реальную пользу многим людям.
Писать имеет там, на мой взгляд, где люди экономят свое время или узнают такие нюансы, которые помогают решить им серьезные вещи, к примеру отладить их трудноуловимые баги.
Это требование справедливо к любому современному проту, иначе смысл его покупать?
Именно по этой причине стараюсь использовать технику сплайсинга как можно меньше!
Куда больше нравится править непосредственно IAT(Import Address Table).
Поясню:
Допустим есть код:
Для наглядности офсет куда указывает инструкция call покажу в виде списка dword-ов:
Как мы знаем это ничто иное как адрес в IAT:
Можно сделать такое:
1) Сохраняется оригинальный адрес в IAT
2) В IAT пишется свой адрес
3) После перехода на код хэндлера мы должны понять: «А это тот кусок кода что мы перехватываем?» На этот вопрос можно получить ответ только когда мы понимаем кто вызвал нашу функцию. Это же в свою очередь можно понять пользуясь технологией SEH, как это делают при раскрутке стека, это не сложно и не накладно по скорости работы! Для 64-битов немного другие правила.
Плюсы:
1) Достаточно быстро патчится
2) Не надо морочиться с корректностью выполнения первых N-байтов где мы поставили свой jmp
3) Код достаточно читабельный и проще сопровождать
К примеру у Вас болит зуб и вы идете к стоматологу, а он принимает решение сделать пломбу. После лечения Вы приходите домой, а зуб все-так и не проходит, более-того он болит еще сильнее. Что Вы будете думать о стоматологе «Вам не кажется что стоматолог тут не причем и это поставщик пломбы виноват?». Возможно, но уверяю, я бы на Вашем месте по началу винил бы стоматолога и только потом, когда бы вылечил зуб в спокойной обстановке подумал и понял бы «А ведь стоматолог не виноват!».
Я к тому что разработчик софта должен понимать, что клиент может быть здравомыслящим, а может с горяча подумать о нем плохо. Нету никакого смысла доказывать кто прав, а кто нет, куда эффективней проверить поддержку самому! Тем более во времена, когда все так и бегут «в облака» поддержка средств виртуализации это уже не стратегическое преимущество, а возможность выжить на рынке.
1) Как он был организован? Agile-практики
2) Как распределялись куски перевода?
3) Проводилось ли аналогичное програмерскому «code-review»? Если да, то как?
4) Был ли предварительно процесс разбит на этапы? Если да, то на какие?
5) Если в п.4 положительно, то был ли получены какие-либо уроки\итоги после каждого этапа и если «да», то какие?
6) Какой конечный итог\урок был вынесен и как бы вы организовали процесс перевода другой технической книги?
А «быстро и досконально» мы чаще можем при не больших по размеру. Другими словами, если в вашем методе слишком много целей, то вынесите достижение каждой цели в отдельный метод и будет вам чуть больше счастья )
>>Вывод один — такой метод хорош
Рафакторим, рефакторим и еще раз рефакторим
>>а способ убедиться
Вы уверены что вы знаете перевод англ. слова 'test' на русский язык?
2)
Вы уверены что вы понимаете в чем заключается «тестирование»?
Отвечу тестирование это процесс нахождения отклонений между «ожидаемым» и «на самом деле», а баг это или фича следует из требований, проекта, документации и в редких случаях слов Product-owner-а.
Мне кажется Вы запутались в формулировках. Попробую пояснить:
«убедиться» — это цель
«новые баги» — это результаты достижения цели. Мы же с Вами понимаем, что отрицательный результат, тоже результат!
У Вас же выглядит все так: Чел столкнулся с проблемой — чел почитал документацию — чел подумал — чел написал код. Все что Вы написали это максимум 3 человеко\дня работы и это еще очень завышенная оценка.
Примеры задач, которые, на мой взгляд, имеет смысл рассматривать:
1) С++ программеры, да и не только, часто пишут абстрактные классы для задания интерфейса, а потом сталкиваются с задачей чтобы от него написать потомка. Можно было бы написать скрипт, который парсит хидер с таким базовым классом и создает *.cpp/*.hpp файлы с готовым к наполнению потомком. Это бы многое упростило другим.
2) Часто админы, не важно фрихи или линухов, правят конфиги и часто выливается это в экспериментирование, если есть неясный нюанс. Конечно на боевом сервере это не будут, но и на тестовом тоже нужно затратить время. Можно было бы написать нечто что смотрит на настройки и текущую систему и пишет хинты админу где он накосячил и что можно поправить? Это бы тоже дало реальную пользу многим людям.
Писать имеет там, на мой взгляд, где люди экономят свое время или узнают такие нюансы, которые помогают решить им серьезные вещи, к примеру отладить их трудноуловимые баги.
Надеюсь ясно выразил мысль