This looks like most Continental DFlash CRC. There is a derived/secret piece of data (nonce) encoded into the CRC, so you will have big issues with straight CRC reversal.

Do you have the bytes FF FE in your DFlash dump? This is the record value which identifies the CRC nonce. The last two bytes will be the nonce. For example, 00010080 00000A45 0BE5F001 FFFE41A0 (record ID FF FE, CRC 41 A0, shifted CRC BE 5F, data 00010080 00000A45) means the nonce for this DFlash is 0A 45.

I figured this out by making a simple ASW patch hooking the CRC functions in flash, and writing a logger which would send me the parameters to a hooked function, in this case what is being CRCed. I intend to eventually do a write up about this strategy as it is very useful for learning things.

The bytes you have outlined in RED are the bytes in PURPLE xor FFFF << 4.

For example, 86 03 XOR FFFF -> 79 FC << 4 -> 07 9F C0.

The bytes in PURPLE are calculated like so:

CRC16_INIT_A55A_POLY_8005(DATA + INFO)

INFO is always 8 bytes: XX XX 00 00 YY YY 46 ZZ

XX XX is the NONCE.

YY YY is the LENGTH.

ZZ is the channel ID.

So for example for your channel 5 (05 46, Len 01):

15 2F 00 00 00 00 00 00 XX XX 00 00 01 00 46 05

Or split up:

15 2F 00 00 00 00 00 00 << DATA, 8 Bytes

XX XX << NONCE, recover it from FF FE record

00 00 << fixed

01 00 << len

46 05 << Channel 5

Depending on the record_way (type) of the record in ASW, it may also have an additional prefix CRC which is part of the data also. This prefix CRC is the same polynomial but init value 0xABCD.

There are a few other oddities I never quite figured out. Some records have a single byte skipped in various places in the CRC calculation and others don't.

Thanks for your help,

The purple was pretty obvious. 

If I follow the logic you explained

I tried to find the FF FE bytes (I have it multiple time but I suppose that the interessting one are at the end) offset 0x2FE00 and 0x2FF00 with the same exact value

0001007A 00000B30 08166001 FFFE7E99

(record ID FF FE, CRC 7E 99, shifted CRC 81 66, data 0001007A 00000B30) means the nonce for this DFlash is 0B 30 ? how did you find B3 10 ?



So if I try to calculate CRC16 CCITT with 1021 poly and FFFF init on

15 2F 00 00 00 00 00 00 B3 10 00 00 01 00 46 06 (if B3 10 is considered as the nonce)

15 2F 00 00 00 00 00 00 0B 30 00 00 01 00 46 06 (if 0B 30 is considered as the nonce)

I still don't have B6 B3 as a result

I also put PFlash here if there is anything to check inside; I saw that you shared the Ghidra TC1791 preset but I haven't had time to play with it. I'm more familiar with this type of reverse than with the assembly.

Thanks again

I think it is ok for poly 1021

So I found out that there are 2 nonces one for dflash0 and one for dflash1 (the file I put in first post is dflash0 + dflash1 combined)

0B31 for dflash0 and 0B30 for dflash1 (have to check if it is always -1 on other SID310 )

I managed to calculate CRC for some parts using reveng giving some blocks to get the initial value.


Just need to figure out how the initial value is changing for other blocks

It seems like if the block length is 01 then init=0x8b35

I choose random 01 size blocks in file and init is always 0x8b35

I think the init value is actually be the same but there is a seemingly random byte skipped in the middle of the longer values which is throwing things off and causing crc reveng to infer a different init value. I never quite figured this part out, I just used the recorded values for the channels I cared about.