aiselcms

Вот какие на данный момент подвижки: 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 69 55 69 56 a9 76 1a aa 60 93 a5 6f aa 9f ab ba ae f6 70 49 61 be 96 5b da 55 bf ab d9 76 9c 6a 06 df 95 6a e5 56 48 9c 65 55 69 56 a9 76 9a aa 20 1f a5 6f aa 9f ab ba ae f6 70 49 61 be 96 5b da 55 bf ab d9 76 93 6a 05 df 95 6a e6 56 48 93 66 55 69 56 a9 76 9a 9a 20 2c a5 6f aa 9f ab ba ae 85 f0 3a 65 61 96 5b da 55 bf 5b da 5d 93 55 05 9f 95 6a e6 56 40 ec Каждый 10-тый (10, 20, 30, 40) байт скорее всего контрольная сумма вычисленная не известным алгоритмом. Разберем байты с 01 до 05: 1. Их можно менять местами без потери целостности КС. 2. Если вычислить КС по алгоритму XOR: 69 xor 55 xor 69 xor 56 xor a9, то если вычислить последовательность, которая будет давать такое же значение, те 69 xor 55 xor 69 xor 56 xor a9 = x1 xor x2 xor x3 xor x4 xor x5, то её можно записать без потери целостности КС. Байт в позиции 06 нельзя менять местами с соседними байтами. Так же байты в позиции 10, 20, 30, 40 так же нельзя менять местами с соседними байтами. Так же есть закономерность: по 20 и 30 байтам: если взять 9 предыдущих байтов a5 6f aa 9f ab ba ae f6 70 49, то если 9 байтов будут одинаковые, то и 10-тих будет такой же, но это работает только для 20 и 30 байта.

Извиняюсь, немного не то написал. Да, получается 3, F получалось в другом дампе.

Например кому мне написать в личку, и обратиться за помощью? Вам например?

Доброго дня. Ужа давно мучаюсь с поиском алгоритма контрольной суммы. Имеется кусок дампа: 69 55 69 56 a9 76 1a aa 60 93 a5 6f aa 9f ab ba ae f6 70 49 61 be 96 5b da 55 bf ab d9 76 9c 6a 06 df 95 6a e5 56 48 9c и кусок из второго дампа: 65 55 69 56 a9 76 9a aa 20 1f a5 6f aa 9f ab ba ae f6 70 49 61 be 96 5b da 55 bf ab d9 76 93 6a 05 df 95 6a e6 56 48 93 и кусок из третьего дампа (для сравнения): 66 55 69 56 a9 76 9a 9a 20 2c a5 6f aa 9f ab ba ae 85 f0 3a 65 61 96 5b da 55 bf 5b da 5d 93 55 05 9f 95 6a e6 56 40 ec Последние два байта (в первом случае 48 9с, а во втором 48 93) - вероятнее всего контрольная сумма. Если в первом куске заменить первые 4-ре байта 69 55 69 56 на 5а 55 55 55, то контрольная сумма не меняется и всё продолжает работать как нужно с некоторыми нужными мне изменениями. Заметил особенность: 69 xor 55 xor 69 xor 56 = F и 5a xor 55 xor 55 xor 55 = F. Может кто сможет помочь в определении алгоритма? Куски из дампа приборной панели Honda Civic X (10 поколение). 93с86 eeprom. В данных кусках записаны данные для включения нужных функций и параметров приборной панели, таких как температура в C или F, язык, опции авто, дизель/бензин и тд.

Вышла ошибка - вот правильные дампы: 66 55 69 56 a9 76 9a 9a 20 2c a5 6f aa 9f ab ba ae f6 70 49 61 be 96 5b da 55 bf 5b d9 86 93 6a 05 9f 95 6a e6 56 40 d3 95 5a 55 55 76 69 96 99 20 20 6f a9 59 aa 75 5b 75 a2 33 f0 a1 85 5b 9b 96 da 9b 7d b1 9f 55 97 af 04 5a 65 55 a5 59 05 55 5a 55 55 76 a9 96 99 20 20 6f 55 5e a9 75 ab f5 a1 b8 78 a1 a5 5b 9b 96 da 5b 7f 53 de 55 17 9f 04 5a 65 55 a5 e9 04 55 65 56 69 76 a9 aa 9a 1f 20 6f a5 9f aa ba ab f6 ae 49 70 be 61 5b 96 55 da ab bf 76 d9 6a 93 df 05 6a 95 56 e6 93 48 55 69 56 69 76 a9 aa 1a 93 60 6f a5 9f aa ba ab f6 ae 49 70 be 61 5b 96 55 da ab bf 76 d9 6a 9c df 06 6a 95 56 e5 9c 48 55 66 56 69 76 a9 9a 9a 2c 20 6f a5 9f aa ba ab f6 ae 49 70 be 61 5b 96 55 da 5b bf 86 d9 6a 93 9f 05 6a 95 56 e6 d3 40 Забыл проинвертировать

Теперь следующий вопрос. В дампе по адресу: 000-027 храниться конфигурация приборной панели. Вот пример: 66 55 69 56 a9 76 9a 9a 20 2c a5 6f aa 9f ab ba ae 85 f0 3a 65 61 96 5b da 55 bf 5b da 5d 93 55 05 9f 95 6a e6 56 40 ec и другие дампы: 55 66 56 69 76 a9 9a 9a 2c 20 6f a5 9f aa ba ab f6 ae 49 70 be 61 5b 96 55 da 5b bf 86 d9 6a 93 9f 05 6a 95 56 e6 d3 40 5a 95 55 55 69 76 99 96 20 20 a9 6f aa 59 5b 75 a2 75 f0 33 85 a1 9b 5b da 96 7d 9b 9f b1 97 55 04 af 65 5a a5 55 05 59 5a 55 55 55 a9 76 99 96 20 20 55 6f a9 5e ab 75 a1 f5 78 b8 a5 a1 9b 5b da 96 7f 5b de 53 17 55 04 9f 65 5a a5 55 04 e9 65 55 69 56 a9 76 9a aa 20 1f a5 6f aa 9f ab ba ae f6 70 49 61 be 96 5b da 55 bf ab d9 76 93 6a 05 df 95 6a e6 56 48 93 69 55 69 56 a9 76 1a aa 60 93 a5 6f aa 9f ab ba ae f6 70 49 61 be 96 5b da 55 bf ab d9 76 9c 6a 06 df 95 6a e5 56 48 9c 66 55 69 56 a9 76 9a 9a 20 2c a5 6f aa 9f ab ba ae f6 70 49 61 be 96 5b da 55 bf 5b d9 86 93 6a 05 9f 95 6a e6 56 40 d3 Если в мой родной дамп перенести этот кусок с другого дампа, то конфигурация поменяется. Если же перенести не весь, а например все кроме последнего байта - пропадает пробег, значит не совпадает контрольная сумма. Предполагаю что контрольная сумма хранится в последних двух байтах этого куска. Как найти алгоритм контрольной суммы? Если кто может помочь, напишите, естественно не бесплатно, но можно и на добровольных началах. Дальше будет сложнее разбираться самому, по этому хотелось бы найти более понимающего человека.

Продолжаю дальше разбираться с панелью. С пробегом получилось вот так, это работает и можно пользоваться, записывает примерно +-200-500 км: Нужно записать 10.000 км 10.000 / 1.609 = 6215.040 -> (округляем) -> 6215 6215 / 32 = 194.21875 -> (округляем) -> 194 194 d -> 00 C2 h 00 C2 -> C2 00 not (C2 00) -> 3D FF C2 00 3D FF - это значение записываем в каждую из 16 строк. Теперь следующий вопрос. В дампе по адресу: 000-027 храниться конфигурация приборной панели. Вот пример: 66 55 69 56 a9 76 9a 9a 20 2c a5 6f aa 9f ab ba ae 85 f0 3a 65 61 96 5b da 55 bf 5b da 5d 93 55 05 9f 95 6a e6 56 40 ec и другие дампы: 55 66 56 69 76 a9 9a 9a 2c 20 6f a5 9f aa ba ab f6 ae 49 70 be 61 5b 96 55 da 5b bf 86 d9 6a 93 9f 05 6a 95 56 e6 d3 40 5a 95 55 55 69 76 99 96 20 20 a9 6f aa 59 5b 75 a2 75 f0 33 85 a1 9b 5b da 96 7d 9b 9f b1 97 55 04 af 65 5a a5 55 05 59 5a 55 55 55 a9 76 99 96 20 20 55 6f a9 5e ab 75 a1 f5 78 b8 a5 a1 9b 5b da 96 7f 5b de 53 17 55 04 9f 65 5a a5 55 04 e9 65 55 69 56 a9 76 9a aa 20 1f a5 6f aa 9f ab ba ae f6 70 49 61 be 96 5b da 55 bf ab d9 76 93 6a 05 df 95 6a e6 56 48 93 69 55 69 56 a9 76 1a aa 60 93 a5 6f aa 9f ab ba ae f6 70 49 61 be 96 5b da 55 bf ab d9 76 9c 6a 06 df 95 6a e5 56 48 9c 66 55 69 56 a9 76 9a 9a 20 2c a5 6f aa 9f ab ba ae f6 70 49 61 be 96 5b da 55 bf 5b d9 86 93 6a 05 9f 95 6a e6 56 40 d3 Если в мой родной дамп перенести этот кусок с другого дампа, то конфигурация поменяется. Если же перенести не весь, а например все кроме последнего байта - пропадает пробег, значит не совпадает контрольная сумма. Предполагаю что контрольная сумма хранится в последних двух байтах этого куска. Как найти алгоритм контрольной суммы?

Смогли бы расчёт написать. Немного не понял Ваш ход мыслей.

Пробег из bbbbb.bin 57 05 a8 fa 57 05 a8 fa 57 05 a8 fa 57 05 a8 fa 57 05 a8 fa 57 05 a8 fa 57 05 a8 fa 57 05 a8 fa 57 05 a8 fa 57 05 a8 fa 57 05 af fa 50 05 af fa 50 05 af fa 50 05 af fa 50 05 af fa 50 05 af fa

Могли бы Вы объяснить подробнее на вот этом блоке данных? 57 05 a8 fa 57 05 a8 fa 57 05 a8 fa 57 05 a8 fa 57 05 a8 fa 57 05 a8 fa 57 05 a8 fa 57 05 a8 fa 57 05 a8 fa 57 05 a8 fa 57 05 af fa 50 05 af fa 50 05 af fa 50 05 af fa 50 05 af fa 50 05 af fa в нем записано 70150 км. Именно в КМ.

b7 03 48 fc b7 03 48 fc b7 03 48 fc b7 03 48 fc b7 03 48 fc b7 03 4f fc b0 03 4f fc b0 03 4f fc b0 03 4f fc b0 03 4f fc b0 03 4f fc b0 03 4f fc b0 03 4f fc b0 03 4f fc b0 03 4f fc b0 03 4f fc 951*32 = 30432 944*32 = 30208 30432-30208 = 224/16 = 14 6*14 = 84 30432-84=30348mil

И так итог: 1. Пробег в зависимости от рынка храниться по разному. Например возьмем пробег: 70151km = 43590mi В машине отображение пробега было в километрах. Возьмем дамп для этого пробега 57 05 a8 fa 57 05 a8 fa 57 05 a8 fa 57 05 a8 fa 57 05 a8 fa 57 05 a8 fa 57 05 a8 fa 57 05 a8 fa 57 05 a8 fa 57 05 a8 fa 57 05 af fa 50 05 af fa 50 05 af fa 50 05 af fa 50 05 af fa 50 05 af fa 57 05 a8 fa not (57 05) = a8 fa 57 05 -> 05 57 (05 57)h -> (1367)d 1367 * 32 = 43744mi 50 05 af fa not (50 05) = af fa 50 05 -> 05 50 (05 50)h -> (1360)d 1360*32 = 43520mi Как видим нашего пробега нет, но оба пробега можно записать так: 43744mi > 43590mi >43520mi Теперь так: 43744 - 43520 = 224 224 / 16 (количество строк) = 14 Теперь считаем количество разных значений для первого столбца: 57 - 11 шт, 50 - 5 шт 14*11 = 154 43744-154 = 43590mi 43590/0.62137=70151km Но если пробег отображается в милях - этот вариант не подходит. b7 03 48 fc b7 03 48 fc b7 03 48 fc b7 03 48 fc b7 03 48 fc b7 03 4f fc b0 03 4f fc b0 03 4f fc b0 03 4f fc b0 03 4f fc b0 03 4f fc b0 03 4f fc b0 03 4f fc b0 03 4f fc b0 03 4f fc b0 03 4f fc 951*32 = 30432 944*32 = 30208 30432-30208 = 224/16 = 14 6*14 = 84 30432-84=30348mil

мой дамп во вложения ppppp.bin. а я ваш не могу скачать. да, сотые смущают при делении на 32.

50 05 AF FA 50 05 -> 05 50 05 50 h -> 1360 d 1360 * 32 = 43520 mil not 50 05 -> AF FA этот дам вычитан именно мной со своей машиной, пробег практически сходиться, проверьте. Суть в том, что в первой и последней строке дампа храниться пробег примерно так: пробег первой строки > реальный пробег > пробег нижней строки not (57 05) -> a8 fa not (50 05) -> AF FA not (00 b1) -> ff 4e not (00 b6) -> ff 49

Так, возможно. По итогу имеем данные с дампа моей машины, пробег на которой около 70000-70150. Не удалось записать пробег до вычитки дампа. 57 05 a8 fa 57 05 a8 fa 57 05 a8 fa 57 05 a8 fa 57 05 a8 fa 57 05 a8 fa 57 05 a8 fa 57 05 a8 fa 57 05 a8 fa 57 05 a8 fa 57 05 af fa 50 05 af fa 50 05 af fa 50 05 af fa 50 05 af fa 50 05 af fa Берем последнюю строку: 50 05 af fa not(50 05) = af fa 50 05 -> 05 50 05 50 h -> 1360 d 1360*32 = 43520 миль 43520 * 1.609 = 70023 км Из этого следует, что пробег изначально записан в милях (машина из США). Но есть два момента: 1. На приборке у меня после вычитки дампа было около 70150 км, но по расчётам выходит значение меньшее. 2. Первые строки: 57 05 a8 fa 57 05 a8 fa 57 05 a8 fa 57 05 a8 fa 57 05 a8 fa 57 05 a8 fa 57 05 a8 fa 57 05 a8 fa 57 05 a8 fa и последние строки: 50 05 af fa 50 05 af fa 50 05 af fa 50 05 af fa 50 05 af fa хранят разные пробеги. и главное - во всех дампах повторения байтов первого столбца на 1 меньше чем в третьем, поясню: 57 05 af fa count (57) = count(a8) + 1 count (50) = count(af) - 1

Номер: 78100-TBC-A710-M1 По пробегу: алгоритм от 2006-2007 года Цивик 93с76. 50 05 af fa для пробега 70023 not (50 05) -> af fa 50 05 -> 05 50 (05 50)h -> (1360)d 1360*32 = 43520mil * 1.609 = 70023 km

С пробегом разобрался. Осталось цельсии и русский язык

Проблема решена. Контрольная сумма двух предпоследних позициях.

Доброго дня. Имеется авто и дамп (93c86) одометра. В дампе имеется возможность включения Русского языка (сейчас английский), изменения показания температуры в Цельсиях (сейчас в Фаренгейтах) и изменение пробега. Изучив несколько дампов нашел только место записи пробега. 16 групп байтов по 4 байта с адреса 1D8 в виде: 00 b1 ff 4e 00 b1 ff 4e 00 b1 ff 4e 00 b1 ff 4e 00 b1 ff 49 00 b6 ff 49 00 b6 ff 49 00 b6 ff 49 00 b6 ff 49 00 b6 ff 49 00 b6 ff 49 00 b6 ff 49 00 b6 ff 49 00 b6 ff 49 00 b6 ff 49 00 b6 ff 49 для пробега 00 58 00 Каждый столбец, в зависимости от пробега имеет либо один либо два разных байта, разница (вычитание) между байтами во 2 и 4 столбце всегда одинаковая, меняется только знак результата. b1-b6 = 49-4e (если считать по модулю), - бывает в первом столбце или во втором, всегда чередуются, одинаковых знаков не бывает. Так же замечено: количество b1 - 1 = количество 4e, количество b6 + 1 = количество 49. Это сохраняется во всех дампах. Хотелось бы выяснить алгоритм записи и кодирования пробега (для понимания, сравнивал с авто предыдущих поколений 93c66/76, там пробег записан совершенно иначе), а так же какие нибудь мысли по поводу включения Русского языка и перевода в цельсии. Имеется с десяток дампов для Англии, и два для США. Но отличия в них большие, и понять что отвечает за язык и цельсии не удалось. ррррр.bin - мой дамп ppppp.BIN civ.bin civ_type_r.bin Honda Civic 2017 93c86 2873km NS.bin 54552km 93c86 x16.bin 17120MILES.bin 6500.bin 5800,.bin 5800.bin 74.709.bin 5800,,.bin 53.500 kms.bin 0km.bin Панель фирмы Denso

Доброго дня. Имеется в наличии собственный авто Civic 10 поколения из США. Температура климата (отображается на головном устройстве, т.е. магнитоле) и наружнего воздуха (отображается на спидометре) в Фаренгейтах. Был снят и вычитан eeprom 93C86 из блока климата, и записан дампом от канадского авто. Цельсии появились на ГУ, но хотелось бы понять, как из родного дампа сделать дамп с цельсиями. То, что знаю на данный момент: Первые две строки дампа одинаковы, и состоят из 16 байтов, два последних всегда FF, значит не используются. Третий байт с конца - контрольная сумма всех байтов от начала строки до этого байта вычисленная по алгоритму CRC16/CCITT с начальным значением 0xffffff и полиномом 0x1021. Результат такой контрольной суммы будет иметь вид XX00, причем на 5 дампах всегда результат контрольки заканчивается на 00, и судя по всему просто не записывается в дамп, а записывается только старший один из двух байтов котрольки. На прилагаемом фото можно увидеть суть. Первая строка в инверсии байтов: e6 21 04 00 54 4c 43 52 36 31 33 00 5e 6c ff ff CRC16/CITT от e6 21 04 00 54 4c 43 52 36 31 33 00 5e дает 6с 00. Третий с конца байт 6c первый байт контрольки. Так же приложу несколько дампов для США и один для Европы. Буду очень благодарен за какие либо разъяснения, как из американского дампа сделать дам в Цельсиях. Так же замечу, что есть байт по адресу 02 в первой строке в США значение 04, в Канаде 08. Возможно он и отвечает за цельсии, но при его замене не получается рассчитать верную контрольную сумму. KAN_1.BIN USA_1.bin USA_2.bin USA_3.BIN Так же чуть позже в этом посту изложу свои мысли по поводу дампа спидометра, где отображается температура наружнего воздуха.