ARV

золотой вы мой человек!!!! приду домой - прошерстю все накопленные массивы - это ведь будет просто счастье, если вы правы!!! я-то тупил на байте 12 перед 4-я последними - он всегда и во всех пакетах на одном и том же месте...

Я хоть и в винде сижу, но свои 5 копеек в тему вставлю :) Пользуюсь Eclipse с его встроенными автогенераторами makefile. В настройках прописываю пути к разным версиям тулчейнов, и все прекрасно собирается. Беда только с тем, что утилита avr-size от версии к версии меняет свои свойства по умолчанию и команды в комстроке, в итоге иной раз не работает, либо выдает в неудобном виде. Эту проблему решил тупым копированием "удобной" версии во все версии тулчейна. Получилась в этом отношении каша, но все остальное достаточно удобно.

Я умом понимаю сложность задачи... но надеюсь еще пока на успех. Не знаете какой-то софт, который бы позволял как-то автоматизировать хотя бы то, что вы посоветовали (а своих идей у меня тоже не мало)? Ну, например, быстро переводить HEX-строку в бинарный вид, инвертировать, XOR-ить и т.п. манипуляции делать? Основное время уходит именно на ручное преобразование и расписывание карандашиком... Для логического анализатора софт вроде как весьма помог, но почему разработчики этого софта не додумались делать "стек" захваченных сигналов, чтобы можно было визуально сравнивать "этот" и "тот" или "пред-предыдущий"? И экспорт тоже та еще беда: для одной программы надо строку в том виде, как я тут привожу, т.е. без префиксов 0x, а лог.анализатор пишет с префиксами, да еще в CSV-таблице... пока вручную переформатируешь... Я, конечно, что-то пописываю сам себе в помощь, но ведь на каждый случай утилитку писать тоже не самый оптимальный вариант по усилиям и срокам. Неужели ничего готового нет? Это, будучи в отрыве от реальности, безусловно верно. Но логическое размышление не находит причин, по которым идентификатор коровы должен передавать инфу о том, активно она жует или нет, в зашифрованном виде... Да и тот факт, что адрес передается полностью в "сыром" виде (правда, старшими байтами вперед), как-то с шифрованием уже не вяжется...

Так там и нет изменения пары битов, там все 4 байта меняются. XOR и суммирование я пробовал, естественно, но, т.к. вариантов много, либо не нашел правильный, либо это в принципе не то... Есть странная закономерность, но не могу понять, к чему она может привести: в последних 4 байтах всех пакетов одного и того же транспондера четные и нечетные байты слева направо связаны друг с другом. Поясняю примером ABCD - 4 последних байта. Так вот, любому значению байта А всегда будет соответствовать одно и то же значение байта C, а для В соответственно D. Но обратной связи нет, т.е. к одному и тому же байту С могут "приводить" разные байты А.

При помощи reveng я пробовал перебор (т.е. брутфорс) 8, 16, 24 и 32-битные варианты CRC для: - полного пакета - полного пакета с инверсией - пакета без адреса - пакета без адреса и без 1-2 байт в начале - пакета без адреса и без 1,2,3 и 4 байт в конце - пакет с адресом и без 1,2,3 и 4 байт в конце - пакет без байта, находящегося перед предполагаемой КС и всегда имеющим значение 12 - пакет с адресом и без, у которого из 4 последних байт удалены четные или нечетные байты все предыдущие варианты показали, что ВСЕ полиномы с начальным обнулением "регистра" и с заполнением, а так же с XOR в конце и без него, не подходят... :(

Способы выделения полей в пакете в общих чертах мне известны, и какой-то успех в этом направлении есть. Но задача у меня стоит прежняя: научиться подсовывать свои данные в пакет. То поле, которое надо менять - поле адреса, - я уже вычленил на 100% в пакете. Остается совсем "пустяк" - подсунуть новый адрес в пакет так, чтобы приемник не заподозрил подвоха. И тут, к несчастью, знание остальных полей пакета очень мало поможет... Кроме реверсинга прошивки и чистого везения с угадыванием, существуют ли какие-то подходы к раскрытию алгоритма КС? Может, я просто не знаю, как надо и пытаюсь изобрести велосипед?

К сожалению, семейство MSP430 для меня абсолютно неизвестное, никаких средств для работы с ним нет :( И даже по поводу ревизии я не понял - как её определить? Что за баг в бутлодыре, какие указания? Боюсь, что в разумное время я ответы на все эти вопросы не найду.

У меня все то же самое, разве что я даже не пытался подключаться к контроллеру по очевидной причине защищенности. А остальное - так и есть. Данные меняются сами по себе, связи с внешним миром при этом не прослеживается. Но кое-что по формату стало понятнее... кроме КС.

Не заглох, как видите... Всё ещё надеюсь разломать протокол...

Для них, родимых. Я продвинулся куда дальше всех, но все равно уперся в КС :(

Вы всерьез верите, что она незалоченная?!

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

Я набрал еще пакетов для статистики. Выяснилось, что пакеты передатчиков, которые полежали два дня сильно отличаются от ранее полученных, т.е. пока девайсы спят, они живут. Но каких-то кардинальных знаний новые пакеты не прибавили. Каждая строка в нижеследующих дампах - это отдельный пакет, интервалы между передачами пакетов примерно одинаковые - секунд 15-20. 7310072541 2004 48 0000000000000000000000008240C1000041824244404242003F12 4B89E468 7310072541 4060 48 0000000000000000000000008240C1000041824244404242003F12 47778004 7310072541 6000 48 0000000000000000000000008240C1000041824244404242003F12 0166E062 7310072541 2004 48 0000000000000000000000008240C1000041824244404242003F12 4B89E468 7310072541 4060 48 0000000000000000000000008240C1000041824244404242003F12 47778004 7310072541 6000 46 0000000000000000000000008240C1000041824244404242003F12 01E6E06C 7310072541 2004 46 0000000000000000000000008240C1000041824244404242003F12 4B09E466 7310072541 4060 46 0000000000000000000000008240C1000041824244404242003F12 47F7800A 7310072541 6000 46 0000000000000000000000008240C1000041824244404242003F12 01E6E06C 7310072541 2004 46 0000000000000000000000008240C1000041824244404242003F12 4C0EE461 724F1BBA9C 6100 10 0000000000000001000002000081840000000000000000005C3C12 01FD3D39 724F1BBA9C 210B 10 0000000000000001000002000081840000000000000000005C3C12 0C423674 724F1BBA9C 4162 10 0000000000000001000002000081840000000000000000005C3C12 FD795FE5 724F1BBA9C 6100 10 0000000000000001000002000081840000000000000000005C3C12 01FD3D39 724F1BBA9C 210B 10 0000000000000001000002000081840000000000000000005C3C12 0C423674 724F1BBA9C 4162 10 0000000000000001000002000081840000000000000000005C3C12 FD795FE5 724F1BBA9C 6100 10 0000000000000001000002000081840000000000000000005C3C12 01FD3D39 724F1BBA9C 210B 10 0000000000000001000002000081840000000000000000005C3C12 0D433675 724F1BBA9C 4162 10 0000000000000001000002000081840000000000000000005C3C12 FD795FE5 724F1BBA9C 6100 10 0000000000000001000002000081840000000000000000005C3C12 01FD3D39 730761BAAF 2005 38 000000000000000000000000408080000000000000000000000012 72A86A57 730761BAAF 4060 38 000000000000000000000000408080000000000000000000000012 699B0F2C 730761BAAF 6000 38 000000000000000000000000408080000000000000000000000012 01A46F64 730761BAAF 2005 38 000000000000000000000000408080000000000000000000000012 72A86A57 730761BAAF 4060 38 000000000000000000000000408080000000000000000000000012 699B0F2C 730761BAAF 6000 38 000000000000000000000000408080000000000000000000000012 01A46F64 730761BAAF 2005 36 000000000000000000000000408080000000000000000000000012 73296A58 730761BAAF 4060 36 000000000000000000000000408080000000000000000000000012 691B0F22 730761BAAF 6000 36 000000000000000000000000408080000000000000000000000012 01246F6A 730761BAAF 2005 36 000000000000000000000000408080000000000000000000000012 73296A58 734F33656A 2000 76 7B7B7B7B7B7B7B7B7B7B7B000C0C0C0C0C0C0C0C0C0C0C0C000012 01073806 734F33656A 4000 6C 7B7B7B7B7B7B7B7B7B7B7B000C0C0C0C0C0C0C0C0C0C0C0C000012 03D0387E 734F33656A 600C 6C 7B7B7B7B7B7B7B7B7B7B7B000C0C0C0C0C0C0C0C0C0C0C0C000012 830234DE 734F33656A 2000 6C 7B7B7B7B7B7B7B7B7B7B7B000C0C0C0C0C0C0C0C0C0C0C0C000012 0199381C 734F33656A 4000 6C 7B7B7B7B7B7B7B7B7B7B7B000C0C0C0C0C0C0C0C0C0C0C0C000012 03D0387E 734F33656A 600C 6C 7B7B7B7B7B7B7B7B7B7B7B000C0C0C0C0C0C0C0C0C0C0C0C000012 830234DE 734F33656A 2000 6C 7B7B7B7B7B7B7B7B7B7B7B000C0C0C0C0C0C0C0C0C0C0C0C000012 0199381C 734F33656A 4000 6C 7B7B7B7B7B7B7B7B7B7B7B000C0C0C0C0C0C0C0C0C0C0C0C000012 03D0387E 734F33656A 600C 6A 7B7B7B7B7B7B7B7B7B7B7B000C0C0C0C0C0C0C0C0C0C0C0C000012 830734D8 734F33656A 2000 6A 7B7B7B7B7B7B7B7B7B7B7B000C0C0C0C0C0C0C0C0C0C0C0C000012 029F3819 Однозначно очевидно, что первые 5 байт - это адрес передатчика, хотя значащих байт там только 3 и то без старших 2 бит. XOR этих 5-и байтов всегда равен 00, т.е. последний байт - это XOR-КС, а предыдущий - какой-то довесок, подгоняющий КС до нуля. Следующие 2 байта абсолютно закономерно от передачи к передаче меняются попарно и по кругу, т.е. каждая третья передача будет иметь те же самые значения в этих байтах. Закономерность явно есть, но что это может значить? передавать 3 варианта по кругу - зачем?! Следующий байт от передачи к передаче имеет тенденцию к закономерному уменьшению, но после длительной паузами между передачами значение байта снова возрастает (по показанным дампам это не видно, но это так) - подозреваю, что это напряжение на литиевой батарейке. Дальше - неизвестно что, но всегда заканчивается на 12. Честно говоря, это как-то настораживает... Последние 4 байта тоже выявили некую закономерность: четвертому от конца байту всегда в пределах одного и того же передатчика соответствует четко определенное значение второго от конца байта, аналогично и для следующей пары последних байт. Но все эти закономерности пока никак не помогли мне понять, как же, блин, считаются эти КС... Пробовал при помощи reveng подбирать полиномы - ни для 16-битных, ни тем более для 32-битных не находится. пробовал брать часть пакета без адреса - тот же результат. пробовал брать без 1 или 2 последних байт, пробовал в последних 4 байтах удалять через 1, т.е. оставлять 1-3 или 2-4 байты - нулевой результат :( Сегодня вечером планирую приступить к генерации пакетов самостоятельно, и буду смотреть, как отреагирует девайс. Хуже всего то, что девайс тоже закрытый, и либо показывает часть адреса передатчика, либо показывает ошибку. Судить об остальных частях пакета нет возможности :(

Приемник пока один. Статистику по пакетам буду набирать для имеющихся передатчиков... Потом буду гондобить свой передатчик и пытаться обмануть приемник... Пока это все, что в моих силах.

Я обращаю внимание... но не все понятно. Например, что за КС Флетчера - не ясно, в интернете что-то непонятное написано (по-русски).

Это, разумеется, один из этапов "взлома", но пока что я к нему не приступил. Все вами сказанное я понимаю, но продолжаю надеяться, что не все так сложно, особенно со скрытыми байтами. Просто система не та, чтобы так стараться сделать её невзламываемой, главное - обеспечить надежность передачи по ИК-каналу, который, в принципе, достаточно "грязный". Так что я все-таки надеюсь, что слишком хитрых трюков не будет... Мне вот уже подсказали, что XOR первых пяти байтов даёт НОЛЬ, хотя АДРЕС содержится только в первых трех - может быть, эта часть и не входит в общую КС... но 4 байта КС - это намекает на CRC32, что выглядит явно избыточным для пакета из 39 байт...

Я же говорю, что простое решение - reveng - результата не даёт, надо что-то оригинальнее...

Собственно, для подбора нужен какой-то автоматизированный инструмент, иначе просто нереально. Знаете такой? пока что не удалось добиться такого, при каждой передаче по непонятному алгоритму меняются 5-7 байты. Пока что я не выявил их назначение, поэтому не могу сказать, возможно ли добиться повторяемости.

Коллеги! Прошу помочь, хотя бы советом, в решении проблемы реверс-инжиниринга ИК-протокола обмена. Есть "фирменная" система, состоящая из приемника ИК-сигналов и кучи передатчиков сигнала. Передатчики посылают пакеты данных, в которых есть их собственный адрес и еще что-то. Сам обмен я просниффил, оказалось достаточно просто, в пакете данных нашел поля адреса, в этом я точно уверен. Все остальные данные пока не известны, где находятся в пакете, но главное - в конце пакета (подозреваю очень сильно!) есть поле какой-то контрольной суммы. Во всяком случае, при изменении буквально 1-2 битов в пакете 4 последних байта сильно меняются, что наталкивает... Так вот: каким способом можно вычислить алгоритм, по которому ведется подсчет этой КС? Прошивка МК недоступна, естественно... Я пробовал брутфорсить при помощи утилиты reveng, но ничего не вышло... Что посоветуете? Вот просниффленные пакеты с трех разных передатчиков: 73 07 61 = BA AF 20 05 1C 00 00 00 00 00 00 00 00 00 00 09 0A 00 00 00 00 00 00 80 00 00 00 41 41 00 3C 12 = 71 6D 62 87 73 07 61 = BA AF 40 60 18 00 00 00 00 00 00 00 00 00 00 09 0A 00 00 00 00 00 00 80 00 00 00 41 41 00 3C 12 = 3B 80 07 A9 73 07 61 = BA AF 60 00 16 00 00 00 00 00 00 00 00 00 00 09 0A 00 00 00 00 00 00 80 00 00 00 41 41 00 3C 12 = 01 6D 67 BD 73 07 61 = BA AF 20 05 12 00 00 00 00 00 00 00 00 00 00 09 0A 00 00 00 00 00 00 80 00 00 00 41 41 00 3C 12 = 71 20 62 88 72 4F 1B = BA 9C 60 00 62 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 12 = 01 30 E7 F6 72 4F 1B = BA 9C 40 62 60 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 12 = D0 13 85 05 72 4F 1B = BA 9C 60 00 5E 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 12 = 01 12 E7 CA 72 4F 1B = BA 9C 20 0B 5E 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 12 = 0B AA EC 80 73 10 07 = 25 41 20 04 1E 00 00 00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 40 00 00 00 00 00 00 00 12 = 47 06 62 4C 73 10 07 = 25 41 40 60 1C 00 00 00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 40 00 00 00 00 00 00 00 12 = 19 20 06 70 73 10 07 = 25 41 60 00 1A 00 00 00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 40 00 00 00 00 00 00 00 12 = 01 6A 66 4E 73 10 07 = 25 41 20 04 18 00 00 00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 40 00 00 00 00 00 00 00 12 = 78 0C 4E 45 знаками равенства я отделил в начале область адреса (я уверен, что это так) и в конце - область контрольной суммы (100% уверенности в назначении этих байтов нет)

не правильное. volatile char mode = 0; interrupt [PC_INT2] void pin_change_isr2(void){ if(PINB & (1<<PB0)) mode = 1; else mode = 0; } int main(void){ while(1){ // главный цикл while(mode == 0){ // цикл первой задачи } while(mode == 1){ // цикл второй задачи } } } как-то так в общих чертах

Лично я воспринимаю этот проект так: 1. Целевая аудитория - "экономные крестьяне", т.е. люди, понимающие, что вырастить огурцы в теплице можно и без автоматики, но с автоматикой оно будет проще (больше времени на сон), но при этом не понимающие, что такое автоматика и с чем ее едят. Например, "если стало жарко - открыть окно теплички для проветривания" - это их уровень алгоритмизации процесса терморегулирования. И точка. Максимум, на что они способны - подключить проводки к клеммнику. 2. Техническая грамотность этой целевой аудитории примерно 2-3 по 10-балльной шкале, уровень компьютерной грамотности - 3-4 (интернет - наше всё), уровень алгоритмических и тем более программистских навыков -5 (минус пять) по той же шкале. Предполагается, что эти юди смогут взять картиночки, положить их на экране в нужном им порядке, затем взять (где?!) платку с контроллером и реле и "запрограммировать". Потом подключить проводочки к плате и как-то решить свою задачу автоматизации... При этом возникает масса вопросов... Часть уже озвучена, и главный такой: если уровень техграмотности низкий, рисование алгоритмов мышкой не поможет решить остальные проблемы (схема приводов, контроля и т.п.), а если уровень техграмотности достаточно высок, чтобы решить "остальные проблемы" - ничто не помешает "запрограммировать" и ардуино. Более того, большинство "экономных крестьян" воспринимают компьютер только в качестве интернета и видео (так и говорят, не для "лазанья по интернету", а "у меня интернет в компе"), и даже если у них есть ноутбук, таскать в тепличку его для корректировки параметров системы автоматики по месту не станут, ибо черевато ноутбук попортить. А принести тепличку в комнату невозможно... Я утрирую, конечно, но смысл именно таков - гаражная автоматика кустарей-одиночек. Каюсь: сам предпринимал попытки сделать нечто под эту целевую аудиторию... Предельно упрощал задачу: программирование контроллера без использования компьютера при помощи 4-5 кнопок... Но получалось нечто крайне неюзабельное: 5-ю кнопками нормальную программу не введешь, даже на суперпростом "языке жестов", процесс превращается в мучение... Что получается при этом - можно получить представление по модели в протеусе, вот статья с описанием и файлами для скачивания - а ведь это всего лишь таймер, у него нет входов для реализации логики анализа их состояния и изменения алгоритма поведения! Я делал и со входами вариант, но ввод алгоритма при этом вообще вызывает седину раньше времени... Так что это тупик: кому надо простую систему автоматизации задешево, те просто ищут умельца, который это сделает из говна и палок. А для остальных этот геморрой с самопальными ПЛК на AVR не нужен - берут ОВЕН или SIEMENS и не горюют.

Делал и в железе - результат 100% тот же самый. И вывод всех статусов карты и т.п. делал, т.е. из Chan-овской библиотеки в нужных местах выводил, что возвращается... толку ноль - не понимаю, что не так. Когда сектор равен 512 в функции lseek, в конце функции карта просто не отвечает - приходит 0xFF и точка... хоть убей...

Вопрос по Petit FatFs. Для отладки использую Proteus VSM 8.4 с виртуальной CD/MMC картой. На карте есть единственный файл 7 с хвостиком килобайт, к которому осуществляется доступ в разные произвольные места. Поначалу все работает: файл открывается, из него читаются данные (все верно читается), функция pf_lseek отрабатывает разные смещения. Но потом по неизвестным причинам pf_lseek начинает выдавать ошибку FR_DISK_ERR, и все, разумеется, перестает работать. При пошаговой отладке добрался до функции send_cmd(CMD17, sector), которая и вызывает эту ошибку. В начале эта функция вызывается многократно успешно, а ошибку возвращает, если sector == 512 (просто обратил внимание, не факт, что именно это значение играет роль). Что-то никак не могу понять, куда копать... подскажите, пожалуйста, если не сложно...

Предлагаю вот такую вещь, немного устаревшую, но с весьма неплохими параметрами: Это широкополосный прецизионный ОУ с полной гальванической развязкой входа от выхода с высоким напряжением изоляции, параметры доступны на сайте производителя. Готов уступить за 50% современной цены: http://www.efind.ru/icsearch/?search=ad215by При покупке нескольких штук (всего есть 4) доставка почтой РФ в подарок, т.е. бесплатно.

Спасибо. Пытаюсь понять сам, ковыряясь в новых версиях, что стало иным. Но под "куда-то что-то пропадает" я имел ввиду, например, avrdude, который то есть, то нет. или другие вспомогательные утилиты... И в WinAVR была вполне себе толковая документация по avr-libc, да и по самому GCC тоже, а в новых сборках нет...