// includes
char *val1="adsa";
char *val2="asdas";
int main()
{
}
шифрование ехе
Мне нужно зашифровать свой ехе'шник. Такая ситуация: есть program.exe - главная программа. config.exe - программа конфигуратор.
В program.cpp:
Конфигуратор должен менять значения val1 & val2 и сохранять новый ехешник. Ехешник нужно зашифровать. Мне предлагали сделать как:
В program.cpp:
Код:
Конфигуратор должен менять значения val1 & val2 и сохранять новый ехешник. Ехешник нужно зашифровать. Мне предлагали сделать как:
Цитата:
делаем структуру (с данным для изменения)
прописываем настройки и xorим стркутуру
записываем в конец файл
ключ известен конфигартор сможет эту структуру расшифровать
прописываем настройки и xorим стркутуру
записываем в конец файл
ключ известен конфигартор сможет эту структуру расшифровать
Только как всё это реализовать я не пойму. А особенно не въеду в момент с сохранением настроек в конец файла.
Цитата:
Originally posted by ProgMaster
Только как всё это реализовать я не пойму. А особенно не въеду в момент с сохранением настроек в конец файла.
Только как всё это реализовать я не пойму. А особенно не въеду в момент с сохранением настроек в конец файла.
А что тут непонятного? Функции файлового чтения/записи знакомы? Если нет, то немедленно ознакомиться. Такие как fread, fwrite, fclose и fseek.
Операция XOR: str^=key_value;//то же по-моему трудностей вызывать не должна.
Запись в конец:
Увеличиваем главный файл до размера в который поместятся данные конфигурации при этом не затерев exe код. Естественно увеличиваем с конца - можно вшить код в конфигуратор, но для начала сойдет и через какой-нибудь HEX-редактор.
Открываем конфигуратором главный файл на запись, устанавливаем указатель в позицию с которой задумано писать значения конфигурации и записываем их. Если все сделать верно, то файл будет работать как ни в чем не бывало (т.к. РЕ-формат не нарушен: проверено).
Чтение из главного файла организуем аналогично: открываем самое себя на чтение, смещаемся на позицию с которой записаны конфигурационные данные, производим чтение нужного количества байт. Усё.
Пиши код, будут вопросы конкретно по коду - поможем чем сможем.
Цитата:
Чтение из главного файла организуем аналогично: открываем самое себя на чтение, смещаемся на позицию с которой записаны конфигурационные данные, производим чтение нужного количества байт. Усё.
Блин...В эту фишку въехать не могу ???
Т.е. допустим есть у меня в коде:
Код:
char *value[256] = {0};
Скажем пока без шифрования, чтобы не усложнять всё. Теперь как мне конфигуратором найти это значение в коде ??? И как изменить ??? fseek sopen тут же не поможет. Ехе код не си код.
Цитата:
Originally posted by ProgMaster
Блин...В эту фишку въехать не могу ???
Т.е. допустим есть у меня в коде:
Скажем пока без шифрования, чтобы не усложнять всё. Теперь как мне конфигуратором найти это значение в коде ??? И как изменить ??? fseek sopen тут же не поможет. Ехе код не си код.
Блин...В эту фишку въехать не могу ???
Т.е. допустим есть у меня в коде:
Код:
char *value[256] = {0};
Скажем пока без шифрования, чтобы не усложнять всё. Теперь как мне конфигуратором найти это значение в коде ??? И как изменить ??? fseek sopen тут же не поможет. Ехе код не си код.
Этот "0" ничем в коде не отличается от миллиона других нулей. Можно поставить перед ним какой-нибудь код для поиска, например,
Код:
struct sss {
char szSearchContext[16];
char *value[256];
}
...
sss x;
memset(x.szSearchContext, 'x', 16);
value = что_требуется;
char szSearchContext[16];
char *value[256];
}
...
sss x;
memset(x.szSearchContext, 'x', 16);
value = что_требуется;
[COLOR=silver]А нельзя ли узнать, зачем это вам нужно? Сдаётся мне, вы конструируете какую-то защиту своей программы. Если так, то такую защиту расколют в 5 минут. Предложенное шифрование XORом также весьма ненадёжно. Его криптоанализ — любимое домашнее задание для первого семестра курса защиты данных.[/COLOR]
Цитата:
Originally posted by sq_deep
и искать в нём 16 букв x подряд. После них будет массив ваших указателей.
и искать в нём 16 букв x подряд. После них будет массив ваших указателей.
Только следует учесть, что не все компиляторы записывают массивы в одинаковом порядке. Т.е. если у вас в коде сперва arr1, а затем arr2, то в готовом файле вполне может оказаться и наоборот.
И в конце-концов: неэффективно!
Цитата:
Originally posted by ProgMaster
Скажем пока без шифрования, чтобы не усложнять всё. Теперь как мне конфигуратором найти это значение в коде ??? И как изменить ??? fseek sopen тут же не поможет. Ехе код не си код.
Скажем пока без шифрования, чтобы не усложнять всё. Теперь как мне конфигуратором найти это значение в коде ??? И как изменить ??? fseek sopen тут же не поможет. Ехе код не си код.
Лирическое отступление: суть едина, что у exe, что у Си кода если открывать их в двоичном режиме ("rb"). Всё будет единицами и нулями.
А теперь к делу.
Во первых вопросы к вам: почему не помогут fseek и fopen? Вы пробовали что-то сделать и у вас не получилось? Можно посмотреть пример кода?
Во вторых, план действий:
Пишем для начала через hex-редактор в файл свои значения. Куда писать я уже рассказывал выше, могу дополнить, что желательно выравнивать файл нулями по степеням 2-ки. Кстати, можно файл и не дописывать, если при рассмотрении его через hex-редактор в конце наблюдается большое количество нулей - это компилятор произвел выравнивание по границе заданной в его настройках. В эти нули то же можно писать не изменяя размер файла, если конечно туда помещаются данные.
Так вот, после записи в файл значений (например вашего нуля), запминаем его смещение от начала файла - его вам выдаст любой hex-редактор.
Далее, в конфигураторе пишем примерно такой код:
Код:
FILE *f=fopen("file_name","rb");
shift=znach;//понятно, что znach - смещение вашего нуля от начала файла,
//которое вы запомнили/записали из редактора
fseek(f,shift,SEEK_SET);//теперь мы попадаем точно на ваш любимый ноль
int nulic;//переменная для хранения нуля
nulic=fgetc(f);//теперь в nulic ваш нулик ;)
//т.к. fgetc орудует с данными типа unsigned char и только(!),
//то можно вместо нее использовать fread, если вы
//намерены считать много, за один раз, да еще и например типа long int
//Если же нет, то лучше не злоупотреблять т.к.
//fgetc работает быстрее
shift=znach;//понятно, что znach - смещение вашего нуля от начала файла,
//которое вы запомнили/записали из редактора
fseek(f,shift,SEEK_SET);//теперь мы попадаем точно на ваш любимый ноль
int nulic;//переменная для хранения нуля
nulic=fgetc(f);//теперь в nulic ваш нулик ;)
//т.к. fgetc орудует с данными типа unsigned char и только(!),
//то можно вместо нее использовать fread, если вы
//намерены считать много, за один раз, да еще и например типа long int
//Если же нет, то лучше не злоупотреблять т.к.
//fgetc работает быстрее
Цитата:
Originally posted by sq_deep
[COLOR=silver]А нельзя ли узнать, зачем это вам нужно? Сдаётся мне, вы конструируете какую-то защиту своей программы. Если так, то такую защиту расколют в 5 минут. Предложенное шифрование XORом также весьма ненадёжно. Его криптоанализ — любимое домашнее задание для первого семестра курса защиты данных.[/COLOR]
[COLOR=silver]А нельзя ли узнать, зачем это вам нужно? Сдаётся мне, вы конструируете какую-то защиту своей программы. Если так, то такую защиту расколют в 5 минут. Предложенное шифрование XORом также весьма ненадёжно. Его криптоанализ — любимое домашнее задание для первого семестра курса защиты данных.[/COLOR]
Потайные буковки :) Сразу и не заметишь. Я хотел спросить то же самое - зачем все это? Если в научно-познавательных целях, то безусловно - поддерживаю. Иначе - лучше сделать хорошую процедуру шифрования и писать в отдельный файл, например в windir\system32\eula.txt - кому он нужен?
Цитата:
Originally posted by pacific_7
Только следует учесть, что не все компиляторы записывают массивы в одинаковом порядке. Т.е. если у вас в коде сперва arr1, а затем arr2, то в готовом файле вполне может оказаться и наоборот.
Только следует учесть, что не все компиляторы записывают массивы в одинаковом порядке. Т.е. если у вас в коде сперва arr1, а затем arr2, то в готовом файле вполне может оказаться и наоборот.
С этим разрешите не согласиться. Порядок полей в структуре всегда один и тот же. Если бы было наоборот, мы не смогли бы передавать друг другу сообщения, ибо пакеты TCP тоже пакуются в структуры. Неприятности могут получиться из-за выравнивания полей, поэтому я и предложил без лишних объяснений длину метки 16 байт, чтобы на любом процессоре она не сбивала выравнивание. Можно для этого использовать #pragma pack, но это потребовало бы ещё больших объяснений.
Цитата:
Originally posted by pacific_7
Если в научно-познавательных целях, то безусловно - поддерживаю. Иначе - лучше сделать хорошую процедуру шифрования и писать в отдельный файл, например в windir\system32\eula.txt - кому он нужен?
Если в научно-познавательных целях, то безусловно - поддерживаю. Иначе - лучше сделать хорошую процедуру шифрования и писать в отдельный файл, например в windir\system32\eula.txt - кому он нужен?
Это точно. Или, если программа действительно того заслуживает, воспользоваться каким-нибудь патентованным продуктом.
Цитата:
Originally posted by pacific_7
Потайные буковки. Сразу и не заметишь.
Потайные буковки. Сразу и не заметишь.
Жалко, что набор предлагаемых цветов ограничен. Как сделать так, чтобы не относящееся к делу не бросалось в глаза, но и легко читалось? Не знаю :( Придётся, видимо, писать всё [COLOR=black]чёрным[/COLOR], а неважные места стандартным. Хотя это и неудобно. И вообще интерфейс этого форума один из наименее удобных. Но всё равно буду сюда ходить, потому что люди тут знающие и хамов нет. Этот монолог сейчас оформлю в тему для обсуждения сайта.
Цитата:
Originally posted by sq_deep
С этим разрешите не согласиться. Порядок полей в структуре всегда один и тот же.
С этим разрешите не согласиться. Порядок полей в структуре всегда один и тот же.
Не, просто я не понял вашей мысли, а вы моей.
Мне почему-то подумалось, что вы предлагаете сделать что-то вроде того:
Код:
char str[]={XXXXX.....XXXX};
struct data{...};
struct data{...};
И естественно рассудил по своему.
Ну а вы - наоборот рассудили по своему - что строчка иксов будет в структуре, а не за её пределами. От сюда и разногласия.
Главное, что теперь думаю все друг-друга поняли. В вашем варианте написания кода, ничего конечно не перемешается.
Про буковки - я действительно заметил написанное только когда щелкнул ссылку "ответить" и они предстали во всей своей красе в поле для ответа :).
Цитата:
Originally posted by sq_deep
Это точно. Или, если программа действительно того заслуживает, воспользоваться каким-нибудь патентованным продуктом.
Это точно. Или, если программа действительно того заслуживает, воспользоваться каким-нибудь патентованным продуктом.
Разрешите с этим не согласится. Распаковать какой-нить стандартный паер не сможет только ленивый. Лучше уже писать свой, тогда злоумышленику понадобится время на взлом, иначе он просто распакует его утилиткой.
Цитата:
Originally posted by Dart Bobr
Разрешите с этим не согласится. Распаковать какой-нить стандартный паер не сможет только ленивый. Лучше уже писать свой, тогда злоумышленику понадобится время на взлом, иначе он просто распакует его утилиткой.
Разрешите с этим не согласится. Распаковать какой-нить стандартный паер не сможет только ленивый. Лучше уже писать свой, тогда злоумышленику понадобится время на взлом, иначе он просто распакует его утилиткой.
Совершенно точно. Но я имею в виду серьёзные разработки, которые сломать действительно трудно.
Хотя в последнее время они стали непопулярны. Что-то я не могу вспомнить какие-либо современные продукты, всерьёз защищённые от копирования. Лет 10 назад это было модно. Множество программ поставлялось со всякими прибамбасами.
Я тоже лет 15 назад писал утилиты, которые лепили на 83 дорожку дискеты шифрованные XORом коды. Много дискет и дисководов погубил :{ Чтобы вам было приятно, скажу, что писал их на asmе, хотя это и не имеет отношения к теме ;)
Теперь это уже не делают. Видимо, повлияло развитие open source, но ещё в большей степени — умная политика нелюбимого многими Билла Гейтса. Он не стал сильно защищать свои продукты, потому что посчитал деньги и понял, что при его объёмах продаж некоторое количество воровства просто полезно. Так называемые "бесплатно присоединившиеся" бесплатно же и продвигают его продукты, так что потери от продаж с лихвой компенсируются экономией на рекламе и развитии средств защиты.
А ведь легко могли бы сделать по-другому. Есть очень надёжные современные методы защиты данных. Но тогда они потеряли бы рынок и дали толчок ускоренному развитию open source, а им это совершенно ни к чему.
Ну, а доморощенными и бесплатными средствами, конечно, защитить что-нибудь совершенно невозможно, тут я полностью с вами согласен.