Необычная проблема

Совершенно неожиданно, но тем не менее факт — США испытывают проблемы с запасными частями для своих военных самолетов. Не все, конечно, но с этой проблемой столкнулись стелс-бомбардировщики Northrop B-2 Spirit. В подтверждение этому на сайте Правительства США был опубликован запрос (PDF, через VPN) к предприятиям авиационной промышленности. Правительство попросило их выполнить разработку запчастей и деталей для B-2 Spirit методом обратного проектирования.

На появившееся на сайте уведомление обратил внимание аналитик по национальной безопасности Марк Томпсон из Project On Government Oversight (POGO, некоммерческая общественная организация, осуществляющая надзор за деятельностью правительства США). В нем говорится об инженерных работах для создания ключевых деталей теплообменников бомбардировщиков B-2. Они должны включать в себя обратное проектирование сердечника теплообменников и разработку процесса удаления дефектных сердечников.

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

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

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

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

- Производственные линии были разобраны, так как ожидалось, что запчастей на складах должно хватить на весь срок службы B-2;

- Имеющаяся техническая документация не позволяет воссоздать производство на современном оборудовании или с учетом современных материалов. А обновление документации займет много времени и обойдется очень дорого;

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

Точную причину мы вряд ли когда-нибудь узнаем. Все же B-2 Spirit — проект с высоким уровнем секретности.

Способы решения

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

В начале января 2021 года сообщалось (PDF, через VPN), что Управление материально-технического обеспечения ВВС США (Air Force Rapid Sustainment Office) ищет «новейшую автоматизированную систему 3D-сканирования». Она должна помочь с процессом копирования деталей самолетов, которые больше не производятся.

Применение 3D-сканера в работе с бомбардировщиком B-2 Spirit можно легко представить. Устройство способно отсканировать исходные детали, а позже воссоздать их чертежи и виртуальную модель. После этого достаточно просто произвести новые необходимые запчасти — на станках с ЧПУ, путем отливки в пресс-форме, штамповки или любым другим подходящим способом.

Преимущества реверс-инжиниринга уже были продемонстрированы на примере американского стратегического бомбардировщика B-52H Stratofortress. Как известно, эти самолеты стоят на вооружении ВВС США c 1955 года и регулярно проходят модернизацию и ремонт.

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

Подобная практика уже существует и в самих ВВС. В логистическом комплексе на авиабазе Робинс в штате Джорджия дислоцируется 402-я группа по техническому обслуживанию электронного оборудования. Она занимается вопросами реверс-инжиниринга, перепроектирования и производства авионики. Главная задача этого подразделения — обеспечить запасными частями системы вооружения предыдущих поколений.

Руководитель 402-й группы Дэймон Браун пояснил (через VPN), что первая часть обратного инжиниринга — это тщательное изучение устаревших элементов.

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

Перед тем как уйти в отставку, бывший помощник министра обороны ВВС по закупкам, технологиям и логистике Уилл Роппер в интервью журналу Air Force Magazine рассказывал о желании «иметь все детали для вооружения и техники ВВС в цифровом виде».

Поиск возможности обратной разработки деталей для бомбардировщика-невидимки B-2 Spirit соответствует нынешним тенденциям ВВС США. Производственный процесс постепенно переходит на новые технологии и цифровое проектирование, чтобы обеспечить качественное обслуживание парка самолетов.

Военно-воздушные силы США имеют небольшой флот стелс-бомбардировщиков. И они в основном были построены на экспериментальных (на тот момент) технологиях. Именно поэтому B-2 является очевидным кандидатом на применение реверс-инжиниринга для поддержания жизнедеятельности самолетов, стоящих на вооружении и активно эксплуатирующихся.

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

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

Крылья войны

GTA Online. Многопользовательская игра, печально известная медленной загрузкой. Недавно я вернулся, чтобы завершить несколько ограблений — и был потрясён, что она загружается настолько же медленно, как и в день своего выпуска, 7 лет назад.

Пришло время докопаться до сути.

Для ЛЛ

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

Разведка

Сначала я хотел проверить, вдруг кто-то уже решил проблему. Но нашёл только рассказы о великой сложности игры, из-за чего она так долго загружается, истории о том, что сетевая p2p-архитектура — мусор (хотя это не так), некоторые сложные способы загрузки в сюжетный режим, а потом в одиночную сессию, и ещё пару модов, чтобы скипнуть видео с логотипом R* во время загрузки. Ещё немного почитав форумы, я узнал, что можно сэкономить колоссальные 10-30 секунд, если использовать все эти способы вместе!

Тем временем на моём компе…

Бенчмарк

Загрузка сюжетного режима: ~1м 10с

Загрузка онлайна: ~6м

Без загрузочного меню, от логотипа R* до игрового процесса (без логина в Cоциальный Клуб.

Старый, но приличный проц: AMD FX-8350
Дешёвый SSD: KINGSTON SA400S37120G
Надо бы прикупить RAM: 2x Kingston 8192 MB (DDR3-1337) 99U5471
Нормальный GPU: NVIDIA GeForce GTX 1070

Я (не) одинок

Если доверять этому опросу, проблема достаточно широко распространена, чтобы слегка раздражать более 80% игроков. Прошло уже семь лет!

Я немного поискал информацию о тех ~20% счастливчиках, которые загружаются быстрее трёх минут, и нашёл несколько бенчмарков с топовыми игровыми ПК и временем загрузки онлайн-режима около двух минут. Я бы кого-нибудь убил хакнул за такой комп! Действительно похоже на железячную проблему, но что-то не складывается…

Почему у них сюжетный режим по-прежнему загружается около минуты? (кстати, при загрузке с M.2 NVMe не учитывались видео с логотипами). Кроме того, загрузка из сюжетного режима в онлайн занимает у них всего минуту, в то время как у меня около пяти. Я знаю, что их железо гораздо лучше, но не в пять же раз.

Высокоточные измерения

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

Почти минута уходит на загрузку общих ресурсов, которые нужны и для сюжетного режима, и для онлайна (почти наравне с топовыми ПК), затем GTA в течение четырёх минут полностью нагружает одно ядро CPU, больше ничего не делая.

Использование диска? Нет! Использование сети? Есть немного, но через несколько секунд падает в основном до нуля (кроме загрузки вращающихся информационных баннеров). Использование GPU? Ноль. Память? Вообще ничего…

Что это, майнинг биткоинов или что-то такое? Чую здесь код. Очень плохой код.

Единственный поток

На моём старом процессоре AMD восемь ядер, и он ещё молодцом, но это старая модель. Его сделали ещё тогда, когда производительность одного потока у AMD была намного ниже, чем у Intel. Наверное, это главная причина таких различий во времени загрузки.

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

Профилирование

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

Итак, добро пожаловать в образцы стека (stack sampling). Для приложений с закрытым исходным кодом есть только такой вариант. Сбросьте стек запущенного процесса и местоположение указателя текущей инструкции, чтобы построить дерево вызовов в заданные интервалы. Затем наложите их — и получите статистику о том, что происходит. Я знаю только один профилировщик, который может проделать это под Windows. И он не обновлялся уже более десяти лет. Это Люк Stackwalker! Кто-нибудь, пожалуйста, подарите Люку немножко любви :)

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

Вниз по кроличьей норе

Позаимствовав у моего друга совершенно законную копию стандартного дизассемблера (нет, я действительно не могу его себе позволить… когда-нибудь освою гидру), я пошёл разбирать GTA.

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

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

Проблема 1: это что… strlen?!

Дальнейший разбор дампа выявил один из адресов с некоей меткой strlen, которая откуда-то берётся! Спускаясь вниз по стеку вызовов, предыдущий адрес помечен как vscan_fn, и после этого метки заканчиваются, хотя я вполне уверен, что это sscanf.

Он что-то парсит. Но что? Логический разбор займёт целую вечность, поэтому я решил сбросить некоторые образцы из запущенного процесса с помощью x64dbg. Через несколько шагов отладки выясняется, что это… JSON! Он парсит JSON. Колоссальные десять мегабайт JSON'а с записями 63 тыс. предметов.

...,
{
"key": "WP_WCT_TINT_21_t2_v9_n2",
"price": 45000,
"statName": "CHAR_KIT_FM_PURCHASE20",
"storageType": "BITFIELD",
"bitShift": 7,
"bitSize": 1,
"category": ["CATEGORY_WEAPON_MOD"]
},
...

Что это? Судя по некоторым ссылкам, это данные для «сетевого торгового каталога». Предполагаю, он содержит список всех возможных предметов и обновлений, которые вы можете купить в GTA Online.

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

10 мегабайт? В принципе, не так уж и много. Хотя sscanf используется не самым оптимальным образом, но, конечно, это не так уж плохо? Что ж…

Да, такая процедура займёт некоторое время… Честно говоря, я понятия не имел, что большинство реализаций sscanf вызывают strlen, поэтому не могу винить разработчика, который написал это. Я бы предположил, что он просто сканировал байт за байтом и мог остановиться на NULL.

Проблема 2: давайте использовать хэш-…массив?

Оказывается, второго преступника вызывают сразу за первым. Даже в одной и той же конструкции if, как видно из этой уродливой декомпиляции:

Все метки мои, и я понятия не имею, как на самом деле называются функции/параметры.

Вторая проблема? Сразу после разбора элемента он хранится в массиве (или встроенном списке C++? не уверен). Каждая запись выглядит примерно так:

struct {
uint64_t *hash;
item_t *item;
} entry;

А перед сохранением? Он проверяет весь массив, сравнивая хэш каждого элемента, есть он в списке или нет. С 63 тыс. записей это примерно (n^2+n)/2 = (63000^2+63000)/2 = 1984531500, если я не ошибаюсь в расчётах. И это в основном бесполезные проверки. У вас есть уникальные хэши, почему не использовать хэш-таблицу.

Во время реверс-инжиниринга я назвал его hashmap, но это явно не_hashmap. И дальше ещё интереснее. Этот хэш-массив-список пуст перед загрузкой JSON. И все элементы в JSON уникальны! Им даже не нужно проверять, есть они в списке или нет! У них даже есть функция прямой вставки элементов! Просто используйте её! Серьёзно, ну ребята, что за фигня!?

Доказательство концепции

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

План такой. 1. Написать .dll, 2. внедрить её в GTA, 3. зацепить некоторые функции, 4. ???, 5. профит. Всё предельно просто.

Проблема с JSON нетривиальная, я не могу реально заменить их парсер. Более реалистичным кажется заменить sscanf на тот, который не зависит от strlen. Но есть ещё более простой способ.

* зацепить strlen

* подождать длинной строки

* «закэшировать» начало и длину

* если поступит ещё вызов в пределах диапазона строки, вернуть закэшированное значение

Что-то вроде такого:

А что касается проблемы хэш-массива, то здесь просто полностью пропускаем все проверки и вставляем элементы напрямую, поскольку мы знаем, что значения уникальны.

Полный исходный код PoC здесь.

Результаты

Ну и как оно работает?

Прежнее время загрузки онлайн-режима: около 6м
Время с патчем проверки дубликатов: 4м 30с
Время с парсером JSON: 2м 50с
Время с двумя патчами вместе: 1м 50с

(6*60 - (1*60+50)) / (6*60) = 69.4% улучшение времени (класс!)

Да, чёрт возьми, получилось! :))

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

Краткое содержание

При запуске GTA Online есть узкое место, связанное с однопоточным вычислением

Оказалось, GTA изо всех сил пытается распарсить 10-мегабайтный файл JSON

Сам парсер JSON плохо сделан/наивен и

После парсинга происходит медленная процедура удаления дублей

R*, пожалуйста, исправьте

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

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

ty <3

Перевод, Оригинал.

Дополнение 15.03.2021:

* Получил подтверждение от R*, что это скоро исправится

* Только что получил награду в размере $10k через их внутриигровую награду H1 в качестве исключения :)) (обычно это делается, только по вопросам безопасности)

* Пытаюсь понять, что такое W8 (от ред. это форма налоговой службы США) и как его заполнить (лол)

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

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

Попытка победить «своими силами»

Ранее использование МЭП от Мегафон было доступно в софте Криптоарм ГОСТ (только режим подписания документов), на данный момент, судя по гитхаб, поддержку выпилили полностью.

Попробуем реализовать подпись документов собственноручно:

Адрес для подписи документов: https://msign.megafon.ru/mes-ws/sign?wsdl=

Адрес для отслеживания статуса заявки на подпись: https://msign.megafon.ru/mes-ws/status?wsdl=

Отправка документа на подпись (/mes-ws/sign)

Входные параметры для отправки документа на подпись:

partner_id - идентификатор партнера, осуществляющего операцию подписания (возьмем из Крипто АРМ – digt)

msisdn - мобильный номер SIM-карты клиента с КЭП

text - текст, который будет отображен на Мобильном Устройстве Абонента при подписании документа

document - подписываемый документ в формате base64

signType - тип подписи, возможные значения: Attached – прикрепленная подпись и Detached – открепленная подпись (Если параметр отсутствует, платформа создает detached подпись)

digest - специфицируемая «свертка» от документа (8 шестнадцатеричных символов)

Правила формирования свертки (поле digest):

1) Вычисляется MD5 от представления документа в формате Base64

2) В цикле от 0 до 8 вычисляется XOR от I, I+8, I+16, I+24

3) Полученные шестнадцатеричные цифры конкатенируются в строковом

представлении

function md5_to_digest($md5) {
$result = '';
for($i=0; $i<8; $i++) {
for($j=0; $j<4; $j++) {
$digit = substr($md5, $i+$j*8, 1);
$d16 = hexdec($digit);
if($j == 0) {
$r = $d16;
} else {
$r = $r ^ $d16;
}
}
$result .= dechex($r);
}
return strtoupper($result);
}

Возвращаемые параметры:

transaction_id - уникальный идентификатор транзакции

Получаем статус обработки документа (/mes-ws/status)

Для проверки статуса передаем параметры partner_id и transaction_id, в результате получаем ответ от сервера, который содержит поле status

Если статус равен 100, то все хорошо и поле cms будет содержать электронную подпись документа в формате Base64

В противном случае смотрим код ошибки из списка:

101 - Документ еще не подписан

200 - Отсутствует один или несколько обязательных параметров

201 - Один из параметров имеет неверный формат

203 - Неизвестный идентификатор транзакции

400 - Неизвестный partner_id

401 - Неизвестный сертификат SSL или сертификат SSL не соответствует парнёру (partner_id).

500 - Внутренняя ошибка сервера повторите запрос позже

800 - Время жизни транзакции истекло

801 - Сервер подписания не смог доставить запрос на подписание на мобильное устройство

802 - Абонент отказался подписывать документ

803 - Заблокирован PIN

804 - SIM карта заблокирована

805 - На SIM карте нет ключевой пары

806 - Ошибка в сертификате Абонента

807 - Запрос на подписание не может быть выполнен необходимо сформировать новый запрос на подписание

У конкурентов есть DSS сервера от КриптоПро, которые позволяют решить большинство задач посредством сторонних сервисов, в Мегафон почему –то отказались от подобной практики.

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

Пост - крик души, но вдруг кто поможет советом...

Ввязался в авантюру портировать прошивку OpenTX на мой любимый dx6i. Привык к нему, но недостатков у него полно, хотя большинство можно решить софтом. Схему зареверсить проще всего, с протоколами и алгоритмами тоже особо проблем нет, а вот экран положил свинью... С виду обычный cog 128x64 с параллельным интерфейсом. В душе тлела Надежда что что-то попсовое, что стоит только определится с распиновкой и дело в шляпе...

Ага, не с моим везением. По схеме видно 5 пинов управления (предположительно). Так вот логика подсказывает что 2 из них должны быть стабильно 1 а на 3 должна быть модуляция ( типа cs1, a0, rd) - но логический анализатор говорит - 2 пина 0в, 3 пина 3.3в, никакой модуляции, свободен...

Как, черт побери? Что это за зверь такой? Как разгадать что за контроллер рулит этим даже не знаю как его назвать...

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

Есть у кого идеи как этого зверя победить?