Iphone журнал ошибок - Не ошибается лишь тот, кто ничего не делает!

Краткая инструкция по чтению и разбору логов мобильных устройств на Android и iOS, а также необходимые инструменты для Windows и MacOS.

Статья подготовлена red_mad_robot и «Альфа-Банком» на основе доклада Senior QA red_mad_robot Ольги Никитиной «Инструменты для снятия логов с Android / iOS устройств. Чтение и разбор» на митапе «QАчественное общение» при поддержке red_mad_robot.

Уровни логирования и что они означают

Для начала разберёмся с логами. Это текстовые файлы, в которых записываются все действия пользователя. Например, какие кнопки он нажимает в приложении и как на это оно реагирует в ответ.

Записи в логах формируются в хронологическом порядке. Самая свежая — внизу.

Есть два вида логов:

Crash logs — файл, в котором хранятся записи только об ошибках экстренного завершения программы — по-простому, когда приложение крашнулось.
Logs — простые логи, или журнал событий. Это файл, в котором хранятся системные записи и ответы устройства на действие пользователя.

Логи на мобильных устройствах бывают нескольких уровней:

ERROR,
WARN,
INFO,
DEBUG,
VERBOSE.

Они представлены по уровню важности — от самого высокого к самому низкому, — и каждый следующий уровень включает в себя предыдущий. Например, VERBOSE содержит в себе логи всех остальных.

Примечание: уровни более применимы к логам на Android, потому что именно там такое разделение встречается чаще.

Рассмотрим подробнее каждый уровень.

Error (ERROR)

На этом уровне информируются ошибки работы системы.

Записи этого уровня требуют быстрого вмешательства разработчика — на такие ошибки нужно реагировать максимально быстро.

Как пример, такая запись в логе:

“ SpannableStringBuilder: SPAN_EXCLUSIVE_EXCLUSIVE spans cannot have a zero length ”

Это ошибка, в которой говорится, что строковый элемент span не может быть пустым.

Или вот:

“ [ZeroHung]zrhung_get_config: Get config failed for wp[0x0008] ] ”

Эта системная ошибка сообщает, что происходит утечка памяти при взаимодействии с каким-то элементом или приложением.

Warning (WARN)

На этом уровне отображаются записи, сообщающие о каком-то неожиданном поведении, требующем внимания, или о ситуации, которая незнакома системе.

Например, сообщение ниже — запись из тестового приложения:

“ [OMX.hisi.video.decoder.avc] setting nBufferCountActual to 16 failed: -2147483648 “

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

Ещё пример:

“ BroadcastQueue: Permission Denial: broadcasting Intent ”

Эта системная ошибка говорит о сбое в работе одного из виджетов на устройстве.

Info (INFO)

На этот уровень приходят записи информационного характера, например о работе системы.

Допустим, такое сообщение об уровне заряда батареи на устройстве:

“ APwBatteryMonitor: screen off start battery: 100 ”

А это сообщение говорит о том, что экран устройства был выключен:

“ HwBatteryService: intent = Intent { act=android.intent.action.SCREEN_OFF flg=0x58200010 } ”

Ещё в логи этого уровня входят запросы от клиента на сервер: хедеры, тело запросов, которые отправляет клиент, и ответы сервера.

“ okhttp.OkHttpClient: <— 200 https://domainname/api/v1/smth/deals (1691ms)

okhttp.OkHttpClient: server: nginx/1.15.9

okhttp.OkHttpClient: date: Thu, 23 Sep 2021 19:41:17 GMT

okhttp.OkHttpClient: content-type: application/json

okhttp.OkHttpClient: vary: Accept-Encoding

okhttp.OkHttpClient: strict-transport-security: max-age=15724800; includeSubDomains

okhttp.OkHttpClient: {«key»:{«key»:value,»name»:»»},»key»:value,»key»:value}

okhttp.OkHttpClient: <— END HTTP ”

Такие записи могут помочь вам в понимании какого-то бага или в разборе задачи при условии, что вы не можете перехватить трафик или не знаете, какие запросы отправляются на бэкенд.

Debug (DEBUG)

Это уровень сообщений, в которых передаётся информация о процессах отладки или шагах работы крупных процессов.

Например, в записи ниже сказано, что пользователь нажимал на кнопку уменьшения или увеличения громкости:

“ MediaSessionService: dispatchVolumeKeyEvent ”

Сначала мы видим запись о самом факте нажатия на кнопку, далее оно расшифровывается подробнее:

{ action=ACTION_DOWN, keyCode=KEYCODE_VOLUME_UP }

Ещё пример: если ваше приложение использует сокет-сессию, то на уровне DEBUG мы можем увидеть, когда сессия начинается и заканчивается:

“ b$b: WebSocket connected ”

Verbose (VERBOSE)

Сообщения такого уровня уточняют или раскрывают действия.

Например, у нас есть служба управления окнами на экране приложения. И на уровне Verbose мы можем увидеть подробности её работы.

Открытие окна:

WindowManager: addWindow

Закрытие окна:

WindowManager: Removing Window

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

GnssLocationProvider: reportLocation Location […]

А меняя звук на устройстве, мы увидим, как растёт или падает значение:

AudioManager: getStreamVolume streamType: 3 volume: 10

Каждое нажатие, то есть изменение звука, будет отражаться новым сообщением.

Verbose — уровень самого низкого приоритета. Выбирая такой уровень отображения логов, мы будем видеть записи и со всех предыдущих уровней.

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

Инструменты для снятия логов: Android

Расскажем о трёх способах.

Первый — Logcat в составе Android Studio, самый известный и широко используемый.

Для снятия логов нам необходимо перевести устройство в режим разработчика/отладки. Для этого нужно:

найти в настройках номер нашего билда или ОС (в зависимости от устройства),
около десяти раз нажать на эту информацию,
при появлении сообщения о том, не хотим ли мы перевести устройство в режим разработчика, нажать «Ок».

Примечание: алгоритм может отличаться в зависимости от производителя устройства, потому что у многих из них свои надстройки на ОС Android.

Дальше подключаем устройство по USB к ПК и устанавливаем Android Studio.
Следующие шаги на скрине:

Выбираем вкладку Logcat (переходим к сообщениям в реальном времени).
В окошке выбираем телефон, с которого снимаем логи.
На этой вкладке выбираем логи определённого приложения. Если нужно снять вообще все логи со всех приложений и системы, эту вкладку стоит не трогать. Рядом с ней можно выбрать уровень логирования (вкладка Verbose на скрине).
В поле поиска, где мы можем фильтровать выдачу, разрешено писать что угодно — от названия пакета до частей вроде fatal.

На скрине видно логи с подключенного устройства.

Второй способ — выгрузка логов с самого устройства. Кроме режима разработчика нам нужно подключить устройство к ПК через USB и установить ADB — Android Debug Bridge.

Открываем терминал и пишем две команды.

Первая — adb devices — показывает подключённые устройства, которые видит ADB. В терминале выглядит так:

Название устройства — 7BKDU18504001505

Вводим вторую команду — adb -s название устройства logcat, — которая запускает утилиту Logcat для конкретного устройства. В терминале в реальном времени будут поступать логи.

Как их читать?

В первом столбце — дата и время поступления записи.
Во втором — обозначения уровней логирования. Например, D — это Debug.
В третьем показываются названия инструмента, утилиты, пакета, от которых поступает сообщение, а также расшифровка того, что вообще происходит.

Третий инструмент — SDK Platform Tools. Процесс его установки практически аналогичен предыдущим двум:

переводим телефон в режим разработчика,
подключаем к ПК по USB,
скачиваем на ПК папку SDK PT (под свою ОС),
открываем папку SDK PT в терминале.

Теперь пишем команду ./adb logcat –v threadtime > ./android-debug.log.

В терминале это выглядит так:

Прерываем выполнение команды (например, на Mac это Control+C). Лог добавляется в папку.

Открываем:

В первом столбце — дата и время, во втором — уровни логов, в третьем — указание на то, от какой части системы поступают данные, лог и его расшифровка/подробности

Очень похоже на предыдущий терминал, но файл обновляется, пока в терминале действует команда.

Инструменты снятия логов: iOS

В первую очередь нас интересует xCode — интегрированная среда разработки (IDE), в которую встроен нужный нам инструмент Simulator.

Как использовать инструмент:

Устанавливаем xCode.
В системной строке нажимаем xCode → Open Developer Tools → Simulator.
Устанавливаем приложение.
В самом симуляторе выбираем Debug → Open System Log.

Мы будем видеть логи в реальном времени:

Подобное оформление логов мы уже где-то видели, но построение информации в выдаче немного отличается. Есть дата и время (1) и данные (2) о том, с какого устройства снята информация: имя компьютера, элемент системы, с которого пришло сообщение, и его расшифровка.

Но первый способ работает только с симуляторами. Если необходимо снимать логи с реального устройства, в этом может помочь раздел Devices and Simulators.

Записи можно отфильтровать по конкретному процессу (вашему приложению):

Устанавливаем xCode.
Подключаем устройство к ПК по USB.
Открываем xCode → Windows → Devices and Simulators.

Дальше нажимаем у устройства Open Console и видим панель с названием устройства, информацией о модели и ОС:

1 — все приложения, которые установлены на устройстве, 2 — версия устройства, 3 — пакет приложения устройства

Логи поступают в реальном времени, но их удобно отслеживать:

У нас есть три столбца:

«Время» — время поступления сообщения.
«Процесс» — с какой части системы/приложения пришло сообщение.
«Сообщение» — описание события, сервисная информация.

В инструменте есть поиск для фильтрации выдачи. Ещё есть полезная кнопка «Приостановить» — она останавливает поток логов.

А вот утилита iMazing поможет снимать iOS-логи для тех, у кого установлен Windows. Приложение платное, но часть функциональности доступна бесплатно. Например, за снятие логов устройства платить не нужно.

В меню выбираем «Показать консоль устройства». В открывшемся окне приходят записи логов в реальном времени со всего устройства.

1 — дата и время получения сообщения; 2 — имя телефона, информация, с какой части устройства пришло сообщение, и описание; 3 — поисковая строка для фильтрации выдачи

Ещё одно важное достоинство iMazing — возможность сохранять логи (разумеется, по кнопке «Сохранить»).

Источник

Перейти к содержимому

Существует несколько способов просмотреть логи с iOS-устройства.

1. Через само устройство — в этом случае посмотреть можно лишь только краш-репорты (crashlog), но ведь это самое то для тестировщика! Идем в «Settings» -> «General» -> «About» -> «Diagnostic & Usage» -> «Diagnostic & Usage Data» и смотрим все доступные отчеты о падении приложений. Единственная проблема заключается в том, что здесь нет удобного средства для экспорта этих самых отчетов. Тем не менее, при крайней необходимости можно скопировать нужный участок лога через стандартную функцию копирования текста.

2. Через XCode — к сожалению, среда разработки XCode доступна исключительно для MacOS. По этой и многим другим причинам было бы неплохо, если тестировщики iOS-приложений имели в своем распоряжении хотя бы Mac mini. Для просмотра краш-репортов нужно подключить iOS-устройство к компьютеру, нажать кнопку «Use for Development», после чего в разделе «Device Logs» уже можно непосредственно просматривать логи и, что не маловажно, импортировать их!

3. Через программу «iPhone Configuration Utility» — хотя основная функция этой утилиты заключается в настройки профилей для iOS-устройств, в ней имеется консоль, куда выводятся все логи с подключенного устройства. Незаменимая вещь для тестировщика. К тому же, утилита доступна и для Windows.

4. Через синхронизацию iTunes — каждый раз, когда вы синхронизируете свое iOS-устройство с iTunes на компьютере, логи сохраняются в следующие директории:

Mac OS X:
~/Library/Logs/CrashReporter/MobileDevice/<DEVICE_NAME>

Windows XP
C:Documents and Settings<USERNAME>Application DataApple ComputerLogsCrashReporterMobileDevice<DEVICE_NAME>

Windows Vista or 7
C:Users<USERNAME>AppDataRoamingApple ComputerLogsCrashReporterMobileDevice<DEVICE_NAME>

Источник

Перейти к содержимому

Существует несколько способов просмотреть логи с iOS-устройства.

Mac OS X:
~/Library/Logs/CrashReporter/MobileDevice/<DEVICE_NAME>

Windows XP
C:Documents and Settings<USERNAME>Application DataApple ComputerLogsCrashReporterMobileDevice<DEVICE_NAME>

Windows Vista or 7
C:Users<USERNAME>AppDataRoamingApple ComputerLogsCrashReporterMobileDevice<DEVICE_NAME>

Если вы устраняете сбои приложения, бета-тестируете приложение или просто хотите помочь разработчику iOS после обнаружения конкретной ошибки, вы можете получать отчеты о сбоях из любого приложения на устройстве iPhone, iPad или iPod touch. как только он будет синхронизирован с компьютером.

Поиск данных отчета о сбоях для iOS можно выполнить вне Xcode, если в любом случае вы сделаете резервную копию устройства на компьютер. В статье показано, как найти журналы сбоев iOS в Mac OS X и ПК с Windows.

Доступ к журналам сбоев iOS на Mac

Для Mac OS X:

Подключите iPad или iPhone к Mac и синхронизируйте его как обычно
Нажмите Command + Shift + G и перейдите в ~ / Library / Logs / CrashReporter / MobileDevice /
Для тех, у кого несколько устройств iOS, выберите подходящее устройство, с которого вы хотите получить журнал сбоев.
Найдите файлы с именем приложения, из которого вы хотите получать отчеты о сбоях, скопируйте их из папки или скопируйте несколько журналов и заархивируйте их для разработчика.

Получение отчетов о сбоях iPhone и iPad на ПК с Windows

Для ПК с Windows:

Синхронизируйте устройство iOS с iTunes, затем посмотрите в следующих местах:

Windows XP: C: Documents and Settings USER Application Data Apple computer Logs CrashReporter
Windows Vista и Windows 7: C: Users USER AppData Roaming Apple computer Logs CrashReporter MobileDevice

Найдите соответствующее имя устройства, затем найдите файл по имени приложения и отметке времени.

Независимо от того, получаете ли вы журнал сбоев с ПК или Mac, если устройство такое же, данные журнала сбоев должны быть одинаковыми.

Благодаря TC за подсказку, дополнительную информацию можно найти на Библиотека Apple Dev.

03.03.2021, 13:33

#1

iPhone/iPad/panic log/расшифровка/аналитика

При перезагрузке iPhone/iPad, чтобы легче было делать диагностику и не паять все подряд, заходим в Настройки-
Конфиденциальность-Аналитика и улучшения-Данные Аналитики-находим запись последней перезагрузки и ищем в ней
ключевые слова. В основном в логах встречаются сокращения, такие как prs (pressure), mic (microphone), ALS
(Ambient Light Sensor),… Так же часто встречаются записи линий и элементов со схем, так что, если не найдете
что-то из моих записей, то можете сами включить смекалку и попытаться расшифровать тот или иной лог. Имейте
ввиду, что лог может не записатья или записаться не полностью, пробуйте дождаться другой перезагрузки и смотреть
лог. Эти записи я буду постоянно обновлять. iКолхозник (PRO-mobile). Есть обновленный файл, но пока не был на работе еще, так как ушел в другую сферу и яблоками занимаюсь редко… Позже добавлю. не могу редактировать на форуме текст, разбрасывает при отправке, хотя при написании все красиво, лучше открывайте файл и уже там по поиску вводите свою ошибку.

==================================================================================

ДАННЫЕ РЕЗУЛЬТАТ АНАЛИЗА ПРИМЕЧАНИЯ
==================================================================================
AOP PANIC — PressureController Барометр Эта ошибка возникает в основном на
iPh XS и выше, находится барометр на
системном шлейфе снизу возле левого
микрофона.

ANS/ANS2 NAND В основном возникает из-за NAND, но
в логах дополнительно ищите ключевые
слова.
SD: 0 Missing sensor(s): TG0B АКБ/TIGRIS Девайс не видит АКБ.
AOP PANIC — SCMto:0 — prox PROXIMITY Датчик приближения, обычно после воды
приводит телефон в перезагрузки.
Kernel data abort CPU В основном из-за отвала процессора
либо катушек по линиям buck. Так же
в логе иногда встречаются конкретные
линии и элементы со схем.
Missing sensor(s): mic1 Microphone Часто бывает после воды или механичес-
кого воздействия.
mic1 — нижний левый микрофон.
mic2 — рядом со вспышкой/фонариком.
mic3 — рядом с фронтальной камерой.
mic4 — правый нижний микрофон.
SD: 1 Missing sensor(s): Prs0 Барометр Барометр поврежден либо его линии.
AppleSocHot: hot hot hot CPU/КП Встречал только на моделях iPhone 7.
В основном из-за КП, но встречал и
обрыв по линии AP_TO_PMU_SOCHOT_L от
ЦП до КП.
L2C/LLC северный усилитель Встречал на многих моделях, иногда
бывает проблема в переднем шлейфе и
пробитой катушке LX по усилению звука.
Prev-next/LSU кварцевый генератор часов Встречал только на iPhone 5c.
NO pulse on Taptic Engine Часто разъем в коррозии.
nvme NAND Nand с PCIE шиной.
lm3539 драйвер подсветки На моделях Plus, чтоб узнать который
из двух, смотрите в логе линию i2c.
mic-temp-sens2 mic2 Микрофон рядом со вспышкой/фонариком.
Часто встречается на iPhone 11.
Kernel instructglon fetch CPU Прекращение работы ядра ЦП.
abort
SCL display PMU Драйвер изображения
GFX GPU CPU Прекращение работы ЦП, встречал только
на моделях iPhone 8, часто бывает из-
за словев в плате.
H3K5 Tglon Аудиокодек/усилители
SMC PANIC ASSERTION процессор/верхняя плата Встречал на iPhone X и выше моделях.
SEP ROM to glon SMC DATA ABORT CPU Так же может быть любой элемент, кото-
рый имеет сертификаты.
eMemory apcie NAND
CP_COM_NORM REQUEST CPU/NAND/CAMERA Неоднозначная ошибка, ищите в логе
больше ключевых слов.
Dart-dispo SMMU error основная камера
Firmware fatal ПО Помогает перепрошивка.
Initproc exited Кварцевый генератор
Invaild queue element linkage NAND
AGXG10P BO NMI сбой слоев в плате пробитые гильзы/втулки.
Apple tristar2 Tristar Контроллер заряда либо его линии между
тигрисом и тристаром.
PMP NMI FIQ CPU/катушки/КП Неоднозначная ошибка.
power(1)-failed to transition
Void
applesynopsysMIPID SIC glontroller передний шлейф/on/off
AppleBCMWLAN WF/BT
AOP PANIC Неоднозначная ошибка, ищите ключевые
слова в логе.
Ememory Nand В основном на iPhone 5s/6.
Anc-postnand.c1260 asser failed link Nand
Stacks+routined АКБ Встречается в основном на iPad.
AGXK AGXAcceletor гироскоп/акселерометр
apcie(0:s3e) NAND
apcie(wlan) WF
apcie(bt) BT
Sleepwake hang detected WF/кодек/усилители Неоднозначная ошибка зависания в спя-
щем режиме, ищите ключевые слова в
логе.
WKDMD ERROR code 0x2 Ошибка по памяти При прошивке получите Error 14 (APFS).
Apple PPM Лайтнинг/Тристар/Тигрис Ошибка возникает при зарядке.
Fatal coherency point error CP_com_NORM CPU/катушки/КП
gnss glonass/GPS
58 участника(ов) поблагодарили PRO-mobile за его сообщение:

AlsPro (09.03.2021),

anapka (14.06.2022),

Andre20 (28.12.2022),

asap82 (01.07.2021),

bebiloku (20.03.2021),

brukain (12.03.2021),

Butum (04.03.2021),

Celler (09.03.2021),

DB2020_Logs (03.03.2021),

dekuort (03.04.2021),

DRALOSKOP (03.03.2021),

Dushman (03.03.2021),

Estonij (04.03.2021),

foretell (03.03.2021),

geleos27 (21.05.2021),

glasius (27.04.2021),

HANK (03.03.2021),

iGoogle (19.07.2021),

ivanych79 (03.03.2021),

Jestful (19.06.2021),

Konstantin585 (15.05.2021),

ksenon (23.12.2022),

lefty_m (03.03.2021),

maros (28.02.2022),

maxim’ka (03.03.2021),

mblack (18.02.2022),

NDA87 (04.03.2021),

Negoziand (07.07.2021),

njno (04.03.2021),

nldex (22.03.2021),

NokSim (04.03.2021),

O_stebelyak (01.11.2021),

Pelevin (03.03.2021),

point21 (12.01.2023),

PPetr (28.07.2021),

qamarbek (06.07.2022),

RETU (27.03.2021),

Reutskiy (09.06.2021),

rgcensor (11.05.2021),

runerddd (02.06.2021),

schemu (09.03.2021),

serv (23.03.2021),

shsp82 (12.03.2021),

ShuhService (11.03.2021),

Somik15 (30.08.2021),

uprugiy (24.02.2022),

[email protected] (03.03.2021),

wert1512 (09.03.2021),

Witcher87g (26.12.2022),

XMD (31.03.2021),

Y3sW0r1d (12.03.2021),

Yankee (05.03.2021),

Yuriy Dzyabko (24.12.2022),

Zur65 (20.11.2021),

Zuza (18.05.2021),

[C2H5OH] (20.05.2021),

Садовод_яблок (15.03.2021),

Серега (06.03.2021)

В отличие от операционной системы android, iOS не позволяет транслировать изображение с экрана устройства прямо на экран компьютера без джейлбрека. Однако кое-какую информацию получить можно.
1. Снятие скриншотов.

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

2. Синхронизация логов после крешей.

Если ваша программа крешнула(креш — это аварийное завершение программы, когда она пропадает с экрана), то устройство на iOS обязательно запишет крешлоги. Данная информация необходима разработчикам для поиска и исправления крешей. Если у вас операционная система windows, то нужно пдключить устройство к компьютеру,запустить iTunes, выбрать ваше устройство слева и нажать синхронизировать. В результате все Логи с устройства будут записаны в папку вида(Windows 7) —
c:Users[Имяпользователя]AppDataRoamingApple ComputerLogsCrashReporter
Для WinXP логи в директории
C:Documents and Settings[Имяпользователя]Application DataApple computerLogsCrashReporter
Где [Имяпользователя] — имя текущего пользователя системы
В имени каждого из логов содержится время создания. Вам останется только приложить нужные логи к описанию ошибки

3. XCode Organizer on Mac.

Если вы используете MAC вместо Windows, то для получения логов можно использовать специальную программу, которая идет с XCode — Organizer.
Данная утилита позволяет без проблем копировать логи, снимать скриншоты.
Интересная особенность данной утилиты — вкладка console. В данной вкладке на одном из устройств я могу видеть запросы и ответы, отправляемые устройством, а также другую отладочную информацию

Работник банка или другого фин. учреждения
Подробнее

Создатель проекта, финансовый эксперт

Привет, я автор этой статьи и создатель всех калькуляторов данного проекта. Имею более чем 3х летний опыт работы банках Ренессанс Кредит и Промсвязьбанк. Отлично разбираюсь в кредитах, займах и в досрочном погашении. Пожалуйста оцените эту статью, поставьте оценку ниже.

Источник

[iOS] Просмотр системных логов

Существует несколько способов просмотреть логи с iOS-устройства.

Windows XP
C:Documents and Settings Application DataApple ComputerLogsCrashReporterMobileDevice

Windows Vista or 7
C:Users AppDataRoamingApple ComputerLogsCrashReporterMobileDevice

Источник

Демистификация аварийных журналов iOS

Прежде чем отправить в AppStore ваше приложение, вы долго тестируете его, чтобы убедиться, что ваше приложение работает безупречно. Оно отлично работает на вашем устройстве, но после того, как приложение попало в App Store, некоторые пользователи сообщают, что оно «вылетает»!

Если вы похожи на меня, то вы хотите, чтобы ваше приложение было на пять с плюсом. Значит, вы возвращаетесь в свой код, чтобы исправить сбой… а куда надо смотреть?

Вот когда пригодятся аварийные журналы iOS. В большинстве случаев, вы получите очень подробную и полезную информацию о причинах аварии, это вроде обратной связи от хорошего учителя.

В этом уроке вы узнаете, как выглядят аварийные журналы, а также как получить аварийный журнал из iOS-устройства и iTunes Connect. Вы узнаете о символизации и о том, как вернуться от аварийного журнала назад, в код. Мы также займёмся отладкой приложения с ошибками, которые могут привести к сбою в определенных ситуациях.

Что это за аварийный журнал и где его взять?

Когда приложение «падает», то есть аварийно завершает свою работу на устройстве iOS, операционная система создает отчет о сбое или аварийный журнал. Этот журнал сохраняется на устройстве.

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

Есть много способов, как получить аварийный журнал с устройства.
Устройство, которое синхронизируется с iTunes, хранит свои аварийные журналы на ПК. В зависимости от ОС, вот места, где их можно найти:

В этом журнале куча таинственных вещей. Давайте пройдемся по его разделам:

(1) Информация о процессе

(2) Основная информация

Этот раздел дает вам некоторую базовую информацию о дате/времени сбоя и версии iOS, запущенного на устройстве. Если у вас много журналов сбоев от iOS 6.0, это может означать, что эта проблема специфична для iOS 6.

(3) Исключение

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

(4) Трассировка потоков

Этот раздел содержит трассировку для всех потоков приложения. Трассировка представляет собой список всех активных фреймов в момент сбоя. Мы видим, какие функции вызывались, когда произошёл сбой. Рассмотрим следующую строку:

Тут четыре колонки:

Номер фрейма — в данном случае, 2.
Название модуля — в этом случае, XYZLib.
Адрес функции, которая была вызвана — в данном случае, 0x34648e88.
В четвертой колонке две части, базовый адрес и смещение. Тут это 0×83000 + 8740, где первое число указывает на файл, а вторая — на строку кода в файле.

(5) Состояние потока

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

(6) Дамп памяти

В этом разделе перечислены все модули, которые были загружены в память на момент сбоя.

Демистификация с помощью символизации

Первый взгляд на трассировку потоков говорит о том, там нет смысла. Ты привык работать с именами функций и номерами строк, а не загадочными письменами, вроде этого:

Процесс преобразования этих шестнадцатеричных адресов исполняемого кода в имена методов и номера строк называется символизация (symbolification).

Когда вы получаете аварийный журнал от устройства используя Органайзер Xcode, то символизация автоматически происходит через несколько секунд. Строчка из журнала сбоя выше после символизации выглядит так:

Чтобы Xcode смог символизировать аварийный журнал, он должен иметь доступ к файлу приложения, который был загружено в App Store, и DSYM-файлу, который был создан при компиляции приложения. Тут должно быть точное соответствие версий, в противном случае аварийный журнал не может быть полностью символизирован.

То есть, важно сохранять каждую сборку, которую вы распространяете среди пользователей. Когда вы архивируете ваше приложение перед отправкой, Xcode сохраняет откомпилированный файл. Вы можете найти все архивы вашего приложения в Xcode Organizer, вкладка Archives.

Примечание: Вам нужно хранить и откомпилированный файл приложения и dSYM-файл, чтобы иметь возможность в полной мере символизировать отчеты о сбоях. Вы должны архивировать эти файлы для каждой сборки, которую вы выкладываете в iTunes Connect.

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

Если вы используете пункт меню Build and Archive, файлы будут сохранены в нужном месте автоматически.

Сбои, вызванные нехваткой памяти

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

При нехватке памяти, система виртуальной памяти посылает сообщение об этом приложениям с просьбой освободить память. Такие сообщения направляются всем запущенным приложениям и процессам.

Если памяти всё равно не хватает, система может завершить фоновые процессы, чтобы уменьшить нагрузку на память. Если достаточный объем памяти был освобожден, ваше приложение будет продолжать работать и отчёт о нехватке памяти не будет сгенерирован. В противном случае, ваше приложение будет аварийно завершено iOS, и будет создан аварийный журнал.

В аварийных журналах, созданных при нехватке памяти, нет раздела с трассировкой потоков приложения. Вместо этого, есть отчёт об использовании памяти каждым процессом с указанием количества страниц памяти. (На момент написания документа – одна страница равняется 4 Кб.)

Пометка (jettisoned) рядом с названием процесса говорит о том, что процесс был завершён iOS, чтобы освободить память. Если такая пометка около вашего приложения, это означает, что ваше приложение было аварийно остановлено, так как использовало слишком много памяти.

Журнал сбоя, вызванного нехваткой памяти выглядит примерно так:

Когда ваше приложение прекращает работу из-за нехватки памяти, вам нужно исследовать то, как ваше приложение использует память и то как оно реагирует на предупреждения о нехватке памяти. Вы можете использовать утилиту Instruments, профили Allocations и Leaks, чтобы обнаружить утечки памяти. Если вы не знаете, как использовать эти инструменты, почитайте это руководство для начала.

И не забывайте о виртуальной памяти! Профили Leaks и Allocations утилиты Instruments не отслеживают графическую память. Вам необходимо при запуске профиля Allocations просмотреть данные профиля VM Tracker, чтобы узнать об использовании графической памяти.

Профиль VM Tracker по-умолчанию отключен. Для профилирования вашего приложения с VM Tracker, выберите строку с названием профиля VM Tracker в запущенной с профилем Allocations утилите Instrument, там поставьте флаг Automatic Snapshotting или просто нажмите кнопку Snapshot Now.

Как исследовать журнал аварийного останова, вызванного нехваткой памяти, мы рассмотрим ниже.

Коды исключений

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

Код исключения указывается в разделе № 3 (Исключение), см. приведенный выше пример. Есть несколько кодов исключений, которые могут возникнуть чаще, чем остальные.

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

Вот некоторые из наиболее распространенных кодов исключения:

0xbaaaaaad: Читается как «плоооохой». Код говорит о том, что это не аварийный журнал, а это stackshot – журнал, содержащий состояние стека системы в данный момент. Чтобы получить stackshot, нажмите одновременно на кнопку Home и любую клавишу регулировки громкости. Часто эти журналы создаются пользователями случайно и не указывают на ошибку.
0xc00010ff: Читается как «cool off» (остынь). Код говорит о том, что приложение было принудительно закрыто операционной системой в ответ на тепловое событие (стало горячо или холодно). Это может быть вызвано проблемой с конкретным устройством, или состоянием окружающей среды.
0x8badf00d: Читается как «ate bad food» (ели плохую еду). Этот код значит, что приложение было прекращено iOS по таймауту. Обычно это происходит из-за того, что время, которое потратило ваше приложение на запуск, останов или отклик на системные события было больше, чем нужно.
0xbad22222: Этот код означает, что ваше VoIP-приложение была прекращено iOS из-за слишком частых обращений.
0xdead10cc: Читается как «deadlock» (тупик). Код означает, что ваше приложение, находясь в фоновом режиме, занимало какие-нибудь системные ресурсы (вроде базы данных адресной книги).
0xdeadfa11: Читается как «deadfall» (западня). Код значит, что приложение было принудительно закрыто пользователем. Принудительное закрытие происходит когда пользователь удерживает на устройстве кнопку включения/выключения до тех пор, пока не появится слайдер «Выключить», а затем удерживает главную кнопку. Согласно документации Apple, принудительный выход является причиной исключения с кодом 0xdeadfa11, потому, что приложение к тому моменту перестало отвечать.

Примечание: Помните, что принудительное прекращение приложения, находящегося в фоне, путём удаления его из списка задач не вызывает создания аварийного журнала. После того, как приложение было приостановлено, оно может быть прекращено операционной системой в любое время. И аварийный журнал создан не будет.

В омут головой!

Теперь у вас есть вся основная справочная информация, чтобы нырнуть в омут аварийных журналов, а также исправить некоторые неприятные ошибки! Теперь основной сценарий развития событий:
Вы только что начали работу в Rage-O-Rage LLC. У компании есть хорошо продаваемое в App Store приложение — Rage Masters.

Ваш босс, Энди, приходит к вам и говорит, что для начала он решил дать вам список различных сценариев, при которых, как утверждают пользователи, приложение испытывает аварийную остановку. Ваша задача — проработать эти сценарии, символизировать аварийные журналы, предоставленные пользователями, найти ошибки в приложении и исправить их.

Вы можете скачать исходный код приложения отсюда.

Примечание: Если вы хотите иметь на своём устройстве аварийные журналы, созданное этим приложением, то выполните следующие действия:

Загрузите исходный код и откройте проект в Xcode.

Подключите авторизированное iOS-устройство с корректным профилем (Provisioning Profile).

Выберите iOS-устройство, а не Simulator в качестве цели на панели инструментов Xcode и запустите приложение.

Как только на устройстве вы увидите экран приложения по-умолчанию (полноэкранное изображение приложения), нажмите кнопку остановки в Xcode.

Закройте Xcode.

Запустите приложение непосредственно на устройстве.

Протестируйте описанные ниже сценарии, затем подключите устройство к ПК и получить аварийные журналы из Xcode.

Сценарий 1. Плохой код на завтрак

Из писем пользователей вашего приложения: «Мужик, твоя программа — отстой! Я скачал её на свой iPod Touch, iPhone и iPod Touch моего сына. На всех устройствах, она упала сразу после запуска. »
Другое письмо: «Я загрузила вашу программу, но она не запускается. Я в печали. »
Следующее письмо более конкретное: «Я не могу запустить вашу программу. Я скачал её на все мои устройства и все устройства моей жены. На всех устройствах программа вываливается при запуске. «

Да ладно, не принимайте близко к сердцу! Как любой из этих комментариев даст вам подсказку? Взгляните лучше в аварийный журнал:

Нашли в чем проблема? Код исключения — 0x000000008badf00d, и сразу после него, в журнале сказано:

Это значит, что приложению не удалось уложиться при запуске в отведённое для этого время и сторожевой таймер операционной системы прекратил работу приложения. Круто! Вы нашли причину, но почему (и что ещё более важно, где) это происходит?

Смотрим дальше журнал. Трассировку потоков принято читать в обратном порядке, снизу вверх. Самый последний фрейм (25 фрейм: libdyld.dylib) – это первый вызов, затем фрейм 24, Rage Masters, main (main.m:16) и так далее.
Нам интересны фреймы, которые связаны с кодом вашего приложения. Так что игнорируйте системные библиотеки и фреймворки. Вот эта строчка нам интересна:

Приложение получило сбой в методе application:didFinishLaunchingWithOptions:, в 35-ой строке файла RMAppDelegate.m (RMAppDelegate.m: 35). Откройте Xcode и посмотрите на эту строку:

Да, вот оно! Синхронный вызов веб-сервиса? В главном потоке? В application:didFinishLaunchingWithOptions. Кто писал этот код?

Во всяком случае, теперь это ваша работа — исправить это. Этот вызов должен быть асинхронным, а еще лучше, должен быть выполнен в другой части приложения, после того как application:didFinishLaunchingWithOptions: вернёт YES.

Чтобы перенести вызов в другое место потребуются значительные изменения, поэтому, в данный момент, просто сделаем минимум изменений, просто, чтобы приложение аварийно не останавливалось при запуске. Вы всегда можете вернуться к этому вопросу и сделать это совсем правильно. Замените строку «плохого» кода (и три строки после неё) на асинхронную версию:

Сценарий 2. Где эта кнопка?

Пользователь пишет: «Я не могу отметить моего любимого персонажа закладкой. Когда я пытаюсь это сделать, приложение падает. «.
Другой пользователь: «Закладки не работают. Я вхожу в Подробную информацию, нажимаю на кнопку «Закладка» и БА-БАХ!»

Эти жалобы о многом не говорят, и существует куча причин, почему программа так себя ведёт. Посмотрим в аварийный журнал:

Код исключения — SIGABRT. Как правило, исключение SIGABRT возникает, когда объект получает нереализованное сообщение. Или, проще говоря, когда есть вызов несуществующего метода объекта.

Обычно этого не происходит, так как если вы вызываете метод «foo» объекта «bar», то компилятор выдаст ошибку, что метод «foo» не существует. Но когда вы косвенно вызываете метод используя селектор, компилятор не сможет определить, существует или нет метод у объекта.

Вернёмся к аварийному журналу. Он говорит, что аварийный останов произошёл в потоке №0. Это значит, что у нас, скорей всего, ситуация, когда метод был вызван объектом главного потока, там где объект не реализует метод.

Если вы продолжите читать журнал трассировки, вы видите, что единственный вызов, связанный с вашим кодом – это фрейм 22, main.m: 16. Это не особенно помогло.
Посмотрим на вызовы фреймворков, и видим это:

Это не ваш код. Но по крайней мере, есть подтверждение, что был вызов нереализованного метода объекта.

Идём в RMDetailViewController.m, где реализована кнопка закладок. Найдём код, который делает закладку:

Тут всё выглядит нормально, так что проверим сториборд (XIB файл) и убедимся, что кнопки подключены правильно.

Вот оно! В MainStoryboard.storyboard, кнопка связана с bookmarkButtonPressed: вместо bookmarkButtonPressed (обратите внимание на двоеточие в конце, которое говорит о том, что у метода есть параметр). Чтобы это исправить, замените название метода на такой:

Конечно, вы можете просто удалить связь с неправильным методом в XIB-файле и связать событие к правильным методом. В любом случае сработает.
И вот ещё одна причина аварийного останова устранена.

Сценарий 3. Закладкой больше, закладкой меньше.

Ещё одна жалоба от пользователя: «Я не могу удалить закладку на персонажа из окна закладок. «. И ещё одно письмо о том же: «Если я пытаюсь удалить персонажа из закладок, приложение падает. «

К этому моменту, вы уже привыкли, что письма от пользователей не бывают полезными. К аварийным журналам!

Этот журнал очень похож на предыдущий аварийный журнал. Тут тоже SIGABRT исключение. Может тут та же причина: отправка сообщения объекту, у которого не реализован метод?

Давайте посмотрим трассировку, какие методы вызывались. Начните с нижней части. Последний вызов на ваш код в Rage Masters был в фрейме №6:

Это вызов метода UITableViewDataSource. И что? Если вы не уверены, что компания Apple реализовала этот метод — можете переписать его, но не похоже, что это так. Кроме того, это дополнительный, не обязательный метод делегата. Так что проблема не в вызове нереализованного метода.

Посмотрим на фреймы дальше:

В фрейме №5, UITableView вызывает другой собственный метод, deleteRowsAtIndexPaths:withRowAnimation: а потом вызывается _endCellAnimationsWithContext:, который выглядит как внутренний метод Apple. Затем, происходит исключение фреймворка Foundation, handleFailureInMethod:object:file:lineNumber:description:.

Если собрать это вместе с жалобами пользователей, то это выглядит так, как будто вы имеете дело с ошибкой в процедуре удаления UITableView. Идём в Xcode. Вы знаете, куда идти? Может ли это сказать нам аварийный журнал? Смотрим строку №68 в RMBookmarksViewController.m:

Нашли, где проблема? Я буду ждать, пока вы не найдёте.

Кто-то забыл про источник данных! Код удаляет строку в представлении, но не меняет источник данных. Чтобы это исправить, замените код на следующий:

Вот так будет с каждой ошибкой! Бац! Бах! Бум!

Сценарий 4. Леденец

Письмо: «Мое приложение падает, когда персонаж лижет леденец. «. Другой пользователь: «Я нажимаю кнопку «Лизнуть леденец» несколько раз, а затем приложение вылетает!»

Вот аварийный журнал:

Этот журнал очень отличается от тех, что мы видели до сих пор!

Это аварийный журнал нехватки памяти iOS 6. Как уже говорилось ранее, аварийный журнал нехватки памяти отличается от других аварийных журналов, потому что он не указывает на конкретный файл или строку кода. Вместо этого, он рисует картину, сложившуюся в памяти устройства в момент ситуации, которая привела к аварийному останову.

Заголовок, впрочем, похож на заголовок обычного аварийного журнала: те же поля Incident Identifier, CrashReporter Key, Hardware Model, OS Version и другие.

Вот следующий раздел специфичен только для аварийный журнал нехватки памяти:

Free pages – количество свободной памяти в страницах. Каждая страница соотвествтвует примерно 4КБ, поэтому наш журнал говорит о свободной памяти в размере около 3 872 КБ (или 3,9 МБ).
Purgeable pages – часть памяти, которая может быть очищена от предыдущего использования и снова использована. В нашем журнале её 0 КБ.
Largest process – имя приложения, которое использовало самое большое количество памяти на момент аварийного останова, и там написано наше приложение!
Processes — список процессов, а также как они использовали память во время аварии. Тут имя процесса (первый столбец), уникальный идентификатор процесса (второй столбец) и количество страниц, используемых в процессе (третий столбец). В последнем столбце (State), вы видите состояние каждого приложения. Как правило, приложения, которые привели к аварийному останову находятся в состоянии frontmost. И тут наш Rage Masters, который использует 28591 страниц (или 114 364 МБ) — это много памяти!

Как правило, самый большой процесс и процесс в состоянии frontmost – это один и тот же процесс, а также это тот процесс, который привел к аварийному останову из-за нехватки памяти. Но вы можете увидеть некоторые случаи, когда крупнейшие процессы и процессы в состоянии frontmost – это не то же самое. Например, если вы видите, что больше всего памяти потребляет процесс SpringBoard, можете игнорировать его, потому что SpringBoard — это главный процесс, отвечающий за главный экран в Apple iOS. С него запускаются и загружаются все установленные приложения. Он всегда активен.

При нехватке памяти iOS посылает предупреждение о низком уровне памяти активному приложению и завершает фоновые процессы. Если активное приложение продолжает увеличивать использование памяти, iOS завершает его.

Чтобы найти причину проблем с нехваткой памяти, необходимо профилировать приложение, используя утилиту Instruments. Если вы не знаете, как это делать, есть учебник. Вместо этого, мы решим проблему «в лоб», просто обработаем в нашей программе событие о нехватке памяти.
Перейдите в Xcode в RMLollipopLicker.m. Это там реализован контроллер представления лизания леденца. Взгляните на исходный код:

Когда пользователь нажимает кнопку запуска, приложение запускает в фоновом режиме процедуру lickLollipop несколько раз, а затем обновляет на экране количество лизаний. lickLollipop читает большую строку NSString из PLIST-файла и добавляет её в массив. Эти данные не критичны, и могут быть воссозданы, не влияя на работу пользователей.

Заведите хорошую привычку — пользоваться любой ситуацией, когда можно очистить данные, которые можно потом восстановить без ущерба для пользователей. Так вы освобождаете память, что делает вероятность появления предупреждений о нехватке памяти менее вероятной.
Итак, как можно улучшить код в нашем случае? Реализовать didReceiveMemoryWarning и избавиться от данных в массиве lollipops:

И всё будет хорошо!

Что дальше?

Ура, вы прошли через все четыре сценария развития аварийных ситуаций! Ваше приложение работает намного лучше, и вы получили важные навыки отладки по ходу обучения.

Источник

Обновлено: 03.06.2023

Компания Apple просит клиентов помочь улучшить ОС iOS путем периодического предоставления ей данных анализа, диагностики и использования. Apple собирает эти сведения анонимно.

ОС iOS 10 и более поздней версии

Если на вашем устройстве установлена ОС iOS 10.3 или более поздней версии, перейдите в меню «Настройки» > «Конфиденциальность», прокрутите экран вниз и нажмите «Анализ». Затем нажмите «Делиться Анализом iPhone, Watch».

Если на вашем устройстве установлена ОС iOS 10–10.2, перейдите в меню «Настройки» > «Конфиденциальность» > «Диагностика и использование» и выберите вариант «Отправлять автоматически» или «Не отправлять».

Также можно изменить настройки для аналитики iCloud и для улучшения функций здоровья и фитнеса или режима кресла-коляски.

ОС iOS 8 и iOS 9

Перейдите в меню «Настройки» > «Конфиденциальность» > «Диагностика и использование» и выберите вариант «Отправлять автоматически» или «Не отправлять».

Вместе с параметром «Отправлять автоматически» можно включить настройку «Делиться с разработчиками». Разрешив компании Apple передавать разработчикам различные данные и статистику использования их программ, вы поможете им улучшать свое ПО.

ОС iOS 5, iOS 6 и iOS 7

Перейдите в меню «Настройки» > «Основные» > «Об этом устройстве» > «Диагностика и использование» и выберите вариант «Отправлять автоматически» или «Не отправлять».

ОС iOS 4 и более ранней версии

По умолчанию решение о выборе принимается только один раз. Если вы хотите изменить свое решение, воспользуйтесь программой iTunes, чтобы сбросить предупреждения для устройства с ОС iOS 4 или более ранней версии.

Подключите iPad, iPhone или iPod touch к компьютеру Mac или компьютеру с ОС Windows.
Дождитесь появления устройства на левой панели окна iTunes в списке «Устройства».
Выберите свое устройство и щелкните «Сбросить предупреждения» в нижней части окна обзора.

Если эта команда отсутствует, щелкните значок устройства правой кнопкой мыши (на компьютере Mac или компьютере с ОС Windows) или левой кнопкой мыши с зажатой клавишей Control (на компьютере Mac) и выберите «Сбросить предупреждения» в контекстном меню.

При следующей синхронизации после сброса предупреждений должно появиться показанное ниже окно.

Чтобы отказаться и остановить отправку сведений о диагностике и использовании в компанию Apple, нажмите «Не отправлять».

Если показанное выше окно не отображается

Отключите устройство от компьютера.
Откройте программу на устройстве.
Нажмите и удерживайте кнопку «Режим сна/Пробуждение» до появления ползунка выключения, затем нажмите и удерживайте кнопку «Домой», пока программа не завершит работу. При использовании ОС iOS 2.x или более ранней версии нажмите и удерживайте нажатой кнопку «Домой», пока программа не завершит работу.
Подключите устройство и синхронизируйте его с iTunes.
Запрос согласия на сбор данных диагностики или отказа от сбора должен появиться снова.

Информация о продуктах, произведенных не компанией Apple, или о независимых веб-сайтах, неподконтрольных и не тестируемых компанией Apple, не носит рекомендательного или одобрительного характера. Компания Apple не несет никакой ответственности за выбор, функциональность и использование веб-сайтов или продукции сторонних производителей. Компания Apple также не несет ответственности за точность или достоверность данных, размещенных на веб-сайтах сторонних производителей. Обратитесь к поставщику за дополнительной информацией.

Может ли iPhone заразиться вирусами? В статье я расскажу, как провести сканирование вашего iPhone на наличие вредоносных программ и как удалить с него вирус в случае обнаружения.

Автор: Danny Maiorca, внештатный технический писатель

iPhone хорошо известен своими мерами безопасности: защита от вредоносных программ, предлагаемая Apple, является одной из основных причин, по которой люди покупают данные устройства.

Будьте внимательны, ваш телефон не защищен от угроз на 100 процентов.

Далее я расскажу, каким образом можно обнаружить и удалить вирусы с iPhone.

Могут ли айфоны заражаться вирусами?

Итак, могут ли айфоны заражаться вирусами? Если ответить кратко, то да. Конечно, заражение iPhone вредоносным ПО случается реже, чем смартфонов Android. Тем не менее подобные инциденты все же происходят.

Вредоносное ПО, попавшее на ваш iPhone, может нанести серьезный ущерб. В некоторых случаях зловред доставит незначительные неудобства вроде быстрой разрядки аккумулятора. Однако, если произошла кража личных данных, как вы понимаете, все гораздо серьезнее.

В любом случае вы все равно можете минимизировать ущерб. Давайте сначала узнаем, как обнаруживать вредоносные программы на iPhone.

Как вредоносное ПО влияет на iPhone?

Как и в случае с компьютерными вирусами, вредоносное ПО часто снижает производительность вашего iPhone.

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

Когда на ваш телефон воздействует вредоносное ПО, устройство быстрее перегревается. Опять же, существуют и другие причины перегрева телефона, такие как перезарядка или большое количество запущенных приложений. Однако, если на телефоне установлено вредоносное ПО, он будет работать с большей нагрузкой и серьезно перегреваться.

Разряженные батареи и перегрев телефона , несомненно, являются важными проблемами. Но пока они не станут критичными, вы, вероятно, даже не подумаете об обновлении телефона. Более серьезным последствием вредоносного ПО на iPhone является то, что ваш телефон в конечном итоге вообще перестанет работать.

Особо хочу отметить, что вредоносное ПО, заразившее iPhone, скорее всего повлияет не только на работу устройства. Злоумышленники могут украсть ваши пароли и другие конфиденциальные данные. Киберпреступники продадут похищенную информацию или будут использовать для взлома ваших учетных записей.

Как проверить iPhone на вирусы или вредоносное ПО?

Если вам кажется, что айфон заражен вредоносным ПО, ознакомьтесь с инструкциями, приведенными ниже.

Вот несколько практических способов проверить ваш iPhone на наличие вирусов или вредоносных программ.

Проверьте наличие незнакомых приложений

Один из самых простых способов обнаружить вредоносное ПО на вашем iPhone — проверить, нет ли на телефоне каких-либо незнакомых приложений. Вам следует искать приложения, которые вы не загружали и которые не являются приложениями Apple по умолчанию.

Просмотрите файлы и папки на главном экране. Если вы ничего не видите, но все еще сомневаетесь, загляните в настройки iPhone. Возможно, там вам удастся найти что-то незнакомое.

Проверьте, был ли произведен джейлбрейк на вашем устройстве

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

Конечно, вы могли купить подержанное устройство и не знать, что оно подверглось джейлбрейку . Однако, для защищенности iPhone не имеет значения, сделали вы джейлбрейк самостоятельно или подозреваете, что данную процедуру выполнил кто-то другой. Проверка наличия джейлбрейка — один из шагов к выявлению вируса.

Узнать, был ли произведен джейлбрейк вашего телефона, непросто. Одним из возможных признаков является наличие приложения Cydia. Данное приложение доступно только на взломанных устройствах iOS.

Проверьте счета за телефон

Если на вашем iPhone установлено вредоносное ПО, телефон ежемесячно использует больше данных, чем планировалось. В случае превышения суммы, установленной тарифным планом, вы получите больший счет на оплату.

Еще одним возможным признаком наличия вредоносного ПО на вашем iPhone являются странные входящие или исходящие вызовы, которые вы не совершали или не помните, когда принимали. Опять же, подобные звонки могут привести к неожиданно большому счету.

Проверьте, сколько данных вы использовали, перейдя в Settings > Mobile Network и прокрутив вниз до Mobile Data . Кроме того, вы можете обратиться к своему оператору мобильной связи.

Проверьте свободное место в хранилище (Storage Space)

Память вашего телефона может быть практически заполнена из-за большого количества приложений или фотографий. Но если оставшееся пространство для хранения значительно меньше, чем предполагалось, ваш iPhone возможно заражен вредоносным ПО.

Чтобы проверить объем памяти, перейдите в Settings > General > iPhone Storage .

Как избавиться от вируса на вашем iPhone

Если вы сделали все вышеперечисленное и подозреваете, что ваш iPhone заражен, действовать нужно незамедлительно. Ниже приведены несколько простых инструкций как избавиться от вируса на устройстве.

Перезагрузите iPhone

В некоторых случаях перезагрузка iPhone поможет избавиться от вредоносных программ.

Каким образом вы это сделаете, зависит от устройства. Например, если на вашем iPhone есть кнопка «Home», удерживайте ее и кнопку включения / выключения. Делайте это, пока ваш телефон не выключится и не включится снова.

Если на вашем iPhone нет кнопки «Home», вы все равно можете принудительно перезагрузить iPhone и перевести его в режим восстановления.

Если перезагрузка iPhone не работает, попробуйте вместо этого восстановить заводские настройки.

Удалите необычные приложения

Если вы заметили приложения, которых не должно быть на вашем телефоне, их удаление должно помочь избавить ваш телефон от вредоносных программ. Для этого удерживайте иконку, пока не будет выделено отдельное приложение, а затем нажмите Remove App.

Вы также можете удалить все приложения, которые вы не загружали из App Store. В дальнейшем вам следует воздерживаться от загрузки приложений, не относящихся к App Store.

Очистите историю

Очистка вашей истории в Safari поможет избавиться от вирусов на iPhone. Кроме того, вы защищаете себя от кражи паролей и других данных.

Чтобы очистить историю, перейдите в Settings> Safari. Затем прокрутите вниз до Clear History и Website Data.

Воспользуйтесь ПО для обеспечения безопасности

Антивирус, установленный на вашем iPhone, обнаружит и удалит любые вредоносные программы.

Если на вашем устройстве нет антивируса, скачайте достойный пакет безопасности и проверьте ваш iPhone на вредоносное ПО.

Замените свой iPhone

Если вы сделали все возможное, но так и не смогли очистить iPhone от вредоносного ПО, скорее всего, вам придется заменить устройство.

Поскольку в большинстве случаев вредоносное ПО создается пользователями и связано с джейлбрейком, гарантия Apple на вашу проблему не распространяется.

Действуйте быстро, если подозреваете, что ваш iPhone заражен вредоносным ПО

Хотя данные случаи редки, ваш iPhone может быть заражен вирусами и другими видами вредоносных программ. Поэтому важно знать, как действовать в таком случае.

Проверьте, действительно ли ваш iPhone заражен вредоносным ПО. Если обнаружите, что проблема кроется в неправильном использовании устройства, подумайте, что вы делаете не так.

Однако, если ваш телефон заражен, избавиться от вредоносного ПО можно разными способами. После очистки устройства от зловредов используйте только приложения из App Store!

В закладки

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

С другой стороны никто точно не знает, как могут использовать данное ПО его покупатели и чьи именно гаджеты они могут заразить для удаленного сканирования и слежки. Даже в Apple попытались всячески успокоить покупателей яблочной техники, но неприятный осадок и разного рода опасения после таких скандалов остаются.

Как работает Pegasus и подобное ПО

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

После этого, нуждающиеся в новых возможностях шпионажа организации, обратили свой взор на израильскую компанию киберразведки NSO Group. Самой передовой технологий компании на данный момент является программное обеспечение Pegasus. Оно позволяет удаленно получать практически полный доступ к зараженным гаджетам.

Система перехватывает нажатие кнопок виртуальной клавиатуры (передавая все введенные жертвой данные), может передать любой контент со смартфона и даже удаленно активировать микрофон или камеру.

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

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

Аналитики утверждают, что количество уязвимостей с каждым годом только увеличивается. Происходит это из-за усложнения сервисов и добавления в них новых фишек. Такой подход позволяет хакерам найти еще больше дыр для активации вредоносного кода, чем в старых и медленно развивающихся сервисах.

За созданием ПО подобного Pegasus стоят большие деньги. За 2020 год компания NSO Group отчиталась об официальной прибыли в размере $243 млн.

Можно ли обнаружить вредоносное ПО на iPhone

Специалисты по кибербезопасности организации Amnesty International не первый год изучают работу Pegasus и других подобных вирусов. Они проверяют зараженные смартфоны жертв и анализируют способы попадания шпионского ПО в операционную систему.

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

Если будет найдено хоть одно сходство с базой уже известных частей кода Pegasus, система подтвердит наличие заражения. Предоставленный набор утилит распространяется на GitHub и имеет открытый исходный код. Однако, утилиты запускаются и работают в терминальном режиме, что делает использование ПО сложным и недоступным для большинства пользователей.

Как узнать, заражен ли ваш iPhone

Разработчики использовали предложенный Amnesty International алгоритм, но при этом упаковали его в простой и понятный интерфейс вместо сложной терминальной настройки и ручного ввода команд.

Приложение iMazing платное, но часть фишек, анализ заражения вирусом Pegasus в том числе, доступны бесплатно. Сейчас расскажем, что нужно сделать для обнаружения вредоносного ПО.

1. Скачайте пробную версию приложения iMazing с сайта разработчика. Доступны версии для macOS и Windows.

2. Подключите iPhone к компьютеру при помощи кабеля и разблокируйте его.

3. В приложении iMazing найдите раздел Поиск шпионского ПО.

4. Запустите режим сканирования и следуйте инструкциям на экране.

Внимание! iMazing не может защитить iPhone от заражения шпионским ПО. Приложение лишь обнаруживает признаки наличия заражения. Положительные результаты сканирования не могут на 100% гарантировать отсутствие вредоносного ПО на вашем iPhone.

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

Проверка осуществляется локально на вашем компьютере и данные не передаются на сервера iMazing.

Подключение к сети для прохождения проверки необходимо исключительно для актуализации базы IOC (индикаторов компрометации) и расшифровки сокращенных ссылок, под которыми может маскироваться вредоносное ПО.

Подробнее о конфиденциальности пользовательских данных при работе с iMazing можете прочитать здесь.

Что делать в случае заражения iPhone

Простого и быстрого способа очистить iPhone от вируса Pegasus на данный момент не существует. В случае с Pegasus вредоносный код маскируется под системные файлы и не может быть идентифицирован и удален каким-либо программным обеспечением.

Избавиться от шпионского кода можно только полной перепрошивкой гаджета. Инструкция по полной переустановке iOS доступна на нашем сайте.

После загрузки чистой iOS на смартфоне не будет вредоносного кода, но никто не застрахован от повторного заражения. Тем более, что осуществить его можно удаленно без какого-либо участия с вашей стороны.

(30 голосов, общий рейтинг: 4.47 из 5)

В закладки

Или почему не всегда можно вернуть телефон в то состояние, в котором его принесли изначально.
На ремонте довольно устаревшее бюджетное яблоко 11 серии:

История его банальная — упал. Насколько сильно я сказать не могу, но в предыдущем сервисе меняли корпус в сборе. Из чёрного в красный)) Какой был)
По неисправностям — перезагружается каждые 3 минуты. Легкотня подумал я, ведь всё оборудование в телефоне (камеры, сканеры морды лица, сети, и т.д) работают исправно, а значит вероятнее всего проблема не в плате, а в подключенных шлейфах, на которых так же находятся дополнительные усилители и стабилизаторы сети. Как раз на ремонте у меня лежал простреленный из винтовки такой же телефон и я ничего лучшего не придумал, а думать то и особо не нужно, просто закинул плату в его корпус для проверки. Но увы. Всё те же перезагрузки, а логи panic kernel говорят об отсутствии неизвестного сенсора и после его опроса, если оно не найдено в системе, процессор просто принудительно перезагружает телефон и опрос оборудования начинается сначала.
Значит проблеm в цифровых линиях передачи информации между устройствами, называемые i2c и spi.
Я не так давно начал углублено изучать принципы работы и даже прикупил себе осциллограф для прослушки пакетов на этих линиях. Увлекательно и запутано, но уровень диагностики слегка повысился.
Осталось попробовать его в двухканальном режиме с синхронизацией по scl (clock линия синхронизации микросхем, сидящих на одной цифровой шине).
В дальнейших ремонтах, если они ещё будут, покажу принципы диагностики на его основе, а сейчас расскажу почему некоторые устройства могут лежать у меня в сервисе месяцами с невыясненными до конца проблемами.
На такие аппараты приходится около 2% от общего количества поступающих устройств ко мне в ремонт.
Как говорится кузов починили, а двигло так и не завелось))
Осматриваю плату:

Видно, что отрезали защитный экран.
Но это для меня не особо понятно и я предполагаю, что хотели погреть процессор без разделения рамы, что говорит небольшая желтизна на компонентах. Зачем? Хз, может для того, что бы наверняка убить плату, ибо греть микросхемы, да ещё и под компаундом, что бы устранить перезагрузки — это уровень мастерства «мастер по ремонту нокия в 2003 году», где прогрев процессор, телефон снова работает пару лет без каких либо проблем. Только в тех нокиях было всего 4 микросхемы: процессор, память, усилитель и контроллер питания)
Тут на пару микросхем побольше и процессор не единственная причина перезагрузок. Например последний айфон 11 серии может перезагружаться даже из за микрофона xD
Что бы исключить перезагрузки из за шлейфов в десятых сериях недостаточно отключить все шлейфы, так как из за отсутствия нижнего шлейфа с вибромотором телефон тоже будет тупить и перезагружаться) Поэтому важно иметь у себя в сервисе полностью рабочий корпус с навеской.
Так что время разделения платы)

Я тут такой простой решил, что отсеку нижнюю плату:

Увижу серый не до конца отбитый пятак в нижней части платы, сразу замотаю низ верхней платы

что бы не коротнуло в корпусе. Накину шлейфы и запущу плату посмотреть на закончившиеся перезагрузки

Но нет. Бюджетник снова перезагружался каждые 3 минуты.
Если Вам кажется, что я просто нафоткал фотки и решил просто так показать как я катаю микросхемы и перезагрузки я выдумал просто так, то знайте, Вы ошибаетесь. Мой пердак полыхал в то время, когда мозг думал что же это сука может быть.
Отложив телефон на два дня, я снова занялся этим перспективным ремонтом.
На этот раз обзвонив основные цифровые линии и немного поразмышляв решил так: раз телефон ударник, то что-то в отвале) Самое логичное же xD
И если телефон перезагружается с минимумом шлейфов и микросхем, то дело наверняка в верхней плате.
По моей статистике: если телефон упал и по замерам всё кажется хорошо, то нужно начинать смотреть с самых больших чипов на плате, так как они самые первые на отвал при ударе из за объёмности)
Сниму для начала чипсет хранилища фотокарточек и тикток, т.е то, что любит вводить телефон в режим бесконечного яблока при недостаточной памяти — nand.
Снимаю на нижнем подогреве и немножко дуя горячим воздухом из паяльного фена, демонтирую чип:

Смотрю на место под чипом из под микроскопа

И понимаю, что я уже 3 дня воспламеняю свой пердак напрасно.

На фото выше всё хорошо. Чип памяти не отбит, а значит перезагрузки не из за него.
Не страшно. Я еженедельно делаю увеличения памяти на любых айфонах и для меня это так же просто, как и поменять оперативку в ноутбуке. Эммм. Ту, которая не распаянная на плате. Высунул-всунул. Такую)
Ладно. Мимо.

Тут мне стоило подумать логически, что при нагреве платы контакт в большинстве случаев восстанавливается и стоило бы плату проверить на горячую, то есть при чуть большей предельной температуре работы телефона. Точнее тогда, когда айфон пишет о перегреве и не даёт ничего сделать. Но это я говорю сейчас, когда пишу эти строки и знаю конечный результат телефона, а тогда я об этом как то и не задумывался. Я топчусь на одном месте тупо катая микросхему за микросхемой, ведь причину то я выяснил точно, как мне показалось. Дело в верхней плате не иначе!
Это ошибка, я часто за собой это замечаю. Если что то не понятно, нужно отложить подумать, ведь холодные мысли умнее горячих. Но кто об этом думает в тот момент? Я например нет)
Установив чип памяти и проверив перезагружающуюся снова плату я начал демонтаж процессора:

Тут самый важный этап ремонта — не повредить плёночный «текстолит» при снятии компаунда, он же обычная чёрная резина:

А ещё важнее не убить процессор чрезмерным нагревом. Аккуратно затупленным скальпелем удаляю резинку с нежного логического чипа:

Можно разглядеть дорожки, которые в толщину примерно очень тонкие. Меньше человечьего волоса в десяток раз. Плюс-минус))

А плёнка между ними не прочнее гидрогелевой. Легко царапается. Вшатать проц на этом этапе легче лёгкого.
Да. Нужно вокруг каждого шарика орудовать скальпелем для удаления компаунда. На это у меня ушло в общем 40 минут. От глазниц микроскопа остаются лёгкие красные круги под глазами, а глаза напряжены очень сильно и приходилось каждые 20 минут на полчаса отпускать ремонт для отдыха и переключения на другие текущие ремонты.

Следом так же аккуратно нужно удалить заводской припой с помощи оплётки и паяльника:

Когда это сделано, мне потребовалось всего лишь нанести паяльную пасту через трафарет:

Но наношу я её не один раз, а как минимум три. Первый проход грубый: на нижнем подогреве, что бы не гнуло трафарет, грею феном всего лишь на 140 градусах. Нет, паста не легкосплав, а полноценные 180 градусов. Не хрупкий, не сплав Розе (ни разу его не использовал ни в одном ремонте).

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

Ровные на глаз под микроскопом шарики припоя на ЦПУ)

Ещё нужно обязательно освободить место для микросхем под процессором, поскоблив лунки для них от компаунда (резинки).

Дальше скучная запайка процессора с необходимостью достаточно точной его отцентровкой, иначе слипнувшиеся свежие шары под ним, особенно в центральной его части могут моментально убить ядро процессора при подаче напряжения (достаточно пристегнуть аккумулятор и нажать кнопку включения). Это сразу тотал. Замена платы. Но у меня это всего лишь так называемый реболл ЦПУ))

Я был рад, что перезагрузки пропали и телефон проработал дольше 3 минут. Видео на Ютубе как мешают коллу и ментос я выучил наизусть)

Воодушевлённый хорошим ремонтом я принялся удалять заводской припой с рамки и подготавливаю новый, в принципе такой же по температуре плавления, но свинецсодержащий припой:

И спаиваю платы на нижнем подогреве:

Затолкав плату в корпус телефон снова начал перезагружаться, теперь не каждые 3 минуты, а спонтанно. Может проработать минуту и уйти в бутлуп, а может работать час без каких либо проблем. Но это не ремонт, так не пойдёт.

Решил отдохнуть от телефона, ведь на него итак в общей сложности потраченно уже часов 10.

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

Я начал проверять все доступные линии i2c и spi по очереди.

Таких цифровых шин в этом яблоке около 50 плюс минус, и это я не считаю mipi интерфейс, ибо они никогда не перезагружают телефон.

И нашёл несоответствие всего лишь на одной — цифровая линия гироскопа.

Ага. Иду и отпаиваю его, а там:

Пффф. Не проблема. Восстанавливаю отбитые контакты, припаиваю микру и проверяю. Компас раб, но телефон перезагружается))

Делаю заказ верхней платы из Китая и жду полтора месяца. По приезду делаю перенос важных микросхем на спиленую под ЧПУ станком плату:

Повторил ритуалы ошаривания процессора снова:

А телефон рухнул в дфу режим)

Данные не нужны, поэтому прошиваю технику. Но она не прошилась. Кто же знал, что нужен оригинальный antirollback? Я тоже не знал и как нибудь покажу как один из сервисов убил телефон, не установив эту микросхему с оригинальной платы.

P.s: я осознал это всего лишь недавно) На этом ремонте xD

Отпиливаю защиту на новой плате и переношу эту микросхему со старой платы:

Платы я не стал запаивать, а установил в трафарет за 10 кусков:

Но при его закрытии плата переставала определяться компом. Методом исключения, вернее методом заклеивания контактов я обнаружил зону, при подключении к которой плата уходила в защиту и в этом кусочке нашёл вдвое заниженное сопротивление на линии микросхемы модема. Причем эта линия цифровая и активируется как я понял только при прошивке из режима dfu. Значит часть микросхемы работала исправно, а другая часть постоянно рапортовала об ошибке и процессор делал перезапуск для устранения проблемы и так по кругу. Но как объяснить то, что телефон до этого прошивался без проблем мне пока что не ясно. Но теперь мне известен факт того, что верх платы не прошивается без нижней части, хотя Х-ХS шьются без проблем, но сети при этом не будет.

Логи прошивки говорят о том, что модем в системе не найден:

А телефон выглядит уже так:

И вернуть в состояние частичной работоспособности не представляется возможным в этом случае.

Так как диагностика на десятки и выше у меня 2000р, то мне придётся в любом случае забрать верх платы и отдать владельцу уже невключающийся телефон. Один из тех случаев, когда микросхема связана с процессором и не меняется отдельно. Напридумают же привязок)) А нам страдай и не зарабатывай))

В данном случае целесообразна замена всей платы на рабочую, но так как был уже заменён корпус, то замена платы и дисплея абсолютно нецелесообразный ремонт. Так посчитал я и сам владелец телефона.

На этом пожалуй ремонт закончен.

За место заявленных 14к пришлось заработать 2 тысячи.

Жалко конечно, но после этого телефона мне без какого либо труда удалось сделать уже парочку 11 без сети и один с такими же перезагрузками, виновником которых был верхний микрофон, который просто не обнаруживался в системе) Как нибудь покажу его в ремонте.

Такая вот трехмесячная история.

На этом снова всё)

Вопросы можно задать, перейдя по ссылке Инстаграмма или в моем профиле на пикабу. В личку xD

P.s: мне до сих пор не понятно как это могло получится. Это же реальный бред как мне кажется и лишён всякой логики с технической стороны. Может мой косяк? Я сделал всё, что смог придумать и сопоставить.

Жаль, что поинтересоваться не у кого.

Читайте также:

Iphone xr самый продаваемый

Phphotoserrordomain ошибка 1 iphone

Что за синий знак появляется на айфоне возле время после обновления на ios 15

Как называется встроенный в ios sdk фреймворк для хранения данных persistence

Экран айфона зеленит почему

Источник

Цель статьи – рассмотреть всю методологию пентестинга приложений на реальном устройстве (под управлением iOS 5), а не на симуляторе.

Автор: satishb3

В первой статье данной серии мы обсуждали анализ трафика iPhone. Вторая статья была посвящена проблемам приватности и хранения данных в списках свойств. В третьей была проанализирована связка ключей iOS. В данной статье мы рассмотрим различные типы файлов, хранящихся/созданных в домашней директории приложения и другие небезопасные хранилища данных.

Хранилище Sqlite

Sqlite – кроссплатформенная библиотека языка C, в которой реализован самостоятельный, встраиваемый, не требующий предварительной установки движок реляционной БД. База данных Sqlite не нуждается в отдельном серверном процессе – вся база данных с множеством таблиц, триггеров и представлений сосредоточена в одном единственном файле. Sqlite позволяет выполнять все стандартные операции языка SQL, включая Select, Insert, Update, Delete. Будучи переносимой, надежной и легковесной, Sqlite является замечательным решением для долгосрочного хранения данных на iOS-устройствах.

Библиотека Sqlite, поставляющаяся с iOS, реализует легковесный и мощный движок реляционной БД, который легко встраивается в приложение и обеспечивает быстрый доступ к записям базы данных. Поскольку вся БД находится в одном плоском файле, приложения могут с легкостью создавать локальные файлы своих БД и оперировать таблицами и их содержимым. Как правило, приложения iOS хранят в БД Sqlite большие объемы данных со сложной структурой, чтобы оптимизировать скорость их обработки и использование памяти. Движок БД Sqlite, поставляемый с iOS, не имеет встроенного шифрования. Поэтому большинство приложений iOS хранят большое количество конфиденциальных данных внутри файлов Sqlite в открытом виде. Например, приложение Gmail, чтобы обеспечить оффлайновый доступ к почте, хранит все электронные письма в открытом виде внутри БД Sqlite.

Незашифрованная конфиденциальная информация, хранимая в файле Sqlite, может быть легко украдена в случае, если злоумышленник получит физический доступ к устройству или завладеет резервной копией данных. Кроме того, Sqlite при удалении записи не производит стирания данных, а лишь помечает запись соответствующим образом. Поэтому, даже если приложение хранит конфиденциальные данные в файле Sqlite временно и удаляет их после использования, эти данные можно легко восстановить на основании журнала упреждающей записи (Write Ahead Log).

Файлы Sqlite могут создаваться с произвольным, в том числе пустым, расширением. Чаще всего они имеют расширение .sqlitedb или .db. Далее мы рассмотрим, как можно просматривать эти файлы и восстанавливать удаленные данные на iPhone. Для этой цели я создал демонстрационное приложение под названием CardInfo. CardInfo – самоподписанное приложение, так что оно может быть установлено только на устройстве, подвергшемся джейлбрейку. Приложение спрашивает имя пользователя и пароль, принимая любой ответ, а затем собирает данные о кредитной карте пользователя, сохраняя их в БД Sqlite. Записи базы данных удаляются при выходе из приложения.

Шаги для установки приложения CardInfo:

Выполните Jailbreak устройства.
Загрузите файл CardInfoDemo.ipa — Ссылка.
На Windows-машине загрузите утилиту для настройки iPhone – Ссылка.
Откройте утилиту настройки и перетащите в ее окно файл CardInfoDemo.ipa.

Подключите iPhone к Windows-машине через USB-кабель. Убедитесь, что подключенное устройство появилось в списке утилиты настройки. Выберите устройство и перейдите на вкладку Applications. В открывшемся списке наряду с уже установленными приложениями должно появиться приложение CardInfo.

Щелкните по кнопке Install, соответствующей приложению CardInfo. В результате приложение будет установлено на iPhone.

Шаги для просмотра файлов Sqlite, принадлежащих приложению CardInfo:

На подвергшемся джейлбрейку iPhone установите OpenSSH и Sqlite3 из Cydia.
На windows-машине загрузите Putty.
Подключите iPhone и рабочую станцию к одной сети Wi-Fi. Замечание: Wi-Fi необходим, чтобы подключиться к iPhone по SSH. Если сеть Wi-Fi недоступна, подключитесь к iPhone по SSHчерез USB-кабель.
Запустите Putty и подключитесь к iPhone по SSH, введя IP-адрес устройства, логин root и пароль alpine.
Перейдите в папку /var/mobile/Applications/ и найдите директорию приложения CardInfo с помощью команды «find . –name CardInfo«. На моем iPhone приложение CardInfo установилось в директорию /var/mobile/Application/B02A125C-B97E-4207-911B-C136B1A08687/.

Перейдите в поддиректорию CardInfo.app найденной директории (в моем случае – в /var/mobile/Application/B02A125C-B97E-4207-911B-C136B1A08687/CardInfo.app) и найдите файл базы данных CARDDATABASE.sqlite3.

Используя команду sqlite3, откройте файл CARDDATABASE.sqlite3. Отметим, что таблица CARDINFO пуста.

Замечание: также можно скопировать файлы Sqlite с iPhone на рабочую станцию по SSH и просмотреть их с помощью утилит Sqlite data browser и Sqlite spy.

На iPhone откройте приложение CardInfo и осуществите вход (приложение принимает любую пару логин/пароль).

Введите данные кредитной карты и щелкните по кнопке Save. В результате данные кредитной карты попадут в БД Sqlite.

Откройте файл CARDDATABASE.sqlite3. Теперь таблица CARDINFO содержит данные кредитной карты.

Выйдите из приложения. В результате данные из БД приложения будут удалены.

Теперь можно снова открыть файл CARDDATABASE.sqlite3 и убедиться, что таблица CARDINFO опять пуста.

Порядок восстановления данных, удаленных из БД Sqlite программы CardInfo:

Прежде чем записать данные в файл БД, движок Sqlite сохраняет их в журнале, чтобы обеспечить возможность восстановления после системных сбоев. При каждом коммите или прохождении контрольной точки данные из журнала записываются в файл БД. Так что, если после удаления записи из БД не последовало коммита, мы можем легко восстановить удаленные данные из журнала. В iOS для вывода удаленных из БД Sqlite данных можно воспользоваться командой strings. В нашем случае команда «strings CARDDATABASE.sqlite3» выведет удаленные данные о кредитной карте.

Если приложение iOS использует БД Sqlite для хранения временных данных, всегда существует возможность восстановить его удаленные временные данные.

Для повышения безопасности хранимых в БД Sqlite конфиденциальных данных их необходимо явно шифровать. Кроме того, перед удалением записи БД нужно затирать ее содержимое случайными данными. В этом случае, даже если кто-то попытается восстановить удаленные данные из файла БД, он не сможет получить желаемый результат. Наконец, при создании файлов Sqlite следует указывать подходящий уровень доступности.

Cookies.binarycookies

Большинство приложений iOS не спрашивают учетные данные у пользователя при каждом входе. Они создают и хранят куки в файле cookies.binarycookies, расположенном в домашней директории приложения. В ходе тестирования на проникновение исследуйте данный файл на предмет наличия конфиденциальной информации и недостатков управления сессиями. Файл cookies.binarycookies имеет двоичный формат, и его содержимое нельзя прочитать напрямую. Поэтому я написал на Питоне скрипт BinaryCookieReader.py, который может отображать содержимое этого файла в читаемом виде.

Чтение файла Cookies.binarycookies:

На Windows-машине загрузите WinScp, Python и BinaryCookieReader.py.
Подключите iPhone и рабочую станцию к одной сети Wi-Fi.
Запустите WinScp и войдите в iPhone по SSH, введя IP-адрес iPhone, логин root и пароль alpine.
Перейдите в папку Library/Cookies внутри домашней директории приложения.
Скопируйте файл Cookies.binarycookies на Windows-машину, перетащив его на соответствующую панель.

На Windows-машине откройте командную строку и запустите следующую команду для просмотра содержимого файла cookies.binarycookies.

Python BinaryCookieReader.py [путь к файлу Cookies.binarycookies]

Вот как выглядят куки, созданные iOS-приложением Facebook.

Клавиатурный кэш

Для того, чтобы научиться предугадывать печатаемое пользователем слово, устройства iOS создают локальный клавиатурный кэш, используя функцию Автокоррекции. Данный клавиатурный кэш разработан для автодополнения предсказумых слов. Проблема этой функции в том, что в кэш заносится вся без исключения вводимая пользователем информация. Размер кэша составляет около 600 слов. Кэш расположен в файле Library/Keyboard/en_GB-dynamic-text.dat. Чтобы просмотреть его содержимое, скопируйте по SSH файл en_GB-dynamic-text.dat на компьютер и откройте его в HEX-редакторе. Вот как может выглядеть содержимое этого файла:

Клавиатурный кэш не хранит информацию, введенную в поля, которые были помечены как безопасные (Secure). По умолчанию такую метку имеют пароли и строки, состоящие из одних цифр (ПИН-коды и номера кредитных карт). Таким образом, данные, вводимые в эти поля, не хранятся в клавиатурном кэше. Однако в нем могут храниться данные, вводимые в поля вроде логина или ответа на секретный вопрос. В ходе тестирования на проникновение очистите текущий клавиатурный кэш, выбрав пункт меню iPhone Settings -> General -> Reset -> Reset Keyboard Dictionary (показан на картинке ниже), затем введите данные в текстовые поля и проанализируйте, попадают ли они в клавиатурный кэш или нет.

Чтобы отключить автодополнение для текстового поля в ходе разработки приложения, либо пометьте его как безопасное (пример: mytextField.secureTextEntry = YES), либо отключите автодополнение (mytextField.autocorrectionType = UITextAutocorrectionTypeNo;).

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

Хранилище снимков экрана

При нажатии на кнопку home окно приложения iPhone сжимается и приложение перемещается в фон. Для создания визуального эффекта сжатия iOS делает снимок окна приложения и сохраняет его в папке Library/Caches/Snapshots внутри домашней директории приложения. В результате конфиденциальная информация пользователя может храниться на устройстве без его ведома. Сделанные снимки автоматически удаляются после перезагрузки устройства.

Пример. В случае приложения Gmail, когда пользователь нажимает клавишу home при просмотре почты, снимок почты пользователя сохраняется на устройство без уведомления пользователя. Показанный ниже снимок сделан во время просмотра почты от Сити-банка.

При разработке приложения данную проблему можно решить двумя способами.

Стирать конфиденциальные данные или выставлять черный фон перед возвратом из функции applicationDidEnterBackground().
Вместо скрытия или удаления конфиденциальных данных можно запретить перевод приложения в фоновый режим, выставив свойство «Application does not run in background» в списке свойств приложения Info.plist.

Файловый кэш

Помимо списков свойств, файлов Sqlite, двоичных куки и снимков экрана, приложения iOS могут хранить файлы других форматов вроде pdf, xls, txt и т. д. при просмотре некоторой информации. Например, при просмотре пользователем вложений письма приложение Yandex.Mail сохраняет вложения на устройство до тех пор, пока пользователь не выйдет из приложения. Приложения, которые хранят на устройстве временные файлы, должны очищать их при выходе/закрытии. На данном снимке экрана показана директория attachment приложения Yandex.Mail.

Журналы ошибок

Приложения iOS обычно заносят данные в журнал в целях диагностики проблем или отладки. Кроме того, разработчики нередко используют для отладки функцию NSLog. Данные журналы могут включать в себя запросы, ответы, куки, маркеры аутентификации и другие конфиденциальные данные. Данные, передающиеся в функцию NSLog, записываются в системный журнал Apple (ASL), в котором они сохраняются до перезагрузки. Также журналы ошибок не ограничены песочницей приложения, то есть, записи журнала, сгенерированные одним приложением, могут быть прочтены другим. Поэтому, если приложение заносит в журнал конфиденциальные данные, вредоносное приложение может подхватывать эти данные и отправлять их на удаленный сервер.

Журналы ошибок iPhone можно просматривать напрямую с помощью приложения Console. Данное приложение доступно для скачивания в AppStore. Журналы ошибок также легко просмотреть через утилиту настройки iPhone или в папке CrashReporter при синхронизации устройства через iTunes.

Вернемся к демонстрационному приложению CardInfo. Как уже было сказано, это самоподписанное приложение, поэтому его можно установить только на устройство, подвергшееся джейлбрейку. Приложение принимает любой логин/пароль, а затем запрашивает у пользователя данные о кредитной карте и записывает полученную информацию в журнал.

Действия, необходимые для просмотра журнала ошибок:

Установите приложение CardInfo на iPhone.
На Windows-машине установите и откройте утилиту конфигурации iPhone.
Подключите iPhone к Windows-машине через USB-кабель. Убедитесь, что подключенное устройство перечислено в списке утилиты конфигурации. Выберите его и перейдите на вкладку Console.
На iPhone откройте приложение CardInfo и войдите с любым логином и паролем.
Введите данные кредитной карты и нажмите на кнопку Save. При этом данные занесутся в журнал ошибок.

Теперь данные карты, занесенные в журнал приложением CardInfo, можно увидеть на вкладке Console утилиты конфигурации.

В целях повышения безопасности не заносите в журнал конфиденциальные данные. Также удаляйте отладочные журналы перед публикацией приложения.

Это четвертая часть серии статей о пентестинге приложений iPhone. В пятой части будет рассмотрен анализ приложений iOS во время выполнения.

Ссылки:

Debunking NSLog Misconceptions

http://blog.gdssecurity.com/labs/2012/3/28/debunking-nslog-misconceptions.html
What’s in your iOS Image Cache ?

http://software-security.sans.org/blog/2011/01/14/whats-in-your-ios-image-cache-backgrounding-snapshot
Hacking and Securing iOS Applications by Jonathan Zdziarski

Источник

Привет! Сегодня стартует наш четвертый митап для тестировщиков, QAчественное общение. До 18:00 МСК на него все еще можно зарегистрироваться. А пока мы начинаем выкладывать доклады с предыдущего митапа, и начинаем с Ольги, старшего QA-инженера в компании red_mad_robot. Поговорим про мобильные устройства и про снятие логов с этих мобильных устройств, почитаем их и разберем, как вообще с ними работать.

Что вообще такое логи мобильного устройства? Логи – это записи либо сообщения в виде текста. У нас в этом тексте записываются все действия пользователя или как отвечает система на действия пользователя, соответственно, вся та информация, что вы делаете, куда нажимаете на самом устройстве, в приложении – всё это пишется в логи.

Какие логи в принципе бывают? Разделим их на две группы. Первая – это Crash logs, они подразумевают под собой отдельный файл, куда сыпется только информация об экстренном завершении программы. И второй вариант – это просто логи, файл, который является журналом событий, в нём хранятся все системные записи и ответы устройства на действия пользователя.

Уровни логирования

Хочу заметить, что эти уровни логирования больше под Android-логи, потому что именно разделение на Error, Warn, Info, Debug и Verbose в основном вы можете увидеть именно на логах с Android. Плюс, такая же информация чаще всего будет в ваших серверных логах, в принципе, будет довольно полезно изучить их. Что примечательно, каждый уровень включает в себя предыдущий. Если мы возьмем Verbose, фильтрацию по нему, например, то мы будем получать логи со всех предыдущих уровней, то есть абсолютно все логи. Разберем каждый подробно.

Первый – это Error. Ошибки уровня Error – ошибки, которые говорят о работе системы, на них надо очень быстро реагировать и всегда сообщать о них разработчикам.

Например, SpannableStringBuilder – это ошибка приложения, которая говорит нам о том, что текстовое поле, то есть Span, наш элемент, он не может быть нулевым либо пустым. Второй вариант – это системная ошибка ZeroHung. Данная ошибка говорит о том, что у нас происходит утечка памяти, она может быть как от какого-то действия с приложением, так и от самого приложения.

Следующий вариант – Warning. Это тоже ошибки, которые говорят о каком-то неожиданном поведении, которые требуют внимания, но они не такие важные, как error. Например, ошибка из приложения: мы пытаемся декодировать видео в нужное нам качество, в нужный формат, и у нас на этом происходит ошибка. Второй вариант, например, BroadcastQueue. Это ошибка системная, ошибка работы какого-то виджета на вашем устройстве. У меня это был Android Huawei, мне от системы сыпятся такие ошибки.

Следующий уровень – Info. Это уровень логов, на котором нам приходят записи чисто информационного характера о работе системы. Например, в этот уровень будут приходить ваши запросы, которые отправляют приложения на сервер. То есть он будет выглядеть так: http start, здесь вы увидите, какие header’ы отправляются, какое тело отправляется, если оно есть, и так же будете получать ответ от сервера в таком формате: json, key, value, ключ, значение и так далее. Заканчиваться он будет как http end. Далее, системный вариант ошибки или системный вариант лога о том, что сейчас мы намереваемся выключить экран. То есть, эта запись появляется, когда мы просто блокируем экран телефона, и он гаснет. Это у нас падает в информацию.

Далее, уровень Debug. Это тот уровень сообщений, в котором передается информация о процессах отладки или шаги каких-то крупных процессов, то, на что разработчики хотели обратить пристальное внимание. Например, мы просто нажали на качель громкости. Здесь будет, конечно, более подробно внутри этого лога – если вы его поймаете, то увидите конкретно что произошло: мы увеличили звук, уменьшили звук и на какое количество. И второй вариант, например, у вас приложение работает по WebSocket, и вам надо понять, подключились вы вообще или нет. Соответственно, вот это сообщение о том, что коннект произошел (на экране «b$b: WebSocket connected»).

Следующий уровень Verbose. Это уровень самого низкого приоритета, там сыпятся вообще все логи, там будет какая-то дополнительная информация, которая не вошла в Info, например. К примеру, у нас всплывает окно, мы его закрываем, у нас WindowManager, и мы здесь видим, что-либо добавилось, либо все удалилось. Далее, вся информация о геолокации. Например, у нас есть LocationProvider. В более расширенном варианте там будет полностью писаться ваша геолокация вплоть до долготы и широты. И третий пример, тоже связанный со звуком, то есть какой у нас звук и насколько он громкий. То есть, например, volume 10 это у нас максимальный звук, и мы его увеличили до такого варианта (на экране «AudioManager: getStreamVolume streamType: 3 volume: 10»). Очень похож на Info, но, я бы сказала, что более подробная информация на него передается.

Чем снимать логи?

Android

Первый инструмент – это Android Studio, в частности, его утилита Logcat. Что надо для того, чтобы начать снимать логи через Android Studio? Первое, конечно же, необходимо перевести устройство в режим разработчика. В настройках вы ищете номер вашего билда или операционной системы, в зависимости от того, на каком устройстве вы собираетесь смотреть, оно меняется от производителей. Нажимаете около 10 раз на эту информацию, и у вас появляется сообщение «Не желаете ли вы перевести ваше устройство в режим разработчика?». Нажимаете «Ок», и ваш телефон уже не такой обычный. Далее, вам надо подключить это устройство по USB к вашему компьютеру, конечно же, установить на сам компьютер Android Studio, он устанавливается как на Windows, так и на MacOS, тут проблем никаких нет.

Открывая Android Studio, выбираем вкладку Logcat. Под цифрой 1 то, где найти это сокровенное слово. Нажимая на него, переходим в сообщения в реальном времени. Под цифрой 2 окно, где мы выбираем телефон, с которого будем снимать логи. Соответственно, если ничего не подключено либо ваш телефон не виден, здесь вы ничего не сможете выбрать. Под цифрой 3 интересный момент: если вы хотите полностью снимать все логи (системные и со всех приложений, которые у вас сыпятся), не выбирайте здесь ничего. Если вы выберете какое-то конкретное приложение, которое debug’ное, у вас будут показываться логи исключительно по нему. Рядом с цифрой 3 вы видите слово Verbose – это уровень того лога, который вы хотите видеть. То есть, если вы выберете Error, будут только Error’ы. И под цифрой 4 у вас поле поиска. Это то поле, где вы сможете фильтровать выдачу по приложению, по уровню, по какой-то утилите, которая вам нужна, соответственно, это у нас regular выражение, и там все довольно просто ищется по совпадению. Вариант второго скриншота – это я уже выбрала конкретную сборку, и мы видим, что у нас по этой сборке сыпятся логи.

Перейдем к следующему варианту. Это через терминал снимать через тот же самый Logcat. Нам нужно, чтобы устройство стояло в режиме разработчика, подключаем это устройство по USB к компьютеру, на компьютер надо установить Android Debug Bridge. Открываем терминал и пишем две команды: первая – «adb devices», которая показывает, какие устройства подключены и какие adb видит устройства, второй командой мы говорим: «Запусти утилиту Logcat у конкретного устройства». То есть, при первой команде вы увидите, как ваше устройство называется, во второй команде вы его просто дополняете. Как это выглядит: вот мой терминал, я вижу то, что мое устройство называется 7BKDU… , оно подключено по USB, и мой Mac его видит. Я ввожу команду adb – s «название устройства» Logcat.

Дальше у вас в терминале, примерно так же, как и в Android Studio, будут в режиме реального времени сыпаться логи. Разберем, как их читать. Под цифрой 1 будет дата и время, когда пришла запись. Под цифрой 2 – маленький столбец, где вы видите буквы V, D, E, I и так далее. Это как раз те самые уровни нашего логирования Debug, Verbose, Warning или Info. В графе 3 – названия – инструменты, утилиты или части ОС, откуда идет сообщение, и, соответственно, его расшифровка – что конкретно у нас происходит. Конечно, выглядит это так, что в Android’е это все намного удобнее и приятнее, легко можно фильтровать. В Terminal’е фильтровать будет уже посложнее, надо будет менять саму команду, добавлять ключи, которые бы фильтровали выдачу по уровню либо по отдельному приложению.

Третий вариант, которым вы можете воспользоваться для снятия логов, это SDK Platform Tools. Для этого нам надо перевести устройство в режим разработчика и подключить его к компьютеру по USB, скачать на компьютер папку SDK Platform Tools, она есть под разные операционные системы. Далее открываем папку в терминале, именно чтобы была открыта папка SDK Platform Tools. Затем пишем команду «adb logcat – d – v time > .log.txt», что говорит о том, что конкретно и в каком варианте мы хотим видеть в этих логах (то есть время, приоритеты, тэги различные) и говорим, что мы хотим сохранять эти логи в log.txt. Вот мы написали команды и начинаем выполнять действия на нашем устройстве, то есть, нажимать на различные компоненты либо воспроизводить баг, который вам мешает, и вы хотите снять с него логи. Далее прерываете выполнение этой команды (на Mac это ctrl+C), и в нашу папку добавляется этот лог (android – debug.log).

Открываем его, как мы видим, информация похожа на ту, что в Terminal, единственное, как вы прекратили команду, этот файл больше не обновляется до тех пор, пока вы снова не повторите эту команду. Опять же, в таблице 1 мы видим дату и время прихода сообщения, таблица 2 – уровень наших логов, в таблице 3 мы видим, от какой части системы у нас сыпятся данные, лог и его расшифровка.

iOS

Конечно же, первое, о чем я хотела бы рассказать, это xCode и встроенный для него симулятор. К сожалению, xCode – программа только для MacOS. Чтобы снять с симулятора логи, нужно установить xCode, зайти в меню, открыть Developer Tools и симулятор. Симулятор – дополнительная программа, которая позволяет воспроизводить работу системы, если у вас нет физического девайса.

В этот симулятор мы устанавливаем нужное нам приложение, выбираем, какой конкретно IPhone, его размеры, разрешение и операционную систему. И уже в симуляторе выбираем пункт «Debug» и «Open System Log». Это выглядит так: я выбираю в самом симуляторе папку Debug и подвкладку Open System Log. Он точно так же идет в режиме реального времени, но они (логи) выведены по-другому, не так, как на Android.

Мы видим, что тут уже нет уровня логирования, есть дата и время. Цифра 2 – сообщение, что мы вообще видим. Мы видим, с какого устройства была снята информация.

В моем случае это имя моего Mac. Видим дополнительную запись, с какого элемента системы это сообщение пришло и его расшифровка. Например, в логах IOS придётся поковыряться чуть поподробнее, чем в Android.

Второй инструмент тоже связан с xCode, но он идет по другой «дорожке». Это Devices and Simulator. Устанавливаем xCode, подключаем устройство по USB, тут уже важно, чтобы было реальное устройство. В самом xCode открываем вкладку Window, там выбираем подвкладку Devices and Simulator. Нажимаем у устройства «Open Console». На панели видим название нашего устройства, какая у него операционная система, модель, и правее этой кнопки нам интересно «Open Console».

Под цифрой 1 мы видим все приложения, которые дополнительно установлены на наши устройства, в колонке под цифрой 2 – версия этого устройства, которую разработчик указывает. Третье пишется URL нашего устройства. То есть, например, у вашего разработчика, у вашей компании, у вашего приложения есть свой URL, по которому он ходит. Соответственно, здесь он отражен.

Как это все выглядит: здесь довольно удобно отслеживать, как сыпятся логи. Они тоже сыпятся в реальном времени, и, если их никак не фильтровать, они будут постоянно падать, но здесь все удобно смотреть. У нас есть время этого сообщения, процесс – это с какой части системы, приложения пришло сообщение. В колонке «Сообщение» мы видим подробное описание того, что происходит, что не так, вся сервисная системная информация. Что интересно, именно в Devices and Simulator есть поиск, который позволяет фильтровать выдачу. То есть, справа сверху мы можем написать название нашего приложения, и у нас все отфильтруется по процессу. Также мы можем приостановить выдачу по кнопке, и тогда логи перестануть хаотично и беспорядочно сыпаться (чтобы удобнее искать то, что вы хотите найти на устройстве).

Как снимать логи с IOS на Windows

Есть приложение iMazing, которое ставится на Windows и MacOS. Подключаете устройство по USB и в меню выбираете «показать консоль устройства». В целом, это приложение платное, однако, снять логи с устройства можно на триальной версии, она никак не ограничивается. У нас открывается следующее окно: мы видим, какое устройство у нас подключено, мы видим аккаунт, и в меню мы видим как раз «показать консоль устройства».

Если мы на нее нажмем, увидим следующее. Первый квадрат – это дата и время, когда мы получили это сообщение, второй пункт – от кого, с какого устройства, так как это уже реальный девайс, он называется у нас «IP-040». Далее, пишется, с какой части системы прилетело сообщение и его описание. Под цифрой 3 мы видим поле поиска. Мы можем фильтровать эту выдачу, можем остановить поток входящих логов по кнопке «пауза» и отфильтровать ее в поле поиска. Это поможет вам сконцентрироваться на конкретном запущенном приложении. Также у iMazing можно эти логи сохранять по соответствующей кнопке.

Источник

If any iOS app crashes some crash logs are generated on behalf of that app.
How to find the location of such crash logs. Please help.

I want crash logs inside the iPhone/iPad, not really using XCode to see the crash logs.

asked Jun 25, 2014 at 4:51

user249605user249605

2292 gold badges3 silver badges8 bronze badges

you can find crash report on iPad/iphone below location for iOS:

IOS7 & Below = Settings —> General —> About —> Diagnostics & Usage —> Diagnotstic & Usage Data

IOS8 & IOS9 = Settings —> Privacy —> Diagnostics & Usage —> Diagnotstic & Usage Data

IOS10 & Above = Settings —> Privacy —> Analytics —> Analytics Data

answered Apr 8, 2015 at 9:52

JashuJashu

1,04113 silver badges19 bronze badges

I think he/she asked about crash logs inside the iPhone/iPad, not really using XCode to see the crash logs.

To check the crash logs inside iPhone/iPad, you have to go to

Settings -> General -> About -> Diagnostics & Usage -> Diagnostic & Usage Data

You will see the crash log with the Title APPName_Date….

Attached the screen shot of one of the crash logs below:-

answered Jun 25, 2014 at 5:16

RickyRicky

10.5k6 gold badges36 silver badges49 bronze badges

👉 https://support.apple.com/en-in/HT202100

IOS 7 & Below = Settings —> General —> About —> Diagnostics & Usage —> Diagnotstic & Usage Data

IOS 8 & Above = Settings —> Privacy —> Diagnostics & Usage —> Diagnotstic & Usage Data

IOS 10.2 = Settings —> Privacy —>Analytics —> Diagnotstic & Usage Data

IOS 10.3.2 and Above = Settings —> Privacy —> Analytics —> Analytics Data

answered May 2, 2017 at 5:06

MAhipal SinghMAhipal Singh

4,7451 gold badge42 silver badges56 bronze badges

From Apple Docs:

Even though you won’t be able to run the app in Xcode’s debugger, Xcode can still give you all the information you need to debug the problem.

1) Plug in the device and open Xcode

2) Open the Organizer window and select the Devices tab

3) Under the DEVICES section in the left column, expand the listing for the device

4) Select Device Logs to see crash logs or select Console to see Console output

answered Jun 25, 2014 at 4:55

Источник

Уровни логирования и что они означают

Error (ERROR)

Warning (WARN)

Info (INFO)

Debug (DEBUG)

Verbose (VERBOSE)

Инструменты для снятия логов: Android

Инструменты снятия логов: iOS

Доступ к журналам сбоев iOS на Mac

Получение отчетов о сбоях iPhone и iPad на ПК с Windows

iPhone/iPad/panic log/расшифровка/аналитика

58 участника(ов) поблагодарили PRO-mobile за его сообщение:

[iOS] Просмотр системных логов

Демистификация аварийных журналов iOS

Что это за аварийный журнал и где его взять?

(1) Информация о процессе

(2) Основная информация

(3) Исключение

(4) Трассировка потоков

(5) Состояние потока

(6) Дамп памяти

Демистификация с помощью символизации

Сбои, вызванные нехваткой памяти

Коды исключений

В омут головой!

Сценарий 1. Плохой код на завтрак

Сценарий 2. Где эта кнопка?

Сценарий 3. Закладкой больше, закладкой меньше.

Сценарий 4. Леденец

Что дальше?

ОС iOS 10 и более поздней версии

ОС iOS 8 и iOS 9

ОС iOS 5, iOS 6 и iOS 7

ОС iOS 4 и более ранней версии

Если показанное выше окно не отображается

Могут ли айфоны заражаться вирусами?

Как вредоносное ПО влияет на iPhone?

Как проверить iPhone на вирусы или вредоносное ПО?

Проверьте наличие незнакомых приложений

Проверьте, был ли произведен джейлбрейк на вашем устройстве

Проверьте счета за телефон

Проверьте свободное место в хранилище (Storage Space)

Как избавиться от вируса на вашем iPhone

Перезагрузите iPhone

Удалите необычные приложения

Очистите историю

Воспользуйтесь ПО для обеспечения безопасности

Замените свой iPhone

Действуйте быстро, если подозреваете, что ваш iPhone заражен вредоносным ПО

Как работает Pegasus и подобное ПО

Можно ли обнаружить вредоносное ПО на iPhone

Как узнать, заражен ли ваш iPhone

Что делать в случае заражения iPhone

Хранилище Sqlite

Cookies.binarycookies

Клавиатурный кэш

Хранилище снимков экрана

Файловый кэш

Журналы ошибок

Ссылки:

Уровни логирования

Чем снимать логи?

Android

iOS

Как снимать логи с IOS на Windows