deutsch1988
Newbie
Karma: +0/-0
Offline
Posts: 7
|
 |
« Reply #120 on: September 26, 2024, 09:59:43 PM »
|
|
|
All its same algo type, litle need mod... algo very simple, with this way i can example direct to OBD write flash and acces to virtual eeprom...
|
|
|
Logged
|
|
|
|
stranger
Newbie
Karma: +0/-0
Offline
Posts: 9
|
 |
« Reply #121 on: September 27, 2024, 08:11:40 AM »
|
|
|
Here is block from 192kb eeprom (tc1793) with correct CS. This block is literally empty. I played with old algo and different input parameters and never got correct CS: "60 4F" or "4F 60".
4B B8 01 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 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 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 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 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 60 4F
|
|
|
Logged
|
|
|
|
deutsch1988
Newbie
Karma: +0/-0
Offline
Posts: 7
|
 |
« Reply #122 on: September 30, 2024, 03:09:48 AM »
|
|
|
this are diference chk way
|
|
|
Logged
|
|
|
|
sergelhr
Newbie
Karma: +1/-0
Offline
Posts: 3
|
 |
« Reply #123 on: December 19, 2024, 10:40:35 AM »
|
|
|
CS block starting from 818C including 819B, now XOR with serial number but how? 9 occurences within dflash
|
|
|
Logged
|
|
|
|
Aslanius
Newbie
Karma: +0/-0
Offline
Posts: 2
|
 |
« Reply #124 on: January 15, 2025, 12:28:01 AM »
|
|
|
Greetings to all! My Bytes: 2000601941C1D9743200C0AE000000000000CDD F4B130000269F000000000000000000000000000 0000000000000000000000000000000000000000 0000000000000000000000000000000000000000 0000000000000000000000000000000000000000 0000000000000000000000000000000000000F5F 700003CB3115E CS1 6019 CS2 3CB3 115E
I use bytes 9 to 124 to calculate cs2: D9743200C0AE000000000000CDDF4B130000269 F000000000000000000000000000000000000000 0000000000000000000000000000000000000000 0000000000000000000000000000000000000000 0000000000000000000000000000000000000000 0000000000000000000000000F5F70000 If I use the algorithm:
unsigned long crc_buffer(unsigned long crc, const unsigned long* p, unsigned long sz) { const unsigned long poly = 0xEDB88320; unsigned long tmp1, tmp2;
while (sz--) { tmp1 = 0; tmp2 = crc & poly; for (int i = 0; i <= 31; i++) tmp1 ^= ((tmp2 >> i) & 1); crc = *p++ ^ ((crc << 1) | tmp1); } return crc; }
I'm getting the wrong result: F49F A0C5 if the result is inverted~crc: 0B60 5F30
|
|
|
Logged
|
|
|
|
Aslanius
Newbie
Karma: +0/-0
Offline
Posts: 2
|
 |
« Reply #125 on: January 15, 2025, 11:03:59 PM »
|
|
|
I figured out the problem was in the initialization bytes 
|
|
|
Logged
|
|
|
|
sergelhr
Newbie
Karma: +1/-0
Offline
Posts: 3
|
 |
« Reply #126 on: January 20, 2025, 08:50:58 AM »
|
|
|
i was struggling for weeks to unsterdand this thread, finally cs1 works ,an example in python.
import struct
def get_crc32_eeprom(data: bytes, crc_initial: int, start_offset: int = 0) -> str: # crc = crc_initial poly = 0xEDB88320
# Process data as DWORDs (4 bytes at a time), starting at the given offset for i in range(start_offset, len(data), 4): # Ensure there's enough data left for a full DWORD if i + 4 > len(data): break
# Read DWORD (4 bytes) in little-endian order dword = struct.unpack_from('<I', data, i)[0] # Print the DWORD being processed print(f"Processing DWORD at offset {hex(i)}: {hex(dword)}") tmp1 = 0 tmp2 = crc & poly
# Calculate tmp1 using parity bits for j in range(32): tmp1 ^= (tmp2 >> j) & 1 # Update CRC crc = dword ^ ((crc << 1) | tmp1)
# Return CRC as a hex string return hex(crc)
# Example usage if __name__ == "__main__": # Data block from the example data_block = bytes.fromhex( "08 00 6C BA 84 55 FF FF D7 FF 1E 57 E6 9A FF BA" "45 7B CD 6C CC D7 86 C9 58 0A 01 48 6C 2B 5C 39" "92 27 D5 8F AA 80 01 00 57 56 57 5A 5A 5A 41 55" "5A 46 57 35 33 39 35 34 32 A5 D4 8D 54 37 86 86" "8E 69 97 9A 7E 24 87 19 D7 9A FF 7C FC FA 85 E9" "95 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 00 00 54 9D DE" "FC 63 FE B7 CA 09 75 F2 6D 42 00 00 F8 C8 7F 9C" ) crc_initial = 0x0008 start_offset = 0x04 # Start calculation at offset 0x04
# Calculate and print the CRC32 checksum crc_result = get_crc32_eeprom(data_block, crc_initial, start_offset) # print(f"CRC32 last two bytes reversed: {crc_result}")
|
|
|
Logged
|
|
|
|
sergelhr
Newbie
Karma: +1/-0
Offline
Posts: 3
|
 |
« Reply #127 on: February 21, 2025, 09:59:45 AM »
|
|
|
0800105E6D1701003ADBDF3BED10BE854500D6722CD30034EB20163CC7912B9A59FEEF5DAA8001005756575A5A5A41555A4657353339353432E02E410E0E0641600FBBFBDF2FDFBF7EFF3FE6DB9C7829EF00000000000000000000000000000000000000000000000000000000BF6EBF7F9CB780DEEEFEBF2DCA000075B86A8B 128-Byte Block Structure Analysis from an EDC17C64 WFS5, done on 3 differents ECU ID Block Offset (0x00 to 0x01): 0800 CS1 Offset (0x02 to 0x03): 105E CS1 Initial ID Block: 0800 CS1 (Spread over 0x04 to 0x7F) Component Security (CS) at Offset 0x0C to 0x1B: ED10BE854500D6722CD30034EB20163C #crypted MAC Offset (0x0A to 0x0B & 0x1E to 0x1F): DF3B 2B9A #crypted Power Class at Offset 0x23: 5D #crypted Offset 0x24 to 0x27: No changes between files → AA800100 VIN at Offset 0x28 to 0x38: WVWZZZAUZFW539542 (Plain Text) Other Observations Offset 0x51 to 0x6C: No differences, all values set to 00
00000000000000000000000000000000000000000000000000000000 CS2 Initial Value at Offset 0x78 to 0x7B: 2DCA000 CS2 at Offset 0x7C to 0x7F: 75B86A8B CS2 Spanning from Offset 0x04 to 0x77
|
|
« Last Edit: February 21, 2025, 11:54:46 AM by sergelhr »
|
Logged
|
|
|
|
|