Эмулятор

Аппаратный эмулятор клавиатуры и мыши с интерфейсом USB

12.01.2021 20:07:52 |

Автор: admin

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

Что же из себя представляет аппаратный эмулятор клавиатуры и мыши? Обычно это небольшое устройство подключаемое к компьютеру через USB порт и которое он определяет как клавиатуру и мышь. Кроме того предусмотрен канал передачи управляющих команд (обычно через тот же USB порт) по которому устройству приходят команды нажать или отпустить кнопку клавиатуры или переместить мышь и покликать ее кнопками. Таким устройством могут быть различные микроконтроллеры имеющие в своем составе модуль связи по USB и прошитые специальной программой эмулятора клавиатуры и мыши.
Для этой цели хорошо подходит отладочная плата Blue Pill.

На ней есть все необходимое микроконтроллер STM32F103C8T6 с интерфейсом USB который выведен на разъем microUSB и вся необходимая обвязка для микроконтроллера. Нужно только прошить микроконтроллер программой эмулятора. Также для этой цели подойдет другие отладочные платы и устройства с микроконтроллером STM32F103C8T6 например отладчик ST-Link в форм-факторе флешки. Использование готовых компонентов позволяет сделать этот эмулятор почти каждому.

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

Эмуляция расширенной клавиатуры содержащей 230 кнопок.
Одновременное нажатие до 14 кнопок клавиатуры не считая кнопок модификаторов.
Эмуляция дополнительной мультимедийной клавиатуры.
Эмуляция стандартной мыши с 8 кнопками, колесиком и возможностью позиционирования курсора в пределах координат 0 32000.
Скорость работы до 500 эмуляций в секунду (2 мс. на каждую эмуляцию).

Видео работы эмулятора. На нем вначале показан код передающий команды аппаратному эмулятору, а затем код выполнен и эмулятор напечатал 200 раз слово Emulator.

Инструкцию по прошивке эмулятора, примеры, документацию, прошивку и т. д. можно найти на сайте emulator.ucoz.org

Подробнее..

Категории: Программирование , Компьютерное железо , Эмулятор , Keyboard , Mouse , Emulator , Эмулятор клавиатуры , Эмулятор мыши

Симуляторы компьютерных систем всем знакомый полноплатформенный симулятор и никому неизвестные потактовый и трассы

02.07.2020 20:17:59 |

Автор: admin

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

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

Полноплатформенный симулятор (full platform simulator), или Один в поле не воин

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

Полноплатформенный симулятор создает окружение для запуска полного софтверного стека, который включает в себя все, начиная с BIOS и загрузчика и заканчивая самой ОС и различными ее подсистемами, такими как тот же сетевой стек, драйверами, приложениями пользовательского уровня. Для этого в нем реализованы программные модели большинства устройств компьютера: процессор и память, диск, устройства ввода-вывода (клавиатура, мышь, дисплей), а также та самая сетевая карта.

Ниже приведена блок-диаграмма чипсета x58 от компании Intel. В полноплатформенном симуляторе компьютера на этом чипсете необходима реализация большинства перечисленных устройств, в том числе и тех, что находятся внутри IOH (Input/Output Hub) и ICH (Input/Output Controller Hub), не нарисованных детально на блок-диаграмме. Хотя, как показывает практика, не так уж мало устройств, которые не используются тем ПО, которое мы собираемся запускать. Модели таких устройств можно не создавать.

Чаще всего полноплатформенные симуляторы реализуются на уровне инструкций процессора (ISA, см. предыдущую статью). Это позволяет относительно быстро и недорого создать сам симулятор. Уровень ISA также хорош тем, что остается более или менее постоянным, в отличие от, например, уровня API/ABI, который меняется чаще. К тому же, реализация на уровне инструкций позволяет запускать так называемое немодифицированное бинарное ПО, то есть запускать уже скомпилированный код без каких-либо изменений, ровно в том виде как он используется на реальном железе. Другими словами, можно сделать копию (дамп) жесткого диска, указать его в качестве образа для модели в полноплатформенном симуляторе и вуаля! ОС и остальные программы загружаются в симуляторе без всяких дополнительных действий.

Производительность симуляторов

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

Здесь как раз уместно будет коснуться темы производительности симуляторов. Обычно ее измеряют в IPS (instructions per second), точнее в MIPS (millions IPS), то есть количестве инструкций процессора, выполняемых симулятором за одну секунду. В то же время скорость симуляции зависит и от производительности системы, на которой работает сама симуляция. Поэтому, возможно, правильнее говорить о замедлении (slowdown) симулятора по сравнению с оригинальной системой.

Наиболее распространенные на рынке полноплатформенные симуляторы, те же QEMU, VirtualBox или VmWare Workstation, имеют неплохую производительность. Для пользователя может быть даже не заметно, что работа идет в симуляторе. Так происходит благодаря реализованной в процессорах специальной возможности виртуализации, алгоритмам бинарной трансляции и другим интересным вещам. Это все тема для отдельной статьи, но если совсем коротко, то виртуализация это аппаратная возможность современных процессоров, позволяющая симуляторам не симулировать инструкции, а отдавать на исполнение напрямую в реальный процессор, если, конечно, архитектуры симулятора и процессора похожи. Бинарная трансляция это перевод гостевого машинного кода в хостовый и последующее исполнение на реальном процессоре. В результате симуляция лишь ненамного медленнее, раз в 5-10, а часто вообще работает с той же скоростью, что и реальная система. Хотя на это влияет очень много факторов. Например, если мы хотим симулировать систему с несколькими десятками процессоров, то скорость тут же упадет в эти несколько десятков раз. С другой стороны, симуляторы типа Simics в последних версиях поддерживают многопроцессорное хостовое железо и эффективно распараллеливают симулируемые ядра на ядра реального процессора.

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

График ниже показывает примерную зависимость скорости симуляции от детализации модели.

Потактовая симуляция

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

Простейший пример инструкция доступа в память. Если запрашиваемая ячейка памяти доступна в кэше, то время выполнения будет минимально. Если в кэше данной информации нет (промах кэша, cache miss), то это сильно увеличит время выполнения инструкции. Таким образом, для точной симуляции необходима модель кэша. Однако моделью кэша дело не ограничивается. Процессор не будет просто ждать получения данных из памяти при ее отсутствии в кэше. Вместо этого он начнет выполнять следующие инструкции, выбирая такие, которые не зависят от результата чтения из памяти. Это так называемое выполнение не по порядку (OOO, out of order execution), необходимое для минимизации времени простоя процессора. Учесть все это при расчете времени выполнения инструкций поможет моделирование соответствующих блоков процессора. Среди этих инструкций, выполняемых, пока ожидается результат чтения из памяти, может встретится операция условного перехода. Если результат выполнения условия неизвестен на данный момент, то опять-таки процессор не останавливает выполнение, а делает предположение, выполняет соответствующий переход и продолжает превентивно выполнять инструкции с места перехода. Такой блок, называемый branch predictor, также должен быть реализован в микроархитектурном симуляторе.

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

Работа всех этих блоков в реальном процессоре синхронизуется специальными тактовыми сигналами, аналогично происходит и в модели. Такой микроархитектурный симулятор называют потактовым (cycle accurate). Основное его назначение точно спрогнозировать производительность разрабатываемого процессора и/или рассчитать время выполнения определенной программы, например, какого-либо бенчмарка. Если значения будут ниже необходимых, то потребуется дорабатывать алгоритмы и блоки процессора или оптимизировать программу.

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

При этом для симуляции остального времени работы программы используется функциональный симулятор. Как такое комбинированное использование происходит в реальности? Сначала запускается функциональный симулятор, на котором загружается ОС и все необходимое для запуска исследуемой программы. Ведь нас не интересует ни сама ОС, ни начальные стадии запуска программы, ее конфигурирование и прочее. Однако и пропустить эти части и сразу перейти к выполнению программы с середины мы тоже не можем. Поэтому все эти предварительные этапы прогоняются на функциональном симуляторе. После того, как программа исполнилась до интересующего нас момента, возможно два варианта. Можно заменить модель на потактовую и продолжить выполнение. Режим симуляции, при котором используется исполняемый код (т.е. обычные скомпилированные файлы программ), называют симуляцией по исполнению (execution driven simulation). Это самый распространенный вариант симуляции. Возможен также и другой подход симуляция на основе трасс (trace driven simulation).

Симуляция на основе трасс

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

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

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

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

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

Подробнее..

Категории: Анализ и проектирование систем , Производство и разработка электроники , Блог компании auriga , Виртуализация , Auriga , Симулятор , Гипервизор , Эмулятор

Использование компьютерных симуляторов. Утром софт, вечером железо

16.11.2020 22:16:56 |

Автор: admin

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

Речь пойдет об использовании моделей не самых простых устройств, таких как, например, SoC (System on Chip) или печатных плат со множеством интегрированных устройств на борту. В разработке самих этих устройств можно выделить два этапа. Сначала разрабатывается аппаратная часть. Это процесс небыстрый может занять и год, и больше.

После того как появляется первая ревизия физического устройства и проводятся базовые проверки, устройство передается разработчикам ПО. С этого момента начинается вторая фаза разработка софта для устройства. Это могут быть прошивки (firmware), BIOS, BSP/CSP (Board and CPU Support Package) для различных операционных систем, а также драйвера.

Кстати, в разработке чипов, которые часто называют силикон (silicon), эти фазы именуются пре-силикон (pre-silicon) и пост-силикон (post-silicon) или просто силикон.

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

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

И тогда на помощь разработчикам ПО приходят симуляторы!

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

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

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

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

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

Большие компании-производители устройств могут поддерживать целую экосистему, выстроенную вокруг своих продуктов. В такую экосистему входят множество других компаний, в том числе и тех, которые производят ПО для данного оборудования. Например, это могут быть производители BIOS, так называемые IBV (Independent BIOS Vendors), наиболее известные из которых AMI, Insyde, Phoenix. Такие компании также получают модели от производителя оборудования и начинают разработку до появления физического устройства. Например, для платформ Intel используется симулятор Simics, о чем подробнее можно прочитать в статье Ecosystem Partners Shift Left with Intel for Faster Time-to-Market.

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

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

Что в итоге получается?

Если принять, что время разработки железа и софта примерно равны друг другу (см. картинку выше), то использование моделей позволяет существенно, практически в 2 раза, сократить время вывода продукта на рынок (т.н. TTM Time To Market), так как разработка железа и софта ведется параллельно, а не последовательно. Для этого часто используют термин Shift Left, пришедший из области тестирования, где он означал как можно более раннее тестирование. Этот же термин применим и к разработке ПО, которая как бы сдвигается влево по шкале времени, когда выполняется на симуляторе.

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

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

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

Подробнее..

Как обойти проверку на Рутинг устройства обхитрив библиотеку RootBeer?

25.01.2021 14:08:49 |

Автор: admin

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

Дисклеймер

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

Как до этого дошло?

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

Экран, который меня не пропускает

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

Что будем делать?

Первое, что пришло мне в голову, так это попробовать выполнить декомпиляцию и поправить кое-где код, а потом собрать все обратно. Основное сомнение по поводу такого подхода вызывало то что, у меня не нативное android-приложение, а flutter-приложение. То есть как такового основного кода приложения в виде байт-кода в .apk найти не получится. Или получится? И нужен ли мне код самого приложения?

Небольшое отступление о том, как во флаттере запускается нативный код, то есть родной код для Android или iOS платформы. Например, перед flutter-разработчиком стоит задача: не давать возможность работать с приложением на рутованном устройстве. Аналогом андроид root-устройства является jailbreak для iOS. Для проверки на рутованность или jailbreak необходимо воспользоваться нативными средствами обеих платформ. Для этого разработчик пишет плагин, который вызывает соответствующие нативные методы в зависимости от платформы на которой запущено приложение.

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

Я решил, что буду менять байт-код во втором месте. Честно говоря, сначала я работал с первым местом, то есть с плагином. Все потому, что кода там намного меньше и запутаться было сложнее. Всего лишь метод, который вызывает другой метод - это пара строк кода. Но в таком случае статья была бы еще сильнее завязана под конкретный .apk, и не было б такой абстрактности. Поэтому будем работать напрямую с кодом библиотеки.

Смотрим байт-код .apk

Итак, посмотрим на внутренности .apk. Для этого можно воспользоваться инструментом, предоставляемый Android Studio. В меню выбираем Build -> Analyze APK В окне выбора файла находим интересующий нас .apk.

Весь скомпилированный байт-код хранится в файле classes.dex. Выберем его и взглянем на его содержимое. В первую очередь нас интересуют не файлы java или androidx, а именно файлы приложения. Поэтому выбираем первый package в структуре файлов android проекта, в моем случае это папка com. Из любопытства к содержимому каждой из папок я затригерился на слово rootbeer. Погуглив в гугле оказалось, что это весьма популярная библиотека для проверки устройства на предмет рутованности.

Исследовав документацию и исходники библиотеки стало ясно о том, как пользоваться библиотекой и где располагается ключевой метод isRooted().

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

Судя по исходникам библиотеки, нужный мне файл должен находится рядом с классом RootBeerNative, и как мы видим тут таких, два a и b. Эмпирическим методом я понял, что это файл b. Правый клик по файлу b и в выпадающем меню выбираем Show Bytecode.

К сожалению, имена всех методов обфусцированы. Снова обращаясь к исходному файлу на github становится ясно, что метод isRooted() находится на строке 42. Побегав по файлу с байт-кодом мне удалось найти этот метод. Только теперь он называется a() и почему-то начинает работу с .line 43. Вот этот метод я и буду редактировать. Но не так быстро, К сожалению здесь только Read-only доступ.

Редактируем содержимое classes.dex

Для этого придется декомпилировать весь .apk при помощи популярного инструмента apktool. Работать с ним довольно просто. После его установки нам понадобятся всего 2 команды:

apktool d appname.apk, которая декомпилирует указанный .apk и apktool b directory_with_app, которая соберет .apk обратно (в указанной directory_with_app должен располагаться файл apktool.yml).

Итак, выполняю декомпиляцию при помощи команды в терминале: apktool d app.apk

После выполнения команды появляется папка с файлами приложения. Нас интересует папка smali. Smali - это язык которым описан байт-код (вот классная статья по основам smali). Именно эта папка и есть содержимое файла classes.dex. К только что выполненной команде можно добавить параметр --skip-sources или просто -s тогда вместо папки smali мы увидим тот самый файл classes.dex.

Далее, в папке smali находим интересующий и уже известный нам файл b.smali:

Открываем его любым текстовым редактором и переходим к месту, где располагается метод isRooted():

Содержимое файла b.smali

.method public a()Z    .locals 1    .line 43    invoke-virtual {p0}, Lcom/scottyab/rootbeer/b;->c()Z    move-result v0    if-nez v0, :cond_1    invoke-virtual {p0}, Lcom/scottyab/rootbeer/b;->d()Z    move-result v0    if-nez v0, :cond_1    const-string v0, "su"    invoke-virtual {p0, v0}, Lcom/scottyab/rootbeer/b;->a(Ljava/lang/String;)Z    move-result v0    if-nez v0, :cond_1    const-string v0, "busybox"    .line 44    invoke-virtual {p0, v0}, Lcom/scottyab/rootbeer/b;->a(Ljava/lang/String;)Z    move-result v0    if-nez v0, :cond_1    invoke-virtual {p0}, Lcom/scottyab/rootbeer/b;->f()Z    move-result v0    if-nez v0, :cond_1    invoke-virtual {p0}, Lcom/scottyab/rootbeer/b;->g()Z    move-result v0    if-nez v0, :cond_1    .line 45    invoke-virtual {p0}, Lcom/scottyab/rootbeer/b;->b()Z    move-result v0    if-nez v0, :cond_1    invoke-virtual {p0}, Lcom/scottyab/rootbeer/b;->h()Z    move-result v0    if-nez v0, :cond_1    invoke-virtual {p0}, Lcom/scottyab/rootbeer/b;->j()Z    move-result v0    if-nez v0, :cond_1    invoke-virtual {p0}, Lcom/scottyab/rootbeer/b;->e()Z    move-result v0    if-eqz v0, :cond_0    goto :goto_0    :cond_0    const/4 v0, 0x0    goto :goto_1    :cond_1    :goto_0    const/4 v0, 0x1    :goto_1    return v0.end method

Можем сравнить его с неповторимым оригиналом:

Очень похожи. Итак, нас интересует return, то есть самый конец метод. Видим, что метод возвращает некоторое значение константы v0, значение которой определяется на основе выполнивших в методе условий. Нам это не подходит. Нам всегда нужно возвращать false или же как это будет в smali 0x0. Для этого добавим свою констант v1 со значением 0x0. Сделаем это прямо над return:

:goto_1const/4 v1, 0x0return v1

И конечно же заменим в return v0 на v1. Поднимемся в самое начало метода и изменим значение .locals с 1 на 2 потому, что так надо. Сохраняем изменения в файле и закрываем редактор.

Собираем .apk обратно

Для этого воспользуемся командой apktool b app, где app - папка с приложением, в котором мы редактировали smali файл. После завершения команды, в папке app появиться директория dist. Здесь и расположен наш заново собранный .apk. Однако при попытке установить его мы получим следующую ошибку:

The APK failed to install.Error: INSTALLPARSEFAILEDNOCERTIFICATES: Failed collecting certificates for /data/app/vmdl164530405.tmp/base.apk: Failed to collect certificates from /data/app/vmdl164530405.tmp/base.apk: Attempt to get length of null array

Это из-за того, что после пересборки нужно еще и переподписать приложение. Для этого нам понадобиться любой keystore файл. Или можно создать новый при помощи команды:

keytool -genkey -v -keystore my-release-key.keystore -alias alias_name -keyalg RSA -keysize 2048 -validity 10000

Подписать ключом приложение можно при помощи одного из двух инструментов: apksigner или jarsigner.

Я выбрал jarsigner используя следующую команду:

jarsigner -verbose -sigalg SHA1withRSA -digestalg SHA1 -keystore keystore app.apk cp_key

В этой команде мы указываем путь к keystore, путь к .apk, который хотим подписать и имя ключа (alias) из указанного keystore. После, вводим пароль от keystore и приложение успешно подписано.

Однако и это еще не все, теперь при попытке установить .apk мы будем получать другую ошибку:

The APK failed to install.Error: INSTALL_FAILED_INVALID_APK: Failed to extract native libraries, res=-2

Это потому, что после подписи приложения нужно выполнить оптимизацию .apk файла при помощи инструмента zipalign.

Для выполнения оптимизации нужно ввести следующую команду: ~/Library/Android/sdk/build-tools/30.0.3/zipalign -v -f -p 4 app.apk rdy.apk

30.0.3 - я выбрал самую последнюю версию на момент написания статьи. После завершения команды на выходе получаем файл rdy.apk, который можно успешно установить! Проверим, получилось ли обойти проверку на рутованность устройства:

И да, это успех!

Заключение

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

Подробнее..

Категории: Разработка мобильных приложений , Разработка под android , Тестирование мобильных приложений , Тестирование , Командная строка , Мобильные приложения , Android , Реверс-инжиниринг , Мобильная разработка , Flutter , Терминал , Эмулятор , Android studio

Швейцарский нож инженера дата-центра Zalman ZM-VE500

23.09.2020 18:06:49 |

Автор: admin

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

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

Что оставалось за кадром

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

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

До массового появления серверов с UEFI проблема загрузки стояла особенно остро. Далеко не все серверы оснащались оптическим дисководом, а самым идеальным вариантом для Legacy-загрузки всегда был запуск с CD или DVD-диска. Очевидным способом было каждый раз подключать внешний привод и записывать диск. Но он имел один существенный недостаток: это долго и не всегда успешно. А если образ превышал по размеру стандартную DVD-болванку, то задача и вовсе становилась нетривиальной.

Разумеется, можно каждый раз записывать образ на флешку и загружаться с нее. Но этот метод имел несколько серьезных недостатков. Главным недостатком было то, что для разных дистрибутивов требовались разные утилиты для записи. Какого-либо универсального способа просто не существует. Так, например, для записи дистрибутива с Windows Server лучше всего использовать Rufus в режиме записи ISO, а для Ubuntu подойдет и обычный Win32 Disk Imager. Когда имеешь дело с зоопарком серверного и десктопного железа, нет никакой гарантии, что метод с записью на флешку сработает именно так, как задумано.

Эмуляция привода

Что если нам заставить жесткий диск представляться как CD/DVD-привод, а ISO-образы монтировать как диски? Примерно так и подумали инженеры Zalman, после чего на свет появилась линейка устройств ZM-VE*, имеющих возможность эмулировать оптический привод.

^{Слева ZM-VE500, справа ZM-VE300}
Использовать эти устройства очень просто, везде одна и та же логика работы:

Ставим внутрь любой отформатированный в NTFS жесткий диск или SSD.
Переключаем устройство в режим HDD.
В корне создаем папку _ISO.
Закидываем образы в созданную папку.
Переключаем устройство в режим VCD.
Подключаемся к нужному компьютеру или серверу.
Выбираем образ и монтируем его с помощью кнопки Mount.
...
Профит!

^{Zalman ZM-VE500 с установленным 2.5 HDD}
Большинство ноутбуков, компьютеров и серверов опознают Zalman в качестве оптического привода, подключенного по USB, и корректно загружаются с этого устройства.

Особенности использования

Как говорилось в известном анекдоте, Но! Есть один нюанс.... А именно некоторые моменты, которые важно знать перед покупкой и использованием этого девайса. Первый потребление тока. Не все USB-порты обладают возможностью запитать устройство корректно, особенно на некоторых старых серверах. В этом случае поможет отдельно запитанный от розетки USB-хаб. Это, пожалуй, самое большое неудобство, замеченное при постоянной экcплуатации в условиях дата-центра.

Второй момент время инициализации и сброс USB-питания. Некоторые серверные платформы в процессе запуска иногда сбрасывают питание USB, что полностью гасит Zalman и заставляет его повторно инициализироваться. Порой бывает так, что платформа проходит POST-тесты быстрее, чем инициализируется Zalman. Вкупе с автоматической сменой загрузочного устройства в BIOS это вызывает крайне негативные эмоции.

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

Остальные особенности четко прописаны в инструкции по эксплуатации и не должны вызывать дополнительных вопросов. Так, к примеру, есть ограничение на количество ISO-образов. ZM-VE500, равно как и предыдущие устройства этой линейки, поддерживают только 32 образа внутри директории _ISO.

Оригинал или копия

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

^{IODD-2541 весьма схож с ZALMAN ZM-VE300. Источник
фото.}
Кто-то говорит, что Zalman всего лишь перелицованная копия устройств IODD с измененной прошивкой. Другие утверждают, что IODD детально скопировал разработку Zalman. Из различных отзывов можно сделать вывод, что IODD работает стабильнее, поддерживает большее количество языков в меню и функций, но нам эти устройства использовать не доводилось.

На многих ресурсах сообщается, что некоторые модели Zalman, а именно ZM-VE200, 300 и 400, могут быть прошиты прошивкой от IODD и наоборот. Модели же 350 и 500 собственная разработка Zalman, и прошить их можно только оригинальными прошивками.

Вместо заключения

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

Надежны ли эти устройства Zalman? На мой взгляд, да, так как в условиях постоянного использования ZM-VE300 прожил более 5 лет и только потом вышел из строя. Стоит ли девайс своих денег? Однозначно ответ положительный.

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

Подробнее..

Категории: Cd , Гаджеты , Компьютерное железо , Блог компании selectel , Накопители , Usb , Эмулятор , Hdd , Zalman , Dvd

BroKB Emulz русскоязычная клавиатура для эмуляторов DosBoxBochsLBochs на Android-телефоне

13.09.2020 02:19:21 |

Автор: admin

Русскоязычная и для эмуляторов

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

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

BroKB Emulz - именно такая клавиатура:

вводимые символы - ТОЛЬКО латинские
отображаемые на клавишах символы - латинские или русские, переключение по кнопке Рус/Лат

Кроме того, для удобства ввода текстов клавиатура повторяет клавиатуру ПК, не нужно переключаться между буквами, спец.символами, цифрами по какой-нибудь клавише. Все клавиши на одном экране и можно, аналогично клавиатуре ПК, нажать шифт (клавиша Sh слева) единожды (клавиша станет SH) или дважды (клавиша станет CA от слов Caps Lock), подписи на клавиатуре при этом сменятся на шифтовые ПКшные аналоги, и выбрать нужный символ.

На клавиатуре есть отдельный ряд функциональных клавиш F1 - F12. Также есть набор вспомогательных клавиш Esc, Tab, Insert, Delete, Home, End, Page Up, Page Down, Print Screen/SysReq, Break/Pause.

Можно зажимать сочетания клавиш, если предварительно нажать в верхнем ряду Ctrl, Shift, Alt, Win клавиши (они будут подсвечены синим). Повторное нажатие на них "отпускает" их, снова превращая в черные.

Таким образом, можно нажать Ctrl+Alt+Del, Ctrl+Break, Alt+Tab, Win+R и любые другие сочетания клавиш. (следует упомянуть, что Ctrl, Shift, Alt на клавиатуре - левые, их правых товарищей на клавиатуре нет).

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

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

BroKB Emulz в DosBox

Есть множество DOS русификаторов, вот, например, один из старых русификаторов от Дмитрия Гуртяка 1993 года выпуска, переключает язык не по обычным сочетаниям Ctrl+Shift или Alt+Shift или Shift+Shift, а по простому нажатию F12: http://blackstrip.ru/keyrus.com

Этот русификатор занимает в памяти всего 11 килобайт.

Запустив этот русификатор можно жать F12 для переключения языка и потом, переключив раскладку по кнопке Рус/Лат, вводить русские символы, например, в Visual Basic for MS-DOS:

Обратное переключение на английский также проводится в два этапа: F12 для переключения языка, Рус/Лат для переключения надписей на кнопках.

Аналогичным образом можно с помощью BroKB Emulz вводить русский текст в любые досовские программы, как текстовые, так и графические:

BroKB Emulz в LBochs

Если установить в LBochs, например, Windows XP, то с помощью BroKB Emulz можно писать в этом эмуляторе русскоязычные тексты в Windows. Язык переключаем прямо с клавиатуры BroKB Emulz по Alt+Shift/Ctrl+Shift, смотря что выбрали в настройках клавиатуры на панели инструментов. Вот как, например, выглядит написание русскоязычных Win32 приложений прямо на телефоне в Delphi 7 (кстати Delphi 7 работает даже на Windows 98, если у вас слабый телефон и XP на нем в эмуляторе тормозит):

Переключаемся на английский и можем продолжать писать код:

Жмем, как обычно, на клавиатуре F9 и у нас есть рабочий EXE-файл. Кстати, LBochs имеет возможность подключения shared-диска, соответствующего выбранной папке на телефоне. Скидываем exe на этот диск и он появляется в указанной папке на телефоне.

(Из опыта работы с LBochs: если файл большой, например, 50 мегабайт - то лучше подождать минуту-другую даже после закрытия окна Windows с индикатором прогресса копирования, т.к. LBochs быстро скопированный файл запоминает, и потом более медленно в фоновом режиме помещает в shared-папку, если завершить работу Windows сразу и выключить эмулятор - то файла в shared-папке может и не появиться).

Вот так можно с помощью клавиатуры BroKB Emulz писать русскоязычные программы под DOS и Windows прямо на телефоне, а также набирать русскоязычные тексты, например, в текстовом редакторе (я набираю, к примеру, статьи системы помощи и потом собираю в CHM-файл в HTML Help Workshop, тоже очень удобно).

Кто желает попробовать подобным образом покодить на телефоне русскоязычные проги - клавиатуру можно взять по адресу http://blackstrip.ru/brokb.apk (ну или на GP, она бесплатная, совсем без рекламы, весом 34 килобайта).

Всем приятного мобильного кодинга.

Подробнее..

Категории: Разработка под windows , Старое железо , Delphi , Эмулятор , Смартфоны , Клавиатура , Dosbox , Bochs , Lbochs , Русскоязычная

	Русский
	English

Эмулятор

Аппаратный эмулятор клавиатуры и мыши с интерфейсом USB

Симуляторы компьютерных систем всем знакомый полноплатформенный симулятор и никому неизвестные потактовый и трассы

Полноплатформенный симулятор (full platform simulator), или Один в поле не воин

Производительность симуляторов

Потактовая симуляция

Симуляция на основе трасс

Использование компьютерных симуляторов. Утром софт, вечером железо

Как обойти проверку на Рутинг устройства обхитрив библиотеку RootBeer?

Дисклеймер

Как до этого дошло?

Что будем делать?

Смотрим байт-код .apk

Редактируем содержимое classes.dex

Собираем .apk обратно

Заключение

Швейцарский нож инженера дата-центра Zalman ZM-VE500

Что оставалось за кадром

Эмуляция привода

Особенности использования

Оригинал или копия

Вместо заключения

BroKB Emulz русскоязычная клавиатура для эмуляторов DosBoxBochsLBochs на Android-телефоне

Русскоязычная и для эмуляторов

BroKB Emulz в DosBox

BroKB Emulz в LBochs

Категории

Последние комментарии