fix(xfactor): change wrong image paths

This commit is contained in:
2024-03-14 15:32:54 +01:00
parent 6e59037725
commit 5f68d2ef09

View File

@@ -57,7 +57,7 @@ If you want more informations about CTAP and such, please click [here](https://f
## Packet buildin' ## Packet buildin'
Thanks to the dissector, I can now at least see the U2F conversations. Thanks to the dissector, I can now at least see the U2F conversations.
![img](packet-building.png) ![img](./images/packet-building.png)
That sure is a lot of _CTAPHID Initialization_ and _CTAPHID Continuation_ packets! That sure is a lot of _CTAPHID Initialization_ and _CTAPHID Continuation_ packets!
Judging from what's being said [here](https://fidoalliance.org/specs/fido-v2.0-id-20180227/fido-client-to-authenticator-protocol-v2.0-id-20180227.html#usb-message-and-packet-structure), an _CTAPHID Initialization packet_ comes first and one or more _CTAPHID Continuation packets_ follow to complete the payload. Judging from what's being said [here](https://fidoalliance.org/specs/fido-v2.0-id-20180227/fido-client-to-authenticator-protocol-v2.0-id-20180227.html#usb-message-and-packet-structure), an _CTAPHID Initialization packet_ comes first and one or more _CTAPHID Continuation packets_ follow to complete the payload.
@@ -83,7 +83,7 @@ Using *Short encoding* would make them fit on 1 byte, but that would reduce the
### Responses ### Responses
Here's a response (that contains data, and that is not always the case): Here's a response (that contains data, and that is not always the case):
![img](responses.png) ![img](./images/responses.png)
As you can see, a responses are a bit simpler: As you can see, a responses are a bit simpler:
- **Response data**: **LE** bytes if specified, n bytes if not - **Response data**: **LE** bytes if specified, n bytes if not