попытка записать файл в формате рсар
у кого есть установленный софт от dedected.org
могут попробовать его открыть
пример телефона который включает шифрование не
сразу а примерно через 1 сек после усановления
связи
http://www.radioscanner.ru/uploader/2009/pcap.zip

Кстати готовый девайс по теме: http://www.kobra.su/OtklikD.html?PHPSESSID=1659ef03d9f273026bb2e59c9f9feda2

Вес центрального блока в 18 кг скорее всего состоит в основном из веса пелика и металлических рам с пластинами.
хотя тем не менее имеется вентиляция, а управление от ноутбука.
Значит железка внутри всётаки ощутимая.
Короче не ясно из чего оно там внутри состоит.

да размер и вес немаленький
наверняка это блок криптоанализа такой большой

ysmat

У Вас что-то не так с файлом pcap, Wireshark не может его открыть.

Дядьки с dedected.org отреверсили DSC.

http://img14.imageshack.us/img14/9674/dsc01425vq.jpg

Обещали публиковать результаты в середине января.

так что это на рисунке
генератор ключевого потока ?

использовать трубку Siemens Gigaset в сервисном режиме.

Для этого нужно выключить трубку. Нажать и удерживать клавиши 1, 4, 7, включить телефон. На экране появится текст "Handset Service", код для трубок 3xxx
серии 46395. Для трубок 4ххх серии код 76200.
Если код набран верно, появится сервисное меню. Выбираем режим "Metering Mode", нажимаем OK. Этот пункт будет помечен галочкой. Снова выключить телефон.
После включения увидите строку формата AAA-B-CC-DDD-EEE,
например,
038-4-08-089-100. Это следующие параметры
AAA - RX sensivity from 0 – 100
(038 - about 20m from BS)
B - DECT channel number
(4 - is 1890,432 Mhz)
CC – timeslot
(08 TX 16 RX)
DDD - BS identification code (RPN)
(089)
EEE - bit error rate (RFAQ)
(100 %)

Чтобы вернуть телефон в обычный режим, нужно снова зайти в сервисное
меню, снять галочку у "Metering Mode", выключить и включить аппарат.
-------------------------------------------------------------------------

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

С вч блока идёт RXD, вот только я не понял, как с синхронизацией, в смысле, кто ведущий- вч-блок или процессор. Если тактовую генерирует вч блок, без участия самого проца трубки, то этот вывод будет выдавать данные сам по себе .всегда.лишь бы трубка стояла на нужном канале.
Хуже, если для вытягивания приёмных данных из вч блока нужны команды проца.

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

Яумаю, даже можно ещё проще сделать. Наверняка трубка, не видящая своей базы (например, база отключена), будет всё время бегать по каналам и искать её. Подаём сигнал RSSI с вч блока на компаратор, и если он высокий, то сигналом с выхода компаратора шунтировать на землю 3-проводную шину управления синтезатором (чтоб не спалить проц, врезать в шину резисторы 200 ом, как это делалось в панасониках 9080), и всё, приёмник остановился. Надеюсь, что в этот момент с выхода данных вч блока будет идти принимаемый сигнал.

Да, чуть не забыл.В отличие от базы, трубка включается прерывисто.Надо найти этот сигнал включения питания трубки и сделать его постоянным. Или всё выше написанное проводить на базовом блоке.


или даже вот такой эксперимент поставить: установить связь трубы с базой, потом во время сеанса выключить базу (или трубку), а в оставшемся работать девайсе принудительно продолжать удерживать в высоком уровне сигнал RSSI, то он начнёт принимать и декодировать все другие базы(трубки), что работают на этом же канале (правда , не знаю, как насчёт слота, видимо, будет слушать на том, котором была)

Что скажете?

А что касается темы, то олько что прочитал:

"Выпускаемые ранее и всё ещё находящиеся в обращении некоторые модели беспроводных телефонов не используют шифрования и могут быть < прослушаны > с помощью несложного радиооборудования на расстоянии до нескольких километров.

В связи с этим в 1992 CEPT, предшественник ETSI (Европейский Институт Стандартов Телекоммуникаций) предложил к использованию стандарт < DECT > (Digital Enhanced Cordless Communications). Практически все телефоны, используемые в Европе, защищены сейчас в соответстии с этим стандартом.

Стандарт включает два патентованых (дословно "проприетарных") алгоритма: < DECT > Standart Authentification Algorythm (DSAA) и < DECT > Standart Cipher (DSC) – соответственно для обеспечения аутентификации и защиты данных. Эти алгоритмы были доступны только на основании подписки о неразглашении и поэтому не были темой для академических исследований.

Ранее алгоритм DSAA был подвергнут реверс-инжинирингу (обратной реконструкции путём дизассемблирования оказавшихся у исследователей драйверов программной реализации < DECT-оборудования >) авторами работы о которой пойдет речь далее. Также ими был создан открытый драйвер для PCMCIA < DECT > карт.

Stefan Luks (Bauhaus University Weimar, Германия), Andreas Schuler (Chaos Computer Club Trier, Германия), Erik Tews (FB Informatik, TU Darmstadt), Ralf-Philipp Weinmann (FSTC University Люксембург) и Matthias Wensel (Chaos Computer Club, Мюнхен, Германия) опубликовали работу "[Вы - гость, Вы не можете просматривать ссылки. Регистрация / Login]".

В ней они проводят полный анализ DSAA, включающий нахождение уязвимостей, которые могут полностью скомпрометировать аутентификацию и осуществить полный взлом системы безопасности < DECT >, а низкостоимостные атаки позволяют незаметно подменить атакующему базовую станцию и < прослушивать > все переговоры.

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

Самым простым типом атаки оказался спуфинг аутентификационных запросов, при помощи модифицированных драйверов для PCMCIA < DECT > карт и анализа ответов при помощи DECT-снифера, также написанного авторами для GNU-Radio. Ошибочно выполненный генератор псевдослучайных чисел использует всего 24 бита энтропии вместо 64 битов. Это позволяет атакующему сгенерировать все варианты случайных запросов и сохранить их в файле размером всего 68 мегабайт. Поиск по такому файлу не составит труда.
После глушения большим количеством пакетов с запросами в течении короткого отрезка времени телефон переключался на подставную базовую станцию с вероятностью 50%. Никаких предупреждений или сообщений об ошибках на телефоне не высвечивается.

Данную атаку также удалось повторить с использованием беспроводных LAN-карт со специально написанными < DECT-драйверами > под Linux. Стоимость атаки, позволяющей перехватывать, записывать и перенаправлять звонки, таким образом равна стоимости дешёвой беспроводной LAN-карты. Возможно также использование беспроводной карты в режиме полностью пассивного < DECT-снифера >. Информация об этом выложена на сайте http://www.dedected.org.

Как сообщает комманда проекта dedected в своём блоге: "Оборудование для < прослушивания > радиотелефонов может быть спрятано в небольшой сумке, поэтому уголовное преследование за такие действия непрактично. Стоимость атаки также очень невелика. Для всех пользователей < DECT > технологии и на основании анализа всех полученных нами образцов устройств мы можем лишь сказать – если вы не хотите превратить свои разговоры по радиотелефону в радиостанцию публичного вещания – вам большое и жирное предупреждение "Не используйте DECT!".

Сам протокол DSAA оказался спроектирован на удивление небезопасным образом. Средние 64 бита выхода DSAA зависят только от средних 64 битов ключа. Это приводит к тривиальным атакам на DSAA, когда 128-битный ключ вскрывается за 264 операций.
Хуже того, безопасность DSAA полностью опирается на безопасность шифра cassable. Анализ показал, что он тоже на удивление слаб. Cassable представляет собой каскад из четырёх похожих шифров. Сами шифры по отдельности тривиально взламываются с помощью дифференциального криптоанализа с помощью небольшого числа подобраных открытых текстов. Авторам удалось сконструировать атаку на полный шифр cassable за 246 и при оптимизации 244 операций.

Слабость алгоритма не была показана в официальных документах ETSI. Дифференциальный криптоанализ, представленный авторами полностью взламывает
шифр, положеный в основу алгоритма < DECT > и позволяет потенциально снизить стойкость за пределы менее 64-битного уровня безопасности при минимальных расходах памяти.

Представители интересов организаций, представляющих стандарт < DECT > несмотря на предупреждения авторов об уязвимости с 2008 года не предприняли никаких мер по защите стандарта, а лишь ограничились угрозами уголовного преследования в случае публикации средств взлома. Исследователи же отклонили подобные обвинения, заявив, что используют присланные спонсорами и добровольцами образцы телефонов, но сами не занимаются незаконным < прослушиванием > чужих разговоров, что наказывается в Германии сроком заключения до 5 лет. Кроме того, на основании ставшей известной информации о протоколе < DECT написать и распространить соответствующие программные средства не составит труда всем желающим специалистам буквально в течении получаса, несмотря на все запреты.

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

На сегодя же, даже если протокол DECT и может обеспечить максимум 64-битный уровень безопасности, что может остановить слабого атакующего, но в текущих вариантах полностью уязвим перед атакующим с PCMCIA картой за 30$.
"

прошивка моего приемника
управление модулем pmb 6610
http://www.radioscanner.ru/uploader/2010/dect51.zip

единственная проблема маленькая дальность
через 2 этажа уже не пробивает выпадение фраз слушать практически не возможно
не понятно почему так происходит
к примеру дис пульты управления сигналки авто 433Mgц можно услышать на самодельный p-45
вплоть до километра
почему же dect так слабо проходит
неужели там мощность меньше чем в етих брелках

Ну у пультов и частота чуть ниже (затухание меньше), да и полоса, вродь как, уже при сопоставимой мощности.

единственная проблема маленькая дальность
через 2 этажа уже не пробивает выпадение фраз слушать практически не возможно
не понятно почему так происходит

Очень просто.Дело в том, что в протоколе декта предусмотрен лишь механизм обнаружения ошибок (CRC), а вот средств исправления ошибок путём введения в сигнал избыточной информации, необходимой для математического исправления,не предусмотрено в данном стандарте. (Кстати, это является одной из проблем , возникающих при попытках увеличить дальность дектов, помимо мЕньшей длительности слота)
И, наскольлько я понимаю, скорее всего нет в декте так же и скремблирования передаваемых данных, которое позволило бы превратить групповые ошибки в одиночные битовые,легче поддающиеся исправлению.(благодаря "размазыванию")

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

рошивка моего приемника
управление модулем pmb 6610
http://www.radioscanner.ru/uploader/2010/dect51.zip

можно по-подробнее? на базе чего сделан приёмник, что нужно паять, используется ли железо самой трубки или только её вч блок? программа зашивается в проц трубки или на этот проц навешивается дополнительный контроллер-костыль? если да, то какой? Хотелось бы узнать,чтоб попытаться повторить ваш эксперимент

скремблирование (размешивание) есть без него
радиоблок не будет работать так как
его модулятор не пропустит длинные очереди одинаковых битов
береш радио модуль с pmb6610 с трубки записываеш скомпиленный hex
в at89s51 подпаиваеш проводки к нему ну и все

береш радио модуль с pmb6610 с трубки записываеш скомпиленный hex
в at89s51 подпаиваеш проводки к нему ну и все
я так понял, используется аудиотракт самой трубки? в самой плате трубки нужно резать дорожки, что-то удалять/добавлять?
После этого трубка работает только в модифицированном режиме или он включается "волшебной"комбинацией с клавиатуры?
схему подключния бы глянуть. И какая частота кварца нужна на контроллер?

нет аудиотракт на плис и кодеке g.726 сделан

так как
его модулятор не пропустит длинные очереди одинаковых битов
а короткие очереди одинаковых битов (два-три-четыре нуля или единички подряд), значит, всё же бывают. Отсюда у меня возникает вопрос в случае самостоятельного снятия цифрового потока с демодулятора- как мне восстановить тактовую частоту битов? поставить генератор с фапч, подстраиваемый по переходам через ноль , который благодаря инерционности фапч может проскакивать через недостающие переходы через нуль? или это надо делать кк-то иначе?
Или же в дектах перед подачей нудей и единиц на модулятор проводится канальное кодирование (например, манчестерское, или DMI)? если да, то какое? или же всё идёт на модулятор "как есть", то есть в коде "без возврата к нулю"? Это важный момент, кстати.

на более низких частотах я с помощью программ, написанных мной для PIC16F84 ,довольно успешно декодировал кодовые посылки дальнобойных радиотелефонов, но там была небольшая скорость 1200 бит/сек, а вот сделать то же самое с одномегабитным потоком , не знаю, удастся ли мне.. слишком уж скорость большая. Хотя, если взять какой-нибудь контроллер с тактовой частотой порядка 80 мгц, что-нибудь из серий PIC24 или PIC32, может, и получится.Только надо бы знать тип канальной модуляции.
Замечено мной, что ЧМ с небольшим сдвигом частоты декодируется хуже , это было, когда я пытался декодировать каналы управления московской сотовой, где частоты "нулей" и "единиц" отличались не в два раза, а в полтора. Если ещё меньше, то мне наверное не удастся вообще надёжноо отделить нули от единиц. А в декте GFSK, как раз с малым сдвигом..

в нутри pmb6610 уже стоит демодулятор с компаратором поетому на выходе
стандартный лог уровень 3v
стандартная длительность 1 бита у dect 900нс
но в реале эта длительность может гулять особенно если принимаеться
сигнал чужого телефона на который компаратор не настроен
или к премеру идет 0000001000000
единица в таком случаи может быть всего 500нс
а если компаратор совсем перекошен то и не быть вовсе

к премеру идет 0000001000000
единица в таком случаи может быть всего 500нс


А как синхронизироваться? как восстановить "недостающие" тактовые перепады?вот об этом я и завёл разговор, так как если не восстановить тактовую часоту битов, то можно и неверно сосчитать количество, например, нулей в приведённом выше примере. Может, нужно что-то вроде цифровой ФАПЧ.. Или здесь как в RS-232 или 1-Wire, то есть, вцепился в первый же перепад и от него отсчитываещь по 900нс, но так будет накапливаться временная погрешность и можно запросто сползти с временного битового интервала. (когда я декодировал POQSAG, у меня это получалось, но часто сбивался, там могло теоретически встретиться до 22 подряд идущих нулей или единиц до ближайшего перепада, по которому можно снова подстроиться)Я вот об этом. Как считаете, что тут лучше сделать?
Интересно, какую процедуру использует штатный проц телефона?

вообще, я , занимаясь этим на более низких частотах(р/т сенао, саньё) всегда отмечал, что в цифровом сигнале, принятом из эфира, длительность принятых нулей и единиц "плавает", и фронты здорово размазаны бывают, что приводило к отклонениям длительности от ожидаемой чуть ли не на 30%
хотя по идее, такого не должно бы быть, ведь на передающей стороне всё кварцовано.
Приходилось в декодирующей процедуре ставить широкие "ворота", и была ещё одна проблема, когда случались ситуации, где определить отдельный бит -ноль или единица, можно было лишь с вероятностью 50%. что вообще никуда не годилось. Если же с целью тестирования такой же сигнал подавался не с эфира, а непосредственно, то всё декодировалось 100%
С эфира же головная боль иногда с распознаванием. А в приёмниках, имеющих контур дискриминатора с катушкой, даже малейшее изменение положения сердечника в этоцй катушке приводило к росту ошибок в работе моего алгоритма декодирования, потому что скважность импульсов типа 1010101010 с выхода демодулятора становилась отличающейся от двух..

да ета проблема серьезно мешает нормальному декодированию
но в пакете dect есть синхрополе помогающее правильно определить скважность
в начале пакета всегда передаеться AAAAE98A то есть впереди идет 1010101010101010
для того чтобы можно было определить длительность 1 и 0 для данных условий

да ета проблема серьезно мешает нормальному декодированию
но в пакете dect есть синхрополе помогающее правильно определить скважность
в начале пакета всегда передаеться AAAAE98A то есть впереди идет 1010101010101010
для того чтобы можно было определить длительность 1 и 0 для данных условий

А как выбрать пакет, относящийся к конкретному номеру слота? в каких-нибудь его полях указывается номер слота? по идее, должен, скорее всего

Господа специалисты, подскажите пожалуйста ! Телефонный номер передан на 4 км с использованием фиксированной коробки Siemens Dect Link RNT-1. Должна ли работать услуга Coller ID или нет ? У провайдера элетронная АТС, но техподдержка тупит. На проводных линях у них данная услуга работает, но есть сомнения, что через канал DECT услуга будет работать.

дубль

и даже выяснив по синхропоследовательности длительность единичного и нулевого бита, у меня нет уверенности, что я не собьюсь при приёме пакета из нескольких сотен бит. Мне до этого приходилось писать декодирующую процедуру для пейджеров (там тоже на выходе детектора шёл код БВН , в котором в начале шла преамбула 10101010101 (575 бит),далее шел сам код,расстояние между двумя перепадами могло принимать значения, отличающиеся друг от друга от 2 до 32 раз), но там было всего 512/1200 бит в секунду. А здесь мегабит...
Даже при наличии высокоточного тактового генератора контроллер моего декодера может ошибиться с выбором момента съёма данных, так как частоты двух генераторов никогда не бывают полностью идентичными. Опасаюсь, что при высоких скоростях обмена данными и длинных последовательностях единиц или нулей небольшое рассогласование тактовых частот может привести к ошибке в целый такт и, соответственно, считыванию некорректного значения бита.

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

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