Skip to content

Conversation

@hwti
Copy link

@hwti hwti commented Sep 25, 2025

The firmware version is at offset 0xC9 instead of 0xB9.

I added the FindByProduct first, but it would be better to have an argument, or to dump all devices.

The firmware version is at offset 0xC9 instead of 0xB9.
@hwti
Copy link
Author

hwti commented Sep 25, 2025

Here is the firmware I extracted from a "PH66" card from Aliexpress : 200311_83_02_02.zip
I was surprised by the date (2020 is probably very early), but MPTool displays the same version.

@cyrozap Since you list two cards on https://github.com/cyrozap/asmedia-xhc-re/blob/master/doc/Notes.md, did you dump the firmwares ?

==== File Info ====
File: 200311_83_02_02.bin
File Checksum [header]: 0x3E (expected: 0x3E)
File Checksum   [body]: 0x56 (expected: 0x56)
Checksum OK
Signature: 2324A_RCFG
FW Name: 2324A_FW
Footer: 2324A_FW
Chip: 0x83: ASM3242
==== Actual Chip Info ====
Chip Rev0: 0x00
Chip Rev1: 0x00

@cyrozap
Copy link

cyrozap commented Sep 26, 2025

Since you list two cards on https://github.com/cyrozap/asmedia-xhc-re/blob/master/doc/Notes.md, did you dump the firmwares ?

Yes, I have. The ORICO PE20-1C and the IOCrest IO-PCE3242-1C both use the same firmware image. Or at least they did at the time I bought them 4-5 years ago--their manufacturers might have updated the shipped firmware images since then.

Here's the output from my validate_fw.py tool on the image:

Chip: ASM3242
Firmware version: 191017_83_02_00
Header checksum OK! 0xa0
Header CRC32 OK! 0x89e6a4d5
Code checksum OK! 0x53
Code CRC32 OK! 0x3961f805
Code signature: 1bd58025a75ecb674a3d4f64ecaa31b10bf55caa7b39b0acedbd3913769a5f6d

Also, FWIW, the way AsmTool/AsmFirmware.cs currently extracts the version is incorrect. The firmware image has a uint16_t header length at byte offset 4, which is equal to the byte offset of the header checksum byte. Following the header checksum byte is the 4-byte CRC-32 of the header, and following that is the 2-byte or 4-byte (depending on the header "RCFG" magic) firmware body length. The firmware image version is always at byte offset 0x80 (128) into the firmware body. So for correct operation, the firmware image parser needs to:

  1. Read the header length at offset 4.
  2. Read the header "RCFG" magic at offset 6.
  3. If the header "RCFG" magic is equal to U2104_RCFG (ASM1042), 2104B_RCFG (ASM1042A), or 2114A_RCFG (ASM1142), then the size of the body length is 2. Otherwise, it's 4.
  4. Add the header length (varies), the size of the header checksum byte (1), the size of the header CRC-32 (4), the size of the body length (varies, always either 2 or 4), and the firmware version offset (128) to get the absolute offset to the firmware version.

This parsing procedure will work for all ASMedia USB host controller firmware images, without having to hardcode a fixed absolute offset to the firmware version. This is important for any firmware images that take advantage of the feature to write to internal MMIO registers (in the 8051's XDATA address space) of the chip, since firmware images that use that functionality will have different offsets for the firmware version than the ones currently hardcoded in AsmTool/AsmFirmware.cs.

If you want to visualize what I'm talking about, load this file and a firmware image into the Kaitai Web IDE. That will parse all the fields in the firmware image and display an interactive hex view and structure tree view of the image.

@hwti
Copy link
Author

hwti commented Sep 26, 2025

Firmware version: 191017_83_02_00

So even older, and maybe with hardware differences (the 00 vs 02).
There are many firmwares for other chips, but nothing for this one.

Also, FWIW, the way AsmTool/AsmFirmware.cs currently extracts the version is incorrect [...]

I will look at it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants