Це дуже схоже на звичайні побутові ситуації, коли одна людина не говорить про те, про що у нього питають, відповідаючи однозначно "так" чи "ні", а відповідає завжди "ні", і лише в один з вдалих моментів відповідає "так" .
Технологія передачі інформації за рахунок перебору являє собою передачу відносно невеликого обсягу інформації, можливо, що дає ключ до більш широким перспективам. Наприклад, ми можемо собі уявити перебір паролю на архів. Якщо ми його дізнаємося, то, власне кажучи, ми зробимо саме те, що хотіли, а заодно і дізналися ті кілька байт, які були для нас перешкодою - пароль!
Односторонній перебір.
Перебір архіву є прикладом одностороннього перебору, тобто ми одного разу підібравши пароль втрачаємо весь інтерес до подальшого перебору або перебору з самого початку. Такий перебір дає нам обмежену інформацію розміром навряд чи більше 16 байт, а скоріше близько 2-8. Подібний перебір не представляє особливого інтересу.
Двосторонній перебір.
Наше з вами завдання - отримувати інформацію за допомогою перебору. Двосторонній перебір на увазі під собою знання того ж початкового пароля і як наслідок - його використання.
Наприклад, уявімо собі інтернет-сайт із доступом до нього тільки після аутентифікації. Аутентифікаційні пароль може складатися тільки з одного байта, так що при використанні латинського алфавіту ми маємо. 66 комбінацій (a-zA-Z0-9). Отже, ми зможемо за 65 запитів однозначно дізнатися пароль, після чого можемо встановити свій.
Ось тут включається друга сторона і проводить аналогічні дії: перебирає пароль і максимум через 65 спроб його дізнається, після чого знову ж таки встановлює свій.
У цей час сам пароль буде носієм інформації. Тобто якщо наш перебір зупинився на 'j', значить, ми отримали 6 6іт інформації. Якої інформації - можна встановити за заздалегідь виготовленим таблицях або алгоритмам.
Найпростіший варіант - a = 1, b = 2, c = 3, ...
Застосування даного способу можна знайти наступне.
Існує внутрішній корпоративний сайт з обмеженим доступом в інтернет. У нього існує власна сторінка, яка доступна як з боку внутрішньої мережі, так і з боку інтернет. Сайт дозволяє виробляти аутентифікацію для перегляду деяких даних. Маючи Web інтерфейс для зміни пароля доступу до станиці і право на це, можна власне і влаштувати передачу інформації через форму введення пароля.
Подібні ситуації виникають нерідко. Наприклад, провайдер може надавати безкоштовний доступ до сторінки перегляду статистики, при цьому нічого крім цієї сторінки не працює. Такий же фокус використовують деякі підприємства, допускаючи всіх корпоративних користувачів лише до єдиної сторінці.
Даний спосіб найбільш універсальний, однак створює значно вужчий канал, ніж інші способи передачі даних через Web форми (та й будь-які інтерактивні елементи, що дозволяють зберігати будь-яку інформацію на стороні сервера, або будь-яких його посередниках).
Уявімо собі таку ситуацію: ви діалапнік, у вашого провайдера є сторінка з доступом до статистики і її деяким налаштувань, що зберігаються на сервері, наприклад, пункт про періодичність розсилки зі станом вашого рахунку. Для передачі інформації вам вже немає необхідності здійснювати перебір для перегляду цього параметра, тому що він висвічується як елемент ваших особистих налаштувань. Завдяки цьому ваша швидкість з передачі даних значно збільшується.
Що значить синхронізація передачі даних? Подумайте, як ви будете передавати інформацію, якщо у вас немає безпосереднього зв'язку з вашим скриптом. Інформацію треба через ЩОСЬ передавати. Ось тут ми і розглянемо механізми синхронізації передачі даних. У нас є серверна частина (з боку інтернет) і клієнтська (з боку корпоративної мережі). Серверна частина виконує наші запити, команди, а клієнтська їх задає. В обов'язки обох сторін входить відстежування стану. Візьмемо наш метод передачі даних через поле пароля.
Розглянемо наступний варіант. Домовимося, що пароль
"1" буде означати дефолтовую ситуацію, коли нічого не передається
"2" - початок передачі даних, запит.
"3" - підтвердження передачі, успішна передача.
З боку мережі встановлюємо пароль "2" (за замовчуванням був встановлений пароль "1") і періодично перевіряємо пароль.
Сервер, побачивши, що пароль став "2", у свою чергу підтверджує це установкою пароля "3". Це значить, що він прийняв наш сигнал і готовий до отримання запиту.
Ми перевіряємо це подія перевіркою пароля, і якщо пароль дорівнює "3", то тепер настала черга передачі даних. За один раз ми передамо 1 біт, а запит може бути, наприклад, з 20 байт. Ми встановлюємо пароль "a".
З боку сервера відбувається наступне. Сервер робить перевірку, чи встановлений пароль "a" або "b" (якщо жоден з них не підходить, то перевіряється пароль "1", що означає кінець передачі даних). Виходячи із значення пароля, робиться висновок, прийшов біт 1 або 0 - тобто ми передали сервера 1 біт.
Після перебору сервер встановлює пароль "2" - сигнал, що потрібно передати наступний біт.
Передається наступний біт.
Після закінчення передачі клієнт встановлює пароль "1" і тепер починає працювати в режимі сервера.
У цей час сервер, отримавши запит, виконує його (наприклад, завантажує вказаний УРЛ).
Після скачування даних сервер виставляє пароль "2", а клієнт чекає цього пароля.
Отримавши пароль "2", клієнт встановлює пароль "3".
Сервер, визначивши, що вже встановлений пароль "3", починає побітове передачу. А ми підтверджуємо кожен біт установкою пароля "3".
Існує дуже багато можливостей реалізувати даний трюк, проте всі ці можливості настільки різноманітні, що написати якийсь універсальний движок буде досить складно. Наприклад, для одного з місцевих провайдерів існує спосіб передачі до себе інформації по каналу шириною в 2 бита за 1 запит, а у зворотний бік можна використовувати досить широкий канал шириною близько 24 байта.
Передісторія знаходження подібного збоченого методу передачі інформації досить невесела. Вечорами і ночами я працював в місті Норильську, обслуговуючи одну з місцевих контор, план робіт давно закінчив, а робити було нічого, от і згадав про провайдерів далекого Уралу.
До даної техніки намагався написати движок на Perl, але часу не вистачило, проте дещо залишилося.
При передачі інформації таким шляхом необхідно:
Шифрувати інформацію
Упаковувати
Звичайно ж використовувати rar для такого не будеш, і тому мені допоміг друг, провівши тести архіваторів.
Результат виявився передбачуваний:
ASS GZ 48
ASS BZ2 51
ASS LZH 54
ASS RAR 98
ASS_ ZIP 118 / / winrar zip
ASS 7Z 119
ASS ARJ 121
ASS ZIP 130 / / 7z zip
ASS 512
Вміст файлу ass:
asasasasasasasasasasasasasasasasa
asasasasasasasasasasasasasasasasa
asasasasasasasasasasasasasasasasa
asasasasasasasasasasasasasasasasa
asasasasasasasasasasasasasasasasa
asasasasasasasasasasasasasasasasa
asasasasasasasasasasasasasasasasa
asasasasasasasasasasasasasasasasa
asasasasasasasasasasasasasasasasa
asasasasasasasasasasasasasasasasa
asasasasasasasasasasasasasasasasa
asasasasasasasasasasasasasasasasa
asasasasasasasasasasasasasasasasa
asasasasasasasasasasasasasasasasa
asasasasasasasasasasas
Режим движка "Очікування запиту".
Алгоритм наступний:
Запускається модуль, що виробляє очікування запиту (все залежить від типу пароля або методу передачі (не виключена можливість передачі засобами XSS атаки, як це реалізоване в одного з Уральських провайдерів)).
При отриманні запиту відбуваються операції, аналогічні 4-8.
Виконується запит до Інтернету (так, ці пункти швидше будуть у движку, тому що вони виробляються звичайним чином, наприклад, за допомогою бібліотеки LWP).
Приймається відповідь з Інтернету.
Упаковуються дані.
Зашифровуються дані.
Запускається модуль відправки результату, який і приймає відповідні дані.
Бібліотеки, які я вам раджу для розробки: LWP, Comdivssed:: ZLib, MIME:: Base64.
Мабуть на цьому можна зупинитися. Хочеться додати лише приклади збочених методів передачі:
передача інформації за рахунок лічильників відвідин (потрібен контроль за правильністю передачі, адже не виключені заходи інших користувачів);
аналіз затримок відповіді сервера (можна штучно створювати незначні затримки з будь-якого боку різними методами);
в деяких випадках передачу даних можна здійснювати за рахунок сесій (номери яких зазвичай зберігаються у клієнта в куках).