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

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

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

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

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

Другая трудность подобной пылинки – это оснащение её сенсорами. Можно представить, что где-то внутри пылинки разместился нанотехнологический акселерометр. Но он будет устроен очень непросто: потому что возникнет проблема с датчиками (а от гироскопа вообще придётся отказаться). Приёмник GPS, очевидно, не уместится, ни по антеннам, ни по накопительным цепям для сигнала – потому что требуется дополнительное питание. Довольно компактными могут быть световые оптические сенсоры, сенсоры температуры. И, пожалуй, всё. Не густо.

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

В общем, тема интересная. Но в публичности потеряла. Наверное, что-то уже сделали. Для ЦРУ, как вариант.

Часто в разных СМИ и даже в презентациях на популярных конференциях можно услышать про ботнеты, насчитывающие миллионы компьютеров. (Например, на РИФе называли кто 30 млн, кто 50 млн – в общем, получается, кто больше.)

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

Итак, если узлы ботнета-миллионника в течение суток придут равномерным потоком в центр за новыми указаниями, то это будет – около 12 запросов в секунду, минимум. Нужно брать место в дата-центре или арендовать мощности в сервисах типа Amazon EC. А для того, чтобы боты приходили в центр равномерно – должен быть реализован очень хитрый алгоритм распределения нагрузки.

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

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

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

Насколько можно преуспеть в реальности, показывает опыт добровольных сетей распределённых вычислений. Даже учитывая полное доверие и желание сотрудничать со стороны участников – сетей-миллионников здесь практически нет, и все те, которые есть, растут из старых, годами хорошо раскручиваемых, проектов, например, SETI@Home. Но в большинстве случаев, хороший результат – сотня тысяч участников.

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

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

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

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

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

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

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

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

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

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

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

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

Посмотрим-посмотрим.

В новой, четвёртой, версии браузера Firefox, похоже, решили “смягчить” следование веб-стандартам в угоду исправлению одной надуманной “ошибки”. Речь о довольно хорошо известном методе определения средствами HTML, CSS и Javascript истории веб-сёрфинга для браузера посетителя веб-сайта.

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

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

Да, на практике можно было бы поднять страницы, которые начали бы строить профили пользователей по истории посещений. Да, понятно, что остались другие методы определения истории веб-сёрфинга. Но интереснее другое: посмотрите, есть счётчики посещений веб-сайтов, размещаемые на веб-страницах; например, Google Analytics. Очевидно, что держатель такого счётчика может собирать историю походов браузера по сайтам (верно для тех сайтов, где установлен счётчик).

При этом, сомнительное игнорирование веб-стандартов разработчиками Firefox никак не помогает спасти пользователей от сбора их данных распространёнными счётчиками, где, кстати, такой сбор смотрится вполне логично – потому что нужен для рекламы. Занятно. (Да, можно отключить Javascript и загрузку изображений с заданных сайтов, но, на минуточку, – а чем это отличается от ситуации с “ошибкой” в CSS? Там тоже можно отключить.)

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

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

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

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

Как может быть устроен такой замок? Тысячи рычагов-перемычек с магнитными связками? Какие-нибудь вложенные сферы разного диаметра? Или трёхмерный пазл из множества кусочков со сложными поверхностями?

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

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

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

Может, есть уже такие замки?

Кстати, первые вычислительные системы распознавания речи конструировали ещё где-то в 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 на нужном участке пространства можно построить дополнительную корректирующую “антипомеху” и – получить более точную (и практически столь же простую по реализации) навигацию. (Хорошие результаты дал бы уже один маяк, выставленный заранее.)