Здравствуйте, wantus, Вы писали:
K>>Это не защитит от кейгена
W>2023 на дворе. Какие нафиг кейгены?
Можно подробнее, чем 2023 год в этом плане отличается от 2012?
K>>... юзер может получить новый ключ на сайте
W>То есть серверная часть уже есть? Это замечательно.
W>1. Напишите тривиальный HTTP/GET клиент на WinHTTP (пример есть на msdn), который из программы посылает на сайт MachineGUID и получает назад подписанную RSA ключом "лицензию" — [MachineGUID + срок годности + подпись]. Причем это можно даже по http делать, без https. На серверной стороне всё что требуется это вызвать "openssl rsautl -sign ..." из командной строки. W>2. Зашейте public часть ключа в программу и периодически проверяйте наличие (а) лицензии (б) её подпись (в) соответствие MachineGUID. W>3. Плюс добавьте отложенные по времени проверки целостности exe.
Это всё надо искать web-программиста, я сам знаю только Delphi. Думал научиться писать cgi скрипты в Lazarus, а он какой-то нелепый, пока даже не могу без посторонней помощи скомпилировать Linux-программу. Но, может быть, скоро ChatGPT сможет нам писать web-скрипты, или учить нас это делать?
Мой нынешний код web-скрипта написал другой человек 15 лет назад, я давно потерял с ним контакты.
"Ты должен сделать добро из зла, потому что его больше не из чего сделать". АБ Стругацкие.
Здравствуйте, wantus, Вы писали:
W>Из простых вариантов
W>1. Добавить проверку подписи собственного exe (через WinVerifyTrust). По случайному таймеру, не сразу. Проверили, запомнили результат, запустили еще один таймер на несколько минут. Когда таймер сработал, покрасили background окна в красный цвет, или перевернули его кверх ногами, или еще чего-нибудь очевидно намеренное и кривое. Это уже достаточно противно патчить.
Пропатчат место вызова WinVerifyTrust.
W>2. Добавить еще несколько копий этой проверки — полных копий всего кода, а не просто вызовов check_exe_signature() — и навешать их на разные события, 56-ой клик мышки или типа того. Опять же, все проверки и реакции на их результаты — отложенные, через таймеры, простые counters или чего там еще.
Положат рядом прокси DLL с "правильным" WinVerifyTrust
W>3. Могут запатчить сам WinVerifyTrust. На это добавляем вызовов WinVerifyTrust с кривыми параметрами и смотрим, что он таки возвращает ошибку.
В прокси DLL сначала вызовут оригинальную WinVerifyTrust, если ничего страшного не произошло — вернут "правильный" результат.
W>Как бонус
W>4. Можно все эти проверки отключать, если похоже что программа бежит под дебагером — IsDebuggerPresent, PEB.BeingDebugged, NtQueryInformationProcess(..., 7, ...), etc. В принципе все хорошие дебагеры умеют притворяться, что их нет, но это простая в изготовлении какашка и подложить её не мешает.
На момент написания прокси DLL поставят ScyllaHide и обойдут все эти проверки на отладчик.
W>5. Из той же серии в релиз билды можно нашпиговать NtSetInformationThread((HANDLE)-2, 0x11), что выключает дебаг текущего треда. Тоже обходится соответствующим add-on'ом к дебагеру, но далеко не все об этом знают.
Из той же серии про ScyllaHide.
W>Типа окопная партизанская война с целью измождения противника.
Я вижу тут измождение только со стороны разработчика. Даже написать вызов WinVerifyTrust у него займет гораздо больше времени чем у крякера занопить его в готовом бинарнике.
W>И как уже сказали — строго online licensing с public keys, никаких прошитых или алгоритмических ключей. Как побочный эффект, это помогает свести credit card fraud и chargebacks практически в ноль.
Public Keys для этого нужно так нихренова защитить, а то получится все таже шляпа, что и с WinVerifyTrust.
Здравствуйте, drVanо, Вы писали:
V>Здравствуйте, wantus, Вы писали:
W>>Из простых вариантов
W>>1. Добавить проверку подписи собственного exe (через WinVerifyTrust). По случайному таймеру, не сразу. Проверили, запомнили результат, запустили еще один таймер на несколько минут. Когда таймер сработал, покрасили background окна в красный цвет, или перевернули его кверх ногами, или еще чего-нибудь очевидно намеренное и кривое. Это уже достаточно противно патчить.
V>Пропатчат место вызова WinVerifyTrust.
Могут.
W>>2. Добавить еще несколько копий этой проверки — полных копий всего кода, а не просто вызовов check_exe_signature() — и навешать их на разные события, 56-ой клик мышки или типа того. Опять же, все проверки и реакции на их результаты — отложенные, через таймеры, простые counters или чего там еще.
V>Положат рядом прокси DLL с "правильным" WinVerifyTrust
Это да. Но это лечится аудитом загруженных DLL, который делается без единого api вызова, либо через LoadLibraryEx + LOAD_LIBRARY_SEARCH_SYSTEM32.
W>>3. Могут запатчить сам WinVerifyTrust. На это добавляем вызовов WinVerifyTrust с кривыми параметрами и смотрим, что он таки возвращает ошибку.
V>В прокси DLL сначала вызовут оригинальную WinVerifyTrust, если ничего страшного не произошло — вернут "правильный" результат.
По уму — да, в реальности — нет, им лень.
W>>Как бонус
V>На момент написания прокси DLL поставят ScyllaHide и обойдут все эти проверки на отладчик.
V>Из той же серии про ScyllaHide.
Ну да, я же написал, что обходится. Но не все школьники про это знают.
W>>Типа окопная партизанская война с целью измождения противника.
V>Я вижу тут измождение только со стороны разработчика. Даже написать вызов WinVerifyTrust у него займет гораздо больше времени чем у крякера занопить его в готовом бинарнике.
Каждый видит чего ему хочется, но в целом это зависит от разработчика. Далеко не все болваны.
W>>И как уже сказали — строго online licensing с public keys, никаких прошитых или алгоритмических ключей. Как побочный эффект, это помогает свести credit card fraud и chargebacks практически в ноль.
V>Public Keys для этого нужно так нихренова защитить, а то получится все таже шляпа, что и с WinVerifyTrust.
Проверять надо целостность exe и плясять от этого.
Но это все оффтоп. Поинт в том, что прокси dll не входят в арсенал подавляющего большинства l33t haxxors, от которых то и стоит по сути защищаться. От более квалифицированных товарищей тоже можно, причем в том же стиле, но это уже next level.
Здравствуйте, Khimik, Вы писали:
K>Это всё надо искать web-программиста, я сам знаю только Delphi. Думал научиться писать cgi скрипты в Lazarus, а он какой-то нелепый, пока даже не могу без посторонней помощи скомпилировать Linux-программу.
Здравствуйте, Черный 😈 Властелин, Вы писали:
ЧВ>У меня несколько десятков ордеров в день, если переписываться с каждым у кого не работает ключ, поменялись железки или там закончились активации, когда тогда писать код?
С другой стороны, если у тебя несколько десятков ордеров в день, зачем писать код?
Здравствуйте, wantus, Вы писали:
V>>В прокси DLL сначала вызовут оригинальную WinVerifyTrust, если ничего страшного не произошло — вернут "правильный" результат. W>По уму — да, в реальности — нет, им лень.
А откуда вы знаете что им лень, а что не лень? Вы предлагаете откровенно слабые варианты, которые может обойти даже начинающий реверсер.
V>>Из той же серии про ScyllaHide.
W>Ну да, я же написал, что обходится. Но не все школьники про это знают.
Школьники уже знают много чего, просто поверьте.
W>Проверять надо целостность exe и плясять от этого.
Вы где предлагаете проверять целостность на диске или в памяти? Если на диске, то в самом простом случае вам подсунут девственно чистый файл, а в более "сложном" сам бинарник будут патчить лоадером прямо в памяти. Если вы предлагаете проверять целостность имейджа в памяти, то разработчику как минимум нужно будет самому разбираться во внутренностях РЕ формата (понимать как файл проецируется на память, исключать из подсчета CRC релоки, IAT, сегменты данных и прочие прелести).
W>Но это все оффтоп. Поинт в том, что прокси dll не входят в арсенал подавляющего большинства l33t haxxors, от которых то и стоит по сути защищаться. От более квалифицированных товарищей тоже можно, причем в том же стиле, но это уже next level.
Прокси DLL я привел в качестве примера, в данном случае большинство из ваших вариантов обходятся банальным лоадером.
Здравствуйте, Sharowarsheg, Вы писали:
S> ЧВ>У меня несколько десятков ордеров в день, если переписываться с каждым у кого не работает ключ, поменялись железки или там закончились активации, когда тогда писать код?
S> С другой стороны, если у тебя несколько десятков ордеров в день, зачем писать код?
Здорово же, когда работа совпадает с любимым делом
Здравствуйте, drVanо, Вы писали:
V> Если вы предлагаете проверять целостность имейджа в памяти, то разработчику как минимум нужно будет самому разбираться во внутренностях РЕ формата (понимать как файл проецируется на память, исключать из подсчета CRC релоки, IAT, сегменты данных и прочие прелести).
Ты все усложняешь. Целостность всего образа проверять смысла нет. Достаточно проверить целостность критически важных данных и кода. Это делается проще, чем ты описываешь.
Здравствуйте, drVanо, Вы писали:
V>А откуда вы знаете что им лень, а что не лень? Вы предлагаете откровенно слабые варианты, которые может обойти даже начинающий реверсер.
Я понимаю, что вы стекольщик и вам надо нагнетать, но преувеличивать уж настолько сильно тоже не стоит.
V>Школьники уже знают много чего, просто поверьте.
Школьники как были балбесами в погоне за street cred, так и остались. Ничего принципиально за последнее время не поменялось.
V>Прокси DLL я привел в качестве примера, в данном случае большинство из ваших вариантов обходятся банальным лоадером.
Ну так себе пример то был, хотя это и уже не l33t уровень. "Банальным лоадером" можно обойти, но их делать умеет еще меньший процент.
Для не high-profile софта даже небольшая защита снижает риск кряков практически до нуля, потому что никто из тех, кто может его сломать, не будет тратить на него время.
Здравствуйте, rudzuk, Вы писали:
R>Ты все усложняешь. Целостность всего образа проверять смысла нет. Достаточно проверить целостность критически важных данных и кода. Это делается проще, чем ты описываешь.
Дык в области критичных данных и кода как раз могут встретиться релоки, особенно на х86.
ЧВ>>У меня несколько десятков ордеров в день, если переписываться с каждым у кого не работает ключ, поменялись железки или там закончились активации, когда тогда писать код? S>С другой стороны, если у тебя несколько десятков ордеров в день, зачем писать код?
В смысле, зачем? Я так к ним и пришел, постоянно совершенствуя и разрабатывая свой софт.
Конечно можно кого-то нанять, но я не люблю людей, а вот код и компы да — потому по сути занимаюсь любимым делом с достойной оплатой.
Здравствуйте, Черный 😈 Властелин, Вы писали:
ЧВ>>>У меня несколько десятков ордеров в день, если переписываться с каждым у кого не работает ключ, поменялись железки или там закончились активации, когда тогда писать код? S>>С другой стороны, если у тебя несколько десятков ордеров в день, зачем писать код?
ЧВ>В смысле, зачем? Я так к ним и пришел, постоянно совершенствуя и разрабатывая свой софт.
ЧВ>Конечно можно кого-то нанять, но я не люблю людей, а вот код и компы да — потому по сути занимаюсь любимым делом с достойной оплатой.
Разумно, да.
С третьей стороны, найми кого-нибудь на техподдержку тогда? Научить человека понимать что там с ключами и проча и перевыдывать их — не слишком сложно, и ты будешь иметь дело с одним человеком, а не со всеми сразу?
С четвертой стороны, забей — можно сказать, что я неудачно пошутил, и это будет не слишком далеко от истины.
Здравствуйте, wantus, Вы писали:
V>>А откуда вы знаете что им лень, а что не лень? Вы предлагаете откровенно слабые варианты, которые может обойти даже начинающий реверсер. W>Я понимаю, что вы стекольщик и вам надо нагнетать,
Вы меня с кем-то путаете.
W>но преувеличивать уж настолько сильно тоже не стоит.
Вы реверсингом сколько лет занимаетесь, если не секрет?
W>Школьники как были балбесами в погоне за street cred, так и остались. Ничего принципиально за последнее время не поменялось.
Здравствуйте, drVanо, Вы писали:
V> R>Ты все усложняешь. Целостность всего образа проверять смысла нет. Достаточно проверить целостность критически важных данных и кода. Это делается проще, чем ты описываешь.
V> Дык в области критичных данных и кода как раз могут встретиться релоки, особенно на х86.
В области кода могут, но нужно написать его так, чтобы их небыло, это не сложно. В области данных... Откуда в области хранения открытого ключа взяться релокам?
Здравствуйте, rudzuk, Вы писали:
R>Здравствуйте, drVanо, Вы писали:
V>> R>Ты все усложняешь. Целостность всего образа проверять смысла нет. Достаточно проверить целостность критически важных данных и кода. Это делается проще, чем ты описываешь.
V>> Дык в области критичных данных и кода как раз могут встретиться релоки, особенно на х86.
R>В области кода могут, но нужно написать его так, чтобы их небыло, это не сложно. В области данных... Откуда в области хранения открытого ключа взяться релокам?
Любые ссылки из кода на данные (в том числе и на ваш открытый ключ), данные на данные, данные на код гарантировано имеют релоки на x86. Учите матчасть.
Здравствуйте, drVanо, Вы писали:
V> V>> Дык в области критичных данных и кода как раз могут встретиться релоки, особенно на х86.
V> R>В области кода могут, но нужно написать его так, чтобы их небыло, это не сложно. В области данных... Откуда в области хранения открытого ключа взяться релокам?
V> Любые ссылки из кода на данные (в том числе и на ваш открытый ключ), данные на данные, данные на код гарантировано имеют релоки на x86. Учите матчасть.
Я же написал, что проверяемый код нужно написать так, чтобы этих ссылок небыло. И это не сложно.
Здравствуйте, rudzuk, Вы писали:
V>> Любые ссылки из кода на данные (в том числе и на ваш открытый ключ), данные на данные, данные на код гарантировано имеют релоки на x86. Учите матчасть.
R>Я же написал, что проверяемый код нужно написать так, чтобы этих ссылок небыло. И это не сложно.
Ну хорошо, давайте вы напишете такой код + все что сюда понаписали ТС-у, а я его попробую взломать. Как вам такое?
Здравствуйте, rudzuk, Вы писали:
R>Мне сантиметрами меряться не очень интересно. Давай я признаю, что у тебя длиннее, а ты признаешь, что написать код без релоков это не бином Ньютона?
Давай ты лучше признаешь, что все что ты предлагал ТС-у вместе с вантусом — это полный шлак.
Шел 2023 год.
