Oleg LOA wrote:
1) Для начала мы долго и упорно модифицируем отладчик кровня Ring0 на предмет того чтобы защита его не видела.
Ну это баян. Все способы обнаружения отладчика давно выявлены. Тем более что приложение не имеет доступ в 0 кольцо. В дебагеррах заточнных под хакерство достаточно пару опций настроить. Да, могут портить регистры DR, но не критично.
2) Потом долго и упорно прорываемся сквозь мутирующий код виртуального процесса после вызова readfile
Хорошо, пусть все вызовы внешних библ сделаны защитой через стабы. Но весь же код приложения не будет виртуализорован защитой, а только те места (как я понял) которые указал разработчик. Теперь скажи, ты натравливал виртуализер на Yap, или он и будет так лежать в памяти процесса? Можно конечно всё приложение перелить в байт код, но это будет ой!. Вряд ли так. Поэтому тормозим процесс в вызове CreateFile и вытрассировываемся вверх куда то в database_attach. Либо просто ищем в памяти код database_attach или какой другой функции. Ну и самая тяжёлая уязвимость - это то что данные всегда будут лежать (если специалных мер не предпринимать) в памяти процесса в нативном виде. Поэтому тормознуть процесс и найти в его памяти кеш Яап не составит труда. А потом собрать базу постранично. Можно попбовать ещё проще - на CreateFile ищем в памяти dpb по очень простой сигнатуре имени файла БД :-), а оттуда выбираем encrypt_key. Мораль в том что автоматические средства защиты не могут помочь против специфичного хака. Чтобы хорошо защититься надо ещё много ручной работы сделать. -- --- Home Page http://ok.novgorod.net/ap ---
