Примечание:
Обратите внимание, что пост называется "EurekaLog с точки зрения ShareWare-разработчика". Т.е. здесь написано о том, на что нужно обратить своё внимание в EL разработчику shareware-программ. Здесь НЕ говорится о том, как писать shareware-программы, и/или стать shareware-разработчиком.
1. Проверка файла на изменение.
В первую очередь, конечно же, хотелось бы обсудить опцию "Check file corruption", которую вы можете найти в опциях EurekaLog для проекта, на вкладке “Build Options”:
The first thing is, of course, checking the file for corruptions. You can enable this feature in "Build Options" section:
В первую очередь хорошо бы заметить, что эта опция расположена в разделе именно “Build Options” (опции сборки). Что бы это значило? Ну, это означает, что при включении опции EurekaLog будет вычислять CRC вашего exe-файла и записывать её в стандартное поле CheckSum запись _IMAGE_OPTIONAL_HEADER. Да, в очень стандартное (и документированное) поле в PE-заголовке.
Когда ваше приложение запускается, код EurekaLog вычисляет CRC вашего модуля и сравнивает его со значением, хранящимся в поле CheckSum заголовка. Если ваш модуль был изменён, то эти значения не совпадают и EurekaLog показывает соответствующее сообщение, после чего немедленно закрывает вашу программу:
Поскольку ничего не препятствует взломщику в изменении поля Checksum в заголовке файла на новую CRC после изменения, то этот механизм не должен рассматриваться как сколь-либо серьёзная защита. Его назначение в проверке файла на непреднамеренные изменения. Не нужно считать его серьёзной линией обороны против взлома. Если вы хотите защитить свой файл именно от взломщиков (crackers) (а не от простых изменений), то вам нужно разворачивать свою собственную защиту (ладно, многие из так называемых крякеров не способны обойти даже такую простую проверку, но это уже другая история).
Ещё один момент, связанный с этой опцией, - использование файловых компрессоров или цифровых подписей. Видите-ли, как только вы сжали свой файл каким-либо файловым компрессором (например, UPX) или же снабдили его цифровой подписью - то ваш файл тут же изменился, что означает неудачу проверок CRC EurekaLog при запуске. С вашей точки зрения это выглядит так: программа работает, вы её сжали и/или подписали - она не работает. Тут важно заметить, что сжатие файла или его подпись уже включают в себя проверки целостности. Поскольку сжатые данные намного более чувствительны к повреждениям, то все современные компрессоры включают в себя какой-либо механизм проверки файла на изменения перед распаковкой - примерно по той же схеме, что это делает EurekaLog. Аналогичные замечания применимы и к файловым цифровым подписям. Если приложение снабжено цифровой подписью, то уже загрузчик ОС (а не само приложение) проверяет его перед запуском, чтобы убедиться, что цифровая подпись не была нарушена. Короче говоря, вывод здесь простой: если вы используете компрессор или цифровую подпись, то вы спокойно можете (и должны) выключить опцию “Check file corruption”.
Кстати, если вы пишете свой собственный установщик, то вы, вероятно, не захотите делать его в виде одного файла и при этом снабжать его какой-либо проверкой целостности (проверка от EL, файлового компрессора или цифровой подписи). Почему? Ну, представьте себе, что у вас получился установщик на 200 Мб в одном монолитном exe-файле. Ваш клиент запускает его. Какой-бы механизм проверки вы не использовали бы, он проверяет целостность ВСЕГО файла при запуске. А сканирование 200 Мб с вычислением CRC займёт немало времени! Пользователь даже может решить, что ваше приложение повисло. Намного лучше сделать установщик в виде (минимум) двух-файлового дистрибутива (маленький установщик и большой архив с данными) или же выключить проверки для установщика.
И напоследок: помните, что даже цифровые подписи - это всего лишь вспомогательных механизм для конечных пользователей, помогающий им убедиться в подлинности программы, но это не является защитой от взломщика! Цифровая подпись на программе может только уверить пользователя, что файл не был модифицирован и что он пришёл от разработчика программы, а не от хакера. Она не защищает ваше приложение от взлома, поскольку ничто не мешает взломщику просто снять цифровую подпись.
2. Отладочная информация: За и Против.
Другой важной особенностью для разработчика shareware программ является хранение отладочной информации. EurekaLog добавляет отладочную информацию в ваши программы, чтобы помочь вам быстрее находить причину сбоев. Показ информации стека вызовов работает на основе отладочной информации. По-умолчанию, отладочная информация включается только в dcu-файлы и не идёт в готовый исполняемый модуль. Но без неё невозможно показать правильный стек вызова с именами функций, методов и номерами строк. Поэтому EurekaLog собирает всю отладочную информацию после компиляции и прикрепляет её к вашей программе в виде ресурса.
Отладочная информация при этом хранится не в текстовом виде, а в сжатом и зашифрованном. Но поскольку пароль (пустой) хранится в самой же программе - то ничто не мешает взломщику расшифровать вашу отладочную информацию и воспользоваться ею. Что он может с этого получить? Ну, отладочная информация содержит имена модулей, классов, методов, процедур и функций, а также номера строк и смещения от начала функции. Она не содержит вашего исходного кода, но, действительно, может дать ценную информацию.
Из-за этого, очень частым вопросом является такой: “верно ли, что программы, скомпилированные с EurekaLog легче взломать?”.
Ну, это зависит от настроек.
Давайте посмотрим каких.
Да, это правда, что простое включение в свою программу отладочной информации МОЖЕТ упростить взлом. Но это не означает, что крек появится автоматически. Взломщику по-прежнему нужно изучать вашу защиту, чтобы найти к ней лазейку, и если ваша защита написана хорошо, то она не содержится в отдельно выделенных специальных функциях, а, скорее, размазана по всему коду. Поэтому, если в вашем коде нет специально выделенных “подпрограмм защиты”, то и чтение отладочной информации не даст о них никакой информации (а даже если вы всё же завели себе такие - просто дайте им ничего не говорящие имена).
В любом случае, даже если отладочная информация включалась бы в виде текста (а это не так, даже если вы не задавали пароль), то она может всего лишь ускорить изучение вашей программы. Она не может предложить способ взлома. С отладочной информацией или без неё - взломщик будет делать одни и те же действия. Таким образом разница между “есть отладочная информация” <> “нет отладочной информации” эквивалентна “крек может появиться раньше” <> “крек может появиться позже”, а не “приложение будет взломано” <> “приложение не будет взломано”.
Хотя вы можете сделать некоторые шаги, препятствующие в получении этого бонуса взломщиком.
Первое: вы можете исключить из отладочной информации некоторые процедуры. Просто оберните свои процедуры в директивы компилятора, переключающие генерацию отладочной информации. НО, опять-таки, взломщик может увидеть “белые пятна” в покрытии кода отладочной информацией (если такая идея придёт ему в голову), так что этот способ может привести его прямо к вашему коду защиты (хорошо для honeypot).
Второе: вы можете защитить отладочную информацию паролем, который не храниться в готовом исполняемом модуле. Для этого вы должны ввести пароль в поле “Encryption password” на вкладке “Advanced options” в опциях проекта EL:
Тогда отладочная информация не будет полезна взломщику без пароля (который знаете только вы и он не храниться в программе). Взломщик может только подобрать ваш пароль или забросить отладочную информацию. Ну, вы также не сможете вот так просто просмотреть стек вызовов (и ассемблерный вид) - он также будет зашифрован (кстати, EurekaLog использует TEA - этот широко известный крипто-алгоритм известен своим компактным кодом):
Но зато вы можете загрузить отчёт в EurekaLog Viewer, ввести свой пароль (который вы знаете, а взломщик - нет) и просмотреть уже расшифрованый отчёт.
Третье: если вы действительно волнуетесь, что взломщику удастся подобрать ваш пароль - тогда вы можете пойти ещё дальше и исключить из отладочной информации имена методов, функций и процедур. Вы можете сделать это, включая опцию “Do not store the Class/Procedure names” на всё той же вкладке “Advanced options”:
С включенной опцией, в конечную программу попадут только названия модулей и номера строк! Эта информация полностью бесполезна для взломщика. Конечно же, теперь ваши отчёты также не будут содержать эти имена. Но стек вызовов всё ещё будет полезен - он содержит имена модулей и номера строк, что достаточно для идентификации места проблемы, хотя теперь это может быть чуть сложнее.
А вот Вы не в курсе, как подружить Эврику с KIS2011? Благодаря тому, что она дорисовывает в exe-шник что-то, KIS каждый (!) раз после линковки сканирует запускаемый файл по 30 сек. И даже если отключить весь контроль программ, то старт затягивается секунд на 5-7.
ОтветитьУдалитьТехсаппорт Каспера непробиваем. Я потратил около месяца пару лет назад на общение с их "попугаем" из техподдержки, чтобы он принял аналогичное поведение старой версии KIS, как ошибку и отправил это в отдел разработки. Но добился - через две недели исправили. Тогда проблема была аналогичная, но касалась любой скомпилированной программы - несмотря ни на какие исключения в настройках KIS для компилируемой программы и bds.exe, проверка очередного скомпилированного exe-шника шла минимум 3 раза в день. После исправления достаточно стало однажды поместить в группу "доверенные".
Я не в курсе.
ОтветитьУдалитьEurekaLog (равно как и madExcept и JCL) просто добавляет в готовый файл секцию с настройками и отладочной информацией. Тут мало что можно сделать с этой стороны.