Проблемы демо

[Igors]

Добрый день

Есть 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). Никаких уведомлений для пользователя не требуется - если код модифицирован, то сдохло, вылетело - все Ок.

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

Спасибо

[JamS007]

Идеальных защит не существует.
Я думаю, что единственно возможный вариант - проверить значение 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

[Igors]

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

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

Код:

char * theLine = (char *) malloc(640);  // здесь 640 можно подменить
char theLine2[640];                            // a здесь нет

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

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

[lit-uriy]

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

Код

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

[Igors]

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

Код

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

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

[brankovic]

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

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

[Igors]

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

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

[JamS007]

Если хотите просто  - то и защита будет от дурака. А если более-менее серьезно: способы защиты от дизассемблера и отладчика

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

[Igors]

Если хотите просто  - то и защита будет от дурака. А если более-менее серьезно: способы защиты от дизассемблера и отладчика

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

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

[ufna]

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

[JamS007]

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

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

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

[lit-uriy]

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

[brankovic]

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

Откуда же такая уверенность в "неразрешимости"?

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

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

[JamS007]

<offtop>

... хакер найдёт ...

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

[Igors]

Во-первых, спасибо всем отписавшимся. Понимаю что я завел "странную" тему - но мне надо решить эту проблему, не имеет значения хочу/нравится мне это или нет. Давайте не горячиться  

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

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

#if DEMO_VERSION
#else
 DoSaveFile();
#endif

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

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

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