|
✊Rot Front✊
Пользователь
Это ответ больше похож на шуточно-серьёзный и является бредом автора:
Сразу скажу:"Если вам лень читать,то не читайте ответ, но и не пишите "брехню"".
Самая основная проблема при создании таких "тем" - отсутствия понимания написания защиты от автора.
Вам не могут предоставить защитное обеспечения из-за пожалей меня(или пожалейки).
Вы не сможете создать "нормальную"/"базовую защиту" без опыта или без траты времени на анализ других защит
(по типу своровать или взять за основу идею),если вы не хотите платит деньги(so it goes).
План A:
Более правильным, но крайне медленным способом является самостоятельное изучение ошибок/недочётов/возможности схитрить.
Я бы порекомендовал на логику определённых инструментов и сравнение с документацией дизассемблированного кода ядра/сравнение с док. Interl/Amd(в зависимости от поддержки системы).
Так же вы должны понимать, что против вас будут с большим шансом использовать(речь противодействию определённым API/NTAPI)
т.к некоторые реверсеры не дураки и не попадутся на "банальные и особенно известные методы".
Про это редко упоминают, но рекомендую подумать над этим хотя бы 1 минуту:
Некоторые реверсеры используют определённые библиотеки для анализа для эмуляции(тот же Unicorn и другие),дизассемблирования(удобно,если код вообще не шифруется) и другие.
Я рекомендую подумать,какие именно библиотеки на ваш взгляд представляют опасность и как их можно обнаружить/сделать бесполезными.
Относительно недавний хороший пример -
При использовании того же VMP/Themida вы должны понять:
Вас частично спасёт только вирта кода(не SDK),но если реверсер понимает vm-handler этих машин/изучал их или
уже имеет доступ/написал девиртуализатор для этим машин,
то это не спасёт это и будет только голая защита(речь про написание собственного mutate-engine кода) и рекомендую прочитать,а потом хорошо подумать над
Так же против вас могут и будут использовать драйвера, поэтому иногда лучше быть с противником на одном уровне +-,но я не буду раскрывать тему т.к лень думать и вы не платите ни цента за ответ!
(А чего вы ожидали от рынка, тут многих волную токлько деньги?!)
План B:
Думать над написанием защиты круто, но некоторые просто "заимствуют" защиту у других p2c/p2p/p2ac(да, много p2 bla-bla) или давным-давно известных способов защиты.
Начиная от охроняемых регионов/самошифрованием/heartbeat и ля-ля-труполя.
Лучше подумать, какие реально могут и будут препятствовать реверсеру для осуществлению его коварных планов.
Так же не забывайте, что часть кода должна хранится на сервере, чтобы реверсер смог понять вашу защиту,вот слегка плохой пример:
Сравнение текущего crc file/модулей идёт на сервере или отсутвия ответа от сервера =>
нет передачи нужного пакета(дешифрования, например) => краш и репорт
Я могу долго приводить примеры, но надеюсь такой ответ устроит большинства читателей.
План C:Пить медовуху
Сразу скажу:"Если вам лень читать,то не читайте ответ, но и не пишите "брехню"".
Самая основная проблема при создании таких "тем" - отсутствия понимания написания защиты от автора.
Вам не могут предоставить защитное обеспечения из-за пожалей меня(или пожалейки).
Вы не сможете создать "нормальную"/"базовую защиту" без опыта или без траты времени на анализ других защит
(по типу своровать или взять за основу идею),если вы не хотите платит деньги(so it goes).
План A:
Более правильным, но крайне медленным способом является самостоятельное изучение ошибок/недочётов/возможности схитрить.
Я бы порекомендовал на логику определённых инструментов и сравнение с документацией дизассемблированного кода ядра/сравнение с док. Interl/Amd(в зависимости от поддержки системы).
Так же вы должны понимать, что против вас будут с большим шансом использовать(речь противодействию определённым API/NTAPI)
т.к некоторые реверсеры не дураки и не попадутся на "банальные и особенно известные методы".
Про это редко упоминают, но рекомендую подумать над этим хотя бы 1 минуту:
Некоторые реверсеры используют определённые библиотеки для анализа для эмуляции(тот же Unicorn и другие),дизассемблирования(удобно,если код вообще не шифруется) и другие.
Я рекомендую подумать,какие именно библиотеки на ваш взгляд представляют опасность и как их можно обнаружить/сделать бесполезными.
Относительно недавний хороший пример -
Пожалуйста, авторизуйтесь для просмотра ссылки.
При использовании того же VMP/Themida вы должны понять:
Вас частично спасёт только вирта кода(не SDK),но если реверсер понимает vm-handler этих машин/изучал их или
уже имеет доступ/написал девиртуализатор для этим машин,
то это не спасёт это и будет только голая защита(речь про написание собственного mutate-engine кода) и рекомендую прочитать,а потом хорошо подумать над
Пожалуйста, авторизуйтесь для просмотра ссылки.
статьёй)Так же против вас могут и будут использовать драйвера, поэтому иногда лучше быть с противником на одном уровне +-,но я не буду раскрывать тему т.к лень думать и вы не платите ни цента за ответ!
(А чего вы ожидали от рынка, тут многих волную токлько деньги?!)
План B:
Думать над написанием защиты круто, но некоторые просто "заимствуют" защиту у других p2c/p2p/p2ac(да, много p2 bla-bla) или давным-давно известных способов защиты.
Начиная от охроняемых регионов/самошифрованием/heartbeat и ля-ля-труполя.
Лучше подумать, какие реально могут и будут препятствовать реверсеру для осуществлению его коварных планов.
Так же не забывайте, что часть кода должна хранится на сервере, чтобы реверсер смог понять вашу защиту,вот слегка плохой пример:
Сравнение текущего crc file/модулей идёт на сервере или отсутвия ответа от сервера =>
нет передачи нужного пакета(дешифрования, например) => краш и репорт
Я могу долго приводить примеры, но надеюсь такой ответ устроит большинства читателей.
План C:Пить медовуху
С++ лучшая защита от них и простой масив с проверкой по названию процесса)
