dxdt.blog: занимательный интернет-журнал

Кстати, первые вычислительные системы распознавания речи конструировали ещё где-то в 60-х годах прошлого века. С тем чтобы решить исключительно практическую в своём роде задачу эффективного использования мощностей аудиозаписи для систем прослушивания переговоров. Задача вот в чём: есть возможность прослушивать некий важный канал речевой связи (организовали, скажем, утечку); канал используется интенсивно, а полезные сведения могут содержаться только в небольшой части переговоров, которые и нужно записывать. Автомат мог бы распознавать голоса участников переговоров, узнавать важных персон и включать запись только когда именно они общаются.

Экономится магнитная лента. Ну или там проволока, не так важно, что именно. Для 60-х это весьма важная экономия, потому что записывающее устройство установлено, например, прямо в линии, в каком-нибудь колодце или туннеле, забирать и заменять кассеты – то ещё приключение. Время записи принципиально мало, потому что сверхкомпактных микроэлектронных ОЗУ ещё нет, а проволока (ну, хорошо, лента) – она очень быстро заканчивается.

Подобную систему распознавания, – или точнее её будет называть системой “узнавания”, – работающую в качестве триггера, в теории можно сделать чисто аналоговой. Но вот чтобы свести к разумному значению количество ложных срабатываний нужно отслеживать и анализировать звук на некотором временном интервале, то есть, просто по одному “срезу” сигналов в фильтрах качественно идентифицировать говорящего не получается. (Останавливать запись, наверное, можно, используя стандартные командные сигналы, которые присутствуют в канале.) Реальная эффективность подобных систем не ясна. Часто рассказывают, что большие по размерам опытные образцы не справлялись с задачей: триггер срабатывал слишком поздно – важный человек уже заканчивал разговор и вешал трубку.

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

Между прочим, идея о хранении паролей от разных онлайн-сервисов в записях Twitter – идея в меру здравая, но требующая приложения технической хитрости в реализации. Конечно, просто “постить” пароли в открытом виде нельзя. Нужно их зашифровать каким-нибудь симметричным шифром (3DES, Blowfish и т.п.), используя мастер-пароль, и преобразовать в Base64, чтобы получить текстовое представление, пригодное для отправки на страницы Twitter.

Зашифровать и преобразовать легко – используем openssl, поддерживающий все нужные шифры и коды. Мастер-пароль, понятно, придётся запомнить. Логины можно либо помнить, либо шифровать вместе с паролем (одной строкой, как обычно). Но возникает резонный вопрос: как найти нужную запись? Оказывается, очень просто: генерируем хеш (MD5, например) от названия ресурса, логин/пароль для которого сохранён в данной записи, и часть строки со значением хеша добавляем в качестве “индекса”, через пробел, или можно использовать “#” (как это принято в “Твитере”). Для экономии места можно использовать пять или семь последних символов от значения хеша. Теперь найти запись можно стандартным поиском “Твитера”.

Использовать для “индексации” записей фрагменты URL-ов онлайн-сервисов – не так занимательно, как куски от сумм MD5, и не так секретно. Да, можно тривиальным способом построить таблицу с MD5 от названий всех сколь-нибудь популярных интернет-ресурсов и тем самым восстановить некоторую информацию о назначении записей. Но это не страшно. Более того, столь же тривиальна защита: просто “солим исходник” – перед вычислением MD5 добавляем к названию ресурса секретный суффикс.

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

Как восстановить зашифрованные пароли на своей машине – понятно: взял и восстановил (непонятно, впрочем, почему же тогда не воспользоваться локальным хранилищем). А вот получить доступ к паролям на произвольном компьютере, подключенном к Интернету – сложно. Ведь дешифровать пароли нужно локально (иначе снижается секретность), но на компьютере может отсутствовать подходящий инструментарий. Даже для поиска пароля потребуется вычислить MD5.

Конечно, можно подготовить и опубликовать веб-страницу, включив в её состав javascript-библиотеку, реализующую нужную криптографию в браузере, на клиентской стороне. Но тогда и зашифрованные пароли лучше хранить на такой странице, а не в “Твитере”.

(Кстати, кроме шуток, если использовать “облачные” сервисы для хранения данных, то данные нужно шифровать, прежде чем отдавать в “облако”. Достаточно быстрые, с учётом доступа через Интернет, реализации стойких шифров сейчас есть. А вот если вы захотите ещё и обрабатывать зашифрованные данные в облаке, то тогда возникнет интересная проблема: далеко не всегда возможно и обработку данных вести в зашифрованном виде; даже если возможно, то придётся написать довольно сложную программную систему, выполняющую такую обработку.)

В рамках “Премии Рунета”, как обычно, проходит “народное голосование” – здесь каждый желающий пользователь Сети может заполнить анкету, поддержав те или иные веб-сайты из списка номинантов. Конечно, голосовалку защищают капчей, которую интересно разобрать. Капчи, используемые разработчиками сайтов премии, уже традиционно служат хорошим иллюстративным материалом по теме “как не нужно делать” (пару лет назад я уже рассказывал про один из вариантов “премиальной капчи”).

Итак, вот что нам предлагают в этом году:

То есть, для того, чтобы доказать “что не робот”, нужно выполнить типичную для робота задачу – арифметическое действие с двумя числами. Кстати, забавно читать, что ответ требуется вводить “числом”. Видимо, это оговорка для тех настоящих геометров, кто предпочитает числам фигуры. (Да, понятно, что хотели сказать “введите цифрами”.) Начинаем разбирать капчу с точки зрения робота “или скрипта накрутки”. Рассматриваем только само изображение, не используя всякой сопутствующей информации, которая скрыта в механизме проверки/демонстрации капчи.

Во-первых, подумаем, сильно ли добавляет вычислительной сложности этот вот финт с требованием “выполнить простое математическое действие”. Понятно, что для обычного человека сложность сильно возрастает: вычитать/складывать числа – это вам не бенгальских тигров от африканских жирафов отличать по фотографиям, может потребоваться калькулятор (да ещё и прочитать ведь нужно правильно, учитывая все эти линии и окружности). А вот для робота, если он уже научился распознавать числа, составляющие данную капчу, ещё одна операция сложения не имеет никакого значения. Обратите внимание, что оба числа записаны одним и тем же шрифтом, в рамках одного и того же шаблона. Поэтому если “скрипт” научился распознавать слова в этой капче, то будьте уверены: он научился распознавать их все и сразу получит оба числа. Так что опять усложняют задачу только для человека. С точки зрения стойкости к распознающим автоматам, в данном варианте капчи достаточно было записать любое четырёхзначное числительное и предложить человеку ввести его. Но, видимо, задача состояла в том, чтобы усложнить капчу, не используя знаний о том, как работают распознавалки.

(Между прочим, именно по только что описанным причинам в хороших текстовых капчах-изображениях всегда используются некоторые “псевдослова”, и ни в коем разе не типовые числительные. Скорее всего, требование выполнить записанную операцию перекочевало в капчу “Премии Рунета” из популярных чисто текстовых капчей, работающих без изображений. Но если в текстовой капче такой подход как-то оправдан, то в графике – он пугает только реальных биологических человеков.)

Кстати, уже на небольшой выборке хорошо заметно, что для вывода текста капчи используется жёсткий шаблон (наверняка так и есть, вряд ли программист что-то изменяет на длинном интервале): здесь всегда две строки, первый “операнд” занимает верхнюю, вторая строка начинается со знака операции. Роботов такие шаблоны всегда очень радуют. Посмотрим на капчу в увеличенном виде:

Как это распознавать?

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

Всякий криптолог скажет вам, что шифрованный текст, о котором известно, что он состоит только из числительных – большая радость для взломщика шифров. А случай с капчей “Премии” ещё более простой. Дело в том, что числительные здесь можно очень эффективно распознавать даже при самом большом уровне шума, потому что они записываются словами с известными свойствами и набор этих слов не велик. Например, число 4 можно безошибочно узнать по двум критериям: первая буква “Ч”, а число букв в слове – 6 (тут даже не страшна погрешность по подсчёту букв, потому что числительных на “Ч” в интервале 1-100 – совсем уж мало). То есть, как читатели догадались, для распознавания числительных не нужно распознавать все буквы (можно букв вообще не распознавать – см. ниже), а нужно правильно использовать другие математические свойства изображения капчи. Забавно, что в использованном шаблоне даже число слов даёт уйму информации: например, “сорок” (40), в качестве первого слагаемого, так и записывается в первой строке шаблона одиноким словом, позволяя совершенно точно не перепутать 40 и 41, 42, … И это хорошо, роботы не любят дополнительной работы по проверке, им нужно экономить батарейки.

Да, в капче шаблон текста искажается “волнами” и “перспективой”. И есть ещё суперчёрточки – очень популярное явление. Но это не страшно, потому что для определения чисел, указанных на капче, не нужно все эти искажения компенсировать. Достаточно сделать примерно следующее:

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

2) посчитать пробелы в строках (строк всегда две, пробелы определяются подсчётом расстояний между “буквами” – распознавать их для этого не нужно – вдоль горизонтальной средней линии строки, которая определяется из положения углов шаблона и центра масс нескольких “букв”, в строке может присутствовать только один пробел, то есть ошибиться программе сложно);

3) посчитать длины слов в строках (определяется длина и в пикселах, и в “буквах”);

4) отфильтровать множество возможных значений элементов капчи по “словарю”, содержащему длины слов, составляющих записи числительных;

5) учесть пробелы и относительные длины слов (сравните сами: “сорок два”, “семнадцать”, “пять” – отличить легко без распознавания букв; составить словарь могут те, кто займётся реализацией очередной распознавалки для народного голосования);

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

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

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

В общем, в этой капче – следующие проблемы: использование числительных в качестве основного элемента из-за малой вариативности сводит к нулю все усилия по затруднению “распознавания текста”; использование двух этапов решения (прочитай слова/вычисли результат) опять затрудняет распознавание только для человека и никак не влияет на сложность автоматического распознавания. То есть, снова защита от добросовестных пользователей, которую пробьют роботы.

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

Итак, продолжаем выпускать блог dxdt.ru.

Кстати, в своё время гражданский сигнал GPS содержал существенную “уводящую помеху”, специально встроенную для того, чтобы систему (в гражданском варианте, понятно) нельзя было использовать для наведения сколь-нибудь быстрого и при этом высокоточного оружия. Позже ограничения сняли. Этот фактор только увеличивает потребность в “локальных” помехопостановщиках GPS.

То есть, прикрыть действительно важные объекты от систем наведения, работающих по GPS, можно с помощью создания помехи, которая не позволит гражданским приёмникам работать в некоторой зоне вокруг объекта. Такой подход компенсирует возможности современных навигационных устройств, доступных на рынке (ведь с их использованием уже давно делают любительские модели самолётов с автопилотами и тому подобные вещи). Метод используется в реальности, что не удивительно.

Интересно, что в те времена, когда гражданский GPS-сигнал транслировался в “сильно испорченном” виде, придумывали методы “корректировки”, которые могли бы позволить получать точную навигацию на базе GPS. Понятно, что коррекцию можно проводить, используя дополнительные точки привязки, координаты которых точно известны и до которых точно известно расстояние. Такими точками могут быть наземные маяки, передающие сигнал синхронизации по радио. При этом, маяк определял бы своё местоположение, используя GPS: для неподвижного приёмника ошибка исправлялась с помощью накопления сигнала в течение определённого промежутка времени.

То есть, для борьбы с помехой использовалась бы обратная схема: если сейчас можно с помощью помехи “закрыть” от GPS определённый участок пространства, то при “испорченном” GPS на нужном участке пространства можно построить дополнительную корректирующую “антипомеху” и – получить более точную (и практически столь же простую по реализации) навигацию. (Хорошие результаты дал бы уже один маяк, выставленный заранее.)

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

Два важнейших фактора: сети связи и вычислительные мощности “в компактном размере”. Ну и GPS, конечно, помогает. Одно из известных достижений: любительские “беспилотники” – небольшие авиамодели, на борту которых установлен автопилот с поддержкой GPS. Такие летательные аппараты уже сейчас могут летать по длинному заданному маршруту с довольно высокой точностью, лишь бы погода не подкачала.

Но GPS – штука более мощная, потому что даёт дешёвый механизм синхронизации времени. Если сюда приплюсовать Интернет, то перед энтузиастами открывается очень интересное поле для деятельности: можно строить хорошо распределённые в пространстве (десятки километров) системы сенсоров, с синхронным временем. Что такие системы могут делать? Они могут определять координаты разных источников сигналов. Схема тут ясна: основу для вычисления координат источника даёт разница во времени прихода отслеживаемого сигнала в разные точки сети (координаты точек известны). Есть проблемы, конечно. Но есть и интересное развитие: по точно такой схеме работают пассивные системы локации, использующие “побочный” электромагнитный фон.

Суть такая (я как-то писал об этом): в результате технологической деятельности в эфире работает куча передатчиков, излучающих самые разнообразные сигналы. Пассивная система, во-первых, принимает основной сигнал от того или иного существующего передатчика; во-вторых, принимает отражённые разными целями сигналы этого же передатчика. Непосредственно, основной передатчик может слушать один приёмник, который формирует опорный сигнал. Такой приёмник снабжаем, например, узконаправленной антенной. Другие приёмники сети принимают отражённые сигналы. (Впрочем, понятно, что в реальности все приёмники могут принять не только исходный сигнал, но и какие-нибудь отражения. “Лишние” данные фильтруются на основе информации о свойствах опроного сигнала.)

Собранные сетью сигналы с точными временными и “географическими” метками передаются через Интернет в некий центр. Центр – это достаточно мощный компьютер, который вычисляет возможную конфигурацию источников отражений и строит искомую картину наблюдений. Получаем “систему мониторинга”. (Тут нужно учитывать, что там возникает вычислительно сложная комбинаторная задача; но и центр можно сделать не “центром”, а распределённой вычислительной системой, увеличив доступную мощность.) В качестве источников опорных сигналов годятся телевизионные передатчики, базовые станции GSM и т.п.

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

Пожалуй, вынесу сюда из комментариев – читатель с ником AA пишет про закладки в микросхемах:

Придумался еще один вариант закладок. Немного нетипичный, но все же:
Для изготовления микросхем используется легирование полупроводниковой основы примесями. “Потенциальный союзник” может ввести дополнительный этап (еще один проход резист-литография-травление-легирование-отчистка, в существующие десятки таких проходов) в пп/производство, когда у некоторых (единичных!) особо мелких транзисторов легирование затворов будет вестись не стандартными примесями, а короткоживущим (десятки лет) ее изотопом. Через какое-то время изотоп распадется поменяв валентность, что приведет к сбою данного транзистора. Что получаем – данная партия сбис гарантированно сломается через n лет, не важно, была ли она в использовании или на складах. Фон от пикограмм (или меньше??) изотопа не детектируется, на ускоренном старении (для определения времени работы микрухи) данный вариант закладки не будет найден. Минусы – нельзя выключить вовремя, плюсы – не надо пытаться запихнуть управляющий импульс в микруху, экранирование и запасные микрухи (из той же партии) дело не спасут.

Специфические микрухи для закладывания изотопов – высокоскоростные и многоканальные АЦП, DSP.

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

Во-первых, кириллические адреса вводятся не в DNS, а чисто на клиентской стороне. Так что сами доменные зоны как были “латинскими”, так и остались. Зато появился дополнительный уровень представления, который, к тому же, с точки зрения технического специалиста (админа, например), расщепляет множество доменных имён на два класса – “традиционные” и “в кракозябрах” (то есть, кодированные в Punycode).

Во-вторых, домены адресуют группы разнородных ресурсов, доступных для неопределённого круга “клиентов” (DNS – глобальная система). При этом сами интернет-ресурсы в своей работе постоянно используют доменные имена для “обратных” ссылок (базовые URL для веб-сайтов, адреса e-mail, доступ с терминалов и т.д., и т.п.). Файлы – это объекты более “локальные”, наружу, конечно, передаются, но обязательно через какой-то “шлюз” (например, через веб-сервер). Даже директории (вполне себе файлы, да), адресующие группы объектов в файловой системе, это не эквиваленты доменов в современном Интернете.

Практическое проявление описанных различий сейчас хорошо видно на веб-сайтах, которые бодро перешли на кириллицу в адресах. Например, документ с описанием домена РФ на сайте Координационного центра (администратора этого домена) имеет вот такой URL: http://кц.рф/ru/domains/domenrf/. Посмотрите сами, где здесь домены и где “файлы”, которые уже давно допускают использование многоязычия.

Это я не к тому, что адреса на кириллице плохо. Просто ситуация – сильно отличается от случая с именами файлов.

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

Интересно, что навязать пользовательскому компьютеру такие вычисления можно и без доступа к системе обновлений. Логичное решение – посещаемый веб-сайт. Конечно, можно что угодно запрограммировать на JavaScript и отправлять результаты подсчётов на сервер после загрузки страницы, или даже считать всё время, пока страница загружена, а результаты отправлять асинхронно, с помощью AJAX. Но JavaScript – медленный, да и решение получается слишком банальное.

Изящное решение могло бы быть вот каким: навязанная вычислительная задача “зашивается” в рендеринг веб-страниц. Например, когда браузер размещает в окне визуальные блоки, определяемые специально подготовленным CSS-ом (таблицами разметки страниц), он решает задачи, близкие к комбинаторным (ведь позиционирование блоков может быть относительным и абсолютным, с разной глубиной, с разным выравниванием и т.п.).

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

Как часто пишут, мобильный телефон может быть “анонимизирован”: сам аппарат приобретается “с рук” на рынке, и там же, без регистрации паспорта, покупается SIM-карта (хотя такие “симки” продаваться, вообще-то, не должны, но, тем не менее). Стандартные методы идентификации абонента GSM на таком телефонном аппарате не работают, по понятным причинам. Вопрос: а как тогда можно вычислить реального абонента, при условии участия оператора (операторов) связи?

Понятно, что сработает наружное наблюдение в сумме со специальным оборудованием, перехватывающим уникальный идентификатор аппарата (а он обязательно есть, иначе телефон не сможет осуществлять вызовы в сети GSM) из эфира. Логика не сложная: оператор связи выдаёт примерное местоположение абонента, дальше работает “наружка”, уточняя данные на месте визуально (если это место людное). Но это непростой по организации способ.

Можно воспользоваться анализом служебного GSM-трафика. Суть сводится вот к чему. Наверняка у разыскиваемого абонента есть другой, вполне официальный мобильный телефонный аппарат. Требуется найти этот аппарат, и идентифицировать абонента по нему. Предположим, что оператор связи ведёт подробные логи перемещения аппаратов между сотами и логи звонков этих аппаратов (доставки/отправки SMS, передачи данных и т.п.). В общем, понятно, что такие логи нужны и на практике имеются за какой-то период.

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

Однако всё можно упростить, взяв в качестве исходной “сигнатуры” для поиска логи перемещений и звонков для идентифицируемого “анонимного” телефона. Информация о звонках (и использовании аппарата вообще) нужна для того, чтобы из получившейся выборки по истории перемещения удалить записи, соответствующие аппаратам, по которым разговаривали одновременно с разговором по “анонимному” телефону. Использование анонимного аппарата только для передачи данных или для приёма SMS-ок – задачу обнаружения, конечно, сильно усложняет.

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

В развитие темы активных систем защиты техники (противоракетных перехватчиков): прикинем требуемое быстродействие и масштаб временной шкалы, на которой происходит срабатывание всей системы (сперва посмотрим на малые скорости, а потом на гиперзвуковые снаряды).

Понятно, что время нужно измерять от момента обнаружения угрозы сенсорами до момента, в который защищаемый объект (танк там, или самолёт) будет поражён. Предположим, что сенсоры обнаруживают подлетающий снаряд (гранату, ракету) на расстоянии в 1000 метров. Тогда, при средней скорости подлёта в 500 м/с, остаётся аж две секунды на всё про всё, можно хорошо прицелиться и так далее.

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

Более практичное расстояние – 100 метров. Получаем 0.2 сек. = 200 мс при средней скорости подлёта 500 м/с. 200 миллисекунд – это 200 тыс. тактов процессора, работающего на частоте 1 Мгц. 200 тыс. операций – как оценка, выглядит достаточной для вычисления параметров перехвата. При этом, 1 Мгц – по нынешним меркам очень медленно даже для военной специальной ЭВМ. Нужно, впрочем, скинуть время, необходимое для актививрования бортового перехватчика (поджиг ускорителей и т.п.) и передачи в этот перехватчик данных целеуказания.

Тут интересно взглянуть, как же может быть устроен перехватчик: например, противоракета выкидывается пороховым зарядом из стартового “стакана”, выдаёт несколько реактивных импульсов корректирующими двигателями (эти двигатели придают разворачивающий момент; т.е., смотрят, так сказать, вбок) и после этого, включив основной ускоритель, отправляется на встречу с целью. Собственно, именно так работает одна из штатовских систем, насколько можно судить по видео. Думаю, понятно, в чём суть схемы. Противоракета всегда выкидывается из пускового устройства в одном направлении. Скажем, вертикально вверх. Это конструктивно удобнее. Уже в воздухе противоракета очень быстро разворачивается в сторону точки перехвата, обеспечивая прикрытие по полусфере.

Ускорители со специальным топливом – они срабатывают очень быстро, хватит 5-10 мс плюс ещё 10 мс накинем на выполнение разворота. Тут, впрочем, кроется весьма хитрое “ноу-хау”: нужно так устроить корректирующие двигатели, чтобы они точно дозировали создаваемый момент, иначе противоракета будет разворачиваться с ошибкой, что сделает всю систему бесполезной. В используемом нами масштабе, заметным становится время, за которое противоракета достигнет точки перехвата. Предположим, что противоракета также показала среднюю скорость 500 м/с (очень такой прикидочный расчёт). Получается, что через 20 мс (10% от общего интервала в 200 мс) противоракета пролетела 10 метров. С запасом хватает для наземной бронированной техники (с точки зрения защиты пехоты перехват должен осуществляться как можно ближе к танку; у самолётов – там ситуация иная, но это для другой записки).

Время на передачу данных по проводам: похоже, им можно пренебречь (примем, что около 4 нс на метр, при использовании оптоволокна в качестве среды распространения). Также не рассматриваем задержки на распространние сигнала радара. Загрузка данных в противоракету: несколько байтов, несколько десятков тактов, получается – в пределах миллисекунды, при условии, что данные передаются по интерфейсу с основной частотой в 1 Мгц.

Промежуточный итог: для медленных целей (500 м/с) времени на вычисление параметров и на сам перехват – целый вагон (у нас специально занижена потенциальная производительность ЭВМ). Выглядит всё реально.

Теперь предположим, что появились упомянутые в комментах гиперзвуковые кинетические снаряды. Скорость такого боеприпаса – 1500 – 2000 м/с. То есть, времени меньше в четыре раза (скорость в четыре раза выше). Но, собственно, для вычислительной части времени всё равно достаточно (мы же взяли самую медленную ЭВМ) и даже задержки на передачу данных опять не заметны. Если противоракета продолжает тратить 40 мс на прибытие в точку встречи, то гиперзвуковой снаряд за это время пролетает всего 80 метров, что укладывается в предложенную схему (дистанция 100 метров). Так что, в теории, не так всё плохо. А ведь есть ещё лазеры. Для перехвата.

Обсуждали тут аудит программного кода. Речь вот о чём: программное обеспечение, которое предназначено для решения каких-либо критичных задач, подвергают аудиту. Цели аудита: обнаружение возможных “закладок” и нехороших особенностей.

Для аудита можно использовать исходные коды. И их используют, потому что так удобнее. Есть разные автоматизированные инструменты и вообще – обкатанные подходы. Пример, который на слуху, аудит разработок Microsoft, для допуска к специальным компьютерам. Эта корпорация предоставляет исходники своих продуктов, на особых условиях.

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

Более того, известно, что вполне себе тщательно (но независимо) проверенный в “исходниках” компилятор, после применения к, опять же, проверенным исходным кодам, может дать на выходе (в исполняемом “бинарнике”) результат с неожиданными дырами и “закладками”. Добротный результат можно получить, если проверять совместно весь набор: и компилятор “в исходниках”, и “исходники” компилируемого продукта.

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

(Часто озвучиваемая идея с подробной сверкой бинарного кода собственной сборки (из проверяемых исходников), и “оригинального” дистрибутива – особого смысла не имеет. Посудите сами: если вы и так можете получить идентичный “оригиналу” бинарный код, настаивать на использовании “оригинала” производителю смысла нет. Если же производитель что-то там, якобы, подписывает своими секретными ключами, и этим мотивирует изменение исполняемого кода, то особого доверия ко всей процедуре аудита уже быть не может.)