Постепенно пришел к такому: в качестве документации открываю в отдельном VSCode корень IDA SDK вместе с его примерами, нахожу объявление нужной функции, читаю там комментарии, затем делаю поиск использований и смотрю «а как оно на самом деле» (и удивляюсь).
Плюс в какой-то момент сказал себе «доколе?!» и выделил время на дизассемблирование самой IDA и процессорного модуля ARM — многое стало понятнее, ну и «грязные хаки» стали возможны — вызвать внутреннюю функцию, отсчитав её смещение от экспортированной, «похитить» таблицу виртуальных методов внутреннего объекта и установить hook туда, куда API не позволяет итд, что ещё усиливает привязку к конкретной версии. Вот такой печальный SDK.
Так я и предлагаю обнаружить и пропустить некорректные случаи (изменение SCL во время DV импульса). Довольно частые в практике ситуации: в захват попали переходные процессы при инициализации пинов, либо начали захват посреди пакета, декодеры подхватывают этот мусор и «плывут».
Доходчиво, спасибо! Как-то попытался на скорую руку и усталую голову переделать под свои нужды готовый декодер (как и советуют), быстро утонул в кортежах с непонятными цифрами и ушел обрабатывать экспортированный бинарник «дедовским способом» на голом Python.
Маленькое уточнение: что если между передним и задним фронтами SDO DV окажется фронт SCL (например мы начали захват посреди отправки данных)? В ожидание заднего фронта DV напрашивается дополнительное условие SCL: ‘e’ по ИЛИ и возврат в начальное состояние.
А мне их с противоположной стороны видеть приходится (от консультирующихся подопечных ремонтников), и оттуда всё выглядит немного по другому. Например, чудный разъём зарядки, в котором 58 вольт зачем-то соседствуют с межмодульной шиной данных (которую зарядка и не использует вообще), выжигая её при попадании туда сырости — как-то далековато от качества обсуждаемого Segway PT.
Загуглите для примера «whatsapp exploit nso group» (история как раз конца прошлого года тоже) — никаких телодвижений со стороны пользователя, одна «сорвавшаяся» попытка входящего Whatsapp-звонка, и в вашем телефоне уже исполняется чужой код (который и эту самую попытку звонка подчистить может). Кто гарантирует что в куда более сложном коде браузера уже вычистили абсолютно все подобные баги?
Да, явно сама идея гироскутера вытесняется ответвившимися от неё более специализированными потомками — моноколесом и электросамокатом. У нынешнего Segway-Ninebot есть и дешёвые (и ломкие, всё «как надо рынку») гироскутеры (серия Mini), но их уже тоже нечасто видно.
Достаточно сравнить количества сообщений по типам устройств в оглавлении какого-нибудь форума вроде electro.club
Там «процессор» и «gsm-часть» в одном чипе (фактически это просто разные ядра многоядерной системы), у них общая DDR память, в которой на личные нужды модема выделена изолированная от Linux область, а общаются они напрямую через общие буферы (ну и сигналы между ядрами). Собственно всё так же, как в большинстве Андроид-смартфонов.
Знакомый ирландец на подряде у General Electric занимался пусконаладкой газовых турбин, в качестве примера языковых различий приводил случай с течью паропровода и ошпаренными людьми, охарактеризованный американским коллегой как «good but not perfect».
«Совсем» дистанционно (как RFID) само собой ничего не читается. Но смартфон в целом предполагает выход в онлайн, а там уже ничто не мешает. Видимые из ОС серийные номера сейчас даже у вибромотора есть.
Как бы вот только под этот шум не взялись за старое — блокировать вообще любые замены запчастей в неавторизованных мастерских.
Не было ли у быстро научившихся людей опыта с чем-то другим, требующим баланса? Готовые общие рефлексы на уходящие из-под туловища ноги наверняка разгрузили бы мозг от большой части новых задач. Вспомнилось как удивился, когда после водно-досочных спортов (учась на которые падал несчётное число раз, но не больно, в воду) легко освоился на роликах, на которые когда-то безуспешно убил время, не освоив ничего, кроме езды по плоскому асфальту с торможением «прыжком на газон».
К вопросу о сложности компиляторов для VLIW: ок, нужно подбирать порядок инструкций для максимального заполнения «пакетов». Но разве это не схоже с задачами, решаемыми out-of-order архитектурами в железе? Однако у компилятора по идее для этого куда больше ресурсов — больше информации о коде, мягче требования к скорости. В чём загвоздка?
Посчитал (руками в дизассемблере) среднее заполнение пакета в случайно выбранной функции из примерно 500 инструкций (функция — управляющий алгоритм общего плана, никакой DSP специфики) для VLIW-ядра QDSP6 (оно довольно распространённое кстати, по нескольку в каждом SoC/модеме от Qualcomm), получил 62.5% (2.5 из 4). Интересно, как это соотносится с эффективностью переупорядочения инструкций тем же x86?
Простите, что такое TrustZone? Что такое CryptoCell? В чём суть «концепции ARM TrustZone CryptoCell» (эта фраза примерно сравнима с «концепция Microsoft Windows HDMI»)
Есть стойкие подозрения, что в NAND всё будет печальнее — там доступ к конкретному транзистору-биту идёт через принудительно открытые все остальные транзисторы той же NAND-цепочки, возникает взаимное влияние. Про read/write disturb слышали? — даже чтение может утянуть соседние по цепочке биты в другие состояния. Адищще.
Довольно красиво попытались подойти к решению данной проблемы в Android: данные шифруются ключами, в вычислениях которых среди прочего хешируется сгенерированный при создании ключа массив случайных данных secdiscardable размерами порядка десятков КБ. При удалении ключа (например при сбросе телефона к начальным установкам) первым делом затирается этот массив, а для успешного восстановления ключа (без которого данные — «тыква») необходимо 100% качество его восстановления. Однако что произойдёт в ячейках flash конкретной модели телефона в ответ на желание ОС сделать этому массиву secure trim, большой вопрос — слишком много уровней абстракции между ними. У Apple же с их вертикальной интеграцией были все возможности сделать «как надо» (ну или «как не надо», кто их знает).
В watchdog на ESP/WiFi/MicroPython смущают как раз все эти создающие «комфорт написания сложного кода» вещи. Как бы ему самому при такой сложности тоже watchdog не потребовался (про надёжность нажатия кнопки сервой вообще молчу). Речь была как раз о максимально примитивном «в пару строчек на асме» — считаем такты от фронта до фронта, если слишком долго — даём сброс.
Включающиеся самостоятельно при возобновлении питания Андроиды существуют — Blackberry например, но там это достигается не настройкой ОС, оно живёт глубже. Хотя и на не-Blackberry есть например вот такая возможность: основной режим зарядки (который с красивой индикацией, в противоположность режиму глубокого разряда, где от силы светодиод мигает) реализуется средствами ОС, для него просто отдельная ветвь в init.xx.rc скриптах (без запуска launcher и пр.). При наличии рута можно попробовать поправить скрипты и заставить ОС стартовать в полный режим.
Выше отвечал о watchdog, не увидел. Туда же и включение при возобновлении встроится без проблем — при холодном старте самого watchdog выдаём импульс на вход кнопки питания и задерживаем переход к «сторожевым» функциям на время, гарантирующее старт телефона.
Если не смущает идея пайки в телефоне, можно придумать что-то вроде такого: сигнал «всё в норме» берём с выхода на вибромотор, в приложении на смартфоне добавляем короткую вибрацию в ответ на ping с сервера. Внешняя схема watchdog наблюдает за своевременностью сигнала и делает выкл-вкл в случае таймаута. Сам watchdog на каком-нибудь простом и надёжном 8-битном микроконтроллере сделать (чтобы без ОС и прочих излишеств, минимальный хорошо проработанный код). Было бы классно вообще на жёсткой логике, но для такого сигнал вибро не очень удобен — будет трудновато отловить зависание с вечной вибрацией.
Ещё один способ «подать голос» из телефона наружу — в некоторых моделях (навскидку из головы — Alcatel 1S, Huawei P Smart, но их явно больше таких) на плате есть тестовые точки RxD/TxD отладочного UARTа. При наличии рута можно в ответ на ping писать определённую последовательность в соответствующее устройство /dev/ttyXX и следить за этим снаружи (опять же мелким MCU).
Вот такая мелочь в первые же минуты знакомства с Гидрой всплыла: как ни старался, не смог найти аналог struct offset delta (когда знаем что в регистре содержится указатель не на начало структуры и при создании смещений от него на поля структуры указываем на сколько он сдвинут).
Постепенно пришел к такому: в качестве документации открываю в отдельном VSCode корень IDA SDK вместе с его примерами, нахожу объявление нужной функции, читаю там комментарии, затем делаю поиск использований и смотрю «а как оно на самом деле» (и удивляюсь).
Плюс в какой-то момент сказал себе «доколе?!» и выделил время на дизассемблирование самой IDA и процессорного модуля ARM — многое стало понятнее, ну и «грязные хаки» стали возможны — вызвать внутреннюю функцию, отсчитав её смещение от экспортированной, «похитить» таблицу виртуальных методов внутреннего объекта и установить hook туда, куда API не позволяет итд, что ещё усиливает привязку к конкретной версии. Вот такой печальный SDK.
Вот на английском более подробно: https://www.vice.com/en_us/article/3aza95/how-police-took-over-encrochat-hacked
И там несколько запутанно, но создаётся впечатление что централизованно затроянивались сами телефоны абонентов сети.
Так я и предлагаю обнаружить и пропустить некорректные случаи (изменение SCL во время DV импульса). Довольно частые в практике ситуации: в захват попали переходные процессы при инициализации пинов, либо начали захват посреди пакета, декодеры подхватывают этот мусор и «плывут».
Доходчиво, спасибо! Как-то попытался на скорую руку и усталую голову переделать под свои нужды готовый декодер (как и советуют), быстро утонул в кортежах с непонятными цифрами и ушел обрабатывать экспортированный бинарник «дедовским способом» на голом Python.
Маленькое уточнение: что если между передним и задним фронтами SDO DV окажется фронт SCL (например мы начали захват посреди отправки данных)? В ожидание заднего фронта DV напрашивается дополнительное условие SCL: ‘e’ по ИЛИ и возврат в начальное состояние.
Загуглите для примера «whatsapp exploit nso group» (история как раз конца прошлого года тоже) — никаких телодвижений со стороны пользователя, одна «сорвавшаяся» попытка входящего Whatsapp-звонка, и в вашем телефоне уже исполняется чужой код (который и эту самую попытку звонка подчистить может). Кто гарантирует что в куда более сложном коде браузера уже вычистили абсолютно все подобные баги?
Да, явно сама идея гироскутера вытесняется ответвившимися от неё более специализированными потомками — моноколесом и электросамокатом. У нынешнего Segway-Ninebot есть и дешёвые (и ломкие, всё «как надо рынку») гироскутеры (серия Mini), но их уже тоже нечасто видно.
Достаточно сравнить количества сообщений по типам устройств в оглавлении какого-нибудь форума вроде electro.club
Там «процессор» и «gsm-часть» в одном чипе (фактически это просто разные ядра многоядерной системы), у них общая DDR память, в которой на личные нужды модема выделена изолированная от Linux область, а общаются они напрямую через общие буферы (ну и сигналы между ядрами). Собственно всё так же, как в большинстве Андроид-смартфонов.
А зачем собирать ядро, rootfs (а тем более appsboot), если конечная цель — сборка user mode приложения? Вы же их никак не использовали в итоге.
«Совсем» дистанционно (как RFID) само собой ничего не читается. Но смартфон в целом предполагает выход в онлайн, а там уже ничто не мешает. Видимые из ОС серийные номера сейчас даже у вибромотора есть.
Как бы вот только под этот шум не взялись за старое — блокировать вообще любые замены запчастей в неавторизованных мастерских.
Не было ли у быстро научившихся людей опыта с чем-то другим, требующим баланса? Готовые общие рефлексы на уходящие из-под туловища ноги наверняка разгрузили бы мозг от большой части новых задач. Вспомнилось как удивился, когда после водно-досочных спортов (учась на которые падал несчётное число раз, но не больно, в воду) легко освоился на роликах, на которые когда-то безуспешно убил время, не освоив ничего, кроме езды по плоскому асфальту с торможением «прыжком на газон».
Посчитал (руками в дизассемблере) среднее заполнение пакета в случайно выбранной функции из примерно 500 инструкций (функция — управляющий алгоритм общего плана, никакой DSP специфики) для VLIW-ядра QDSP6 (оно довольно распространённое кстати, по нескольку в каждом SoC/модеме от Qualcomm), получил 62.5% (2.5 из 4). Интересно, как это соотносится с эффективностью переупорядочения инструкций тем же x86?
Простите, что такое TrustZone? Что такое CryptoCell? В чём суть «концепции ARM TrustZone CryptoCell» (эта фраза примерно сравнима с «концепция Microsoft Windows HDMI»)
Довольно красиво попытались подойти к решению данной проблемы в Android: данные шифруются ключами, в вычислениях которых среди прочего хешируется сгенерированный при создании ключа массив случайных данных secdiscardable размерами порядка десятков КБ. При удалении ключа (например при сбросе телефона к начальным установкам) первым делом затирается этот массив, а для успешного восстановления ключа (без которого данные — «тыква») необходимо 100% качество его восстановления. Однако что произойдёт в ячейках flash конкретной модели телефона в ответ на желание ОС сделать этому массиву secure trim, большой вопрос — слишком много уровней абстракции между ними. У Apple же с их вертикальной интеграцией были все возможности сделать «как надо» (ну или «как не надо», кто их знает).
Включающиеся самостоятельно при возобновлении питания Андроиды существуют — Blackberry например, но там это достигается не настройкой ОС, оно живёт глубже. Хотя и на не-Blackberry есть например вот такая возможность: основной режим зарядки (который с красивой индикацией, в противоположность режиму глубокого разряда, где от силы светодиод мигает) реализуется средствами ОС, для него просто отдельная ветвь в init.xx.rc скриптах (без запуска launcher и пр.). При наличии рута можно попробовать поправить скрипты и заставить ОС стартовать в полный режим.
Выше отвечал о watchdog, не увидел. Туда же и включение при возобновлении встроится без проблем — при холодном старте самого watchdog выдаём импульс на вход кнопки питания и задерживаем переход к «сторожевым» функциям на время, гарантирующее старт телефона.
Если не смущает идея пайки в телефоне, можно придумать что-то вроде такого: сигнал «всё в норме» берём с выхода на вибромотор, в приложении на смартфоне добавляем короткую вибрацию в ответ на ping с сервера. Внешняя схема watchdog наблюдает за своевременностью сигнала и делает выкл-вкл в случае таймаута. Сам watchdog на каком-нибудь простом и надёжном 8-битном микроконтроллере сделать (чтобы без ОС и прочих излишеств, минимальный хорошо проработанный код). Было бы классно вообще на жёсткой логике, но для такого сигнал вибро не очень удобен — будет трудновато отловить зависание с вечной вибрацией.
Ещё один способ «подать голос» из телефона наружу — в некоторых моделях (навскидку из головы — Alcatel 1S, Huawei P Smart, но их явно больше таких) на плате есть тестовые точки RxD/TxD отладочного UARTа. При наличии рута можно в ответ на ping писать определённую последовательность в соответствующее устройство /dev/ttyXX и следить за этим снаружи (опять же мелким MCU).
Вот такая мелочь в первые же минуты знакомства с Гидрой всплыла: как ни старался, не смог найти аналог struct offset delta (когда знаем что в регистре содержится указатель не на начало структуры и при создании смещений от него на поля структуры указываем на сколько он сдвинут).