In fastboot we trust. Part 3

Сборка прошивки для LG G3s(jag3gds):

• Скачиваем исходники основной прошивки:
  $ repo init -u https://github.com/LineageOS/android.git -b cm-14.1
• Обновляем исходники:
  $ repo sync -j 4
• Обновляем переменные окружения:
  $ . build/envsetup.sh
• Подготавливаем специфичные для устройства каталоги:
  $ breakfast jag3gds
• Дописываем project name="TheMuppets/proprietary_vendor_lge" path="vendor/lge" remote="github" в .repo/local_manifests/roomservice.xml для добавления блобов
• Запускаем сборку:
  $ brunch jag3gds

In fastboot we trust. Part 2

Некоторые устройства содержат нестандартные протоколы загрузки или неполные реализации стандартных протоколов. В случае LG G3s(jag3gds) мы имеем 4 способа загрузки:

• стандартный загрузочный сектор(boot), загружается при обычном нажатии кнопки Power;
• загрузчик для стандартной системы обновления прошивки(laf), поддерживает только стандартный протокол LG для установки прошивок, для входа нужно выключить телефон подождать с десяток секунд, нажать Volume UP и подключить usb или adb reboot bootloader;
• если стереть laf то aboot не найдя laf входит в режим fastboot, реализовано только часть протокола - можно только отформатировать разделы или перегрузить телефон(поддержки команды boot нет);
• раздел с recovery - загрузиться можно только с основного раздела через adb reboot recovery.

Решением могло бы быть реализация fastboot или использование uboot. Но можно использовать наработки efidroid минимальный lk образ содержит поддержку fastboot. Для сборки можно использовать такую последовательность команд:

• $ source build/envsetup.sh
• $ lunch
• # select Device name == lge/jag3gds and build type == debug
• $ make -j6 lk
• $ adb push out/device/lge/jag3gds/lk.img /sdcard/Download/lk.img
• $ adb root
• $ adb shell
• # dd if=/sdcard/Download/lk.img of=/dev/block/platform/msm_sdcc.1/by-name/laf
• # exit
• $ adb reboot bootloader # boot to laf

Если хочется использовать полный образ нужно заменить lk на uefi.

В текущей реализации в uefi образе содержится ошибка и нужно применить такое исправление в uefiapi/target/msm8226.c заменить:

pdata = cb(pdata, MSM_IOMAP_BASE, (MSM_IOMAP_END - MSM_IOMAP_BASE), LKAPI_MMAP_RANGEFLAG_RESERVED, 

на:

pdata = cb(pdata, MSM_IOMAP_BASE, 1*MB, LKAPI_MMAP_RANGEFLAG_RESERVED,.

Сборка NSX wagon

Для offline установки на инфраструктуру без доступа к внешнему миру, нужно создать пакет содержащий все зависимости, cloudify использует wagon как формат пакетов установки. Для создания подобного пакета на основе CentOS можно использовать такую последовательность команд:

• sudo yum install epel-release
• sudo yum install python-pip python-setuptools python-pip python-wheel python-setuptools python-virtualenv
• mkdir wagon
• virtualenv wagon
• cd wagon
• . bin/activate
• pip install --upgrade pip
• pip install wagon
• wagon create -t tar.gz https://github.com/cloudify-cosmo/cloudify-nsx-plugin/archive/1.0-build.zip

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

In fastboot we trust. Part 1

Или обновление ядра android на официальное ядро с kernel.org

Все современные ядра для android, хоть и до сих пор базируются на 3.4, но все же перешли на device tree, поэтому напрямую использовать их на старых устройствах(до 2011 года) скорее всего не получиться, так как они рассчитаны на загрузку используя atags, поддержку которого благополучно сломали в процессе обновления, есть ещё и вторая потенциальная проблема, на мобильных телефонах размер подобных atags может быть очень большой, для примера там может быть прошивка для Wi-Fi и калибровка для камеры и получается размер под 64 килобайта. Если немного пройтись по тому как оно работает получается такое поведение: в идеале на новых загрузчиках ядру передается как один из параметров ссылка на devicetree, который представляет собой упакованное дерево с описанием устройств и их настроек доступных на аппаратном уровне, каждый узел подобного дерева содержит список совместимости, где перечислен список типов устройство потенциально совместимых с доступными на аппаратном уровне, для примера может быть указано что мы имеем какой-то телефон или платформу и указано что также у нас система базирующаяся на каком-то чипе, если ядро не в курсе нашей платформы оно может попытаться задействовать код поддержки от чипа, этого должно быть достаточно для поддержки 99 процентов устройств, так как все устройства внутри soc обычно совпадают для того же процессора, а отличие только в описании и настройке линий ввода/вывода. Данная технология изначально была придумана для power и используется широко на данный момент в официальном ядре для реализации поддержку различных платформ одним ядром одновременно, как следствие можно загрузиться на одном ядре Qualcomm msm и Samsung Exynos устройство сообщив ему путь к device tree.

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

Новый загрузчик под android понимает образы которые содержат 3 секции: само ядро, device tree, initrd. Старые загрузчики игнорируют DT секцию и для того чтобы можно было загрузиться ядру с поддержкой DT, придуманы такие обходные маневры: в конец образа ядра записывается DT и в ядре выбирается опция, что нужно искать DT после образа ядра и опция конвертации atags в DT во время загрузки, в результате ядро загрузить DT и прочитав atags перепишет используя эти значения DT.

Инвентаризация blockchain

Базируется на открытых источниках и субъективном

мнении - может не совпадать с реальностью.

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

• существует несколько клиентов (отделов/офисов) и каждый из таких клиентов может с нужной ему периодичностью создавать записи в своей локальной базе;
• к каждой записи добавляется hash/электронная подпись/или какая-то работа которая позволяет убедиться что не возможно генерировать такие записи чаще чем с какой-то периодичностью и каждая следующая запись зависит от предыдущей что не позволит вставить новую запись в середину списка записей;
• с определенной периодичностью эти записи синхронизируются в рамках организации, и ветки записей с каждого клиента и подписывается общей подписью/hash. Далее эта подпись распространяется среди филиалов, а также распространяется в открытых источниках, как комментарии в bitcoin или публикуются на публичных сайтах. Так как публикуется только слепок подписи/hash открытия конфиденциальных данных не происходит.

Возможные недостатки данной технологии:

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