Help! Задача по защите от копирования. - Сети, сокеты, протоколы

Добрый день! Прошу прощения за возможную некомпетентность, помогите, плиз, разобраться со следующей задачкой.

У крупного дистрибьютора мед.продукции есть много клиентов по всей стране. Компания внедряет систему электронного дистанционного заказа продукции.. Алгоритм информационного обмена следующий:

1. Разработчики пишут для каждого клиентские модули (это экзэшник) и выкладывают их на сервер.
2. Клиенты скачивают клиенский модуль (у каждого он свой со своим идентификатром), устанавливают его у себя.
3. Далее обращение за новыми прайс листами идет уже через прогу-клиент. На основе прайсов клиенты формируют заказ, отсылают на сервер и далее заказ обрабатывается и выполняется.

Стоит актуальная задача защиты от копирования клиентской части с ПК клиентов. Силами наших программеров была реализована привязка к железу проги-клиента на клиентский ПК. Конкурентам ее удается отламывать, поэтому обратились к протекторам (типа ASProtect, Themida и проч.), чтобы не враги клиентское ПО не дебажили и, соответственно, не отламывали привязку к железу. Хотим еще один эшелон защиты сделать – обеспечить привязку к железу, но уже силами того самого протектора или же какой сторонней программулины. Понятно, что отломают, в конце концов и это, но все же…

Вопрос именно по привязке к железу сторонними прогами. Видно, не любят эту функцию разработчики (протекторов в том числе), потому что зависимость от железа возникает. Так что сходу найти нужный софт мне не удалось. Попробовал 3 протектора : ASProtector, EXECryptor и WINLicende:

1. ASProtector может использовать уникальные железные данные клиента только для создания Hardware зависимого ключа активации. Т.е. происходит только проверка машины, на которой пытается встать софт. А после активации злые люди могут свободно копировать нашего клиента.
2. EXECryptor использует привязку вроде, но не так как хотелось бы – привязал софтину на мой комп так, что больше ни у кого не запустилась. Другими словами привязал софт к компу разработчика

И нигде не предложил мне ввести уникальный Hardware ID клиента, чтобы потом привязаться к нему при инсталляции.
3. WINLicende не привязался вовсе (или я че не так сделал). Хотя пишут, что должен. Как и EXECryptor, он не потребовал у меня ввода клиентского Hardware ID.

И еще один общий недостаток схемы защиты с некоторыми протекторами – необходима процедура предварительного получения Hardware ID, что может быть не очень удобно. Хотелось бы в процессе оборачивания клиентского ПО протектором или чем иным задать опцию привязки к железу при последующей инсталляции на ПК клиента.

Подскажите, пожалуйста, чем это можно сделать!
Спасибо

Здравствуйте, ribentrop79, Вы писали:

R>Добрый день! Прошу прощения за возможную некомпетентность, помогите, плиз, разобраться со следующей задачкой.

R>У крупного дистрибьютора мед.продукции есть много клиентов по всей стране. Компания внедряет систему электронного дистанционного заказа продукции.. Алгоритм информационного обмена следующий:

R>1. Разработчики пишут для каждого клиентские модули (это экзэшник) и выкладывают их на сервер.
R>2. Клиенты скачивают клиенский модуль (у каждого он свой со своим идентификатром), устанавливают его у себя.
R>3. Далее обращение за новыми прайс листами идет уже через прогу-клиент. На основе прайсов клиенты формируют заказ, отсылают на сервер и далее заказ обрабатывается и выполняется.

R>Стоит актуальная задача защиты от копирования клиентской части с ПК клиентов. Силами наших программеров была реализована привязка к железу проги-клиента на клиентский ПК. Конкурентам ее удается отламывать, поэтому обратились к протекторам (типа ASProtect, Themida и проч.), чтобы не враги клиентское ПО не дебажили и, соответственно, не отламывали привязку к железу. Хотим еще один эшелон защиты сделать – обеспечить привязку к железу, но уже силами того самого протектора или же какой сторонней программулины. Понятно, что отломают, в конце концов и это, но все же…

R>Вопрос именно по привязке к железу сторонними прогами. Видно, не любят эту функцию разработчики (протекторов в том числе), потому что зависимость от железа возникает. Так что сходу найти нужный софт мне не удалось. Попробовал 3 протектора : ASProtector, EXECryptor и WINLicende:

R>1. ASProtector может использовать уникальные железные данные клиента только для создания Hardware зависимого ключа активации. Т.е. происходит только проверка машины, на которой пытается встать софт. А после активации злые люди могут свободно копировать нашего клиента.
R>2. EXECryptor использует привязку вроде, но не так как хотелось бы – привязал софтину на мой комп так, что больше ни у кого не запустилась. Другими словами привязал софт к компу разработчика

И нигде не предложил мне ввести уникальный Hardware ID клиента, чтобы потом привязаться к нему при инсталляции.
R>3. WINLicende не привязался вовсе (или я че не так сделал). Хотя пишут, что должен. Как и EXECryptor, он не потребовал у меня ввода клиентского Hardware ID.

R>И еще один общий недостаток схемы защиты с некоторыми протекторами – необходима процедура предварительного получения Hardware ID, что может быть не очень удобно. Хотелось бы в процессе оборачивания клиентского ПО протектором или чем иным задать опцию привязки к железу при последующей инсталляции на ПК клиента.

R>Подскажите, пожалуйста, чем это можно сделать!
R>Спасибо

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

Здравствуйте, ribentrop79, Вы писали:

R>Добрый день! Прошу прощения за возможную некомпетентность, помогите, плиз, разобраться со следующей задачкой.

>[SKIPPED]

Честно говоря, идея с защитой клиентской программы от копирования — совершенно дурацкая.
Я так понял, либо злоумышленник имеет доступ к компу, на котором находится легально скачанный клиент, либо есть недобросовестные пользователи, которые сами передают клиент злоумышленнику.
Вместо защиты от копирования предлагаю сделать следующее:
1) Убрать вообще какую-либо защиту с клиента (ибо она не нужна)
2) Пустить весь протокол через SSL (лишним не будет)
3) Организовать авторизацию пользователя, логин/пароль давать только легальным клиентам (когда срок договора с клиентом закончится, его учетную запись можно заблокировать)
4) Выдвинуть требование наличия фиксированного IP-адреса у клиентов, соответственно проверять валидность IP-адреса (с других компов точно не получится как-либо работать с вашей системой)
Насколько мне известно, как-то так сделана система оплаты связи в салонах сотовой связи.
А еще можно убрать вообще какие-либо клиенты в виде исполняемых модулей, а все реализовать через веб.

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, ribentrop79, Вы писали:

R>>Добрый день! Прошу прощения за возможную некомпетентность, помогите, плиз, разобраться со следующей задачкой.

R>>У крупного дистрибьютора мед.продукции есть много клиентов по всей стране. Компания внедряет систему электронного дистанционного заказа продукции.. Алгоритм информационного обмена следующий:

R>>1. Разработчики пишут для каждого клиентские модули (это экзэшник) и выкладывают их на сервер.
R>>2. Клиенты скачивают клиенский модуль (у каждого он свой со своим идентификатром), устанавливают его у себя.
R>>3. Далее обращение за новыми прайс листами идет уже через прогу-клиент. На основе прайсов клиенты формируют заказ, отсылают на сервер и далее заказ обрабатывается и выполняется.

R>>Стоит актуальная задача защиты от копирования клиентской части с ПК клиентов. Силами наших программеров была реализована привязка к железу проги-клиента на клиентский ПК. Конкурентам ее удается отламывать, поэтому обратились к протекторам (типа ASProtect, Themida и проч.), чтобы не враги клиентское ПО не дебажили и, соответственно, не отламывали привязку к железу. Хотим еще один эшелон защиты сделать – обеспечить привязку к железу, но уже силами того самого протектора или же какой сторонней программулины. Понятно, что отломают, в конце концов и это, но все же…

R>>Вопрос именно по привязке к железу сторонними прогами. Видно, не любят эту функцию разработчики (протекторов в том числе), потому что зависимость от железа возникает. Так что сходу найти нужный софт мне не удалось. Попробовал 3 протектора : ASProtector, EXECryptor и WINLicende:

R>>1. ASProtector может использовать уникальные железные данные клиента только для создания Hardware зависимого ключа активации. Т.е. происходит только проверка машины, на которой пытается встать софт. А после активации злые люди могут свободно копировать нашего клиента.
R>>2. EXECryptor использует привязку вроде, но не так как хотелось бы – привязал софтину на мой комп так, что больше ни у кого не запустилась. Другими словами привязал софт к компу разработчика

И нигде не предложил мне ввести уникальный Hardware ID клиента, чтобы потом привязаться к нему при инсталляции.
R>>3. WINLicende не привязался вовсе (или я че не так сделал). Хотя пишут, что должен. Как и EXECryptor, он не потребовал у меня ввода клиентского Hardware ID.

R>>И еще один общий недостаток схемы защиты с некоторыми протекторами – необходима процедура предварительного получения Hardware ID, что может быть не очень удобно. Хотелось бы в процессе оборачивания клиентского ПО протектором или чем иным задать опцию привязки к железу при последующей инсталляции на ПК клиента.

R>>Подскажите, пожалуйста, чем это можно сделать!
R>>Спасибо

А>Я вот только чего не понимаю — нафига оно все нужно?
А>Если система клиент-сервер, то без стыренного сервера клиентский экзешник никому нафиг не нужен,
А>если софт такой суперский и выполняет кучу всего самостоятельно, да еще и все это хорошо денег стоит,
А>обратите свой взор на хардлоки (типа алладин-usb) — давайте софт в аренду с ключом, в конце концов...
Спасибо за внимание!! К сожалению, я сам еще не погрузился целиком в идею – было мало времени, а задачку поставили. Так вот, тырить сервер не обязательно вовсе! Гораздо проще оказывается скопировать клиент, поставить его у себя и как бы от имени клиента таскать прайсы. Сейчас наши программеры привязывают к новой версии клиента процедуру обмена сеансовыми ключами с сервером. Сеансовик дается сервером клиенту для обращения номер N к серверу, после обращения N дается сеансовик для обращения N+1. Т.е. если и стырят клиента, то рано или поздно возникнет коллизия, когда с одинаковым сеансовиком будет 2 обращения. Хотелось бы не допустить и этого хорошей привязкой к железу внешними софтовыми средствами.

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

Здравствуйте, Сергей, Спасибо за внимание!!

С>Я так понял, либо злоумышленник имеет доступ к компу, на котором находится легально скачанный клиент, либо есть недобросовестные пользователи, которые сами передают клиент злоумышленнику.

Совершенно правильно поняли.

С>2) Пустить весь протокол через SSL (лишним не будет)

Это для защиты канала? Там с этим проблем нет, узкое место в защите именно компы клиентов.

С>3) Организовать авторизацию пользователя, логин/пароль давать только легальным клиентам (когда срок договора с клиентом закончится, его учетную запись можно заблокировать)

Недобросовестным пользователям совесть позволит пароль рассказать злому дяде...

С>4) Выдвинуть требование наличия фиксированного IP-адреса у клиентов, соответственно проверять валидность IP-адреса (с других компов точно не получится как-либо работать с вашей системой)

Есть несколько схем подключения удаленного клиента. В большинстве из них IP выделяется динамически

С>А еще можно убрать вообще какие-либо клиенты в виде исполняемых модулей, а все реализовать через веб.

Начальник рассказал, что когда-то была такая модель, но от нее отказались – бабушкам-аптекаршам Веб не понравился – слишком сложно.

Здравствуйте, ribentrop79, Вы писали:

R>Недобросовестным пользователям совесть позволит пароль рассказать злому дяде...

Недобросовестным пользователям давать по ушам. В виде блокировки аккаунта. И на видном месте об этом написать. В противном случае приемлемой защиты не получится — будут только костыли.

С>>4) Выдвинуть требование наличия фиксированного IP-адреса у клиентов, соответственно проверять валидность IP-адреса (с других компов точно не получится как-либо работать с вашей системой)

R>Есть несколько схем подключения удаленного клиента. В большинстве из них IP выделяется динамически

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

С>>А еще можно убрать вообще какие-либо клиенты в виде исполняемых модулей, а все реализовать через веб.

R>Начальник рассказал, что когда-то была такая модель, но от нее отказались – бабушкам-аптекаршам Веб не понравился – слишком сложно.

С этим ясно.

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

Здравствуйте, Сергей, Вы писали:

С>Здравствуйте, ribentrop79, Вы писали:

R>>Недобросовестным пользователям совесть позволит пароль рассказать злому дяде...

С>Недобросовестным пользователям давать по ушам. В виде блокировки аккаунта. И на видном месте об этом написать. В противном случае приемлемой защиты не получится — будут только костыли.

С>>>4) Выдвинуть требование наличия фиксированного IP-адреса у клиентов, соответственно проверять валидность IP-адреса (с других компов точно не получится как-либо работать с вашей системой)

R>>Есть несколько схем подключения удаленного клиента. В большинстве из них IP выделяется динамически

С>О том и речь, чтобы такие схемы подключения запретить, совсем. Повторюсь, каждый салон совтовой связи имеет свой фиксированный IP-адрес, это "жжж" неспроста.

С>>>А еще можно убрать вообще какие-либо клиенты в виде исполняемых модулей, а все реализовать через веб.

R>>Начальник рассказал, что когда-то была такая модель, но от нее отказались – бабушкам-аптекаршам Веб не понравился – слишком сложно.

С>С этим ясно.

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

Гмм, значит насколько я понимаю, защите подлежит текущая информация на экране (как например терминал Reuter или DowJones).
Тогда засланный казачёк у программы и так может нажать PrintScreen и отдать инфу налево (если инфа не меняется каждые 5 секунд),
понятно, что ему придется это делать регулярно, что неудобно, но при любой защите кроме "перед прочтением сжечь" утечка возможна.
Аппаратная привязка — это жутко неудобно для пользователя, однако можно ввести ряд нарастающих мер, например
1) использовать крипто (SSL) сертификаты и ключи (сертификаты можно отзывать)
2) явный или неявный логин системы
3) если клиент соглашается на фикс-IP то логин-пароль прошиты (можно его защитить серийником тома харда) и никто не напрягается
4) не давать одинаковым аккаунтам работать одновременно (кто последний тот и папа, с сообщением отрубаемому что его послали с такого то IP)
5) отслеживание перескоков (например пол часа один IP потом другой, потом опять первый... (точнее — подсети)
6) к аппаратуре привязываться можно, но или в виде хорошо сделанного (типа хардлок) или совсем простого (типа привязка к серийнику тома харда)
7) сеансовик — идея неплохая, но он дается только один раз как начальный вектор, после каждого коннекта вычисляется следующая итерация наложения (с использованием того-же пароля входа), только нужно четко определять момент удачного логина для вычисления следующей последовательности.
8) Ну и административные меры, конечно... чуть какая трабла — наказывать, и менять ключи/серты. Как вариант — делать вид что ничего не произошло но на терминал похитителей выдавать "дезу" — всякий очень похожий на правду левак.
Это я все взял из своей жизни, ничего не напридумывал (кроме 7).

Здравствуйте, ribentrop79, Вы писали:

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

Здравствуйте, Сергей, Вы писали:

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

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

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

Здравствуйте, Аноним, Вы писали:

А>Гмм, значит насколько я понимаю, защите подлежит текущая информация на экране (как например терминал Reuter или DowJones).

Если это финансовая информация реального времени, значит клиент за нее платит. Раз платит, его право давать свой пароль кому угодно. А право владельцев сервера — следить, чтобы было только подключение по одному паролю. Второго просто не соединять. Элементарно.

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, Аноним, Вы писали:

А>>Гмм, значит насколько я понимаю, защите подлежит текущая информация на экране (как например терминал Reuter или DowJones).

А>Если это финансовая информация реального времени, значит клиент за нее платит. Раз платит, его право давать свой пароль кому угодно. А право владельцев сервера — следить, чтобы было только подключение по одному паролю. Второго просто не соединять. Элементарно.

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

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, Сергей, Вы писали:

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

А>

А>либо авторизация с жесткими мерами при разглашении пароля, либо фиксированный адрес, а еще лучше — и то, и другое сразу.

А>Чудненько. Если клиент оплатил этот сервис, то может дать пароль кому угодно. Надо только чтобы одновременно не могли подсоединится. Если же хозяин сервера заинтересован чтобы о его прайс листах все узнали, то он еще за баннеры обычно доплачивает. Какая-то мутная проблема. Одни прячут свои прайс листы, другие делают страшные усилия, чтобы их получить.

Проблема не очень мутная (хотя есть момент

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

Здравствуйте, Аноним, Вы писали:

А>Чудненько. Если клиент оплатил этот сервис, то может дать пароль кому угодно. Надо только чтобы одновременно не могли подсоединится. Если же хозяин сервера заинтересован чтобы о его прайс листах все узнали, то он еще за баннеры обычно доплачивает. Какая-то мутная проблема. Одни прячут свои прайс листы, другие делают страшные усилия, чтобы их получить.

Согласен, "Какая-то мутная проблема" непонятно толком даже что вообще на фирме автора топика хотят
сделать.
Защищать клиент -- маразм. Или вы торгуете клиентами? Тогда это маразм в квадрате,
но хоть понятна задача.

Защищать информацию? Ну так защита информации -- совершенно другая задача,
практически никак не связанная с защитой клиента от копирования. Будь он хоть
сто раз защищён от копирования -- потырить инфу может оказаться проще пареной репы. Хоть ручкой
переписать. И, блин, первый раз вижу, чтобы кто-то секретил прайсы на свои услуги.
Я бы при наличии более вменяемых конкурентов постарался не связываться с таким поставщиком.
К тому же я не спец в законах, регламентирующих торговлю, но есть смутное подозрение, что
секретные цены на свои услуги -- это даже не вполне законно, во всяком случае, магазины
запросто штрафуются за неправильный или отсутствующий ценник на товар.

Кстати, а как тогда ваши клиенты, да и вы сами перед налоговой собрались отчитываеться?

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

А>Проблема не очень мутная (хотя есть момент

А>Предположим вы продаете нечто с огромными прибылями (а фармацевтика это как раз оно самое), так вот, в каждом конкретном случае вы договариваетесь о цене (выставляете разным заказчикам разные цены), и совсем не хотите чтобы один заказчик знал по какой цене покупает конкурент (например аналогия с зарплатой — обычно стараются не афишировать кто сколько в организации получает денег, хотя какзалось-бы прайсы на раб-силу должны быть вывешены). Это большой бизнес, это не батоны с йогуртами в продмаге.
А>В общем разговор как-то утек от технической темы. Я спросил зачем это надо для того чтобы понять как решить проблему а не для того чтоб сказать "это вам не надо"

Вношу рацпредложение — опубликовать прайс и ввести скидки от объёма (ну, типа по первой колонке, по второй, по третьей — как в больших компьютерных конторах).

А иначе плодится толпа незаменимых менеджеров по продажам с индивидуальным подходом к клиенту.

Здравствуйте, Аноним, Вы писали:

А>>Проблема не очень мутная (хотя есть момент

А>>Предположим вы продаете нечто с огромными прибылями (а фармацевтика это как раз оно самое), так вот, в каждом конкретном случае вы договариваетесь о цене (выставляете разным заказчикам разные цены), и совсем не хотите чтобы один заказчик знал по какой цене покупает конкурент (например аналогия с зарплатой — обычно стараются не афишировать кто сколько в организации получает денег, хотя какзалось-бы прайсы на раб-силу должны быть вывешены). Это большой бизнес, это не батоны с йогуртами в продмаге.
А>>В общем разговор как-то утек от технической темы. Я спросил зачем это надо для того чтобы понять как решить проблему а не для того чтоб сказать "это вам не надо"

А>Вношу рацпредложение — опубликовать прайс и ввести скидки от объёма (ну, типа по первой колонке, по второй, по третьей — как в больших компьютерных конторах).

А>А иначе плодится толпа незаменимых менеджеров по продажам с индивидуальным подходом к клиенту.

Вам не стать очень богатым человеком ибо в торговле вы ничего не понимаете

	От:	ribentrop79
	Дата:	19.10.06 11:19
	Оценка:

	От:	Аноним
	Дата:	19.10.06 11:42
	Оценка:

	От:	Сергей
	Дата:	19.10.06 11:51
	Оценка:

	От:	ribentrop79
	Дата:	19.10.06 12:57
	Оценка:

	От:	ribentrop79
	Дата:	19.10.06 13:01
	Оценка: