Need help reversing CRC Algorithm

[Rerouter]

Trying to reverse engineer the communications protocol between 2 serial devices, but coming a little unstuck with how exactly the CRC is implemented, a few hints say its something like CRC16 CCITT-FALSE, (0x1021 Poly, 0xFFFF initial, possibly reflected) but I am not able to calculate a match

I have some example Data, The end is a 16 byte CRC and 0x7E as the end of packet character,

0x7E 43                           E7 80   7E
0x7E 44                           58 F4   7E
0x7E C3 01                      0C FE   7E
0x7E C5 03                      Ce 89   7E
0x7E C3 02 3D 00 00 00   74 2D   7E

I can also source many more examples if needed, Anyone have any tricks on how to figure it out?

[nfmax]

See https://www.eevblog.com/forum/projects/unable-to-figure-checksum-algo!/msg1446027/#msg1446027

[Psi]

I'm assuming that initial 7E is the end of frame marker from the previous packet. So I have removed it.
Anyway, whatever that initial 7E is, it's not part of the data block being CRC'ed because once you remove it CRC-16/X-25 matches up nicely.

43                          = E7 80   
44                          = 58 F4   
C3 01                      =0C FE   
C5 03                      =Ce 89   
C3 02 3D 00 00 00   =74 2D   

Use https://crccalc.com/
Switch it to hex mode
Paste in the hex
Click CRC-16
Note: high and low are reversed for output.

etc, for input C3 02 3D 00 00 00  that website gives

Algorithm         Result      Check     Poly         Init        RefIn     RefOut    XorOut
CRC-16/X-25    0x2D74    0x906E   0x1021    0xFFFF   true       true      0xFFFF

I checked a couple of others and they also worked, so it's definitely X-25

[Rerouter]

Thank you very much Psi,
The 7E's are separate start and end of frame markers, so its a little odd that its not in the CRC. but this was the main puzzle piece left so now I can start fuzzing the thing.

[Psi]

Thank you very much Psi,
The 7E's are separate start and end of frame markers, so its a little odd that its not in the CRC. but this was the main puzzle piece left so now I can start fuzzing the thing.

I guess the Start Of Frame marker doesn't need to be CRC'ed, because the code only processes the frame when it detects the marker.
Any error in that byte and the data will be ignored anyway.

[bsdphk]

Be aware that 0x7e as a SOF/EOF marker almost always an indication of HDLC(-like) framing.

That can be done a number of ways, but common for them all is that they need to escape databytes of 0x7e so they do not get misinterpreted as EOF.

True HDLC is bit-serial protocol and it does bit-stuffing.

HDLC over byte-serial lines need to pick an escape-character which escapes not only 0x7e, but also itself, and maybe other "special" characters.  (Prudent: escape XON and XOFF on async lines).