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

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

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

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

(Update, 04/01/2024: пример успешного переключения “шампанского” и “хлопчатобумажного” на примере GigaChat.)

Кстати, что ещё касается регистраторов и, в частности, GoDaddy. Доменные зоны, а точнее – имена хостов в этих зонах, – часто используются косвенно, в составе тех или иных технических систем. Про это могут забыть даже администраторы и DevOps. Тут могут быть имена авторитативных серверов DNS (NS), имена для почтовых серверов, технические зоны для CDN и прочих систем распределения нагрузки. Потеря подобного имени может привести не только к недоступности ресурсов, но и к той или иной подмене адресации (потому что имя могут перехватить). При этом, GoDaddy мог выступать провайдером DNS-хостинга, что означает появление задач по корректному переносу самой доменной зоны. Так что проблемы у администраторов и DevOps, конечно, могут быть. Особенно, если учитывать, что изменение регистратора доменного имени, даже при содействии отдающей стороны, может занять время: нужно получать коды подтверждения, снимать/устанавливать разные флаги, вести дополнительную переписку. У GoDaddy, например, не самая надёжная и понятная панель управления – часто при переносе имён происходят какие-то загадочные сбои, не отправляются письма.

(И, опять же, не стоит забывать про реестры.)

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

Получается, потребитель QR-кода ничего не знает о том, что стоит за кодом. Человек даже не в состоянии прочесть этот код самостоятельно, без использования электронного устройства (сравните с “текстовым” URL). А вот владелец сервера, на который приходит браузер смартфона (мобильного устройства), напротив, обладает как минимум следующей информацией: некий IP-адрес, связанный с устройством (определяет оператора, провайдера, дополнительный источник данных о местоположении); тип устройства; тип ПО на этом устройстве, сведения о браузере; ну и весьма точные данные о местоположении пользователя в данный момент.

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

Небольшой комментарий о привычных форматах и способах записи TLS-сертификатов (SSL-сертификатов, как почему-то некоторые продолжают называть). Такой сертификат представляет собой публичный электронный документ, состоящий из множества полей. Внутри эти поля записываются в так называемой ASN.1-структуре, которая, в общих чертах, является иерархией вложенных строк байтов. Общий принцип кодирования здесь такой: строка всегда начинается с префикса, точно задающего тип поля данных и длину данных, а оставшиеся байты – несут сами полезные данные. С базовыми, независимыми от платформы, способами записи связаны разные тонкости, исторически сложившиеся “допущения”, а также и всякие прочие спецификации, например, DER (Distinguished Encoding Rules). Однако реальные хитрости и сложности, происходящие из интерпретации упомянутых схем/спецификаций, возникают только у разработчиков программного обеспечения, которое существенным образом использует данные TLS-сертификатов, но не у пользователей. Например, содержимое файла сертификата в удобном формате PEM выглядит, примерно, так (но тут, для удобства, удалена большая часть строк):

-----BEGIN CERTIFICATE-----
MIIEDjCCAvagAwIBAgISBB+ebYSbzCVbUmAq3rUH97bcMA0GCSqGSIb3DQEBCwUA
MDIxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MQswCQYDVQQD
[...]
JaRB6DTHZdmM0MzOf6ltVn48cE8LVUuTAM7cFcw+Z1a40XlrMj0nY6Et+QDTZ1n+
2QZDaj5N+G21wxqvpj29BusHurW0xpFIM/Iv2+A8sX+IWQ==
-----END CERTIFICATE-----

Никакой сложности или “криптографии” конкретно тут, в способе записи сертификата, нет. Если не использовать нарочито строгие формулировки, то PEM – это просто текстовый формат с base64-кодированием, переводами строк на заданной границе и строками-разделителями, которые определяются пятью символами “минус” с BEGIN/END. В данном случае:

"-----BEGIN CERTIFICATE-----"

и

"-----END CERTIFICATE-----".

Между этими строками находится просто base64-запись байтов сертификата, закодированного в DER (можно считать, что в “бинарном” виде, а не в “тексте”). Если взять байты сертификата, закодировать их в base64, поместить результат в текстовый редактор, дописать “BEGIN…END” в заданном формате с минусами, добавить переносы строк, то получится PEM. И наоборот. (Исключения, наверное, можно попробовать придумать, но они будут экзотическими.) Естественно, так как сертификат содержит внутри электронную подпись, то значения всех его битов – важны: если что-то изменится, то подпись перестанет сходиться (или вообще проверяться, если испорчена сама запись подписи).

Преобразовать сертификат между текстовым PEM и “бинарным” DER можно при помощи OpenSSL:

PEM -> DER
$ openssl x509 -in cert.pem -out cert.der -outform DER

DER -> PEM
$ openssl x509 -in cert.der -out cert.pem -inform DER -outform PEM

(Опция “-inform DER” во втором случае нужна потому, что openssl x509 по умолчанию ожидает формат PEM.)

В сертификате при этом ничего не изменяется, никаких особо сложных операций не выполняется, а OpenSSL здесь нужен только как удобная утилита “всё в одном”. Аналогичного эффекта, действуя через командную строку, нетрудно добиться и сочетанием cat с base64 -d.

Пишут в The Guardian, что обнаружена “самая старая” чёрная дыра из когда-либо наблюдавшихся. При этом в самой статье, конечно же, речь про следы “окрестностей” дыры, которые “датируют” в 440 млн лет после Большого взрыва. То есть, самая старая дыра относится к раннему периоду избранной модели наблюдений Вселенной – на чём и строится новизна результата наблюдения.

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

Конечно, нужно отдельно считать (что это вообще означает: год – при такой плотности?), но про 440 млн лет может же так оказаться, что свет, попавший в телескоп, должен был пройти существенно большее расстояние, чем расстояние между точкой источника и точкой приёмника в тот момент, когда этот свет излучили разогретые газы, падающие в чёрную дыру. Предположительно. Потому что это косвенные измерения и, наверное, не совсем корректно говорить про свет в телескопе, но направление получается такое. Если только подобные объекты – это не эхо, доносящееся из предыдущих состояний Вселенной, когда шкала измерений была совсем другой (как у Пенроуза).

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

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

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

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

Мотивировать такой ход несложно: узлы, находящиеся внутри наложенной сети, “будут ближе к пользователю”, “лучше защищены”, “станут лучше ранжироваться в выдаче поисковых систем”, кроме того, и доступ проще оптимизировать. “Внутри” – означает, что на узлах провайдера выходных шлюзов, при том, что эти узлы принадлежат логической перемешивающей сети. Естественным примером из практики являются скрытые TOR-сервисы. Занятно, что если речь будет идти на уровне Google, то даже можно отказаться от “общепринятой” DNS – система имён и адресов может быть своей, а вход на сервисы и сейчас нередко происходит через поисковый запрос, даже из браузера. А браузер Chrome, например, более чем достаточно распространён для того, чтобы администраторы популярных сервисов задумались о параметрах доступа пользователей этого браузера, ну, это кроме только что перечисленных “прочих преимуществ”.

Всякая беспроводная технология предоставляет множество дополнительных направлений для скрытых дистанционных атак. В этот раз продолжают эксплуатировать вектор Bluetooth для беспроводных клавиатур и прочих HUD: возможность обойти авторизацию/аутентификацию позволяет подключиться к устройству с правами локальной клавиатуры, дальше – и так понятно. В большинстве случаев – проблема кардинально и без существенных дополнительных трудностей решается проводами, но это мало кому интересно. Кстати, даже древний ИК-порт тут сильно лучше защищён, потому что требует прямой видимости, но ИК-порты давно вышли из моды.

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

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

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

Добавил на экспериментальный (тестовый) сервер TLS 1.3 разбор и вывод расширения ECH (Encrypted Client Hello). Это расширение присылают свежие версии браузера Chrome/Chromium, раньше сервер просто узнавал тип расширения, но не выводил содержание. Для того, чтобы браузер прислал ECH (GREASE) в качестве сигнала – поддержка ECH на TLS-сервере или в DNS не требуется. Расшифровать ECH не получится, потому что в таком варианте просто нечего расшифровывать: это сигнальный вариант ECH, ключа у сервера нет, да и основное содержание ECH должно быть представлено байтами со случайными значениями. Однако это не мешает проверить формат и вывести значения полей.

Адрес сервера: https://tls13.1d.pw/. Если успешно подключились свежим Chrome, то ECH нужно искать по “ECH /DRAFT/” (идентификатор 0xFE0D).