Возникли следующие соображения. Шифрованный по DSC разговор по сути дела представляет собой обычный wav-файл, отXOR-енный шифрующей последовательностью. Зная эту последовательность, можно восстановить исходный звук. Следовательно, подавая на вход шифратора известный сигнал, можно вычислить эту самую последовательность, верно?
О чём подумалось: у большинства записей первые секунды – или молчание, или гудок 425 Гц (при исходящих звонках). Нельзя ли эту информацию принять в качестве заранее известной для извлечения шифра? Современные компы вроде довольно быстро должны просчитать варианты.

следовательно, поксорив два файла можно получить эту самую последовательность в готовом виде

Проблема в том, что особенно в случае гудка нам неизвестна его начальная фаза для получения правильного начала последовательности. Т.е. ксорить придётся много раз с разных точек, и как-то анализировать результат.

Восстановление потока путём XOR-а "молчания" описано в последней (за 2012 год) работе не без известного в этом вопросе Эрика Тюза.

Позволю себе большую цитату языком оригинала:

8.1 Outline of the Attack

The attack is executed in two phases: In the first phase, an encrypted call is passively recorded as
described in Section 5.1. If the call would be unencrypted, the attack would be finished after this step.
For encrypted calls, a second phase is executed, which decrypts the call.
The key idea in the second phase of the attack is, to use a replay attack against the phone to recover all
keystreams, which were used to encrypt the original call. This step can be executed with some delay,
so that an attacker can record some call first, and decrypt them later. However, he needs to be again
in communication range of the phone. We first set up our base station impersonating the original base
station of the victim. One can use the tool described in Section 5.5 to make the phone switch to our
base station. Checking whether the phone has locked on our base station can be done by periodically
broadcasting a LCE-PAGE-REQUEST[15] message from our base station. When the phone answers to the
LCE-PAGE-REQUEST, it has locked on our base station.

8.2 Recovering the Keystreams

In the next step, we need to set the correct cipher key on the phone, which was used in the call we would
like to decrypt. If no further call has been made and the phone was not switched off in the meantime,
we could skip this step. Executing the step will only cost less than a second of additional attack time. Of
course we do not know the key, otherwise, we could easily decrypt the call from our capture ourselves.
However, the key was derived from the UAK and two random numbers RAND_F and RS using the A11 and
A12 algorithms at the begin of the recorded call. We simply send again the AUTHENTICATION-REQUEST
message, which was exchanged at the beginning of the recorded call. The phone will respond with an
AUTHENTICATION-REPLY message containing the response of the challenge we send. This procedure is
described in Section 2.4.1.
If the response, which is included, is not equal to the response in our recording, we might have picked
the wrong phone, recorded incorrect data or the UAK on the phone has been altered. Therefore, the
following steps would be unlikely to succeed:
We now repeat the following procedure: Let n be the multiframe number of the first packet in our capture
that we have not decrypted so far. We wait just before our base station broadcasts the next update of
our multiframe number using a Q-channel message and set the multiframe number of our base station
to n − (t d /16). Here, t d is the time it takes from sending a CIPHER-REQUEST message to the phone until
ciphering is enabled in the MAC layer and the first encrypted packet from the phone is sent in 10−2
seconds.
Then we broadcast our multiframe number update and send a CIPHER-REQUEST[15] message to the
phone. The phone will receive our multiframe number update and update its multiframe number
accordingly. After having received our CIPHER-REQUEST message, the phone will respond with an en-
cryption control MAC layer message stating that it is ready to enable encryption. We now confirm that
using a MAC layer message and the phone will signal that it will enable encryption now. The next packet
sent by the phone will be encrypted using the same key as the original call and the same initialization
vectors (frame numbers) will be used. From now on, we do not send any payload to the phone and wait
until the LCE.01 timer on the phone has expired and the link is released. Because we have not estab-
lished a phone call on the link or did run any other application on it, the B-fields of all frames sent by
the phone just contained ff as plaintext. XORing all B-fields of the received frames with ff reveals the
keystreams used to encrypt the frames in the original call. XORing these keystreams with the B-fields in
the original call decrypts these B-fields, revealing the audio data sent from the phone to the base station
in the original call. We now repeat that procedure until all original call frames have been decrypted. A
good overview how keystreams are used to encrypt DECT packets is given in Figure 6.
After the call has been decrypted, we shut down our base station and the phone starts scanning for the
original base station and locks on it again.

tostera
Это не совсем то, данный метод заключается в подборе реального ключа и труднореализуем в первую очередь из-за того, что требуется принудительная блокировка излучения базы-"жертвы" и липовая авторизация трубки-"жертвы" на подставной базе.

Вчерашние новости: http://dect.osmocom.org/trac/dect/blog/kaber-2013/03/31/linux_38_merged
Как я понял, по существу ничего не менялось, к сожалению :(

Здравствуйте!
Заинтересовался данной веткой форума. В целях эксперимента приобрел карту
ASCOM voo:doo DECT PCMCIA Karte TYP III - COM-ON-AIR - dedected compatible
и переходник PCI to PCMCIA. Использую софт - Backtrack5 R3.
Все манипуляции с картой проводились строго по инструкции выложенной на
http://www.backtrack-linux.org/wiki/index.php/DECT_Sniffing_Dedected
В качестве подопытного использовался домашний телефон Panasonic KX-A143UAB.
После конвертации дампа кроме шума ничего неслышно. Отсюда делаю вывод о том, что телефон использует шифрование. Однако остается возможность неправильной работы софта (например кодека g72x), поэтому если у кого нибудь есть тестовый дамп для проверки данного кодека поделитесь пожалуйста :-)

Шифрованный по DSC разговор по сути дела представляет собой обычный wav-файл, отXOR-енный шифрующей последовательностью. Зная эту последовательность, можно восстановить исходный звук.

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

если быть уверенным в том, что шифрующая последовательность не становится новой каждые 20 миллисекунд
Постойте.. 20 миллисекунд? Это каждые 160 семплов? Не слишком часто?

20 миллисекунд? Это каждые 160 семплов? Не слишком часто?
именно. Потратив уйму сил и десятилетий на подбор этой последовательности, ты будешь наслаждаться прослушиванием аж целых 20 миллисек разговора. трудиться столько же ради ещё следующих 20 мсек желания уже не будет. эти ребята неплохо придумали.

Потратив уйму сил и десятилетий на подбор этой последовательности, ты будешь наслаждаться прослушиванием аж целых 20 миллисек разговора
Десятилетия уйдут, если ничего не знать о содержимом записи и тупо перебирать все варианты от сотворения мира. Однако в случае с DECT тишина и гудок 425 Гц в начале записи часто длятся секундами, а иногда десятками секунд. Бывают также не положенные часами трубки). Так что подобрать N раз по 20 миллисек будет несложно, а там глядишь и повторы начнутся ;)
Кстати, подобная атака успешно реализована немцами, только они как всегда держат подробности в секрете.

Уважаемые участники форума необходима помощь! Купил карту Telefonnica Type III, имеется ноутбук с PCMCIA. Но отсутствует программное обеспечение. ОС Chaox2009.7 не работает, ссылки на форуме на Chaox, так же не работают. Может быть кто-нибудь поделится рабочей версией Chaox. e-mail: geracl_83@mail.ru

Dominic
Поделись пожалуйста софтом для DECT, в инете нашёл, но не работает. Ссылки на форуме тоже не работают.

gen12
Не могу поставить Chaox2009, скинь ссылку если залил на торрент. С уважением.

Уважаемые участники форума необходима помощь! Купил карту Telefonnica Type III, имеется ноутбук с PCMCIA. Но отсутствует программное обеспечение. ОС Chaox2009.7 не работает, ссылки на форуме на Chaox, так же не работают. Может быть кто-нибудь поделится рабочей версией Chaox.

Зачем Chaox? В BackTrack 5 R3 эта карта работает без проблем. Использую ее на стационарном компьютере через переходник.
Ссылка на дистрибутив http://www.backtrack-linux.org/downloads/

Хотя если уж очень нужен то вот http://burnbit.com/torrent/155568/chaox_2009_7_iso

Linx
ОС Chaox2009.7 не работает
У меня работает. Ею и пользуюсь.

А вот не поделится ли кто хоть какой-нибудь рабочей сборкой Osmocom DECT (libnl+libdect+dectmon)? А то у меня чо-то все сборки битые, либо отказываются компилироваться, либо компилируются, но dect-llme-scan отказывается запускаться....

Все тут экспериментируют на сколько я понял с специфической "сетевушкой" на дектовскую частоту и портом PCMCIA, что влечёт за собой некоторую возню с добыванием нужных железяк.
Вот тут образовался сервис-мануал на довольно распространённый Панасоник, с блок-схемой, распиновкой и подобными вещами: Panasonic KX-TG7125 DECT - реально разогнать или нет?
Не проще ли будет превратить такой телефон в "сканер", подключив к компу управление радиомодулем и выход с демодулятора? Или вообще выпаять радиомодуль и подцепить его на подобии тв-тюнера KSH-148, задействованных выводов там немного.
Или это никому не интересно, по причине "паяльного гимора"?

Не проще ли будет превратить такой телефон в "сканер"
Чем купить на ебее карточку за 20 евро? Не проще.

Или это никому не интересно, по причине "паяльного гимора"?
А софт кто будет писать под этот паяльный гимор?

Arch
Спасибо, запустил и то и другое, только chaox немного тормозит, Back Track арбайтен!

Dominic
Какую карту по Osmocom DECT используешь тип II и
ли III.

Linx
Карта PCI.
Только последний раз у меня осмоком работал весной, до перестановки системы. К сожалению, старые исходники потёр. А свежие все с ошибками, из них не собирается. Но и с ними сайт вообще полёг в последнее время.

Dominic
Есть большое желание попробывать Osmocom, напиши пожалуйста какая конкретно карта. Попробую поэкспериментировать.

Linx
Карта Com-On-Air PCI, вот такая. Если найдёшь рабочую сборку Osmocom, поделись )

Dominic
Доброго времени суток!
Dominic подскажите при запуске chaox куда dump пишутся?
Dectshark при синхронизации автоматически dump пишет?

Linx
Приветствую. Дамп пишется туда, откуда вызвана dect_cli, по умолчанию на RAMDISK или как его там. Дектшарк пишет дамп по нажатию кнопки на нужной станции (не помню, то ли P, то ли S – методом тыка находил в своё время). Но надеяться на это особенно не надо, т.к. дектшарк не поддерживает хоппинга.

Я смотрю, проект Osmocom DECT благополучно почил? Жаль, жаль, многообещающие были планы.

Я тут на досуге накидал парсер для выходных данных сканера, с RFPI в читабельном виде и удобным табличным представлением:

А то заколебало каждый раз вручную разгребать эти текстовые файлики, которые скан выдаёт.

Dominic
Приветствую! Получилось свою базу записать!!!! Удача!!! Только с использованием BackTrack. Не могу USB с Chaox создать, пишет не найдено загрузочное устройство USB???!!!!! Использовал UNitbootin, PENDRIVE. Направь на путь истинный?

Dominic
Привет! Если загрузка с LiveCD, при записи возникает ошибка не могу записать dump file. Как решить, USB с Chaox не могу создать?

Linx
У меня комп вообще не умеет с USB грузиться, с этим ничем не могу помочь.

Dominic
Всё, разобрался!!!
Спасибо!!!
Работает!!!

Теперь понимаю для чего парсер накидал!

Просить неудобно, но всё же, не поделишься парсером.