Тестирование защищенности десктоп приложений

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

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

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

Короче - какова цель? Что хотим узнать?

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

Короче - какова цель? Что хотим узнать?

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

Посмотрите отчёты по прохождению различных 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.
Насколько мне известно,проверяется чтением исходников,а вот средств тестировщика я таких не встречал