Зашитые в код строковые константы- как защитить их от просмотра?

← →
roadster © (2009-05-20 10:47) [0]

Всем привет!
Имеется программа, которая, грубо говоря, читает из инишника зашифрованную с ключом строку, расшифровывает ее, использует, при необходимости делает обратную операцию.
С зашифровкой/расшифровкой все понятно.
Дело в том, что ключ шифрования не будет вводиться вручную пользователем (это служба архивации, вертится на сервере). Хранить ключ во внешнем файле- все равно что не шифровать вовсе.
Интересует вариант объявления этого ключа в коде программы.
Если объявить константой- этот ключ видно даже в ФАРе :).
Если объявить ресурсстрингом- вроде не видно.
То есть задача: каким-то образом объявить строку, но чтобы декомпилятором/дизассемблером и ничем иным ее в файле ехе-шника нельзя было посмотреть.

← →
brother © (2009-05-20 10:51) [1]

использовать шифрование и записывать в string уже шифрованную строку...

← →
roadster © (2009-05-20 10:53) [2]

Ага, а ключ для расшифровки зашифрованной в стринг строки где хранить?
:)

← →
brother © (2009-05-20 10:54) [3]

> Ага, а ключ для расшифровки зашифрованной в стринг строки
> где хранить?

ключ не нужен, храни алгоритм расшифровки...

← →
Плохиш © (2009-05-20 10:55) [4]

> Интересует вариант объявления этого ключа в коде программы.

Ключ должен состоять из нечитаемого набора символов. А ещё можно и чередовать объявления константных символов.

> Если объявить ресурсстрингом- вроде не видно.

Рыдал, зачем тратить время на "защиту" от полных идиотов?

← →
brother © (2009-05-20 10:57) [5]

> Рыдал, зачем тратить время на "защиту" от полных идиотов?

ну очередной велосипед для молодых.

← →
brother © (2009-05-20 10:58) [6]

res:="Всем привет"; res2:=""; for i:= 1 to length(res) do res2:=res2 + chr(ord(res[i])+i); showmessage(res2);
типа так ;)

← →
roadster © (2009-05-20 11:22) [7]

> ну очередной велосипед для молодых.

Тоже мне, старичок нашелся...
Абстрагируемся от всего, кроме "каким-то образом объявить строку, но чтобы декомпилятором/дизассемблером и ничем иным ее в файле ехе-шника нельзя было посмотреть".- по этому поводу есть еще мысли?

← →
brother © (2009-05-20 11:26) [8]

> но чтобы декомпилятором/дизассемблером и ничем иным ее в
> файле ехе-шника нельзя было посмотреть

только железный ключ тогда...

← →
roadster © (2009-05-20 11:27) [9]

> только железный ключ тогда...

Не...
А ежли екзеху упаковщиком каким сжать?

← →
brother © (2009-05-20 11:46) [10]

> А ежли екзеху упаковщиком каким сжать?

ну если уж будут смотреть:

> декомпилятором/дизассемблером и ничем иным ее в файле ехе-
> шника нельзя было посмотреть

то тут уже ничего не спасет)

← →
brother © (2009-05-20 11:47) [11]

зы зачем такие сложности? от кого защищаем в итоге? мой пример не катит?

← →
roadster © (2009-05-20 11:57) [12]

> зы зачем такие сложности? от кого защищаем в итоге? мой
> пример не катит?

Система резервного копирования.
Зипуху надо запаролить.
Пароль в инишнике в открытом виде держать не стоит.
Хочу ентот пароль зашифровать с ключом.

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

Хотел ключ для расшифровки прошить в екзехе так, чтобы хекс-едитором этот ключ нельзя было посмотреть.

← →
brother © (2009-05-20 11:59) [13]

> Хотел ключ для расшифровки прошить в екзехе так, чтобы хекс-
> едитором этот ключ нельзя было посмотреть.

так это же не

> декомпилятором/дизассемблером и ничем иным

;) Просто оч. строгие рамки ты поставил, тебе подойдет мой вариант

← →
roadster © (2009-05-20 12:01) [14]

Не, эт я немного недописал...
Я хотел сказать, чтобы прошитый ключ НИЧЕМ нельзя было достать...

← →
brother © (2009-05-20 12:02) [15]

> Я хотел сказать, чтобы прошитый ключ НИЧЕМ нельзя было достать...

это не реально!
Вы даете не реальные планы, это как его - валюнтаризм (с) Приключения Шурика

← →
Юрий Зотов © (2009-05-20 12:05) [16]

> roadster © (20.05.09 10:53) [2]

1. На каждый паковщик есть свой распаковщик.

2. Защиты от серьезного хакера не существует.

3. Непросто написать программу, взлом которой заинтересовал бы серьезного хакера. Поэтому стоит подумать - а станет ли серьезный хакер вообще Вашей программой заниматься? Она представляет для него хоть какой-нибудь интерес?

4. А для защиты от юных пионеров с гордо загнутыми пальцами вполне можно хранить зашифрованную строку, а код ее расшифровки вшить прямо в тело программы.

5. Если существует некий проверочный оператор
if <условие> then <работаем> else <не _работаем>
то это самое уязвимое место и о нем стоит подумать в первую очередь.

← →
brother © (2009-05-20 12:06) [17]

> 4. А для защиты от юных пионеров с гордо загнутыми пальцами
> вполне можно хранить зашифрованную строку, а код ее расшифровки
> вшить прямо в тело программы.

я про [6] автору уже сколько говорю ;)

← →
Юрий Зотов © (2009-05-20 12:12) [18]

Кстати, если речь идет о хранении ключа, то быть осмысленной строкой он вовсе не обязан. Никто не мешает сделать его бессмысленным набором байт, включая и непечатные коды.

← →
roadster © (2009-05-20 12:12) [19]

> 4. А для защиты от юных пионеров с гордо загнутыми пальцами
> вполне можно хранить зашифрованную строку, а код ее расшифровки
> вшить прямо в тело программы.

А зашитый код расшифровки- насколько проблематичнее получить из екзехи? Ибо не против пионеров задумывается. Тривиальное перестановочное шифрование не подойдет...

← →
Юрий Зотов © (2009-05-20 12:13) [20]

Еще кстати - а зачем вообще тут нужен ключ? Можно и без него.

← →
roadster © (2009-05-20 12:14) [21]

> Кстати, если речь идет о хранении ключа, то быть осмысленной
> строкой он вовсе не обязан. Никто не мешает сделать его
> бессмысленным набором байт, включая и непечатные коды.

Эт понятно. Но ках лучше описать? переменной, константой, ресурсстрингом?
Пусть даже если и код расшифровки зашить?

← →
roadster © (2009-05-20 12:15) [22]

> Еще кстати - а зачем вообще тут нужен ключ? Можно и без
> него.

Простые перестановочные алгоритмы?

← →
roadster © (2009-05-20 12:20) [23]

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

← →
Юрий Зотов © (2009-05-20 12:21) [24]

> roadster © (20.05.09 12:12) [19]

> А зашитый код расшифровки- насколько проблематичнее получить из
> екзехи?

При наличии отладчика и соответствующего навыка - просто (если это простой статический код). Но можно усложнить. Например, САМ машинный код расшифровки можно хранить в зашифрованном виде в секции данных, "на ходу" его расшифровывать и исполнять в стеке.

Можно использовать полиморфный код. Можно еще кучу всего напридумывать (кстати, статей в Сети полно) - но защиты от серьезного хакера все равно нет. Весь вопрос лишь в рентабельности взлома - стоит ли его результат затраченных на него ресурсов?

← →
brother © (2009-05-20 12:22) [25]

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

разошелся ;)
как вариант: читай разные байты СВОЕЙ программы по нужному алгритму)

← →
Юрий Зотов © (2009-05-20 12:24) [26]

> roadster © (20.05.09 12:20) [23]

Можно и ничего не генерить, и ничего не переставлять. Тут ключ вообще не обязателен. Клиент получает от сервера зашифрованный пароль и расшифровывает его известным ему алгоритмом без всякого ключа.

> roadster © (20.05.09 12:14) [21]
>
>
> > Кстати, если речь идет о хранении ключа, то быть осмысленной
> > строкой он вовсе не обязан. Никто не мешает сделать его
> > бессмысленным набором байт, включая и непечатные коды.
>
>
> Эт понятно. Но ках лучше описать?

Логику включить не пробовал, как ты собираешься узнавать какой из "бессмысленным набором байт" в exe является необходимым ключём.

> переменной, константой, ресурсстрингом?

Хотя, что это я про логику, тут со знаниями проблема.

> Логику включить не пробовал, как ты собираешься узнавать
> какой из "бессмысленным набором байт" в exe является необходимым
> ключём.

А бессмысленный набор символов в строковой константе не является бессмысленным набором байт? :) Ты ж не конкретизировал в посте, что за набор...

> как вариант: читай разные байты СВОЕЙ программы по нужному
> алгритму)

Тогда ключ будет зависеть от версии. Перекомпилял- и вот тебе новый ключ.
Не уследишь ни фига...

> Можно и ничего не генерить, и ничего не переставлять. Тут
> ключ вообще не обязателен. Клиент получает от сервера зашифрованный
> пароль и расшифровывает его известным ему алгоритмом без
> всякого ключа.

С ключом понадежнее будет. А сдвиг/перестановка/замена проще ломается...

> Ибо не против пионеров задумывается.

Зато пионером.

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

> Зато пионером.

Может тогда член партии с 18ХХ года подскажет что-нибудь?

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

Понятно...
Куда ж тады ключ запрятать? В реестр, наверно, не покатит, наверняка можно проследить в какую ветку программа лезет...

> Куда ж тады ключ запрятать?

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

> даю подсказку, асинхронные алгоритмы шифрования

Не поможет, у него как декодирование, так и декодирование используется (по крайней мере в [0] так написано, что обратные действия тоже нужны)

> Не поможет, у него как декодирование, так и декодирование
> используется

А не нужно кодирование - кодирование должно производиться со стороны разработчика приватным ключом, а авторизацию на сервере и запрос новой порции данных производить опять-же на основе приват-паблик ключей, интеренет хорошо помогает в таких условиях ;)

Зашитые в код строковые константы- как защитить их от просмотра? Найти похожие ветки