You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
This is a continuation of #1714 with better reproducibility steps and a patch that fixes the problem, but probably introduces other problems.
The bug seems to be more general and to do with the way the packets are being sent via UART on macOS.
To Reproduce
Compile latest pm3 + firmware on macOS.
Flash the firmware onto the Proxmark 3.
Grab a passport utilizing ISO/IEC 14443(B) as a communication standard.
Run hf emrtd info.
Expected behavior
Details of passport being printed.
Instead, observed behavior is:
[usb] pm3 --> hf emrtd info -m xyz
[=] ..
[=] Authentication is enforced
[=] Switching to external authentication...
[=] External authentication with BAC successful.
[=] ------------------ Basic Info ------------------
[+] Communication standard: ISO/IEC 14443(B)
[+] Authentication........: Enforced
[+] PACE..................: Available
[+] Authentication result.: Successful
[=] ----------------- EF_CardAccess ----------------
[+] PACE version..........: 2
[+] PACE algorithm........: ECDH, Generic Mapping, AES-CMAC-256
[+] PACE parameter........: NIST P-256 (secp256r1)
[=] You can cancel this operation by pressing the pm3 button
[!!] 🚨 APDU: reply timeout
[!!] 🚨 Failed to secure select 011E
[!!] 🚨 Failed to read EF_COM.
After minimum viable patch from below is applied, passport is read successfully:
[=] ..
[=] Authentication is enforced
[=] Switching to external authentication...
[=] External authentication with BAC successful.
[=] ------------------ Basic Info ------------------
[+] Communication standard: ISO/IEC 14443(B)
[+] Authentication........: Enforced
[+] PACE..................: Available
[+] Authentication result.: Successful
[=] ----------------- EF_CardAccess ----------------
[+] PACE version..........: 2
[+] PACE algorithm........: ECDH, Generic Mapping, AES-CMAC-256
[+] PACE parameter........: NIST P-256 (secp256r1)
[=] ..
[=] -------------------- EF_COM --------------------
[+] EF_DG1 ...............: Details recorded in MRZ
[+] EF_DG2 ...............: Encoded Face
[+] EF_DG14...............: Security Options
[=] ...............
[=] ..
[=] -------------------- EF_DG1 --------------------
[+] Document Type.........: Passport
[+] Document Form Factor..: TD3
[+] Issuing state.........: GBR
[+] Nationality...........: GBR
[... omitted ...]
Desktop (please complete the following information):
Upon research on #2289 with three separate passports issued by different countries, I managed to trace down the issue and "fix" it.
In particular:
Hungarian passport issued in 2019 using ISO/IEC 14443(A) w/ optional PACE support worked fine.
UK passport issued 2024 using ISO/IEC 14443(B) w/ optional PACE support results in the crash seem above.
Polish passport issued 2014 using ISO/IEC 14443(A) w/o PACE support works fine.
Then after debugging the exact communications path differences, I noticed the following:
Passport using NFC-A send data via ExchangeAPDU14a(), and they communicate fine.
Passports using NFC-B send data via exchange_14b_apdu(), and they cause the device to crash.
Enabling
#defineCOMMS_DEBUG#defineCOMMS_DEBUG_RAW
in client/src/comms.c indicated that:
NFC-A passports use the MIX frames in the appropriate function to talk to the pm3
NFC-B passports use the NG frames to talk to the pm3
After extensive debugging across the comms path on both the client-side and the device-side, it seems that:
the client successfully sends the data to the Proxmark via UART
however, the device firmware never processes the data, in particular, sending debug messages from receive_ng_internal do not get sent from the device and it ends up being locked
Therefore, as receive_ng() is continuously called from the event loop in the firmware, it seems that receive_ng never passes control over to receive_ng_internal.
This led to the minium viable fix for the issue, which is:
diff --git a/armsrc/cmd.c b/armsrc/cmd.c
index ee2565cd2..fb0ea539d 100644
--- a/armsrc/cmd.c+++ b/armsrc/cmd.c@@ -232,7 +232,7 @@ static int receive_ng_internal(PacketCommandNG *rx, uint32_t read_ng(uint8_t *da
int receive_ng(PacketCommandNG *rx) {
// Check if there is a packet available
- if (usb_poll_validate_length())+ if (usb_check())
return receive_ng_internal(rx, usb_read_ng, true, false);
#ifdef WITH_FPC_USART_HOST
Unfortunately, as usb_poll_validate_length was introduced for a reason, this is likely not the correct fix, but it does cause the passport to be read correctly on macOS.
I hope this framing of the issue will make it easier to track down the cause, which now looks likely to be related to the uart implementations in the macOS POSIX SDK instead of the emrtd code path specifically.
The text was updated successfully, but these errors were encountered:
Describe the bug
This is a continuation of #1714 with better reproducibility steps and a patch that fixes the problem, but probably introduces other problems.
The bug seems to be more general and to do with the way the packets are being sent via UART on macOS.
To Reproduce
ISO/IEC 14443(B)
as a communication standard.hf emrtd info
.Expected behavior
Details of passport being printed.
Instead, observed behavior is:
After minimum viable patch from below is applied, passport is read successfully:
Desktop (please complete the following information):
Additional context
Upon research on #2289 with three separate passports issued by different countries, I managed to trace down the issue and "fix" it.
In particular:
ISO/IEC 14443(A)
w/ optional PACE support worked fine.ISO/IEC 14443(B)
w/ optional PACE support results in the crash seem above.ISO/IEC 14443(A)
w/o PACE support works fine.Then after debugging the exact communications path differences, I noticed the following:
ExchangeAPDU14a()
, and they communicate fine.exchange_14b_apdu()
, and they cause the device to crash.Enabling
in
client/src/comms.c
indicated that:MIX
frames in the appropriate function to talk to the pm3NG
frames to talk to the pm3After extensive debugging across the comms path on both the client-side and the device-side, it seems that:
receive_ng_internal
do not get sent from the device and it ends up being lockedTherefore, as
receive_ng()
is continuously called from the event loop in the firmware, it seems thatreceive_ng
never passes control over toreceive_ng_internal
.This led to the minium viable fix for the issue, which is:
Unfortunately, as
usb_poll_validate_length
was introduced for a reason, this is likely not the correct fix, but it does cause the passport to be read correctly on macOS.I hope this framing of the issue will make it easier to track down the cause, which now looks likely to be related to the uart implementations in the macOS POSIX SDK instead of the
emrtd
code path specifically.The text was updated successfully, but these errors were encountered: