robertfisk / usg Goto Github PK

Various use-cases (forensics, enhanced paranoia) have a need for a read-only mass storage mode. This could be either a compile-time option, or dynamically set on bootup based on an input pin controlled by the user.

Both Upstream and Downstream would need to be put into read-only mode to ensure robustness in the face of USB exploits coming from either direction.

Add your email address here if you are interested in pre-ordering next batch.

Ole Tange [email protected]

A user reported their DIY v0.9 running 0.9r03 firmware was not working. Upstream was stuck in the CheckFirmwareMatchesHardware() function on bootup.

We determined this was due to the PC12-pullup check failing (implying that the firmware was not running on a H405 board). Bypassing the PC12 check allowed normal functionality.

We need to determine if this issue can be fixed with a delay in the PC12 check, and how much delay is required. Or whether the issue is due to a logic threshold change, in which case we probably want to find another way to confirm we are running on a H405 board.

Looks like USG incorrectly send device size information - always it's one block smaller:

Raw device:

usb-storage 3-1.2:1.0: USB Mass Storage device detected
scsi host6: usb-storage 3-1.2:1.0
scsi 6:0:0:0: Direct-Access     Generic  Flash Disk       5.00 PQ: 0 ANSI: 2
sd 6:0:0:0: Attached scsi generic sg0 type 0
sd 6:0:0:0: [sda] 4096000 512-byte logical blocks: (2.10 GB/1.95 GiB)
sd 6:0:0:0: [sda] Write Protect is off
sd 6:0:0:0: [sda] Mode Sense: 0b 00 00 08
sd 6:0:0:0: [sda] No Caching mode page found
sd 6:0:0:0: [sda] Assuming drive cache: write through
 sda: sda1
sd 6:0:0:0: [sda] Attached SCSI removable disk

With USG:

scsi 7:0:0:0: Direct-Access     The USG  is Good, not bad v1.0 PQ: 0 ANSI: 2
sd 7:0:0:0: Attached scsi generic sg0 type 0
sd 7:0:0:0: [sda] 4095999 512-byte logical blocks: (2.10 GB/1.95 GiB)
sd 7:0:0:0: [sda] Write Protect is off
sd 7:0:0:0: [sda] Mode Sense: 00 00 00 00
sd 7:0:0:0: [sda] Asking for cache data failed
sd 7:0:0:0: [sda] Assuming drive cache: write through
 sda: sda1
sda: p1 size 4095968 extends beyond EOD, enabling native capacity
 sda: sda1
sda: p1 size 4095968 extends beyond EOD, truncated
sd 7:0:0:0: [sda] Attached SCSI removable disk

• Connected fat32 formatted flash drive to Win10 machine.
• Got a popup saying drive needs a scan.
• Ignored popup, did not attempt to access the drive.
• Approx 30sec later, Upstream MCU freaked out (red flashing LED on USG v1.0)
• Removed and reinserted flash drive, ran scan as requested, scan finished and everything fine. Cannot trivially reproduce.

Generally speaking, Upstream should not freak out in any circumstance. If I or anyone else sees this happen I will investigate further. Until then this will be a low priority.

Every now and then discussion surfaces about profiling users by characterizing their input actions. It would be cool if the USG could render this profiling ineffective, by de-randomizing keyboard and mouse inputs. Presumably by homogenizing keystroke timings, mouse velocity, etc.

Note that this is the opposite of the HID bot-detect feature currently under development.

It would be nice to have a single device that could both isolate the keyboard and boot the machine via Qubes AEM.