| |
 Определение алгоритма CRC8, неизвестный CRC8 |
|
|
|
|
 Oct 17 2007, 15:36
|
Участник
Группа: Свой
Сообщений: 43
Регистрация: 12-10-07
Пользователь №: 31 293
|
Цитата(TONAL @ Oct 17 2007, 18:46)  Вроде шото нашел
[attachment=14528:attachment] то что было выдернул. сейчас посмотрю еще ньюансы с подсчетами, может там байты переставляются предварительно или еще чтонибудь. Код static unsigned char \
crc8_tab[256] = \
{
0x00,0x5E,0xBC,0xE2,0x61,0x3F,0xDD,0x83,0xC2,0x9C,0x7E,0x20,0xA3,0xFD,0x1F,
0x41,
0x9D,0xC3,0x21,0x7F,0xFC,0xA2,0x40,0x1E,0x5F,0x01,0xE3,0xBD,0x3E,0x60,0x82,
0xDC,
0x23,0x7D,0x9F,0xC1,0x42,0x1C,0xFE,0xA0,0xE1,0xBF,0x5D,0x03,0x80,0xDE,0x3C,
0x62,
0xBE,0xE0,0x02,0x5C,0xDF,0x81,0x63,0x3D,0x7C,0x22,0xC0,0x9E,0x1D,0x43,0xA1,
0xFF,
0x46,0x18,0xFA,0xA4,0x27,0x79,0x9B,0xC5,0x84,0xDA,0x38,0x66,0xE5,0xBB,0x59,
0x07,
0xDB,0x85,0x67,0x39,0xBA,0xE4,0x06,0x58,0x19,0x47,0xA5,0xFB,0x78,0x26,0xC4,
0x9A,
0x65,0x3B,0xD9,0x87,0x04,0x5A,0xB8,0xE6,0xA7,0xF9,0x1B,0x45,0xC6,0x98,0x7A,
0x24,
0xF8,0xA6,0x44,0x1A,0x99,0xC7,0x25,0x7B,0x3A,0x64,0x86,0xD8,0x5B,0x05,0xE7,
0xB9,
0x8C,0xD2,0x30,0x6E,0xED,0xB3,0x51,0x0F,0x4E,0x10,0xF2,0xAC,0x2F,0x71,0x93,
0xCD,
0x11,0x4F,0xAD,0xF3,0x70,0x2E,0xCC,0x92,0xD3,0x8D,0x6F,0x31,0xB2,0xEC,0x0E,
0x50,
0xAF,0xF1,0x13,0x4D,0xCE,0x90,0x72,0x2C,0x6D,0x33,0xD1,0x8F,0x0C,0x52,0xB0,
0xEE,
0x32,0x6C,0x8E,0xD0,0x53,0x0D,0xEF,0xB1,0xF0,0xAE,0x4C,0x12,0x91,0xCF,0x2D,
0x73,
0xCA,0x94,0x76,0x28,0xAB,0xF5,0x17,0x49,0x08,0x56,0xB4,0xEA,0x69,0x37,0xD5,
0x8B,
0x57,0x09,0xEB,0xB5,0x36,0x68,0x8A,0xD4,0x95,0xCB,0x29,0x77,0xF4,0xAA,0x48,
0x16,
0xE9,0xB7,0x55,0x0B,0x88,0xD6,0x34,0x6A,0x2B,0x75,0x97,0xC9,0x4A,0x14,0xF6,
0xA8,
0x74,0x2A,0xC8,0x96,0x15,0x4B,0xA9,0xF7,0xB6,0xE8,0x0A,0x54,0xD7,0x89,0x6B,
0x35
};
static unsigned char \
crc8_update (unsigned char crc, unsigned char v)
{
#if 0
crc ^= v;
crc = crc8_tab[crc];
#else
int i;
crc ^= v;
for (i = 0; i < 8; i++)
{
crc = (crc >> 1) ^ ((crc & 0x01) ? 0x8C : 0x00);
}
#endif
return crc;
}
static unsigned char \
crc8 (const unsigned char *ptr, int len)
{
unsigned char crc;
crc = 0;
while (len--)
{
crc = crc8_update (crc, *ptr++);
}
return crc;
} P.S. Добавил... CRC считается для блоков 2, 3, 4 байта при записи в устройство, при чтении из него ничего не считается. остальное посмотрю чуь позже.
|
|
|
|
|
|
|
|
Oct 17 2007, 15:56
|
Участник
Группа: Новичок
Сообщений: 19
Регистрация: 16-10-07
Пользователь №: 31 405
|
Цитата(Ivan_Petrov @ Oct 17 2007, 18:36) то что было выдернул. Круто!!! как это ты его так быстро ??? Цитата(Ivan_Petrov @ Oct 17 2007, 18:36) P.S.
Добавил...
CRC считается для блоков 2, 3, 4 байта при записи в устройство, при чтении из него ничего не считается.
остальное посмотрю чуь позже. Спасибо папробую посчитать по этим процедурам.
|
|
|
|
|
|
|
|
Oct 17 2007, 17:50
|
Участник
Группа: Свой
Сообщений: 43
Регистрация: 12-10-07
Пользователь №: 31 293
|
Все перепровирил, при чтении CRC не проверяется. Читается всегда по 8 байт с порта "/dev/usb/tts/0" на скорости 9600, 8 бит данных. Вторым байтом идут идентификаторы, которые могут принимать значения: 0x4B,0x4D,0x42. Для идентификатора 0x4B 4 и 5 байты пакета раскладываются в массив int значений, примерно вот так: Код for (i = 0; i < 8; i++)
{
array[i] = (packet[4] & (1 << i)) ? 1 : 0;
} Для других идетификаторов проверяются внутренние состояния. Дальше копать не стал. при открытии порта посылаются вот такие пакеты инициализации Цитата 0x52,0x03, CRC
0x41,0x04,0xFF, CRC и есть еще пакет на запись вот такого формата: Цитата val = <expr> ? 3 : 0
0x4D,0x05, val, 0x00, CRC когда точно отсылается тоже не стал копать. все  p.s. я еще вот что думаю, а может в пакете на прием это не CRC, а неочищенный перед заполнением буфер, выделенный на стеке? Тоже самое объяснение может быть и для повторных полей с данными.
|
|
|
|
|
|
|
|
Oct 17 2007, 19:12
|
Участник
Группа: Новичок
Сообщений: 19
Регистрация: 16-10-07
Пользователь №: 31 405
|
Пересчитал по твоему коду: CRC расчитаный таблично и через LSFR совпадают(это хорошо), но не совпадают с тем шо надо(это плохо). Цитата(Ivan_Petrov @ Oct 17 2007, 20:50) Все перепровирил, при чтении CRC не проверяется. Читается всегда по 8 байт с порта "/dev/usb/tts/0" на скорости 9600, 8 бит данных. Вторым байтом идут идентификаторы, которые могут принимать значения: 0x4B,0x4D,0x42. Для идентификатора 0x4B 4 и 5 байты пакета раскладываются в массив int значений, примерно вот так: Код for (i = 0; i < 8; i++)
{
array[i] = (packet[4] & (1 << i)) ? 1 : 0;
} Для других идетификаторов проверяются внутренние состояния. Дальше копать не стал. Точно так и есть: Идентификатор 0x4B это клавиатура а в четвертом байте упакованы побитно состояния кнопок 8шт. Идентификатор 0x4D это тоже команда Идентификатор 0x49(42 ошибка?) это команды ДУ. Цитата(Ivan_Petrov @ Oct 17 2007, 20:50) при открытии порта посылаются вот такие пакеты инициализации
Init0 - 52 03 04
Init1 - 41 04 FF 94
и есть еще пакет на запись вот такого формата:
Start - 4D 05 03 00 1D
когда точно отсылается тоже не стал копать. ТОЧНО!!! А вот для этих пакетов восстановленный тобой алгоритм полностью подходит (я проверил)!!! Цитата(Ivan_Petrov @ Oct 17 2007, 20:50) p.s.
я еще вот что думаю, а может в пакете на прием это не CRC, а неочищенный перед заполнением буфер, выделенный на стеке?
Тоже самое объяснение может быть и для повторных полей с данными. Да непохоже скорее всего эта фича контроллера которую РС не юзает(или юзает в другом месте). А повтор нормальное явление Мусор от стека кажется маловероятным (этож однокристалка)(тем более выполняются свойства опереций в (GF2*)) То есть там CRC но другой!
Сообщение отредактировал TONAL - Oct 17 2007, 19:18
|
|
|
|
|
|
|
|
Oct 17 2007, 19:44
|
Участник
Группа: Свой
Сообщений: 43
Регистрация: 12-10-07
Пользователь №: 31 293
|
Цитата(TONAL @ Oct 17 2007, 23:12) Идентификатор 0x49(42 ошибка?) это команды ДУ. Нет не ошибка. вот CASE блок комманд. Код .text:0807C5BA mov eax, [ebp+pObj]
.text:0807C5BD cmp byte ptr [eax+135h], 4Bh
.text:0807C5C4 jnz @loop1_end ; not 4B
...
.text:0807C6EE mov eax, [ebp+pObj]; not 4B
.text:0807C6F1 cmp byte ptr [eax+135h], 4Dh
.text:0807C6F8 jnz loc_807C7B1 ; not 4D
...
.text:0807C7B1 mov eax, [ebp+pObj]; not 4D
.text:0807C7B4 cmp byte ptr [eax+135h], 42h
.text:0807C7BB jnz @end_case ; not 42 вот 49 комманды тут точно нет, или ана обрабатывается другим модулем.
|
|
|
|
|
|
|
|
Oct 17 2007, 20:39
|
Участник
Группа: Новичок
Сообщений: 19
Регистрация: 16-10-07
Пользователь №: 31 405
|
Цитата(Ivan_Petrov @ Oct 17 2007, 22:44) Нет не ошибка. вот CASE блок комманд. Код .text:0807C5BA mov eax, [ebp+pObj]
.text:0807C5BD cmp byte ptr [eax+135h], 4Bh
.text:0807C5C4 jnz @loop1_end ; not 4B
...
.text:0807C6EE mov eax, [ebp+pObj]; not 4B
.text:0807C6F1 cmp byte ptr [eax+135h], 4Dh
.text:0807C6F8 jnz loc_807C7B1; not 4D
...
.text:0807C7B1 mov eax, [ebp+pObj]; not 4D
.text:0807C7B4 cmp byte ptr [eax+135h], 42h
.text:0807C7BB jnz @end_case ; not 42 вот 49 комманды тут точно нет, или ана обрабатывается другим модулем. Согласен, но я ни разу не видел команды 42, а 49 это точно ДУ. Может 49 выведет на этот хитрый CRC? Качаю VMWare. 
|
|
|
|
|
|
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0
|
|
|
