Добрый день

Возник вот какой вопрос. Есть EXE-файл. Его можно открыть всякими ResHacker, XN Resource Editor и т.д. и подправить капчи, фонты, лейблы и прочую
Что можно предпринять, чтобы это было бы хотя бы ну уж не так прямо "в лоб"?

Раньше был какой-то AsPack. Для совсем простых случаев - упаковать upx-ом.

а, допустим, ксорить строковые константы и присваивать значения в процессе создания формы?

А почему ксорить-то? тогда уж лучше зашифровать.

А зачем ксорить-шифровать, если достаточно проверить целостность? Раз уж задача поставлена "чтобы нельзя было подправить".

а механизм проверки?

допустим, я считаю КС файла, куда я ее дену? если заменю в редакторе определенное место этой суммой, то результирующая ведь тоже поменяется?

или я все не так понимаю?

Что-то я не понимаю затруднений. Считаете хэш, прикручиваете его к .exe файлу, на старте проверяете. От пионеров хватит.

опять непонятно. Вот я выделил константу, с которой буду сравнивать рассчитанный хэш, знаю расположение в EXE
считаю, допустим, MD5, сохраняю в это место

запускаю EXE, считаю MD5. Но ведь сумма будет уже другой!

Повторяю вопрос - какой вообще механизм проверки целостности?

Самый простой вариант - записать в конце. Если значение записано где-то в середине, то, разумеется, во время проверки придется его подменить.

ну так что мешает тогда "хакеру" найти сумму в конце, что надо подправить и снова записать сумму в непроверяемую область?

Если это сумма, то ничего не помешает. А вот если это CRC32 с неизвестным полиномом и стартовым значением, то пионера отвадит.

Вы определитесь, какого уровня крякера (от слова crack, а не хакера) Вы хотите остановить. Если минимального - то достаточно упаковать UPX и поискать утиль, который делает его нераспаковываемым самим UPX. С контрольной суммой тоже просто. Отводите для нее статическу переменную, зануляете, считаете внешней прогой КС и добавляете в переменную так, чтоб КС стала равнв нулю. После запуска и распаковки - проверяете КС. Естественно, все это потребует некоего времени и минимальных знаний, как устроен код, сгенеренный вашим компилятором. От человека, который хотя бы минимально знаком с крекингом, Вы за кототкий промежуток времени, без использования специализированных программ, не защититесь.

"ПионЭр" просто найдет место, где проверяется на сопадение и заменит один байтик условного перехода на код 0хEB - безусловный переход на нужное место.

Если не поленится. Проверять можно не только на старте. А вообще, пионеры - они разные бывают. В т.ч. и очень упорные

Делать любую защиту "несекретных" EXE при помощи упаковщика не только бесполезно, но и вредно.
Во-первых, любой пионер за 5 минут загуглит программу для снятия упаковщка, что делает его использование бесполезным.
Во-вторых, любая нормальная антивирусная программа при виде такого файла впадет в ступор от 0,1 до нескольких секунд (длительность ступора зависит от сложности упаковщика и размера EXE-файла), что делает использование упаковщика вредным.
В-третьих, любой сервис типа virustotal выдаст несколько ложноположительных детектов только из-за присутствия упаковщика, что также нельзя назвать приятным.

Исключения - случаи, когда защита действительно имеет смысл, например, при применении секретных узкоспециализированных алгоритмов в более-менее массовом софте. И делается это при помощи самых тяжеловесных протекторов: WinLicense, EXECryptor, и т.д. с обязательным внесением элементов защиты на уровне исходных кодов. В зависимости от качества наложенной защиты и, главное, количества и усердия супостатов, можно получить от нескольких месяцев до нескольких лет защищенности.

Если очень хочется защитить логотип софта от скучающих пионеров - можно хранить его в зашифрованном или нестандартном формате. Но это не остановит даже мало-мальски заинтересованного пионера, так что спорный вопрос, стоит ли тратить на это время разработчика.
Наилучшая защита от внесения изменений - подпись исполняемого файла и распространение информации об обязательности ее наличия. Это не спасает от изменений, но дает надежный инструмент их обнаружения.

Вообще-то ресурсы как отдельная и открытая составляющая exe-файла и проектировались специально для удобства локализации, когда, не затрагивая авторских прав на код, можно было бы подправить интерфейс.
Не хотите ресурсов - создавайте кнопки, переключатели, окна диалога и пр. в ходе выполнения программы. Иконки-картинки шифруйте и храните в теле программы.

Шифруйте свои ресурсы, только не 'xorом', а нормальным несимметричным алгоритмом (можно задействовать CryptoAPI). Тогда никакие хакеры не смогут поменять в вашей программе никаких ресурсов, т.к. для этого им понадобится приватный ключ, которого у них просто не будет.
Если у вас Builder, то дешифровку можно врезать прямо в VCL

CRC вообще не вариант, независимо от полинома. Ломается на раз тупым (тупейшим) перебором в пределах одного кодового слова. Причем, диапазон перебора не так уж и велик - в пределах кодового расстояния.

Пусть дан произвольный файл объемом 200кБайт, в котором где-то вшит CRC. Что и как перебирать будем?

а каким образом это врезается в Builder?

Берете сорцы VCL, находите там место, где происходит чтение форм и добавляете дешифровку. Потом модифицированные исходники VCL добавляете к себе в проект

Сначала заменяется открытый ключ, затем подменяются ресурсы.

Вообще-то RSA, ECC и иже с ними крайне вычислительно накладны. Поэтому ими обычно шифруется симметричный ключ или их используют для проверки правильности хеша, который считается по той части программы, которая дожна контролироваться. Про то, что можно подменить открытый ключ уже написали

Ключ должен быть вшит в программу, а не лежать в ресурсах. Однако, если взломщик обладает достаточной квалификацией, то ему и ключ подменять не надо будет - он просто врежется в программу после дешифровки ресурсов, снимет их расшифрованный образ, потом положит его (с любыми своими правками) обратно в ресурсы и отломает дешифровку вообще.
От этого защиты нет, но такие действия требуют немалой квалификации

На самом деле подмена ключа методически правильнее, чем лопатить программу в поисках всех точек дешифровки, так как их может быть несколько.