Взлом протокола Радмина. Помогаем автору
 

В начале немного о радмине (для исследования применялся метод тыка :))...

- Сервер хранит хэш пароля в реестре:
HKEY_LOCAL_MACHINE\SYSTEM\RAdmin\v2.0\Server\Param eters
"Parameter"=hex:02,ba,5e,18,7e,25,89,be,6f,80,da,0 0,46,aa,7e,3c // Пароль 12345678 ;)
Пароль шифруется алгоритмом MD5, причём сначала пароль дополняется нулевыми символами до 100 символов, тока потом шифруется
Проверил... работает!! :)

- В справке по радмину говорится:
"Radmin работает в режиме шифрования...все данные передаваемые между компьютерами...шифруются случайно генерируемым ключем. Используется 128 битный Twofish алгоритм..."
Думаю мона поверить разработчикам... Или нет!?

Запускаем сниффер, допустим Ириску...
Содержимое пакетов (данные в hex) при авторизации по паролю:

1) Клиент: 01 00 00 00 01 00 00 00 1B 1B - 10 байт
2) Сервер: 01 00 00 00 21 A8 99 B4 A7 1B 2A 5F 62 5E 69 EA 5E 82 8C 1D 41 63 1E F7 B7 10 B7 9D 7D D2 0F 92 97 E8 C1 59 82 2E ED B1 56 51 - 42 байта
3) Клиент: 01 00 00 00 21 89 2D 73 BC 09 5D 00 4E F9 3A CF 71 13 EA B4 D0 B0 F0 A8 F8 F7 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 - 42 байта
4) Сервер: 01 00 00 00 01 00 00 00 0A 0A - 10 байт

Предположение:
1) Похоже на обычную команду с кодом $1B1B, предложение на авторизацию
2) скорее всего ключ для шифрования пакетов
3) Введённый пароль!!! А точнее его хэш (по логике MD5 хэш, как и в реестре у сервера), т.к. размер ответа ВСЕГДА 26 байт (не считая 16 нулей).
4) Результат авторизации, $0A0A - всё в порядке, $0B0B - неудача :(

Написал на делфи переборщик для "ключа" (2) и "зашифрованового пароля" (3)... использовал компонент TDCP_twofish.
При расшифровки (3) ключом (2) ожидалось найти MD5 хэш пароля 12345678: 02 ba 5e 18 7e 25 89 be 6f 80 da 00 46 aa 7e 3c
Ничё не получилось :(... Почему?

- Может передаётся по сети не MD5 хэш пароля, а какой-нить другой, но точно хэш :)
- Может трафик шифруется не 128 битным Twofish

Если ты знаешь больше или я где-то ошибся, напиши плииииииииииииз!!!!

Так, интересно...
Заметь, 01 00 00 00 подозрительно повторяеться. Возможно сам ключ лежит в байтах ПОСЛЕ повтора, или ещё дальше.

Вполне возможно.

Регился на 8 форумах, там народ ваще вялый, похоже antichat рулит :)
Так что давайте мозговать!!!
Попробуйте тоже поснифать трафик, разобратся в кодировках.... Кста пробовал запускать клиента радмина из отладчика (Olly debuger), ставил брики на вызовы функций, но ОЛЯ что-то глючила :(.

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

Если разберёмся с шифрование сетевого трафика, я смогу написать прогу, чтобы мона было авторизоватся по хэшу пароля....
ЖДу ваших наработок и предложений!! ;)

хай, а может не хеш отправляетса, а сам пароль ???
если на CPAN есть модуль для Twofish то вечерком проверю

Именно хэш!!! потому что длина пакета постоянна.
ОТкрой в радмине "обмен файлами"...поснифать трафик именно этот трафик....при расшифровке пакетов стремись получить имена папок, в которые заходил радмином!

Глюкс Не знаеш где спецыфикацыя ТуФиш лежыт а то почитать охота ????

Незнай....найдёшь кинь линку.... я скачал компоненты для делфи DCPCrypt2, там есть реализация TwoFish-а!

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

Сервер: 01 00 00 00 | 21 | 2F 19 31 2F | 1B | 09 86 BE C7 5C 68 00 E9 16 9B 0B DD 18 87 BB 81 85 94 E4 EA C5 A8 D0 DF DD 04 1F C0 71 C6 D4 7D
Клиент: 01 00 00 00 | 21 | FA E2 1E 80 | 09 | C3 B8 19 A2 BA D5 B1 FE CF 45 A2 A1 D0 0D 8D 36 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Сервер: 01 00 00 00 | 21 | EE E1 B0 2D | 1B | 07 F3 66 3D E1 53 24 45 BD 9E 78 61 FC 2B 88 A2 EC EE A3 00 30 76 A2 3D BD D6 65 57 33 94 B6 F9
Клиент: 01 00 00 00 | 21 | 09 14 45 1F | 09 | 0E 68 FE 09 FF 6B B0 BB 9E 3F DB 4C 99 00 7F 06 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

И всё таки шифрование смахивает на связку TwoFish + MD5... в пакете от сервера есть 32 случайных байта (если захешировать ключ, то получим новый ключ размером 16 байт = 128 бит), а у клиента 16 байт (нули не считаем :)) - размер хэша MD5, MD4 и т.д.
Не могу понять зачем в каждом пакете есть 4-байтовое случайное число (2F 19 31 2F, FA E2 1E 80.... )????????????????????????????
GluckX задумался..........

Прошла ещё одна бессонная ночь....

До меня дошло зачем эти числа :), немного математики...
Рассмотрим два ответа клиента:
01 00 00 00 21 | Fa E2 1e 80 | 09 | C3 B8 19 A2 Ba D5 B1 Fe Cf 45 A2 A1 D0 0d 8d 36 <нули>
01 00 00 00 21 | 09 14 45 1f | 09 | 0e 68 Fe 09 Ff 6b B0 Bb 9e 3f Db 4c 99 00 7f 06 <нули>

Предположим, что первые 10 байт - это заголовок, а остальные байты - это данные... и так, если просуммировать все 4-хбайтовые слова данных, учесть переполнение, поменять местами 1 и 3 байты слева местами, получим:
1) C3b819a2 + Bad5b1fe + Cf45a2a1 + D00d8d36 = 31de0fb77 -> 3 | 1d E0 Fb 77 -> 1d E0 Fb 7A -> Fb E0 1d 7A = Fa E2 1e 80
2) 0e68fe09 + Ff6bb0bb + 9e3fdb4c + 99007f06 = 245150916 -> 2 | 45 15 09 16 -> 45 15 09 18 -> 09 15 45 18 = 09 14 45 1f

Числа Fbe01d7A и Fae21e80, 09154518 и 0914451f похожи ;)... Получается, что эти числа контрольные суммы, точный алгоритм вычисления я не искал за ненадобностью, но он нам нужен будет, когда начнём менять данные в пакете ;)

Есть ключ 09 86 Be C7 5c 68 00 E9 16 9b 0b Dd 18 87 Bb 81 85 94 E4 Ea C5 A8 D0 Df Dd 04 1f C0 71 C6 D4 7d и зашифрованные данные C3 B8 19 A2 Ba D5 B1 Fe Cf 45 A2 A1 D0 0d 8d 36.... перебераем варианты алгоритмов шифрования %)

GluckX, я понимаю, что разобрав протокол по косточкам, можно сделать что угодно.

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

Таким образом, задача сводиться к написанию программы, которая снифает траф(желательно АРП-пойзонингом), запоминает и дублирует его. Возможно, потребуеться спарить её со стандартным клиентом радмина(лучше 3-й версии) для более удобного юзания.

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

Как думаешь? Это проще и вполне достижимо(но я не потяну, слабо)