У кого украли Webmoney и доступ к ним - давайте разберемся наконец-то?

Wine не поможет, нужно запускать полноценную вирт ось. Либо довольствоваться кипер мини.

Ставьте на ubuntu бесплатный vbox - там есть скриншот(snapshot) системы. И откатывайте каждый раз кипер, если что заметили.

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

Так нам эти данные и не нужны) Коллизии в алгоритме генерации кода еще никто не отменял) Даже приватного ключа и кода активации знать не требуется.

Например, засылаем жертве трояна, который мониторит переводы с кипера. Под каким-либо предлогом заставляем жертву совершить перевод в размере 200 руб. 00 коп. на кошель R301329629286 и в нужный момент трой подменяет сумму на 10001 руб. 00 коп.

Код подтверждения при этом не меняется, можете проверить (всей семьей ночью сидели перебирали, пальцы в кровь, кнопки на телефоне облезли 😂)

это всё чисто теоретически 😂

woff добавил 12.03.2011 в 09:17

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

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

И есть причины полагать, что enum беспокоится из-за подобных особенностей алгоритма. Так, например, в java-мидлете версии 3 по сравнению с версией 2 был увеличен размер приватного ключа в 2 раза и, судя по всему, введена задержка при генерации кода подтверждения (чтобы затруднить перебор?)

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

Но за инфу спасибо, очень интересно.

Не совсем понятна ваша мысль. Если трой подменяет сумму, код подтверждения еще ведь не выслан -как он может меняться/не меняться?

Или вы имеете ввиду, что будет послан следом второй перевод на тот же кошелек с большей суммой, который хакер подтвердит тем же кодом?

Смотрите, порядок действий, каким я себе его представляю.

Пользователь формирует запрос на перевод средств, указывая номер кошелька и сумму. Выбирает подтверждение через enum. Кипер от сервера enum получает число-вопрос. Пользователь через приложение генерирует код подтверждения, вводит его и нажимает "Далее". В этот момент трой подменяет сумму перевода и на сервер enum на проверку уходит уже другая сумма, но код подтверждения остается прежним и при этом корректным (возникла коллизия), поэтому enum говорит, что всё ok.

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

пс. Хотя, если посмотреть API, который предоставляет enum http://service.enum.ru/ (для корпоративных клиентов?), видно, что при использовании запроса GetChallenge (получить то самое число-вопрос) данные о сумме перевода на сервер enum'a не отсылаются. И проверка выполняется только запросом CheckUserAnswerTransaction ☝