2016-02-18 3 views
0

Я разрабатываю статическую библиотеку и использую Guardius для защиты IOS от Polidea, чтобы запутать мою статическую библиотеку. Я выполнил шаги по загрузке obfuscate_project в корневой путь моего проекта, изменил требуемые имена внутри и, наконец, запустил bash obfuscate_project в моем терминале. У меня появилось сообщение о том, что моя сборка прошла успешно, но я не смог найти файл symbols.h. Я также заметил, что была создана папка сборки. Мой вопрос: действительно ли запутывание произошло? Если да, то как я могу проверить? Является ли запутанный проект внутри моей папки сборки?Polidea iOS Class Guard успешно, но не может отличить

+0

Почему вы запутываете? Если вы не знаете, как проверить, запущен ли ваш продукт или нет, вам, вероятно, не нужно ничего путать ... – dcow

+0

@dcow Необходимо добавить слой защиты от таких инструментов, как класс-дамп. Я не думаю, что ответить на мой вопрос с вопросом очень помогает ... – iamarnold

+0

Вот почему я прокомментировал, а не отправил ответ. – dcow

ответ

1

Документация PPiOS-Rename (форк IOS Class Guard) explains how to do it:

Чтобы убедиться, что ваше приложение было запутанным, использовать nm утилиту, которая входит в состав средств для разработчиков Xcode. Запуск:

nm путь/to/your/binary | less

Это отобразит символы из вашего приложения. Если вы сделаете это с помощью несвязанной сборки, вы увидите оригинальные символы. Если вы сделаете это с запутанной сборкой, вы увидите обфусканные символы.

Обратите внимание, что после удаления символов из вашего двоичного файла nm не будет работать должным образом. Вы можете использовать утилиту otool, если вам нужно проверить символы Objective-C после удаления.

otool покажет ненужную информацию, но она может быть отфильтрованы с помощью grep и awk показывать только символы:

otool -o /path/to/your/binary | grep 'name 0x' | awk '{print $3}' | sort | uniq 
+2

- это хорошая практика для раскрытия вашего подключения к определенному продукту/компании (в данном случае [PreEmptive Solutions] (https://www.preemptive.com/products/)) – fpg1503

0

Эй, не знаю, что вы исправили эту проблему или not.I только встретились та же проблема, что и у вас сегодня, и я случайно обнаружил причину, из-за которой файл DerivedData, этот файл, по-видимому, обнаружит по умолчанию /Users/'username'/Library/Developer/Xcode/DerivedData, но в моем проекте файл DerivedData находится на корневом пути проекта, и все мои проекты одинаковы. Я предполагаю, что этот код while read app в строке obfuscate_project 78 ищет приложение в файле DerivedData по пути по умолчанию, очевидно, он не будет найден, поэтому другой код после этой строки не будет выполнен.

Чтобы изменить путь к файлу DerivedData: Xcode-> Preferences-> Locations, выберите опцию «Производные данные» «По умолчанию» и выберите «Уникальный» в «Дополнительно», а затем удалите файл DerivedData в поиске проекта, скомпилируйте проект, теперь запустить bash obfuscate_project должен быть успешным.

Смежные вопросы