Rus IT Front

О проекте

Пока что основных цели две:

1. Реверс-инжиниринг и анализ программ, которые использует ВСУ, а также приложений артиллерийских калькуляторов и тактических карт.

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

Реверс-инжиниринг

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

Система Кропива:

Мапа (ua.milarmysos.android_2.7.3)
Тенета (ua.mil.armysos.network.networkbridge_2.2.8)
Тенета Группы (ua.mil.tenetagroups_1.2.23)
Обновление ресурсов (ua.kmd.resourceclient-1.2.0)
Метео (com.idepositbox.btspp-1.2.5)
Быстрое удаление (ua.logika.fastdelete_1.5)
FireFly (video.zhuker.sancho_1.5.1)

Код доступен по любому из этих адресов, но в любой момент эти сервисы могут его удалить:

https://0xacab.org/users/RusItFront/projects

https://codeberg.org/rusitfront

https://notabug.org/RusItFront

https://gitlab.com/users/RusItFront/projects

https://bitbucket.org/rusitfront/

Разработка

Примеры модулей, разработка которых имеет смысл:

- Геопространственный модуль - системы координат, конверсии между ними, решение геодезических задач. К примеру, вот названия классов с различными способами ввода координат в "Кропиве" - WSGInput, UTMInput, SK42Input, PolarInput, PairedCalcInput, NotchCalcInput, MgrsInput, InverseNotchOrientedInput, InverseNotchNotOrientedInput, InputByTimer, InputByTarget, InputByLandmark, InputByImpact, InputByEntity, InputByEmplacement, InputByCop, InputByBaseEntity, InputByAverage, Graphical, FromBOObjectInput, CoddedInput.

- Модуль шифрования. Здесь могут быть реализованы алгоритмы ГОСТ, AES, ECC и протоколы обмена ключами. Такой модуль должен пройти аудит, и его использование должно быть максимально простым и не требовать глубоких знаний по криптографии для достижения криптобезопасности.

- Артиллерийский модуль. Здесь содержатся все расчеты и данные по орудиям и боеприпасам в определенном формате, чтобы было легко добавлять новые.

- Общий модуль передачи данных. Этот модуль подключают потребители, и им не нужно вникать в работу протоколов и методы передачи данных. Здесь должны быть определены структуры данных "Группа контактов" и "Контакт". Внутри контакта указан один или несколько его адресов в доступных системах и протоколах свзяи. Адрес - текстовая строка типа URI, которая включает в себя протокол и идентификатор абонента (к примеру, IP-адрес или его открытый ключ), к примеру, "ax25:afsk1200@400mhz/44.136.8.5" или "dmr@800mhz/Gost3410/6202c2b5ce9a7a35515e".

- Отдельные модули по протоколам и методам передачи данных, сюда относится взаимодействие с конктретными радиостанциями по Bluetooth, аудиомодемы, протоколы типа AX.25.

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

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

Как поучаствовать

- Присылайте сслыки на программы (или сами программы), которые имеет смысл подвергнуть реверс-инжинирингу.

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

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

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

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

Работа над кодом во время реверс-инжиниринга

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

- Деобфускация (восстановление названий переменных). Открываете папку с проектом в любой среде разработки (к примеру, Android Studio), открываете любой класс с логикой приложения (не сторонних библиотек), вникаете в логику, находите обфусцированные переменные и названия классов и методов, нажимате на них правой кнопкой -> Рефакторинг -> Переименовать и придумываете название по смыслу. Пример того, что в итоге получается, можно посмотреть здесь.

- Ручная декомпиляция. Автоматическая декомпиляция не всегда проходит корректно, нужно находить методы, с которыми декомпилятор не справился и восстанавливать код вручную.

В целом этого достаточно для понимания и анализа кода, но если на этом не останавливаться, есть дополнительные задачи:

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

- Билд проекта. Имеет смысл сделать так, чтобы проект хотя бы собирался. Для этого нужно исправлять ошибки, которые выдает компилятор. Среди этого - исправление XML-файлов ресурсов, переписывание интерфейсов без использования блока const, добавление отсутствующих import'ов. Куски кода внутри методов с ошибками декомпиляции (особенно в сторонних библиотеках) можно просто закомментировать, при этом пометив такие методы комментарием "// FIXME: !", чтобы можно было потом легко их найти.

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

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

Другие пути

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