☕️ Вступ
У моїй практиці не раз траплялося так, що, прийшовши на роботу (чи просто вставши з ліжка) та відкривши пошту, я бачив гнівний лист, що повідомляв про несправність апсторівської збірки застосунку і про потребу негайно все налагодити. 😱🤯🤬
Іноді це була моя провина. Іноді — колег. Траплялося, що й сам Apple Inc завинив 😏.
Але найбільш вбивчі сценарії були пов'язані з багами, що траплялися лише на апсторівських/релізних збірках. Ніщо так не спантеличує і не змушує галасувати на свій макбук, як неможливість приєднати налагоджувач до свого власного застосунку і подивитися що там відбувається ☠️.
Схожі труднощі створює APNS і його траблшутинг на релізних/ad hoc збірках. На тих збірках, де є production APNS оточення, неможливо приєднати дебагер. А на тих збірках, де є налагоджувач, немає APNS production пушів. Саме з ними, зазвичай, і виникають проблеми 💩🤕😭.
Apple, подібно старозавітному богу, однією рукою надає платформу, де jailbreak скоро відійде в історію, а піратство в AppStore знаходиться на рівні статистичної похибки. Іншою ж рукою він змушує розробника почувати себе бідним родичем, маленьким Олівером Твістом, що дозволив собі попросити ще каші.
Для середнього програміста зробити щось з релізною/епсторівською збіркою iOS застосунку було майже нереальним. Хіба що звільнитися до релізу 🤠.
Якщо коротко, то:
Релізна збірка підписується як Distribution Certificate і використовує Distribution Provisioning Profile. Entitlement забороняють приєднувати налагоджувач до процесу застосунку. До того ж при завантаженні ipa з Апстору бінарник є зашифрованим. App Extensions підписуються окремо.
Тобто, автор застосунку може ніби перепідписати Апстор збірку сертифікатом налагодження, використовуючи provisioning profile налагоджувача. Але так ще треба вміти. Навіть після викладеного, стоїть питання про те, як приєднати налагоджувач до процесу застосунку. І як таке потім налагоджувати 🔪💔🤯.
Саме тому важливо не схибити на етапі розробки й піймати усі баги до того, як застосунок піде в Апстор. І логи: більше логів богу логів!
Але нещодавно на горизонті з'явилась нова надія.
У попередній частині ми познайомились з Frida, гарним фреймворком для dynamic code injection. З його допомогою ми обійшли SSL-pinning у проекті FoodSniffer 🍔👃
У цій статті познайомимось з фреймворком, створеним на основі Frida, який значно полегшує маніпуляції з релізними збірками iOS застосунків.
Objection
Objection дозволяє зробити injection FridaGadget в iOS збірку та перепідписати її потрібним сертифікатом та provisioning profile.
Приготування
Спочатку нам потрібна релізна збірка FoodSniffer.
Важливе зауваження: при створенні ipa вимкніть «Include bitcode for iOS content».
Далі нам знадобиться provisioning profile для налагоджуваної збірки.
Аби його отримати:
- Встановіть застосунок на пристрій через Xcode.
- Знайдіть FoodSniffer.app у Finder.
- Перейдіть до FoodSniffer bundle.
- Скопіюйте звідти embedded.mobileprovision до теки з вашим релізним ipa.
У вас повинно вийти щось подібне.
Встановіть objection згідно з інструкцією. Наполегливо рекомендую використовувати саме virtualenv варіант.
Окрім Objection нам знадобиться ios-deploy для запуску пропатченого застосунку на пристрої.
🔏 Перепідпишемо застосунок!
У терміналі з'ясуємо хеш потрібного нам code sign identity:
security find-identity -p codesigning -v
Нас цікавить 386ХХХ identity, тому що саме вона і відповідає налагоджуваному сертифікату, котрим і було підписано застосунок при встановленні з Xcode, та з якого ми отримали provisioning profile.
Заінжектимо FridaGadget та перепідпишемо наш застосунок.
objection patchipa --source FoodSniffer/FoodSniffer.ipa --codesign-signature 386XXX --provision-file embedded.mobileprovision
У результаті, ми повинні отримати FoodSniffer-frida-codesigned.ipa.
Тепер нам необхідний ios-deploy для встановлення та підключення до FridaGadget. Це важливий етап: якщо просто встановити ipa на пристрій через iTunes чи Xcode, то під'єднатися до FridaGadget не вийде.
Попередньо розпакувавши FoodSniffer-frida-codesigned.ipa.
unzip FoodSniffer-frida-codesigned.ipa
Запускаємо наш пропатчений застосунок на пристрій.
ios-deploy --bundle Payload/FoodSniffer.app -W -d
Якщо все пройшло вдало, то на пристрої повинен запуститись застосунок, а у терміналі ми побачимо:
Тепер в іншій вкладці терміналу приєднаємо objection до FridaGadget objection explore.
Профіт!
Плюшки, які надає objection 🍪
Обхід SSL Pinning
Тут усе просто:
ios sslpinning disable
Тепер можна без проблем використовувати Proxy Server для моніторингу трафіку нашого застосунку, як це було описано у першій частині.
Дамп UserDefaults
ios nsuserdefaults get
Наприкінці дампа ми повинні побачити "mood_state" = "I'm hungry".
Дамп app keychain
ios keychain dump
А ось і наш суперсекретний пароль🕵️♀️
Вибірка даних з SQLite бази
У застосунку я додав sqlite базу chinook.db звідси.
Objection дозволяє здійснювати запити безпосередньо до бази таким чином:
- Підключення до бази.
sqlite connect chinook.db
- Запит до неї.
sqlite execute query select * from albums
Висновок
Objection і Frida дозволяють, нарешті, відносно нормально та просто працювати з Ad Hoc та Distribution збірками iOS застосунків. Вони повертають програмісту владу над власним застосунком, приховану за шарами захисту, якими Apple так обережно огортає iOS застосунки. До того ж, Objection і Frida працюють на non-jailbroken пристроях, а також є відносно простими у роботі.
З ними у мене є надія make iOS development great again без потреби підриву нової штаб-квартири Apple зсередини.
Гіпер(корисні) посилання
Special thnx to @manishrhll!
П.С. 👀
Усе, що було описано у статті, варто застосовувати лише до власних застосунків і не намагатися ламати Тіндер чи Приват24.
Тим паче у вас і не вийде !🤣
Ще немає коментарів