green-green-avk / AnotherTerm

Local PTY, USB and Bluetooth serial ports, SSH and Telnet terminal client for Android. Xwayland support (in dev only).
https://green-green-avk.github.io/AnotherTerm-docs/
Other
190 stars 19 forks source link

Unable to access CTAP2 device to backup in Debian PRoot #45

Closed spoelstraethan closed 1 year ago

spoelstraethan commented 1 year ago

On the plus side, I was able to dump a full device backup in the regular backup mode, unfortunately I haven't been able to perform an export or import which is more useful than full backup for adding new entries while away from a PC.

It is possible that there is a special U2F or security key permission that needs requested to interact with that aspect of the device. The Yubikey Authenticator app might have an example of that permission even though it's a different device.

This first section is the output from the PRoot, I'll add the lsusb from a working Linux install shortly.

(venv) root@localhost:~/xous-core/apps/vault/tools/vaultbackup-rs# lsusb
Bus 002 Device 005: ID 1209:3613 Generic
(venv) root@localhost:~/xous-core/apps/vault/tools/vaultbackup-rs# cargo run backup password backup.json
   Compiling indexmap v1.9.1
   Compiling proc-macro-error-attr v1.0.4
   Compiling hidapi v1.4.1
   Compiling proc-macro-error v1.0.4
   Compiling ctaphid v0.1.1
   Compiling protobuf-parse v3.1.0
   Compiling clap_derive v3.2.7
   Compiling protobuf-codegen v3.1.0
   Compiling clap v3.2.12
   Compiling vaultbackup-rs v0.1.0 (/root/xous-core/apps/vault/tools/vaultbackup-rs)
warning: could not load dep-graph from `/root/xous-core/target/debug/incremental/build_script_build-3lraug2goa318/s-gnoqpkxkpv-ixe1ek-working/dep-graph.bin`: memory map must have a non-zero length

warning: `vaultbackup-rs` (build script) generated 1 warning
warning: could not load dep-graph from `/root/xous-core/target/debug/incremental/vaultbackup_rs-30h2kapme4mw8/s-gnoqpo1bm5-xm1t8c-working/dep-graph.bin`: memory map must have a non-zero length

warning: `vaultbackup-rs` (bin "vaultbackup-rs") generated 1 warning
    Finished dev [unoptimized + debuginfo] target(s) in 21.97s
     Running `/root/xous-core/target/debug/vaultbackup-rs backup password backup.json`
Error: no CTAP2 devices found
(venv) root@localhost:~/xous-core/apps/vault/tools/vaultbackup-rs# lsusb
Bus 002 Device 005: ID 1209:3613 Generic
(venv) root@localhost:~/xous-core/apps/vault/tools/vaultbackup-rs# lsusb -v

Bus 002 Device 005: ID 1209:3613 Generic
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.10
  bDeviceClass            0
  bDeviceSubClass         0
  bDeviceProtocol         0
  bMaxPacketSize0         8
  idVendor           0x1209 Generic
  idProduct          0x3613
  bcdDevice            0.10
  iManufacturer           1
  iProduct                2
  iSerial                 3
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength       0x0029
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0
    bmAttributes         0x80
      (Bus Powered)
    MaxPower              100mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass         3 Human Interface Device
      bInterfaceSubClass      0
      bInterfaceProtocol      0
      iInterface              4 U2F Token
        HID Device Descriptor:
          bLength                 9
          bDescriptorType        33
          bcdHID               1.11
          bCountryCode            0 Not supported
          bNumDescriptors         1
          bDescriptorType        34 Report
          wDescriptorLength      34
         Report Descriptors:
           ** UNAVAILABLE **
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               5
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x02  EP 2 OUT
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               5
Binary Object Store Descriptor:
  bLength                 5
  bDescriptorType        15
  wTotalLength       0x000c
  bNumDeviceCaps          1
  USB 2.0 Extension Device Capability:
    bLength                 7
    bDescriptorType        16
    bDevCapabilityType      2
    bmAttributes   0x00000000
      (Missing must-be-set LPM bit!)
Device Status:     0x0000
  (Bus Powered)
(venv) root@localhost:~/xous-core/apps/vault/tools/vaultbackup-rs#
green-green-avk commented 1 year ago

Is it possible to see both lsusb outputs (PC and Android) just to compare?

spoelstraethan commented 1 year ago

Yeah, I'll upload those, I think I just figured out part of the problem though.

The import/export tool I'm using is written in Rust and it's using a hidapi crate that requires the system packages libhidapi-hidraw0 and libhidapi-dev and therefore it is trying to access the device directly via /dev/hidrawN instead of through libusb.

This just occurred to me when without doing an lsusb beforehand the Python full device backup script prompted me to allow access to the device but I don't get that prompt from the Rust version and even if I use lsusb to attach the device beforehand it can't see it.

I'm not sure if the device's creator (who also hacked together the Python and Rust tooling) would be interested in using a libusb crate abstraction layer if one exists or if there's a way to patch the libhidapi bits for PRooted Linux on Android.

On Sun, Aug 13, 2023, 1:52 PM green-green-avk @.***> wrote:

Is it possible to see both lsusb outputs (PC and Android) just to compare?

— Reply to this email directly, view it on GitHub https://github.com/green-green-avk/AnotherTerm/issues/45#issuecomment-1676435889, or unsubscribe https://github.com/notifications/unsubscribe-auth/ANPSNA2D2A5ZOQSOAESYEPTXVEPAPANCNFSM6AAAAAA3NLISIE . You are receiving this because you authored the thread.Message ID: @.***>

green-green-avk commented 1 year ago

https://github.com/libusb/hidapi

On Linux, either the hidraw or the libusb back-end can be used. There are tradeoffs, and the functionality supported is slightly different. Both are built by default. It is up to the application linking to hidapi to choose the backend at link time by linking to either libhidapi-libusb or libhidapi-hidraw.

Possibly, no code changes should be required in order to use libusb here at least...

green-green-avk commented 1 year ago

Android has no hidraw specific API available for apps.

Maybe, it's possible to make a wrapper for full libhidapi-hidraw functionality via libhidapi-libusb... Some research is required.

spoelstraethan commented 1 year ago

So I attempted to override the default hidapi implemented used by Rust to linux-shared-libusb instead of linux-shared-hidraw but without success on my first few attempts.

Then I attempted to implement the barest minimum Rust "app" using the example code from https://docs.rs/hidapi/ but it was printing nothing in its device list. That made me think that my override wasn't working and it was still trying to use hidraw, so I played around with a couple different override methods and finally got it to apply, and then it complained that libusb-1.0 wasn't available even though I'd performed the libusb "fix". I installed libusb-1.0-0-dev and that appeared to sort the issue and I was able to list the device.

Then I attempted to get that MVP pulled into the Cargo.toml of the software I'm attempting to get working to see if it enabled the missing functionality. It appears that while the hidapi-shared-libusb worked in my simple app, with the wider set of crates pulled in I ended up having to switch to hidapi-static-libusb, and then it worked wonderfully, so I think this can be considered resolved, as long as a person can use libusb.

spoelstraethan commented 1 year ago

It also seems that the main reason a lot of folks have been using hidraw is that libusb hasn't always been able to resolve some of the self describing attributes like DeviceInfo while hidraw has been pretty effective at that.