Хорошая разработка программного обеспечения и безопасность

Руководства Безопасность и дизайн в значительной степени описывают различные методы, чтобы сделать его более трудным для компрометации реализации биллинга в приложении.

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

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

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

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

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

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

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

Ответ 1

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

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

Ответ 2

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

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

Ответ 3

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

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

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

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

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