Форум тестировщиков: Тестирование защищенности десктоп приложений - Форум тестировщиков

Здравствуйте. Интересует пример отчета по тестированию защищенности десктоп приложений. По веб приложением более-менее все ясно, а вот что писать про десктоп ума не приложу. Тем более что десктоп сложно защитить, если не сломали сейчас, то могут сломать потом, до какой степени тестировать и искать ошибки?

Bora (20 Февраль 2012 - 11:58) писал:

Перво-наперво нужно определиться от чего конкретно (угрозы, атаки) приложение должно быть защищено. Без этого не то что бы отчет, а само тестирование имеет мало смысла. Короче - какова цель? Что хотим узнать?

Цитата

Насколько программа подвержена не санкционированному копированию.

Bora (20 Февраль 2012 - 19:24) писал:

Посмотрите отчёты по прохождению различных crackme. Как правило один crackme соответсвует одному способу защиты (приёму для её обхода).
Рекомендуемые ресурсы: wasm.ru (а также фоурм ресурса), и другие ресурсы по Assembler, защите, ...

Например, у вас используется следующий комплекс защитных мер:
1. Проверка пароля, записанного в конфигурационный файл, при запуске
- возможно обходится поиском места операции сравнения этого пароля и записью его в конфигурационный файл.
- если же происходит не прямое сравнение строк, а ещё куча криптографии, вривязка к SID, ... то возможно будет проще пропатчить исполняемый файл, чтобы он всегда возвращал положительный результат проверки.
2. Наличие антиотладочных функций (чтобы нельзя было узнать суть защиты)
- проверка, что Olly Debugger 1.0 и 2.0 (+ вариации, как Immunity Debugger) не отлаживают программу, вообще не могут найти точку входа.
- проверка что Hview тоже ничего не видит (точку входа).
- что IDA не мжет дизассемблировать код.
- что Windows Debugger не справился.
3. Возможно для защиты от копировать какие-то данные передаются по сети
- проверка что не сервер передаёт клиенту ключ, а наоборот (такое тоже может быть)
- проверка что непонятно из чего сформирован ключ
- проверка, что у двух разных клиентов на раных машинах, ... будут созбарны разные ключи запроса
4. Вероятно используется криптография:
- проверка что критография надёжная
- что используется для хеширования не CRC32, не MD4 и даже не MD5, а 100-кратный MD5 с солью, SHA, или надёжное шифрование
5. Если используется "отложенная проверка", то:
- проверка, что отложенная провека проверка срабатывает при запуске, при сохранении, при экспорте, ...
- что её сложной обойти
6. Проверка, что у исполняемого файла есть защита от модификации:
- зашифрованные и упакованные критические участки кода (для простоты подойдет даже бесплатные и для .NET и для нативных приложений есть, но можно и самому написать)
- проверка цифровой подписи исполняемого файла

Почитайте, поспрашивайте, выпишите тесты. А потом отчёт - пройден (вот в такой конкретной ситуации)/не пройден/требует дальнейшего изучения (непройден, но большой кровью, стоимость взлома несопоставима со стоимостью ПО).

Спасибо за столь развернутый ответ. Отчеты по крекми я видел, но хотелось более стандартизированные. Еще раз большое спасибо. (Olly рулит:))

хех,это что,тест-кейсы должны быть такие,как вы описали ?

ЗЫ: Этим же вручную занимаются,а не в...тестировании,хотя логично будет использовать это в качестве тестов.

Кстати,а какие тестируемые средства позволяют проверить приложение на различные атаки/приемы типо переполнения буфера,стека,кучи,обхода DEPа ?
Именно IDE.
Насколько мне известно,проверяется чтением исходников,а вот средств тестировщика я таких не встречал