Custom Mainboard Design for Forensic Device
Thought for 9 sec
You’re looking at the main project, not the connector part project.
In your screenshot:
- Left side = chat/Copilot panel
- Right side = component library/search/properties area
- You are not inside the cloned Amphenol connector part editor
Open this part project directly:
That should take you to the imported connector part by itself.
Then:
- Click Schematic at the top.
- Click one of the small terminal symbols on the connector.
- The properties panel should appear on the right side.
- Look for fields like:
- Pin Number
- Pin Name
- Terminal / Pad
But honestly, don’t fight the UI too much.
Easier path
Since the part already exists at:
If you can find a way to rename the terminals there, do it. If not, send Flux support this:
I need help renaming the terminals onmkgemmell/20021121-00040t4lfto createOlimex_GPIO1, while preserving terminal numbers 1–40 and the existing footprint pads 1–40.
The exact terminal list is the one we already built.
Verify and support
Verify Amphenol parts
Draft support request
Create mapping docs
Plan next schematic
Refine this doc
Ask about this doc
Architecture Notes - USB Write Blocker
Summary
The requested path has been refined again to: USB 3.x Type-A evidence input → Olimex iMX8MP-SOM-4GB-IND write-block front end → trusted downstream interface/status path → Raspberry Pi. The Raspberry Pi must not directly mount or own the suspect USB device.
The key architecture issue is that STM32H753 is not a USB 3.x SuperSpeed bridge device. It can support USB 2.0 Full-Speed and High-Speed operation, with high-speed operation requiring an external ULPI PHY. It cannot terminate, inspect, and regenerate USB 3.x SuperSpeed traffic.
New active decision: use the Olimex iMX8MP-SOM-4GB-IND instead of the STM32H753 + USB3300 prototype. This removes the U20 ULPI/QFN fanout blocker by using the SOM's integrated USB3-capable controllers and pre-solved DDR/PMIC/BGA implementation. The internal Gigabit switch remains selected for external Ethernet/Pi networking, but its exact relationship to the SOM is TBD after connector pinout capture.
Evidence Checked
- STM32H753 library part found: STM32H753ZIT6, active STMicroelectronics MCU.
- Datasheet extract: STM32H753 has two USB OTG interfaces and supports USB 2.0 FS/HS up to 480 Mbit/s. USB HS1 requires an external ULPI PHY for 480 Mbit/s high-speed operation.
- No USB 3.x SuperSpeed PHY/controller capability was found in the STM32H753 datasheet extract.
- Independent review agreed that STM32H753 is unsuitable as an inline USB 3.0 SuperSpeed write-block bridge.
Why Pass-Through Is Not Acceptable
USB 3.x devices use SuperSpeed TX/RX differential pairs in addition to USB 2.0 D+/D-. If the SuperSpeed lanes are passed through while an MCU only monitors USB 2.0, writes can bypass the blocker completely.
A real write blocker must terminate USB on both sides:
Diagram
Internal Gigabit Switch Boundary
The internal Gigabit Ethernet switch is the selected API/data path between the write-block front end and the Raspberry Pi.
Design intent:
- The Pi runs Python3 malware and BadUSB scanning software.
- The Pi never directly mounts the suspect USB storage device.
- The Pi requests descriptors, file listings, block reads, hashes, and scan data from a service on the write-block front end.
- The write-block front end owns USB enumeration and read-only policy enforcement.
- BadUSB detection includes descriptor/interface analysis, especially suspicious HID, network, serial, or composite-device behavior.
- The switch connects external RJ45/PoE Ethernet, Raspberry Pi, and STM32MP257/write-block front end.
- Selected switch IC: Microchip KSZ9893RNXC-TR, a 3-port Gigabit Ethernet switch.
- Switch management controller: STM32MP257. Preferred control bus is SPI so the write-block front end can configure VLANs/private API isolation and switch policy directly.
- Initial schematic wiring uses STM32MP257 SPI4: PA6/SCK, PA10/MISO, PA5/MOSI, and PA9/NSS connected to KSZ9893 SCL/MDC, SDO, SDI/SDA/MDIO, and ~SCS respectively.
- The Pi-to-write-block API should use a private subnet or VLAN and should not be directly exposed to the external LAN by default.
- This switch-based approach is preferred over direct PHY-to-PHY routing because it is easier to validate, more debuggable, and scales better if service/debug networking is added later.
Protocol Requirements
The blocker must understand USB mass-storage transport and SCSI command behavior.
Minimum policy areas:
- Block obvious writes: WRITE(6), WRITE(10), WRITE(12), WRITE(16), WRITE SAME, WRITE BUFFER.
- Block or safely emulate destructive/configuration commands: FORMAT UNIT, MODE SELECT, UNMAP/TRIM, SANITIZE, SECURITY PROTOCOL OUT, firmware update, vendor-specific modifying commands.
- Present consistent read-only state to the upstream host where possible.
- Log blocked commands, device descriptors, capacity, serial number where available, firmware version, and timestamps.
- Fail closed if the policy engine crashes, resets, or cannot classify a command.
Architecture Options
Option A - STM32H753 USB 2.0-only prototype
Use STM32H753 with USB HS host/device capability and external ULPI PHY as needed. This may be useful for learning and proof-of-concept work, but it is not a USB 3.0 forensic write blocker.
Pros:
- Lower design complexity.
- Uses the requested STM32H753.
- More approachable firmware scope than USB 3.x.
Cons:
- Limited to USB 2.0 high-speed, 480 Mbit/s theoretical max.
- Not suitable for a USB 3.x SuperSpeed product claim.
- Still requires serious SCSI/BOT policy work and validation.
Option B - USB 3.x-capable SoC / bridge architecture
Use silicon that can act as USB 3.x host toward evidence media and USB 3.x device/gadget or equivalent controlled interface toward the Pi.
Pros:
- Can support true SuperSpeed paths.
- Better aligned with modern USB SSD workflows.
Cons:
- Much higher hardware and firmware complexity.
- UASP support and validation are difficult.
- May require embedded Linux, multiple USB controllers, PCIe, or FPGA/controller ICs.
Option C - Commercial forensic USB 3.x write-block module/appliance
Use a validated external or embedded commercial write-blocker path and let the Pi handle UI, logging, hashing, networking, and workflow.
Pros:
- Best path for real evidence use.
- Lower legal/evidence-integrity risk.
- Reduces custom USB protocol burden.
Cons:
- Less custom hardware integration.
- BOM cost and mechanical constraints may be higher.
Current Recommendation
Do not continue spending routing effort on the STM32H753 + USB3300 path. The active direction is the Olimex iMX8MP-SOM-4GB-IND carrier architecture.
Connector-symbol blocker is mostly cleared: dedicated Olimex_GPIO1..GPIO6 components were created with verified schematic terminals. The remaining blocker is footprint verification: the parts must use the exact Olimex carrier-side PA-V16X footprints before layout and routing. After that, wire USB1/USB2 role straps, SuperSpeed pairs, VBUS behavior, and THREAT/MEDIA_READY GPIOs.
Summary
Evidence Checked
Why Pass-Through Is Not Acceptable
Internal Gigabit Switch Boundary
Protocol Requirements
Architecture Options
Option A - STM32H753 USB 2.0-only prototype
Option B - USB 3.x-capable SoC / bridge architecture
Option C - Commercial forensic USB 3.x write-block module/appliance
Current Recommendation
