2

Чтение технической документации и заумных лицензионных соглашений не дает никакой полезной информации, и трепанацией Keeper'а приходится заниматься самостоятельно. Как это можно осуществить? Самое простое – перехватить обмен Keeper'а с «базой», снифая трафик любым подходящим sniffer'ом, например, тем, что встроен в персональный брандмауэр SyGate Firewall, однако, если трафик зашифрован, его будет не так-то легко расшифровать!

Гораздо проще воспользоваться файловым монитором и монитором реестра Марка Руссиновича (оба можно найти на Windows Sysinternals: Documentation, downloads and additional resources), а также монитором шины Bus Hound от компании Perisoft (www.perisoft.com). Полезно также снять дамп с работающей программы любой утилитой по вкусу (например, PE-TOOLS) и поковыряться в нем на предмет интересных текстовых строк, MAC-адресов и прочих приватных данных. Самые опытные исследователи могут прибегнуть к тяжелой артиллерии — дизассемблеру IDA Pro, который покажет, чем на самом деле занимается Keeper при запуске и в процессе перевода денег. Естественно, полное дизассемблирование занимает слишком много времени, поэтому мы будем обращать внимание лишь на самые заметные, наименее замаскированные места, сразу же бросающиеся в глаза при анализе.

Внутри Keeper'а

Последняя версия Keeper'а проходила под номером 3.0.0.2 и занимала порядка ~1,9 Мб. После установке на диске в папке WebMoney образовалось множество файлов, среди которых были WebMoney.exe (пусковой файл, размером 183,024 байт, упакованный, по сообщению PEiD, протектором ASProtect 1.2x - 1.3x) и WWClient.dll (динамическая библиотека, реализующая основной функционал, размер — 3331,824 байт, не упакована).

Собственно говоря, WebMoney.exe можно сразу отбросить в сторону, не тратя силы на распаковку — все равно ничего интересного там нет. Но прежде нужно запустить монитор реестра и посмотреть, в какие ветви реестра лезет Keeper и не пытается ли он получить доступ к той информации, разглашать которую мы не хотим?

Даже невооруженным глазом видно, что сразу же после запуска Keeper ринулся определять имя чипа сетевой карты («AMD PCNET Family PCI Ethernet» в данном случае), имя машины («W2K»), и, если покопаться в дампе памяти, там можно обнаружить и MAC-адрес моей сетевой карты: 00-0C-29-F6-6C-3C (виртуальный, естественно). Кстати, чтобы узнать свой MAC-адрес, достаточно запустить штатную утилиту ipconfig c ключом /all (см. рис).
«Честные» программы не нуждаются в MAC-адресах и работают с сетью через TCP/IP-протоколы. Зачем же тогда Keeper'у потребовался наш MAC-адрес? А вот зачем! MAC-адрес уникален для каждой карты, и, хотя его теоретически возможно сменить на другой, даже без использования программатора, это считается веской уликой при расследовании преступления.

Значит, все-таки Keeper палит наш компьютер! И насколько глубоко? Берем в руки IDA Pro, загружаем WWClient.dll внутрь, и пока оно там дизассемблируется (а дизассемблироваться оно будет долго), достаем из заначки непочатую бутылку пива, затягиваемся сигаретой и думаем, думаем, думаем…

Лучше всего начинать анализ с поиска текстовых строк. Их легко найти в окне «Name Windows», вызываемом комбинацией клавиш <Shift-F4>. Тестовые ASCIIZ-строки начинаются с префикса «a». Действительно, здесь притаилось немало непуганой дичи:

Текстовые строки «pic_xxx», обнаруженные в Keeper'е

.rdata:1021ECB0 aPci_wmtid db 'pci_wmtid=',0 ; DATA XREF: sub_100901C0+C45o

.rdata:1021ECBC aPci_pursedest db '&pci_pursedest=',0 ; DATA XREF: sub_100901C0+CCCo

.rdata:1021ECCC aPci_pursesrc db '&pci_pursesrc=',0 ; DATA XREF: sub_100901C0+D53o

.rdata:1021ECDC aPci_amount db '&pci_amount=',0 ; DATA XREF: sub_100901C0+DDAo

.rdata:1021ECEC aPci_marker db '&pci_marker=',0 ; DATA XREF: sub_100901C0+E61o

.rdata:1021ECFC aPci_desc db '&pci_desc=',0 ; DATA XREF: sub_100901C0+EE8o

.rdata:1021ED08 aPci_datecrt db '&pci_datecrt=',0 ; DATA XREF: sub_100901C0+F6Fo

.rdata:1021ED18 aPci_modeTest db '&pci_mode=test',0 ; DATA XREF: sub_100901C0+FFFo

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

Поскольку виртуальные машины, в частности VM Ware, несут на своем борту довольно специфический набор оборудования и выделяют MAC-адреса из фиксированного пула адресов, становится ясно, как система распознает факт наличия виртуальной машины. Она просто сравнивает конфигурацию пользовательского оборудования с конфигурацией виртуальной машины, и, если они совпадают, электронный кошелек закрывается без предупреждений. Причем сравнение происходит не на клиентской, а на серверной стороне! То есть Keeper не просто опрашивает PCI-шину, но еще и передает эти данные в сеть, где они, по всей видимости, заносятся в банк данных, представляющий огромный интерес для спецслужб различных стран.

Штатные средства VM Ware не позволяют менять ни MAC-адреса, ни конфигурацию оборудования (в новых версиях вроде бы сделаны некоторые шаги в этом направлении, но не слишком радикальные). К счастью, есть неофициальная заплатка, позволяющая менять все, что угодно: http://honeynet.rstack.org/tools/vmpatch.c. Эксперименты подтверждают: после изменения конфигурации Keeper перестает распознавать VM Ware, и электронный кошелек больше не «палится».

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

Как вам нравится следующее? Keeper динамически создает драйвер citio.sys (на NT/W2K/XP)/citio.vxd (на 9x), тут же его загружает в память, а после удаляет:

Ссылки на неопознанный драйвер, обнаруженные в Keeper'e

.rdata:10222D5C aSystem32Driver db 'system32\drivers\citio.sys',0
.rdata:10222D78 aFileName db '\\.\citio',0

.rdata:10222D8C aSystemCitio_vx db 'system\citio.vxd',0

.rdata:10222DA0 a_Citio_vxd db '\\.\CITIO.VXD',0

3

С самим драйвером я не разбирался. Выяснил только, что он имеет размер 4048 байт и, по сообщениям на форумах, часто является источником многих проблем. Тут уже дело не в конфиденциальности, а в надежности и стабильности работы. Мастерить драйвера — это вам не прикладные программы писать. Малейшая небрежность/неосторожность превращается в сплошной геморрой. Зачем пускать к себе на компьютер заведомо некорректно написанную программу?!

«Источники, приближенные к кругам разработчиков» сообщили, что все эти драйвера вставлены вовсе не из-за пакости или желания навредить пользователю. Напротив! Они охраняют Keeper от нехороших программ, крадущих электронную наличность. Как говорится, все на благо пользователя, даже если это благо идет ему вопреки. Я повторяю еще раз: нормально спроектированный платежный клиент работает исключительно на прикладном уровне, а не вгрызается в систему, как бульдозер в асфальт. Если на компьютер проникла зловредная программа, захватившая администраторские права (а такие права заполучить очень легко), она может вытворять с Keeper'ом все, что угодно, и никакие драйвера не в состоянии ее остановить, поскольку, после того как зловредная программа загрузит свой собственный драйвер, она уровняет свои шансы с Keeper'ом, а в противостоянии двух драйверов обороняющаяся сторона всегда обречена на поражение.

Но не будем зацикливаться на текстовых строках и двинемся дальше. Посмотрим на список импортируемых API-функций. Для этого достаточно воспользоваться утилитой dumpbin.exe, входящей в штатную поставку компилятора Microsoft Visual C++ и Platform SDK. Вызываем ее («dumpbin.exe /EXPORTS WMClient.dll > output») и смотрим на результат:

Функции, импортируемые Keeper'ом (фрагмент)

Dump of file WMClient.dll

KERNEL32.dll

83 DeviceIoControl

353 Thread32Next

352 Thread32First

28C Process32Next

262 Module32Next

260 Module32First

204 Heap32ListNext

203 Heap32ListFirst

28A Process32First

6C CreateToolhelp32Snapshot

Функции семейства TOOLHELP32 (CreateToolhelp32Snapshot(), Process32First(), Heap32ListFirst(), Heap32ListNext(), Module32First(), Module32Next(), Process32Next(), Thread32First() и Thread32Next()) служат для получения списка процессов и потоков, имеющихся в системе. Только зачем Keeper'у знать об этом?! Чтобы «отлавливать» троянские программы?! Непохоже… Троянские программы меняют свои имена как перчатки, и к тому же никакого «черного списка» внутри Keeper'а нет. Судя по всему, он передает их на сервер, и умные дядьки смотрят: а каким, собственного, программным обеспечением мы пользуемся? И где гарантия, что, увидев OllyDbg, PE-TOOLS и прочие хакерские утилиты, они не ликвидируют наш аккаунт или не настучат «куда нужно»? Keeper – идеальное средство для удаленного наблюдения за миллионами машинами, тем более что своего любопытства он даже и не скрывает. Больше всего смущает наличие функций Heap32ListFirst() и Heap32ListNext(), выдающих карту памяти каждого из процессов.

А функция DeviceIoControl() — это вообще ласты. Ее основное предназначение — посылать драйверам специальные управляющие IOCTL-коды, с помощью которых можно напрямую читать или писать на диск. Поскольку разработчики никак не замаскировали ее вызов, все IOCTL-коды видны в IDA Pro как на ладони! Давайте разберемся, что же такого делает Keeper с нашим оборудованием, чего нельзя было бы сделать с помощью нормальных API-функций?!

Переходим в IDA Pro, нажимаем <Shift-F4> для открытия окна «Name», пишем «DeviceIoControl» (полностью вводить имя необязательно — IDA Pro сама поставит курсор на него, как только поймет, что же мы от нее хотим). Теперь нажимаем <ENTER> и оказываемся в секции импорта. По умолчанию IDA Pro отображает только первые две перекрестные ссылки. Чтобы увидеть остальные, необходимо в меню «View» выбрать пункт «Open subview», а там — «Cross references» или просто нажать <ALT-V>,<O>,<O>.

Первая же перекрестная ссылка ведет нас к следующему коду, который нам сейчас и предстоит дешифровать:

Фрагмент Keeper'а, вызывающий функцию DeviceIoControl

.text:100B76C3 push 0 ; lpOverlapped

.text:100B76C5 lea edx, [ebp+BytesReturned]

.text:100B76CB push edx ; lpBytesReturned

.text:100B76CC push 18h ; nOutBufferSize

.text:100B76CE lea eax, [ebp+OutBuffer]

.text:100B76D4 push eax ; lpOutBuffer

.text:100B76D5 push 0 ; nInBufferSize

.text:100B76D7 push 0 ; lpInBuffer

.text:100B76D9 push 74080h ; dwIoControlCode

.text:100B76DE mov ecx, [ebp+hObject]

.text:100B76E4 push ecx ; hDevice

.text:100B76E5 call dseviceIoControl

4

Прокрутив дизассемблерный листинг вверх, мы узнаем, что в переменной [ebp + hObject] находится дескриптор, возвращенный функцией CreateFileA(), которой скормили строку «\\.\PhysicalDrive%d». Очень интересно! Значит, перед нами код, напрямую взаимодействующий с жестким диском. Но как именно он с ним взаимодействует? Ответ скрыт в IOCTL-коде, равном 74080h. Все, что нам нужно, — перевести его в удобочитаемую константу, а для этого необходимо знать, как формируются IOCTL-коды, или воспользоваться online-калькулятором, доступном на Downloads:OSR Online IOCTL Decoder.

Вводим IOCTL-код в окошко «VALUE» и получаем полную расшифровку: Device – DISK (0x7), Function – 0x20, Access – «FILE_READ_ACCESS», Method – «METHOD_BUFFERED». Ага, значит, чтение. Ну хорошо хоть не запись! Однако запись еще впереди! Например:

Еще один фрагмент Keeper'а, вызывающий функцию DeviceIoControl

.text:100B7F63 push 0 ; lpOverlapped

.text:100B7F65 mov ecx, [ebp+lpBytesReturned]

.text:100B7F68 push ecx ; lpBytesReturned

.text:100B7F69 push 210h ; nOutBufferSize

.text:100B7F6E mov edx, [ebp+lpOutBuffer]
.text:100B7F71 push edx ; lpOutBuffer

.text:100B7F72 push 20h ; nInBufferSize

.text:100B7F74 mov eax, [ebp+lpInBuffer]

.text:100B7F77 push eax ; lpInBuffer

.text:100B7F78 push 7C088h ; dwIoControlCode

.text:100B7F7D mov ecx, [ebp+hDevice]

.text:100B7F80 push ecx ; hDevice

.text:100B7F81 call dseviceIoControl

Калькулятор говорит, что IOCTL-код 7C088h обеспечивает как запись, так и чтение данных с диска на секторном уровне в обход файловой системы и всех установленных ею ограничений. Возможно, что Keeper создает на жестком диске какой-то «тайник» или своеобразную метку, помогающую «людям в погонах» отождествить его. Или это просто Keeper так привязывается к оборудованию, чтобы его было нельзя запустить с чужого компьютера (скорее всего, так оно и есть, ведь WM Keeper не загрузит ключи на другом железе. — Прим. ред.)? Кто знает, полное исследование требует большой концентрации сил, ресурсов и времени, но вряд ли конечный результат стоит того, поскольку и без того ясно, что за зверь этот Keeper (а еще невинным муравьем прикидывается!).

Заключение

Мы выяснили, что Keeper Classic не только собирает (и отсылает) приватную информацию, но и отличается крайне агрессивным поведением. Скрываясь под аляповатым интерфейсом прикладной программы, он пробивает тоннель к самому центру операционной системы и делает это настолько некорректно, что у ряда легальных пользователей появляются серьезные проблемы.
(с) serev

А главное достойной альтернативы и нет пока, по моему.
Охватило все и теперь монополизирует в сети.

А если фаер настроить только на те порта на которые ты можешь зайти и все через эту машину
с Веб Мани.Я думаю более не нужно не чего.
И далее я об этом думал не только о Кеепе,но и о других программах.Это тоже проги которые по хлеще Трояна
могу т передать автору не только данные но и все остальное.
Так что по идее,не нужно пользоваться не чем кроме тех прог которые ты сам написал Выходит так как я понял

Статься довольно старая уже. В Хакере была вроде. Сам уже давно на Light перешёл с аутентификацией по сертификату. Так спокойнее, а то есть подозрения, что именно из-за этого *овнокипера classis, пару раз когда-то винда слетала.
А вообще любая крупная(да и не крупная) контора может такого в свой софт напихать. Хорошо хоть ещё антивирусы при срабатывании на Hacktool в отдел К отчёт не посылают, но думаю и этого доживём.

Я скажу вам что это не факт.Все может быть.кто знает.просто следят за всеми и все.а потом делают выводы