Коллеги,

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

Но нужно сохранить вспомогательные данные для системы защиты не в самом очевидном месте вроде ветки где программа хранит настройки
HKEY_CURRENT_USER\Software\MySuperSoft

Чтобы рядовой Джо или админ Джо не добился успеха тупо удалив всю ветку с настройками программы (HKEY_CURRENT_USER\Software\MySuperSoft) в случае если взломанная программа перестала работать.


Другими словами в какие неочевидные места реестра можно безопасно насохранять вспомогательных данных от системы защиты?


Данных нужно сохранять довольно много, поэтому сохранять во времени создания каких-либо файлов не вариант.

Шифруй, тогда без разницы где.

Здравствуйте, Temnikov, Вы писали:

T>Шифруй, тогда без разницы где.

От удаления (т.е. сброса триала) не спасет.

Здравствуйте, K13, Вы писали:

K13>Здравствуйте, Temnikov, Вы писали:

T>>Шифруй, тогда без разницы где.

K13>От удаления (т.е. сброса триала) не спасет.
Нет ключа — триал недоступен. При установке шифруй нужные тебе данные и пиши в бинарно их. Ну и шифровать собсно так чтобы на разных машинах оно по разному шифровалось.

Здравствуйте, Temnikov, Вы писали:

T>>>Шифруй, тогда без разницы где.

K13>>От удаления (т.е. сброса триала) не спасет.
T>Нет ключа — триал недоступен. При установке шифруй нужные тебе данные и пиши в бинарно их. Ну и шифровать собсно так чтобы на разных машинах оно по разному шифровалось.

тогда кулхацкеры напишут прогу для генерации этого ключа и триал станет вечным без патча.

Здравствуйте, uuuser, Вы писали:

U>Здравствуйте, Temnikov, Вы писали:

T>>>>Шифруй, тогда без разницы где.

K13>>>От удаления (т.е. сброса триала) не спасет.
T>>Нет ключа — триал недоступен. При установке шифруй нужные тебе данные и пиши в бинарно их. Ну и шифровать собсно так чтобы на разных машинах оно по разному шифровалось.

U>тогда кулхацкеры напишут прогу для генерации этого ключа и триал станет вечным без патча.
Зачем тебе ключ? Можно воспользоваться виндовой CryptProtectData зашифровать либо perUser или localMachine. Если !!! ломать таки начнут, можно будет подумать над чем то другим. Скорее тебе вырубят переход при проверке условий, чем будут ковыряться с шифрованием.

Здравствуйте, K13, Вы писали:

K13>От удаления (т.е. сброса триала) не спасет.

Я неправильно пояснил.
Это в реестре не счетчик триала. Это вспомогательные данные для дополнительной защиты. Вроде хэшей динамически заблокированных ключей.

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

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


Какое нибудь мутное место вроде
HKEY_CLASSES_ROOT\.h
HKEY_CURRENT_USER\Printers\Connections
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet
Но так чтобы и Windows не начал сбоить, и желательно чтобы для антивирусов это не выглядело похожим на поведение вирусов

Здравствуйте, Temnikov, Вы писали:

T>Зачем тебе ключ? Можно воспользоваться виндовой CryptProtectData зашифровать либо perUser или localMachine. Если !!! ломать таки начнут, можно будет подумать над чем то другим. Скорее тебе вырубят переход при проверке условий, чем будут ковыряться с шифрованием.

Или просто купят ключ по ворованной карте и выложат с дистрибутивом (если нету активации).

deleted

Здравствуйте, Matrix_Failure, Вы писали

M_F>Какое нибудь мутное место вроде

M_F>HKEY_CLASSES_ROOT

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

Здравствуйте, Matrix_Failure, Вы писали:

M_F>Надо чтобы при тупом удалении из реестра обычной ветки с обычными настройками программы они тупо не стерлсь.

M_F>Т.е. мне надо найти тихое и неоднозначное место в реестре, куда безопасно записать значения переменных
т.е. вы предполагаете, что крякеры не умеют пользоваться regmon от sysinternals?

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

Здравствуйте, nigh, Вы писали:

N>т.е. вы предполагаете, что крякеры не умеют пользоваться regmon от sysinternals?

не умеют
ему на замену давно пришел procmon

Здравствуйте, bnk, Вы писали:

M_F>>Какое нибудь мутное место вроде

M_F>>HKEY_CLASSES_ROOT

bnk>Обычно это оно. Создаешь ключ с guid и пишешь туда. Там этих гуидов вагон. Но лучше все же просто зашифровать как предложили выше, а-ля CryptProtectData и положить в обычное.

А ещё лучше, посмотри, как какой-нибудь COM-объект регистрируется в ROOT, и сделай так же, причём все имена напиши от своего софта, типа это твой COM-компонент там зарегистрирован, можно даже реальный COM-компонент сделать, и создавать его, проверяя, что реестр в порядке, ничего не потёрто. И вот где-нибудь в его полях пиши свои данные. Кстати, ещё замечено, хотя сильно не рекомендую: можно писать бинарные данные в поле типа "строка", regedit при этом показывать тебе будет строку (да почти ничего не будет показывать, на первом нуле бросит это дело, поэтому можно с нуля и начать, выглядеть будет, как пустой параметр), а API будет нормально вычитывать бинарные данные. Красиво, но ненадёжно.

Чтобы усложнить жизнь потенциальным анализаторам, пиши тыщи раз вперемешку несколько одних и тех же данных в реестр, где-то среди них пиши нужное. Разобрать такой спам в процмоне будет сильно сложнее.

Здравствуйте, Matrix_Failure, Вы писали:

M_F>Данных нужно сохранять довольно много, поэтому сохранять во времени создания каких-либо файлов не вариант.

Уже раз 100 обсуждалось — все критичные данные храните у себя на сервере, а все что попало на компьютер пользователя может быть удалено/модифицировано и т.п. и вы с этим ничего не сделаете.

Здравствуйте, icezone, Вы писали:

I>не умеют
I>ему на замену давно пришел procmon
олдфаги до сих пор юзают regmon %)

Здравствуйте, drVanо, Вы писали:

V>Уже раз 100 обсуждалось — все критичные данные храните у себя на сервере

А как юзеру работать в оффлайне?

Здравствуйте, 777777w, Вы писали:

V>>Уже раз 100 обсуждалось — все критичные данные храните у себя на сервере
7>А как юзеру работать в оффлайне?
Я бы для начала хотел увидеть ответ на вопрос "А зачем что-то вообще хранить на стороне пользователя?", а потом уже можно рассуждать на тему какую схему лицензирования/активации можно предложить в конкретном случае.

P.S. Вот топикстартер пишет:

Это в реестре не счетчик триала. Это вспомогательные данные для дополнительной защиты. Вроде хэшей динамически заблокированных ключей.

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

Здравствуйте, Temnikov, Вы писали:

T>Зачем тебе ключ? Можно воспользоваться виндовой CryptProtectData зашифровать либо perUser или localMachine. Если !!! ломать таки начнут, можно будет подумать над чем то другим. Скорее тебе вырубят переход при проверке условий, чем будут ковыряться с шифрованием.

А зачем ломать ? Декриптовать на этой же машине, и добавить дешифрованными в ломанный инсталлер + развёртывание.

Шифровать на пользовательской машине — это делать security by obscurity. Раз ваш софт может декриптовать данные, значит и злоумышленник может.

Здравствуйте, CEMb, Вы писали:

CEM>Чтобы усложнить жизнь потенциальным анализаторам, пиши тыщи раз вперемешку несколько одних и тех же данных в реестр, где-то среди них пиши нужное. Разобрать такой спам в процмоне будет сильно сложнее.

Яйца за такое надо отрывать. Мусорить говном на чужом компе — плохо.