Russian Qt Forum

Добрый день

Есть N "строк" одинаковой длины. Распределяются они в стиле С

C++ (Qt)
for (i = 0; i < N; ++i)
 line[i] = malloc(pixel_size * num_pixels);
 

Где pixel_size  может принимать значения степени 2 (4, 8, 16, 32, 64)

Задача: сделать так чтобы ни при каких сторонних модификациях кода (взломе) num_pixels никак не мог превысить заданное значение (640). Никаких уведомлений для пользователя не требуется - если код модифицирован, то сдохло, вылетело - все Ок.

Понимаю что задача странная, причудливая - но реально надо.

Спасибо

Идеальных защит не существует.
Я думаю, что единственно возможный вариант - проверить значение num_pixels непосредственно перед работой с памятью.

Updated: еще можно попробовать комбинировать разные типы данных, чтобы избежать превышения значения, но 640 вряд ли так можно добиться. Пример:

C++ (Qt)
quint8 a, b, c;
// ...
for (i = 0; i < N; ++i)
 line[i] = malloc(pixel_size * quint16(a+b+c));

Так можно добиться только значения, где максимально возможным будет 768 (256*3), зато его уже не так просто изменить в дебаггере. Можно также так:

C++ (Qt)
quint8 a, b, c;
// ...
for (i = 0; i < N; ++i)
 line[i] = malloc(pixel_size * quint16(a+b+c - 128)); // Получим 640

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

Updated: :) Еще такой вариант, в продолжение уже сказанного:

C++ (Qt)
quint8 a, b, c;
// ...
for (i = 0; i < N; ++i)
 line[i] = malloc(pixel_size * quint16(a+b+c - (std::numeric_limits<qint8>::min()*-1))); // Получим 640

Ну "if" вообще не годится т.к легко забивается. Мне не нужна "защита", я не запрашиваю никаких паролей и.т.п. Мне надо построить код таким образом чтобы больший объем был недоступен. Упрощенный пример

А вот как это сделать для более сложного случая?

Edit: к сожалению, все значения <=  640 должны обрабатываться корректно

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

C++ (Qt)
QString str1 = "598", str2 = "42";
line[i] = malloc(pixel_size * (str1.toInt() + str2.toInt()));

Идея интересная, но вызов malloc прекрасно виден, как и число выделяемых байт, т.е. можно накрутить много вычислений но в итоге все равно получается "одно число"

Ну вы же и сами понимаете, что в общем случае задача неразрешима.

Ну так сказать легко. А почему неразрешима - просто такого не написано в книжке?  :) Ведь возможности есть - могу напр распределить все 1 блоком, могу всегда распределять 640 (ничего, примирюсь с напрасной тратой памяти, это демо), могу подселить какие-то переменные в хвост(ы) буфера. Откуда же такая уверенность в "неразрешимости"?

Если хотите просто  - то и защита будет от дурака. А если более-менее серьезно: способы защиты от дизассемблера и отладчика (http://web-protect.net/p43.htm)

Updated: еще вспомнил, есть такие программы упаковщики, которые сжимают исполняемый файл, и возвращают его в исходное состояние уже при выполнении и только в вирт. памяти. Минус этих программ - на них кидаются антивирусы и это win32 only.

Да не хочу я "засисяться"  :) Хочу написать такой код чтобы буфер не мог быть расширен ковырянием кода. Это не "защита" - хотя имеет к ней косвенное отношение.

Мне кажется здесь нужно чисто считать строку-ключ на основании порядка байтов или еще чего в готовом экзешнике, дальше вшивать в этот экзешник проверку на соответствие "изначальной части" этой строке.

Это вряд ли поможет, ведь "ключ" можно считать и проверить в двух случаях: непосредственно при выделении памяти, или в другом месте программы.

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

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

Оттуда, что не определено понятие "модификация кода", какую бы наворот вы ни написали, в общем случае хакер может также его и убрать.

Если хотите избежать узкого места "константа в маллоке", то можно выделять изолированную страницу памяти, а потом делить её на 6 буферов начиная с 256-го байта, далее в программе _считать_ размер буфера равным введённому, любой больший размер приведёт к каше или SIGSEGV. Но тут вы опять скажете что хакер найдёт константу 6 и поправит и опять мы вернёмся к неразрешимой задаче.

<offtop>

Хакер - человек, который ищет уязвимости в компьютерных системах. Взломщик (Крякер, Крэкер и т.д.) - человек, который изменяет бинарный код программы в свою пользу.
</offtop>

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

#if DEMO_VERSION
#else
 DoSaveFile();
#endif

И никакие ухищрения никакому хакеру не помогут - нельзя оживить код DoSaveFile которого нет -  не был создан компилятором.

На первый взгляд - наивно. А если подумать? В совершенно др. месте вызывается проверка(и) на размер распределенного line[ i ] (технически не вопрос).  И если превышает - скромно (но со вкусом) гадим в каком-нибудь указателе. Что гений(и) могут против этого предпринять?

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

 Тогда это точно увеличит головную боль взломщика, но и это не гарантирует, что программа не будет взломана.

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

Согласен, это не "архитектурное" решение

jump куда? Я читаю переменную в куче, а модифицирую не ее а что-то другое (чтобы завалить)
К сожалению, есть основания полагать что хакер весьма хорош  :'(

В таком случае защиты на основе ключей малоэффективны. Надо ограничивать функционал демки радикально: убирать код(#if DEMO_VERSION...), или делать код заведомо ошибочным с явным указанием в инструкции к демке, что ошибка добавлена сознательно. Либо, если проект сложный, то это все решается на уровне Поддержки Производителя. Без наличия  либо исходников, либо Поддержки Производителя, ни один долгоиграющий проект не может быть эффективным. Естесственно, если это не реализация какого-либо жесткого алгоритма(черный ящик).

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

jump на функцию "заваливания" демки.

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

Ну такая демка может и отпугнуть

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

Ну как бэ... Я ведь не знаю что делает ваше приложение, но могу предположить, что удвоение счетчика должно либо сделать работу алгоритма ошибочной, либо замедлит его ну, вообще что-то из этого разряда. Чем это отличается от явно описанной ошибки?
И вцелом, мы сейчас обсуждаем безтолку. Т.к. лучшим вариантом было бы почитать хотя бы что нибудь типа "курс молодого крякера". Это позволит понять как они действуют и сообразить простецкую защиту. Ну а если подразумевается хороший крякер, то кроме как на внесение ошибки в код или ограничение функциональности расчитывать сложно. Защита от хорошего крякера - крякер чуть большей квалификации.
А с другой стороны: всетаки проект не расчитан на перспективу сотрудничества? Аутсорсинг?

Могу предложить примитивный вариант защиты основанный на множественных таймерах.
Т.е. принятие решения о выходе делаем в одном таймере. Выход в другом. А между ними несколько промежуточных. Причём время везде разное.

Если была попытка модификации - никаких "цивильных" выходов я обеспечивать не обязан, просто "завалить" как угодно

Идеально было бы именно "ограничение ф-циональности" т.е. application просто "не умеет" делать выход больше заданного (как его ни модифицируй).

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

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