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 (ну и еще великое множество менее распространенных протоколов). Вот об этом и речь.

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

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

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

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

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

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

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

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

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

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

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

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

Ваше имя или адрес блога (можно OpenID):

Текст вашего комментария, не HTML: