KEYB.COM, warez, SecureBAT!, e-mail via FTP

Привет!
Всех, кто считает себя причастным к этому празднику, с Днем Победы! C этого и начнем… :))

Сидел вчера под Windows 98. Работал под FAR. Все хорошо, но оглушительное пищание динамика при переключении раскладки клавиатуры меня несколько… как бы это помягче… достало. В общем, моя психика, не выдержав подобного издевательства, попросила мозг принять меры.

В общем патчится KEYB.COM. Эта софтина находится обычно в подкаталоге COMMAND каталога Винды. Та версия, которую я патчил, весила 20135 байт, так что будьте внимательны. Ущербные байтики перечислены в таблице чуть ниже.

KEYB.COM

0F12: E4 EB
0F13: 61 16
0F5F: 50 EB
0F60: E4 0C

Warez
Только-только вышел PHP 4.0.5, а PHP team уже приступила к разработке 4.0.6. Уже доступен 4.0.6RC1. Изменения коснулись, в основном, GD (в связи с появлением второй бета версии) и OpenSSL.

RitLabs выпустила TheBAT! 1.52f. Что там нового уж не знаю, сравнивать списки исправлений довольно лениво. Не забудьте заново пройтись патчиком. Ссылку я давал позавчера.

Как-то незаметно для меня вышел один из моих любимейших плагинов к FAR — FarNavigator (в прошлом — ProxyFTP). Новая версия — 1.80b5, это багфикс. Должен быть исправлен, найденный лично мной, баг с падениями плагина на плохом канале.

Фирма RitLabs (автор TheBAT!) начала выпуск нового продукта — SecureBAT!. Это полнофункциональный почтовый клиент, построенный по образу и подобию TheBAT!, но главный акцент в нем сделан в пользу защиты вашей почты от чужих глаз. SecureBAT! умеет шифровать все хранимые на диске файлы, выполнять защиту передаваемой информации с использованием OpenPGP или S/MIME и многое другое.

Вообще ребята из RitLabs — молодцы. В свое время они практически полностью отказались от защиты почты в TheBAT!, оно и правильно — лучше никакая, чем настолько легко ломаемая система, по крайней мере не создает чувство ложной безопасности. И все это время, оказывается, они работали над созданием полностью секурного агента… молодцы, определенно!

Продаю идею. Нет, просто отдаю в хорошие руки :). Почту, в последнее время, все чаще и чаще используют, как средство обмена бинарными файлами. Неудивительно, только вот транспорт e-mail совсем не предназначен для передачи бинарников.

Бинарники, вообще говоря, сначала переводятся в текст (слышали о base64 и ююке? вот это оно и есть), а уже потом уже пересылаются. Что сильно сказывает на размере передаваемого файла, иногда настолько сказывается, что сидя на модеме на размер этот без слез смотреть невозможно. Менять что-то в протоколе уже поздно, да и не предназначалось это все хозяйство для передачи чего-то отличного от текста… это уж так… надстройка.

Для передачи бинарников, вообще говоря, есть FTP (ну и еще великое множество менее распространенных протоколов). Вот об этом и речь.

Лирическое отcупление. Вообще в FTP передача файлов сделана довольно оригинально. Диалог между сервером и клиентом идет на одном канале (обычно порт 21), а передача файла — на другом (обычно порт 20). В отличие от недиалогового HTTP, где файлы передаются по одному и тому же каналу, но ему можно, он устроен по-другому. Да и это все тоже держится на паре костылей, связанных с появлением докачки и keep-alive. Конец лирического отступления.

Так вот. Было бы неплохо, что бы по SMTP (почтовый протокол) и присным передавался только текст. А вот, если нужно передать бинарник, в тексте письма можно было бы дать ссылку на файл, благо протокол позволяет, а сам файл закачивать на FTP адресата.

На другом конце, мейл-сервер (ведь письма хранятся на сервере), когда адресат пошлет запрос на получение письма сверяется с заголовком почтового клиента и проверяет его на предмет поддержки этого нового сервиса. Далее, если клиент понимает такие ссылки, отдает ему письмо без изменения, почтовый клиент связывается с FTP и качает оттуда файл; иначе почтовый сервер связывается с FTP сам и внедряет скачанный файл в тело письма, отдавая письмо с бинарником «по старинке».

Вуаля. Проблемы две.

Первая — воровство чужих файлов с FTP-сервера решается простым именованием файла так, что бы его имя трудно (лучше — невозможно) было угадать, а так же запретом на FTP чтения содержимого директория и перезаписи файлов. Хотя лучшее решение, наверное, совместить почтовый и FTP-сервер и отдавать файлы только на тот IP, с которого было произведено соединение. Могут, конечно, возникнуть проблемы с файрволами и проксями, но, в конце концов, клиент всегда может попросить открыть соединение на другом порту или отдать почту «по старинке».

Вторая — закачка мусора. Тут все сложнее. Вариант с сертификацией утомителен, и для разработчика, и для пользователя. Что же остается? Удаление постфактум, это когда, по прошествии какого-то интервала, если не пришло соответствующее письмо файл удаляется. И есть еще вариант с введением второго FTP-сервера.

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

Схема такова. Вводится еще один FTP-сервер, на стороне отправителя. На нем запрещено просматривать список файлов, удалять их и читать.

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

Кроме того, сервер номер раз (тот, который на стороне отправителя) должен переодически «подчищать» файлы и соответсвующие им аккаунты на скачивание, сверяясь с логами (т. е. если файл скачали, но не удалили, его нужно удалить).

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

На сегодня, думаю, хватит. Не прощаюсь, Евгений Степанищев.