Хорошая программная инженерия против безопасности

Question

Рекомендации Security and Design содержат подробное описание различных методов, которые затрудняют взломщику компрометацию реализации биллинга в приложении.

Особенно важно отметить, насколько это простовыполнить обратный инжиниринг файла .apk, даже если он был запутан через Proguard.Поэтому они даже рекомендуют изменить весь пример кода приложения, особенно «известные точки входа и точки выхода».

Чего мне не хватает, так это какой-либо ссылки на обертывание определенных методов проверки в одном методе, например статическом Security.verify()которая возвращает boolean: Хорошая практика проектирования (уменьшение дублирования кода, возможность повторного использования, упрощение отладки, самодокументирование и т. д.), но все, что нужно сделать злоумышленнику, - это определить этот метод и заставить его всегда возвращать true ..Таким образом, независимо от того, сколько раз я использовал его, с задержкой или без задержки, случайно или нет, это просто не имеет значения.

С другой стороны, в Java нет макросов, как в C / C ++, чтопозволяет уменьшить дублирование исходного кода, но не имеет единой точки выхода для функции verify().

Итак, мои вопросы:

Есть ли врожденное противоречие между хорошо известной разработкой программного обеспечения /методы кодирования и дизайн для так называемой безопасности?(по крайней мере, в контексте Java / Android / безопасных транзакций)

Что можно сделать, чтобы смягчить побочные эффекты «дизайна для безопасности», который выглядит как «стрельба себе в ногу» с точки зрения чрезмерной-сложное программное обеспечение, которое могло бы быть проще, удобнее в обслуживании и легче отлаживаться?

Можете ли вы порекомендовать хорошие источники для дальнейшего изучения этого предмета?

Answer 1

Как обычно, это компромисс. Создание более сложного кода для обратного проектирования / взлома делает его менее читабельным и сложным в обслуживании. Вы сами решаете, как далеко идти, основываясь на предполагаемой базе пользователей, собственных навыках в данной области, времени / стоимости и т. Д. Это не относится к Android. Посмотрите эту презентацию Google I / O , чтобы узнать о различных этапах запутывания и повышения устойчивости кода. Затем решите, как далеко вы готовы пойти для своих собственных приложений.

С другой стороны, вам не нужно запутывать / защищать и т. Д. весь вашего кода, только часть, которая имеет дело с лицензированием и т. Д. Это обычно очень малая часть вся база кода и на самом деле не нужно менять это часто, так что вы, вероятно, можете жить с ней, которую трудно отслеживать / поддерживать и т. д. Просто оставьте несколько заметок о том, как это работает, чтобы вы напоминали себе 2 года спустя :).

Answer 2

Производительность счетчика, которую вы описываете, является верхушкой айсберга ... Никакое программное обеспечение не является на 100% безошибочным при выпуске, что вы делаете, когда пользователи начинают сообщать о проблемах?

Как вы устраняете неполадки или отлаживаете проблемы на местах после того, как отключили ведение журнала, трассировку стека и всю другую информацию, которая помогает реверс-инженерам, но также помогает законной команде разработчиков?

Answer 3

Какими бы жесткими ни были методы запутывания, всегда есть способ их перепроектировать. Я имею в виду, что если ваше программное обеспечение станет более популярным среди хакерского сообщества, в конце концов кто-то попытается его перепроектировать.

Запутывание - это всего лишь способ сделать процесс реверс-инжиниринга более жестким.

Так же как и упаковка. Я думаю, что есть много методов упаковки, но так же и процесс их обратной разработки.

Вы можете проверить www.tuts4you.com , чтобы увидеть, как доступны тонны направляющих.

Я не эксперт, как многие другие, но это мой опыт в изучении реверс-инжиниринга. Также недавно я видел много руководств по обратному проектированию приложений для Android. Я видел даже в nullc0n (не уверен) CTF, было приложение в Реверсинг Android. Если хотите, я могу упомянуть сайт после поиска.