Если ставить нетронутые ипахи (ака подписанные сертификатом AppStore и зашифрованные FairPlayDRM) - подобных танцев с бубном не надо. Чтоб выкачать такую, понадобится всего лишь компьютер и утилита ipatool (ныне с некоторыми модификациями для получения токена). И ее уже можно ставить кому угодно, куда угодно и когда угодно - главное ввести данные от AppleID при запуске, чтоб FairPlayDRM выполнила расшифрование бинарей.
Да я и не против таких требований, в общем-то, поэтому и написал в постскриптуме :). Мои претензии касаются скорее весьма низкого уровня исследования реализуемой области. Взять код 10-летней давности, надеяться, что он идеально работает, да еще и про это написать на хабре целую статью - извините, но уж лучше ничего тогда не писать.
В противовес могу привести статью из предыдущего моего комментария. Человек, в основном не работающий с iOS, детально и по полочкам разобрал весь принцип обнаружения рута/джейлбрейка в Snapchat. Полноценно провел настоящее исследования и убедился, что его метод обхода детекта работает. Вот если бы подобное было озвучено в текущей статье - вопросов бы не было от слова совсем.
iOS приложения работают в песочнице как минимум. Вам система никогда не позволит записать файл вне песочницы, хоть 100500 джейлбрейков поставьте.
fopen("/bin/bash"
Чем fopen() в контексте проверки будет отличаться от stat(), указанного чуть выше по статье? Абсолютно ничем, разве что потратит лишние ресурсы. Про закрытие успешно открытого файла уже тут написали.
По итогу: если хотите проверять на джейлбрейки, делайте это хотя бы правильно. Как Snapchat. Иначе получается какой-то детский сад из прошлого века
P.S.: И тут еще в комментариях есть абсолютно верная мысль про абсолютную бесполезность таких детектов. Они почти все обходятся в два счета. Как минимум потому что вы и ваше приложение ограничено приватными API, а джейлбрейкеры - нет.
Вставлю и свои пять копеек, пожалуй. На хабре еще с тех времен, когда было разделение на нормальный технический ресурс и что-то менее техническое под названием Гиктаймс. Тогда это было тепло и лапмово. Заходишь - а тут тебе классное исследование чего-то по типу тогда еще журнала Хакер.
Однако, сейчас хабр скатился в полное днище и перестал как-либо вообще представлять тех самых бородатых айтишников. В новостях статьи и тупо копипастнутые с коммерсантов и виси (даже без какого-либо изменения - чистая копипаста), и проплаченные от всяких рувдс, и в принципе довольно кривые переводы неизвестных малокомпетентных личностей с твиттера. Скажите мне на милость, как вот это чудо относится к хабру как к ресурсу в целом?! Тем более к техническому.
Печально, но из-за этой дряни я практически перестал заходить на хабр, ибо это теперь обычный помоечный сайт, каких в рунете до кучи, имхо. Мне лично очень обидно.
Сейчас архитектура вообще только одна - arm64. Если конечно вы не таргетируетесь на поддержку 9 iOS и 5 айфона, что в принципе сейчас невозможно. А arm64e пока находится в бета-тесте и возможно в магазине никогда и не будет. Так что ждем какую-нибудь arm128 тогда уж.
После выполнения приведенный выше код создаст в общей сложности 150 потоков, что приведет к взрыву потока. В этом можно убедиться, приостановив выполнение и проверив навигатор отладки.
В навигаторе отладки отображаются реальные потоки, которые управляются как раз через GCD. Что приводится в статье под термином потоков - это задачи GCD. Каждая из них будет выполняться ровно на том потоке, приоритетом которого обладает.
Я выполнил этот тест пару раз, максимальное количество потоков может немного отличаться, но оно более или менее равно 3-кратному количеству ядер ЦП.
Опять же - нет. Вне зависимости от количества ядер, система выделяет четко определенное количество потоков - один основной (main), 1-3 фоновых (в зависимости от загруженности и количества задач, находящихся в очереди libdispatch) и остальные (eventloop для UI приложений, таймеров и тд, network - для работы с сетью, XPC - для взаимодействия с другими сервисами системы (тот же NSNotificationCenter))
Перестаньте, пожалуйста, насиловать свифт кривыми переводами и статьями от непонятных авторов. В какой-то прошлой статье один из комментаторов выражал подобное мнение - я с ним соглашусь. Общее качество системы из-за этого падает бешеными темпами, имхо.
Есть вот это. А если у вас найдется мак на арме, то вообще прекрасно - можно будет расшифровать бинарник приложения и убрать с него цифровую подпись. Потерял ссылочку на эту утилиту, к сожалению, но сама ее суть гуглится по запросу mremap_encrypted
Если ставить нетронутые ипахи (ака подписанные сертификатом AppStore и зашифрованные FairPlayDRM) - подобных танцев с бубном не надо. Чтоб выкачать такую, понадобится всего лишь компьютер и утилита ipatool (ныне с некоторыми модификациями для получения токена). И ее уже можно ставить кому угодно, куда угодно и когда угодно - главное ввести данные от AppleID при запуске, чтоб FairPlayDRM выполнила расшифрование бинарей.
Да я и не против таких требований, в общем-то, поэтому и написал в постскриптуме :). Мои претензии касаются скорее весьма низкого уровня исследования реализуемой области. Взять код 10-летней давности, надеяться, что он идеально работает, да еще и про это написать на хабре целую статью - извините, но уж лучше ничего тогда не писать.
В противовес могу привести статью из предыдущего моего комментария. Человек, в основном не работающий с iOS, детально и по полочкам разобрал весь принцип обнаружения рута/джейлбрейка в Snapchat. Полноценно провел настоящее исследования и убедился, что его метод обхода детекта работает. Вот если бы подобное было озвучено в текущей статье - вопросов бы не было от слова совсем.
Прошу прощения, но все приведенные проверки либо устарели, либо не будут работать должным образом.
Неужель у нас на дворе все еще 2013 год? Эти приложения пропали еще в те времена.
iOS приложения работают в песочнице как минимум. Вам система никогда не позволит записать файл вне песочницы, хоть 100500 джейлбрейков поставьте.
Чем fopen() в контексте проверки будет отличаться от stat(), указанного чуть выше по статье? Абсолютно ничем, разве что потратит лишние ресурсы. Про закрытие успешно открытого файла уже тут написали.
По итогу: если хотите проверять на джейлбрейки, делайте это хотя бы правильно. Как Snapchat. Иначе получается какой-то детский сад из прошлого века
P.S.: И тут еще в комментариях есть абсолютно верная мысль про абсолютную бесполезность таких детектов. Они почти все обходятся в два счета. Как минимум потому что вы и ваше приложение ограничено приватными API, а джейлбрейкеры - нет.
А, тогда видимо не так понял. Прошу прощения.
В коде на Rust нет std::Rc, аналога std::shared_ptr из мира C++
Есть и есть
Более того, версия для macOS весит 600 с хвостиком мегабайт.
Вставлю и свои пять копеек, пожалуй. На хабре еще с тех времен, когда было разделение на нормальный технический ресурс и что-то менее техническое под названием Гиктаймс. Тогда это было тепло и лапмово. Заходишь - а тут тебе классное исследование чего-то по типу тогда еще журнала Хакер.
Однако, сейчас хабр скатился в полное днище и перестал как-либо вообще представлять тех самых бородатых айтишников. В новостях статьи и тупо копипастнутые с коммерсантов и виси (даже без какого-либо изменения - чистая копипаста), и проплаченные от всяких рувдс, и в принципе довольно кривые переводы неизвестных малокомпетентных личностей с твиттера. Скажите мне на милость, как вот это чудо относится к хабру как к ресурсу в целом?! Тем более к техническому.
Печально, но из-за этой дряни я практически перестал заходить на хабр, ибо это теперь обычный помоечный сайт, каких в рунете до кучи, имхо. Мне лично очень обидно.
Весьма вероятно может стоять хакинтош. Да и не все обладатели десктопов обзавелись 4к мониторами, к тому же.
Сейчас архитектура вообще только одна - arm64. Если конечно вы не таргетируетесь на поддержку 9 iOS и 5 айфона, что в принципе сейчас невозможно. А arm64e пока находится в бета-тесте и возможно в магазине никогда и не будет. Так что ждем какую-нибудь arm128 тогда уж.
В навигаторе отладки отображаются реальные потоки, которые управляются как раз через GCD. Что приводится в статье под термином потоков - это задачи GCD. Каждая из них будет выполняться ровно на том потоке, приоритетом которого обладает.
Опять же - нет. Вне зависимости от количества ядер, система выделяет четко определенное количество потоков - один основной (main), 1-3 фоновых (в зависимости от загруженности и количества задач, находящихся в очереди libdispatch) и остальные (eventloop для UI приложений, таймеров и тд, network - для работы с сетью, XPC - для взаимодействия с другими сервисами системы (тот же NSNotificationCenter))
Перестаньте, пожалуйста, насиловать свифт кривыми переводами и статьями от непонятных авторов. В какой-то прошлой статье один из комментаторов выражал подобное мнение - я с ним соглашусь. Общее качество системы из-за этого падает бешеными темпами, имхо.
Есть вот это. А если у вас найдется мак на арме, то вообще прекрасно - можно будет расшифровать бинарник приложения и убрать с него цифровую подпись. Потерял ссылочку на эту утилиту, к сожалению, но сама ее суть гуглится по запросу mremap_encrypted