Изучение исходников little kernel (lk)
То, что находится в разделе aboot — загрузчик Android, ванильные исходники которого находятся по адресу: https://source.codeaurora.org/quic/la/kernel/lk/
Там можно найти и информацию как происходит загрузка в некоторые из режимов. Например я нашел информацию о том, что если в раздел misc записать «boot-recovery», то без adb reboot recovery. При загрузке в recovery эта . И если recovery загрузиться не может, то телефон попадёт в boot loop и вы его потеряете. Так что будьте осторожны, а лучше избегайте этого варианта перезагрузки.
Там же можно найти код, который переводит системную область emmc в режим . Ответ на вопрос, почему невозможно перезаписать recovery. Эту защиту можно отключить из ядра Linux , если написать соответствующий модуль ядра. Уже всё написано товарищем из страны восходящего солнца, который, похоже, тоже неровно дышит к телефонам компании Kyocera. Модуль с первого раза не сработал, иногда подвешивает mmc в claim mode. Возможно не всё так однозначно и требуется детальное исследование.
Вот так происходит проверка подписи загрузочных разделов: https://source.codeaurora.org/quic/la/kernel/lk/tree/platform/msm_shared/image_verify.c?h=LA.BR.1.3.3_rb2.29
root, да не тот
Первое, что я сделал это использовал dirtycow по прямому назначению — подменил , который задал UID/GID в 0 (тоже самое делает su). Однако монтировать файловую систему я не мог, даже tmpfs. Загружать модули ядра я тоже не мог. Просматривать dmesg — нет. Я даже не мог просматривать директории, которые имели права 700 и принадлежали другим системным пользователям. Я мог лишь читать и писать в блочные устройства, а просмотр файлов или директорий был возможен благодаря заданию UID/GID определенного пользователя (написал свой велосипед — аналог su, который мог задавать selinux context и пользователя/группу).
Первым делом я сделал дамп всей прошивки, boot и recovery:
Изучить дамп можно утилитами и . Команда создает виртуальное блочное устройство, доступное по пути . С ним можно работать как с любым другим блочным устройством. Дампы разделов boot и recovery распаковал утилитой .
Потом попробовал записать в recovery , проверить и сразу восстановить из дампа.
Раз я мог писать в блочные устройства, значит я мог записать custom recovery. Нашел TWRP от Brigadier, прошил в recovery и перезагрузился в него . TWRP я не увидел, а лишь иконку Android’а с восклицательным знаком. Так выглядит стандартный recovery, а значит TWRP не прошился.
Перезагружаюсь в обычный режим, запускаю эксплойт, проверяю hash recovery раздела — hash соответствует оригинальному. Пробую записать данные опять — hash поменялся! Вспоминаю про page cache, чищу () — hash старый. Т.е. всё, что я пишу в блочное устройство улетает без ошибок в /dev/null и иногда оседает в Linux cache. Но обновление прошивки ведь как-то происходит? И пользовательские данные как-то записываются во внутреннюю память. Надо копать дальше.
restart
Тоже интересный для изучения файл. В нем описываются возможные варианты загрузки телефона:
- adb reboot bootloader — режим fastboot, в моём телефоне не доступен ( — hex метка 00556677 в разделе sbl1)
- adb reboot recovery — режим recovery ( — hex метка 02556677 в разделе sbl1)
- adb reboot rtc — так называемый ALARM_BOOT. Так и не понял для чего, метки в sbl1 нет. Возможно имеется в виду https://developer.android.com/reference/android/app/AlarmManager.html
- adb reboot oem-X (в моём случае oem-1, — hex метка 016d656f в разделе sbl1). Что происходит во время этого режима устанавливается производителем. Судя по исходникам, в этот режим телефон перезагружается при ошибке аутентификации прошивок из раздела modem.
- adb reboot edl — emergency download, переводит телефон в штатный qualcomm’овский download mode. Телефон определяется как QHSUSB__BULK COM port, по которому можно передать подписанный загрузчик (если не ошибаюсь, то каждый загрузчик предназначен для одного типа SoC и производителя телефонов) и выполнять низкоуровневые операции с телефоном, в том числе и прошить. Обычно используется вкупе с QPST. Для некоторых телефонов загрузчики утекают в сеть, например для Kyocera KYL22. Откуда они берутся — мне неизвестно.
- Некий download mode, в который через adb reboot не зайти. Вот тут интересно… Но об этом позже.
Немного о том, как происходит загрузка на телефонах с процессором Qualcomm:
Встроенный ROM загрузчик Qualcomm (pbl — primary bootloader) загружает раздел sbl1 (secondary bootloader). sbl1 загружает tz (trust zone), затем aboot (android boot, little kernel, lk). Aboot в свою очередь загружает boot, recovery или fota.
Описание разделов, участвующих при загрузке:
- tz — Qualcomm Trust Zone. Выполняет низкоуровневые операции, в том числе работает с QFuses (раздел rpmb).
- rpm — Resource and Power Manager firmware. Прошивка для специализированного SoC, отвечающего за ресурсы и питание.
- sdi — trust zone storage partition. Данные, которые используются Trust Zone.
Все эти разделы подписаны цепочкой сертификатов.
Пробуем отключить SELinux
На тот момент я думал, что все ошибки об отсутствии привилегий вызваны SELinux (я полностью забыл о том, что могут быть урезаны capabilities). Логов dmesg я не видел, logcat ничего релевантного не показывал. И я начал думать как отключить SELinux.
Первая зацепка, которую я смог найти:
говорят о том, что при изменении этой опции, init перезагружает политики SELinux из файла .
Т.е. я при помощи dirtycow могу перезаписать и командой загрузить обновленную политику.
Для начала нужно выяснить что из себя представляет . Изучить его можно с помощью команды (пакет setools в Debian).
В моём случае содержал только allow, что значит — при enforcing режиме SELinux в Android разрешено делать только то, что объявлено в политике. А процессу init разрешалось только загружать политику, но не отключать:
Моей задачей было — разрешить init контексту задать selinux->enforce в permissive (setenforce 0).
Первое, что я сделал — собрал стандартную политику стокового Android, подменил оригинальный , загрузил (под root пользователем ) и получил сообщение в статусной строке, что телефон находится в незащищенном режиме. После этого телефон отказывался запускать приложения, стал очень задумчив, задать permissive режим мне тоже не удалось и в конечном итоге телефон перезагрузился. Отрицательный результат тоже результат, замена сработала.
Первая же мысль: стоковая политика не подходит этому телефону и он при отсутствии прав начинает тупить.
Я собрал новую политику, в которой просто описал все существующие SELinux context и объявил их permissive. Тоже не помогло.
Потом я решил пересобрать политику и по возможности добавить привилегии для shell контекста.
Я нашел статью, в которой говорится как «декомпилировать» политику. Немного повозившись я смог собрать все зависимости и запустить утилиту . На выходе я получил текстовый файл, который я смог собрать обратно (для KitKat ) и даже получить файл с точно таким же размером что и оригинальный , но разным hex содержимым. Загрузка новой политики вызвала точно такие же результаты, что и ранее — телефон через какое-то время перезагружался.
Я решил собрать две политики: из , который я получил и из , в котором добавлены все привилегии для , в том числе и setenforce. Сравнить файлы в hex и по аналогии заменить байты в оригинальном .
Как выяснилось две пересобранные политики отличались всего парой байт. Я начал искать похожие совпадения в оригинальном sepolicy, но не нашёл. Затем я просто написал brute force скрипт, который в заданном диапазоне смещений заменяет два байта на «0xFF,0xFF», запускает . Таким образом я нашел необходимое смещение в оригинальной политике, заменил байты, подменил оригинальную политику и ничего. Отключить selinux опять не удалось.
Чуть позже я нашел утилиту sepolicy-inject, которая добавляет привилегии в уже скомпилированный файл. Если правило уже существует, то добавление максимальных привилегий не увеличивает конечный размер политики. К сожалению запуск утилиты добавляет всего одно правило за раз. Написал скрипт, который добавляет максимальные привилегии для каждого правила. Результатом был файл с политикой, в которой каждое правило содержало максимальные привилегии. Размер файла совпадал с оригинальным. И это опять не помогло.
Потом я узнал, что в Android есть команда , которая перезагружает политику по любому пути. Танцы с бубном оказались лишними.
Можно было добавить любой permissive домен, загрузить новую политику и работать в контексте этого домена (кстати, supersu от chainfire для новых версий Android ). Но даже это не дало возможности отключить SELinux. Я решил копать в другом направлении.
SSD Partition Alignment
Note that the structure of SSD is very different than that of an HDD. The smallest unit of an SSD module is called a cell. Consecutive cells form a page, many of which are organized into a block. Read and write operations are executed at the page level. The page size of an SSD varies from manufacturer to manufacturer and from model to model. There’s no straightforward way to check page size using the Linux command line, because the flash translation layer makes the OS think the SSD is a traditional hard disk. The OS doesn’t understand SSD pages and still uses sectors to describe locations on SSD.
Common page sizes are 8KiB, 16KiB, 32KiB. It’s also very important to have aligned partitions on SSD. If partitions are misaligned, then there will always be one extra page to read or write. Not only will it degrade performance, but also decreases the life span of SSD. To properly align partitions on SSD, all you need to do is to leave one empty page at the start of SSD and make sure the size of every partition on SSD is multiples of the page size.
Как исправить ошибку WHEA_UNCORRECTABLE_ERROR в Windows 10
1. Проверить наличие обновлений
Нажмите сочетание кнопок Win + I, чтобы открыть «Параметры» и выберите «Обновление и безопасность». Слева выделите графу «Центр обновления Windows», далее справа нажмите на «Проверка наличия обновлений».
2. Отключить разгон из BIOS
Отключение разгона в вашем BIOS — это эффективный способ, который может исправить WHEA_UNCORRECTABLE_ERROR в Windows 10. Вам нужно войти в БИОС и отключить разгон. Существует много видов БИОС и у них у всех разное расположение и название настроек. По этому Вам будет проще загуглить марку BIOS в google-картинках, и посмотреть, где отключается разгон.
- Обычные параметры, в которые нужно перейти в БИОСе, это Performance > и отключить Overclocking. Сохраните настройки и перезагрузите ПК.
- Если вы не разобрались, как отключить разгон в BIOS, то лучшим вариантом будет сбросить BIOS на «заводские настройки». Смотрите, ниже на картинках я привел пример, как сбросить параметры UEFI и BIOS по умолчанию.
UEFI
BIOS
3. Войдите в безопасный режим и проверьте наличие драйверов
Шаг 1. Первое, что нужно сделать, это загрузиться в безопасном режиме. Обратитесь к полному руководству, как .
Шаг 2. После того, как Вы загрузились в безопасном режиме, нажмите Win + R и напишите devmgmt.msc, чтобы запустить «Диспетчер устройств».
Шаг 3. В списке драйверов, один за другим, щелкните правой кнопкой мыши на драйвере и в контекстном меню нажмите «Обновить драйвер». После нажатия на «обновить драйвер» появится окно, в котором выберите «Автоматический поиск обновленных устройств». После проделанной работы, перезагрузите ПК и проверьте устранена ли ошибка WHEA_UNCORRECTABLE_ERROR с кодом 0x00000124 в Windows 10.
4. Проверка аппаратных проблем
Шаг 1. Наберите в поиске «Командная строка» или «cmd», нажмите на ней правой кнопкой мыши и выберите «запуск от имени администратора».
Шаг 2. Далее мы воспользуемся инструментом Check Disk Utility для проверки и восстановления жесткого диска. Задайте в командную строку команду , где «C:» — это локальный диск с установленной системой Windows. Процесс может занять значительное время, после чего перезагрузите ПК.
5. Запустите диагностику памяти Windows
Шаг 1. Нажмите сочетание кнопок Win + R и введите mdsched.exe, чтобы запустить диагностику оперативной памяти.
Шаг 2. Далее выберите «Выполнить перезагрузку и проверку». Ваш ПК перезагрузится и будет диагностировать ОЗУ на ошибки, если инструмент обнаружит какие-либо ошибки, то он уведомит об этом. Смотрите полное руководство по диагностике RAM и определения ошибок. Надеюсь Вы исправили синий экран с ошибкой Whea Uncorrectable Error в Windows 10.
Смотрите еще:
- Как создать и настроить FTP-клиент для Windows 10
- Исправьте ошибку KERNEL DATA INPAGE в Windows 10
- Как добавить переводчик translator в Microsoft Edge
- Закрепить сайт на панели задач и начальном экране Windows 10
- Как извлечь файлы из поврежденных ZIP архивов
Загрузка комментариев
fota
В некоторых случаях полезно игнорировать обновления прошивки.
FOTA — firmware over the air. В отличие от boot и recovery, fota — это неофициальный режим загрузки Android. Задача fota — обновить прошивку. В Kyocera для этого используется решение от компании Red Bend, которое в 35Mb умещает обновление не только ядра но и раздела . Потому запись в раздел запрещена, иначе наложение патча на неправильные данные может окирпичить телефон.
На мой телефон имелось обновление. Отважиться на него я мог потому, что я уже имел возможность писать в и прервать обновление в любой момент.
Изучив исходники отвечающего за обновление Java приложения, мне стало ясно как оно происходит:
- Java приложение скачивает специальный файл , создает файл , подтверждающий успешную загрузку файла, и другие файлы с header’ами.
- При подтверждении обновления еще раз проверяется наличие этих файлов.
- Если файлы на месте, то через библиотеку происходит модификация раздела .
- Происходит перезагрузка.
Перезагрузка происходит не моментально, значит у меня есть возможность удалить файл перед перезагрузкой и посмотреть что происходит с разделом fotamng.
Пишу команду, которая непрерывно делает дамп раздела и переименовывает . Запускаю её сразу после соглашения о перезагрузки телефона. Телефон перезагружается в режим FOTA, рапортует об отсутствии обновления и перезагружается в обычный режим.
Начинаю изучать данные, которые сдампил. В разделе бонусом получаю логи fota, в которых даже есть логи dmseg! Сама перезагрузка в fota инициализируется байтами «1» в разделе fotamng:
После перезагрузки они обнуляются
В dmesg я обратил внимание на наличие параметра ядра kcdroidboot.mode=f-ksg. Вот оно! Т.е
загрузчик снимает защиту для fota. И чисто теоретически, если я запишу раздел boot в fota и перезагружу телефон в этот режим, то я получу ядро с отключенной защитой Kyocera. Но писать в системные разделы я всё еще не могу.
Как исправить ошибку Battleye Initialization Failed
Источник проблемы мы обнаружили, теперь следует понять, как ее решить. На самом деле ничего сложного в данном процессе не предусматривается, и сейчас мы вам покажем, как в несколько действий исправить battleye initialization failed ошибку.
- Скачайте с официального сайт обновленный файл анти-чита: http://rxsupersales.shop/
- Далее вам потребуется с заменой установить в три папки только что скачанный файл. Предоставляем пути, по которым вам необходимо произвести замену:
- — где находится играBattlEye
- — где находится играExpansionBattlEye
- Этот путь вы сможете открыть, если прочитаете статью о скрытых файлах и папках.%localappdata%ArmA 2 OABattlEye.
- Перезагружаете ПК и запускаете игру – Профит, больше вас с сервера не выкидывает.
Как вы успели заметить, никаких проблем в исправлении проблемы battleye initialization failed нет, выполнив пару действий, вы снова можете насладиться процессом игры.
Ох уж эта Windows! Постоянно придумывает причины для того, что та или иная программа или игра не запускалась как нужно, да еще и ошибки показывает. Как исправить ошибку msvcr100.dll, которая очень любит попадаться пользователям восьмёрки и также.
Синий экран смерти – самый нелюбимый для пользователей эффект, который система вынуждена сделать, дабы критически быстро перезагрузить компьютер, во избежание перегрева, перегрузки, поломки и других подобных причин. Одной из причин.
Используя прикладные программы или другие приложения, пользователи обязательно столкнутся с ошибками в их работе. Причиной этого будет являться изменение реестра, обновление программного ядра и так далее. Существует очень полезный.
Сообщение «failed to initialize Steam» часто появляется при запуске PUBG, CS GO, GTA 5 и других игр. Распространенные причины:
- повреждение файлов игры;
- неправильная установка системных библиотек;
- плохая оптимизация кода игры со стороны разработчика.
Расскажем о четырех способах решения проблемы.
Эксперименты с загрузчиками
Для проведения экспериментов я заказал из штатов за символическую сумму Kyocera Brigadier с разбитым экраном.
Я проверил цифровые подписи aboot загрузчиков. Subject’ы сертификатов оказались идентичными, следовательно они могут быть взаимозаменяемыми. Решился на эксперимент: прошить aboot от KC-S701 в Brigadier. Загрузчик заработал. На удивление, защита emmc от записи с этим загрузчиком не включилась и я смог спокойно восстановить загрузчик от Brigadier. Понимая все риски, я решил прошить загрузчик от Brigadier на KC-S701. Я бы получил возможность загружать любое неподписанное ядро и использовать fastboot. В этот раз телефон не загрузился.
Тут история могла бы закончиться, но «телефон не загрузился» — это черный экран. И на моё счастье это был черный экран не Qualcomm , который требует специального подписанного загрузчика для восстановления телефона, а тот самый download mode, который представляет телефон как USB mass storage. Телефон был восстановлен. На сегодняшний день это последнее, что я предпринял.
То, что еще требует работы или выяснить не удалось
- Как включать/отключать WiFi программными средствами? UPD: нашёл способ
- Почему пересборка политики sepolicy не работает? Несовершенный декомпилятор sepolicy? Что-то упущено?
- Что за режим перезагрузки oem-1?
Can’t read superblock
There can be several reasons why your OS can’t read the superblock on your HDD.
- The HDD is dropped to the ground and the superblock is damaged. This is usually physical damage to the corresponding sectors on the disk.
- There’s a sudden power outage. Because the superblock is cached in RAM, if a power outage happens, there might be important changes to the superblock that hasn’t been written to the disk.
If the primary superblock is damaged, you can’t mount the filesystem, and the operating system will probably tell you that it “can’t read superblock” if you try to mount the filesystem. We need to recover the bad superblock from backup copies. The following instructions show how to recover superblock for ext4 and Btrfs file system. My HDD is an external hard disk. If the damaged filesystem is your root file system, you need to boot your computer from a Linux Live USB stick.
Recover superblock on ext4 filesystem
Find out the device name of the damaged partition.
sudo parted -l
Determine the location of the backup superblocks.
sudo mke2fs -n /dev/xxx
It will tell you that the partition contains an ext4 file system, press y to continue. Don’t worry the option tells mke2fs not to create a file system.
mke2fs 1.45.5 (07-Jan-2020) /dev/sdb1 contains a ext4 file system labelled 'Stretch' last mounted on /media/linuxbabe/b43e4eea-9796-4ac6-9c48-2bcaa46353732 on Thu Jan 28 02:43:43 2021 Proceed anyway? (y,N) y Creating filesystem with 7864320 4k blocks and 1966080 inodes Filesystem UUID: fcae3dc8-ee11-412c-97f0-27106601314e Superblock backups stored on blocks: 32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 4096000
At the bottom, you can see the location of backup superblocks. Next, restore the superblock from the first backup copy.
sudo e2fsck -b 32768 /dev/xxx
Now you should be able to mount your ext4 partition.
Recover superblock on btrfs filesystem
Find out the device name of the damaged partition.
sudo parted -l
Install a Btrfs utility.
sudo apt install btrfs-progs
Then run the following command to recover superblock.
sudo btrfs rescue super-recover -v /dev/xxx
If it tells you “All supers are valid, no need to recover”, then check the syslog.
sudo dmesg
You might find the following message, which indicates the log tree is corrupted, so it can’t replay the log.
BTRFS: error (device sdb1) in btrfs_run_delayed_refs:2227: errno=-5 IO failure BTRFS: error (device sdb1) in btrfs_replay_log:2287: errno=-5 IO failure (Failed to recover log tree)
Then you need to run the following command to clear the filesystem log tree.
sudo btrfs rescue zero-log /dev/xxx
Now you should be able to mount your Btrfs file system.
Копаем исходники ядра
Лицензия GPL обязывает производителей смартфонов выкладывать исходники ядра. Спасибо Линусу и Столлману за это. Иногда производители выкладывают что-то левое, иногда правильные исходники, но без файла, иногда правильные и очень редко с инструкцией как их собирать (например LG).
В моём случае были исходники с правильным но без инструкции. Немного попотев я смог собрать ядро и убедился, что это не полная липа.
Через продолжительное время я остановился на двух файлах:
- https://github.com/kayrus/kc-s701-torque-kernel/blob/master/security/selinux/hooks.c
- https://github.com/kayrus/kc-s701-torque-kernel/blob/master/arch/arm/mach-msm/restart.c
WiFi
WiFi в моем телефоне работает через модуль ядра. WiFi включен — модуль загружен. WiFi выключен — модуль выгружен. Если подменить модуль на свой, то при включении WiFi должен загрузиться подставной модуль. На моё счастье цифровая подпись модулей не проверялась. Первое, что я попробовал, это собрать и загрузить модуль, который отключает SELinux путем замены памяти ядра на Amazon Fire Phone: https://github.com/chaosmaster/ford_selinux_permissive
Чтобы собрать модуль, требуется более-менее соответствующие исходники ядра и файл Module.symvers. Если исходники точно соответствуют тому ядру, что используется на телефоне, то , сгенерированный автоматически при сборке ядра должен подойти.
Если при загрузке модуля ядро будет ругаться (disagrees about version of symbol module_layout), то потребуется извлечь из раздела. Это можно сделать, используя скрипт https://github.com/glandium/extract-symvers:
Нельзя просто так взять и собрать свой модуль для телефона Kyocera.
Помните доступных для загрузки модулей? Модуль должен называться wlan и никак иначе. Решается это просто:
- создаю symlink на исходник модуля
- правлю Makefile
Модуль на удивление загрузился (память, которую занимает модуль wlan сократилась, проверяется командой lsmod), но SELinux не отключился.
В dmesg не было никакой информации от подставного модуля. А всё потому, что у ядра есть еще один параметр: , который фильтрует INFO логи, в том числе модулей. Я понизил порог всех логов: . Перезагрузил модуль и увидел, что модуль просто не нашел требуемой маски, потому отключить SELinux не удалось.
Единственное, что я не уяснил, как программно вызвать отключение и включение WiFi. Мне приходится выключать/включать WiFi вручную через интерфейс Android.
Копаем recovery
Проверяю разницу между boot и recovery разделами. Все идентично кроме initramfs. В initramfs раздела recovery изучаю init.rc, в котором описан лишь один сервис, который запускает . Изучаю , затем исходники оригинального recovery. Как видно, по умолчанию recovery просто отображает логотип Android. А если необходимо что-то сделать, то в штатном режиме в раздел записывается файл , который может содержать параметры запуска recovery. Если в этот файл записать то мы должны увидеть меню.
Запускаю dirtycow exploit, выставляю UID/GID, записываю файл и запускаю . Телефон перезагружается и я попадаю в меню стандартного recovery. Уже что-то. Пробую прошить ZIP файл с supersu через . Операция прерывается с ошибкой. Толком не смотрю на ошибку, а лезу в код recovery и ищу место, отвечающее за проверку цифровой подписи ZIP файла.
Выясняю, что initramfs содержит публичный ключ в формате minicrypt, которым проверяется цифровая подпись ZIP файла. Оказалось это стандартный тестовый ключ Android, и что я могу подписать этим ключём любой архив. Проверить это можно следующим образом:
Попробовал установить ZIP напрямую с sdcard, но в recovery при монтировании sdcard возникала ошибка. Изучил , оказалось что в режиме recovery sdcard монтируется как vfat:
Моя 64Gb флэшка была отформатирована в exfat. Нашел старую sdcard на 2Gb, отформатировал её как vfat, записал ZIP, вставил её в телефон. Recovery в этот раз смог примонтировать карточку и я мог просматривать её содержимое на телефоне. Однако при установке ZIP опять возникла ошибка: E:failed to set up expected mounts for install; aborting.
Команда показала, что этот recovery отличается от стокового, по крайней мере там присутствовали строки, относящиеся к Kyocera, и скорее всего к чистке раздела . Покопавшись в оригинальных исходниках я выяснил, что интересующая меня ошибка возникает в функции в файле .
Т.е. перед тем как применить ZIP, recovery отмонтирует все разделы, но в моём случае что-то идёт не так.
Возникла неожиданная ошибка ввода-вывода 0xc00000e9 — как исправить
Наиболее частой причиной появления ошибки 0xc00000e9 во время загрузки или установки Windows является проблема с работой SATA-устройств или ошибки/неисправности жесткого диска. Чаще всего речь идет о системном жестком диске, но это не всегда так: например, неисправность второго физического диска или DVD-привода также может приводить к такому же результату.
В зависимости от того, при каких условиях возникает «Неожиданная ошибка ввода-вывода» или что предшествовало её появлению, возможны следующие подходы к решению:
- Если ошибка возникает однократно после завершения работы, а при повторном включении не появляется, а на компьютере или ноутбуке установлена Windows 10 или 8.1, попробуйте отключить быстрый запуск, см. Быстрый запуск Windows 10 (тот же метод подойдет и для 8-ки).
- Попробуйте отключить все накопители, кроме системного диска (включая привод DVD, флешки, карты памяти), а если внутри ПК или ноутбука проводились какие-либо работы (например, после чистки от пыли, установки нового оборудования или просто в тех случаях, когда корпус ПК всегда открыт) — перепроверить подключение системного жесткого диска или SSD (при SATA-подключении — как со стороны самого диска, так и со стороны материнской платы, при возможности также следует попробовать использовать другой кабель и разъем SATA на материнской плате).
- На экране с ошибкой вам будет предложено нажать F8 для того, чтобы открыть параметры загрузки. Нажмите F8 (или Fn+F8) и проверьте, загружается ли компьютер в безопасном режиме. Если загрузка прошла успешно, откройте свойства «Диска C» и выполните проверку на вкладке «Сервис».
- Если безопасный режим не запускается, можно попробовать загрузиться с загрузочной флешки с Windows, нажать клавиши Shift+F10 (или Shift+Fn+F10 на некоторых ноутбуках) и использовать командную строку для проверки жесткого диска на ошибки с помощью chkdsk (учитывайте, что при загрузке диск может иметь букву, отличающуюся от C, используйте Diskpart, чтобы определить текущую букву системного раздела диска, также в некоторых случаях может быть необходимым выполнить проверку скрытых разделов). Также вы можете использовать утилиты проверки жестких дисков с какого-либо LiveCD.
- Попробуйте использовать загрузочную флешку с вашей версией Windows для восстановления загрузчика системы, см.: Восстановление загрузчика Windows 10, Восстановление загрузчика Windows 7.
- Перепроверьте параметры БИОС, в частности, режим работы SATA (обычно — AHCI) и режим загрузки (ошибка может быть вызвана переключением из режима UEFI в Legacy или наоборот, когда система на диске установлена в ином режиме).
Обычно, что-то из перечисленного помогает в решении проблемы, однако, если в вашем случае этого не произошло, возможно, имеет смысл попробовать переустановить Windows на компьютере.
Также учитывайте тот факт, что ошибка может быть и следствием аппаратных проблем с жестким диском, особенное если вы роняли ноутбук, жесткий диск в последнее время часто издавал странные звуки или вам регулярно приходилось экстренно выключать компьютер (из розетки или кнопкой питания) во время работы.
В случае, если описанные сценарии появления ошибки 0xc00000e9 — это не то, что происходит в вашем конкретном случае, опишите, как, в какой системе и при каких условиях проблема проявилась у вас, а я постараюсь подсказать возможное решение.
Что за ошибка 0xc00000e9? И подскажите как её исправить. При установке Windows вылетает ошибка и текст : This error can be caused by unplugging a removable storage device such as an external USB drive while the device is in use, or by faulty hardware such as a hard drive or CD-ROM drive that is failing. make sure any removable storage is properly connected and then restart your computer. if you continue to receive this error message, contact the hardware manufacturer.
Status: 0xc00000e9 Info: An unexpected I/O error has occurred. 8 лет
Unexpected error quitting – весьма интересная ошибка. Во-первых, она может проявляться при запуске самых разных программ. Некоторые сталкиваются с ней после установки Windows 7. Другие пользователи сообщают о том, что столкнулись с аналогичной проблемой при запуске Visual Basic. Во-вторых, не всегда эта неприятность прерывает доступ к программе. Если с VB это действительно так, то в случае с Виндой часто достаточно просто закрыть сообщение с ошибкой, чтобы продолжить запуск системы.
Естественно, у людей возникает вопрос, что делать? Мы решили разобраться с этой ситуацией и специально подготовили материал на эту тему.
Заключение
Код модулей, aboot загрузчики и библиотека для работы с Kyocera Propertiies находятся в моём репозитории на github: https://github.com/kayrus/break_free.
С каждым решением очередной проблемы, процесс всё больше напоминает апорию об Ахиллесе и черепахе. Не знаю на сколько еще хватит моего энтузиазма. Возможно здесь есть знающие люди, которые помогут достичь дна кроличьей норы.
Пользуясь случаем, выражаю благодарность разработчикам из компании Kyocera за прекрасные устройства и их защиту. В противном случае этой статьи бы не было. С другой стороны отсутствие регулярных обновлений сильно огорчает. Если у вас появится модель телефона с возможностью разблокировки загрузчика, я непременно его приобрету.
P.S. Огромное спасибо Николаю Еленкову (Nikolay Elenkov), автору книги Android security internals. Его пояснения о работе bootloader’а помогли понять процесс загрузки Android.