Избежать использования методов просто; используйте функции, а не методы (т. е. делайте что-то по старинке, без объектов, на C++ или, по крайней мере, в Core Foundation). Но если вы используете среду выполнения ObjC, вас можно обмануть.
В принципе, вы можете обнаружить swizzling путем кэширования всех ваших указателей IMP, например, используя class_getMethodImplementation в чем-то вроде +load или, возможно, конструкторе C++ для глобальной переменной (которая запускается до main()), а затем повторно проверяя все ваши указатели IMP в разное время. чтобы убедиться, что они не изменились.
Это, вероятно, не будет слишком сложно, но трудно представить, чего все это даст. Если у кого-то есть двоичный файл вашего фреймворка, не составит большого труда исправить его, чтобы удалить вашу проверку. Где-то в исходном коде должно быть if (swizzled) { ... }, и это будет преобразовано в условную инструкцию перехода, если в ассемблере. Вы втыкаете отладчик в систему, ждете, пока не произойдет переход к «а! мы запутались», отмечаете точку, где это происходит, и исправляете этот байт как «ветвь-если-нет» или просто добавляете безусловный переход. .
Чтобы замедлить эту атаку, даже немного, требуется существенное обфускация. Есть методы (которые в основном работают не очень хорошо), но они работают только в том случае, если их держат в секрете. В этом разница между обфускацией и безопасностью.
Короткий ответ: вы действительно не можете добиться этого стабильным способом. Это означает, что вам либо нужна команда, постоянно придумывающая новые, более продвинутые средства обфускации и регулярно обновляющая их по мере появления новых атак (например, как такие компании, как Blizzard или Apple, предотвращают взломы), либо вам нужно найти способ не нужно это.
Самый простой ответ? Работайте в основном на C++ и как можно меньше используйте классы ObjC (что предотвратит swizzling, но не реверс-инжиниринг или исправление). Или смиритесь с тем, что пьянства не избежать.
(Кстати, если бы на этот вопрос был даже ответ «Я готов сделать все, что потребуется», тогда Apple просто использовала бы эту технику, чтобы сделать джейлбрейк невозможным. Тот факт, что айфоны регулярно подвергаются джейлбрейку, говорит о сложности проблемы. )
person
Rob Napier
schedule
30.01.2017
