Сообщение Re[5]: Шифрование кода – 2023 от 28.02.2023 11:53
Изменено 28.02.2023 13:18 wantus
Re[5]: Шифрование кода – 2023
Здравствуйте, drVanо, Вы писали:
V>Здравствуйте, wantus, Вы писали:
W>>Из простых вариантов
W>>1. Добавить проверку подписи собственного exe (через WinVerifyTrust). По случайному таймеру, не сразу. Проверили, запомнили результат, запустили еще один таймер на несколько минут. Когда таймер сработал, покрасили background окна в красный цвет, или перевернули его кверх ногами, или еще чего-нибудь очевидно намеренное и кривое. Это уже достаточно противно патчить.
V>Пропатчат место вызова WinVerifyTrust.
Могут.
W>>2. Добавить еще несколько копий этой проверки — полных копий всего кода, а не просто вызовов check_exe_signature() — и навешать их на разные события, 56-ой клик мышки или типа того. Опять же, все проверки и реакции на их результаты — отложенные, через таймеры, простые counters или чего там еще.
V>Положат рядом прокси DLL с "правильным" WinVerifyTrust
Это да. Но это лечится аудитом загруженных DLL, который делается без единого api вызова.
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.
V>Здравствуйте, wantus, Вы писали:
W>>Из простых вариантов
W>>1. Добавить проверку подписи собственного exe (через WinVerifyTrust). По случайному таймеру, не сразу. Проверили, запомнили результат, запустили еще один таймер на несколько минут. Когда таймер сработал, покрасили background окна в красный цвет, или перевернули его кверх ногами, или еще чего-нибудь очевидно намеренное и кривое. Это уже достаточно противно патчить.
V>Пропатчат место вызова WinVerifyTrust.
Могут.
W>>2. Добавить еще несколько копий этой проверки — полных копий всего кода, а не просто вызовов check_exe_signature() — и навешать их на разные события, 56-ой клик мышки или типа того. Опять же, все проверки и реакции на их результаты — отложенные, через таймеры, простые counters или чего там еще.
V>Положат рядом прокси DLL с "правильным" WinVerifyTrust
Это да. Но это лечится аудитом загруженных DLL, который делается без единого api вызова.
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.
Re[5]: Шифрование кода – 2023
Здравствуйте, 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.
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.