Hi all,
during the last days I've tried to setup cardem with a simtrace2 under Manjaro/Arch and ran into some non-default problems. I've found solutions to all of them and would like to share this :)
You'll find the detailed documentation below.
Have a great day, Katharina
# Card Emulation on simtrace2 under Arch/Manjaro I ran into some troubles setting everything up under Manjaro/Arch and document the troubleshooting as follows. All of this is about card emulation via cardem.
Problem: Using the default firmware, the phone shows "invalid SIM card" and handing over the commercial SIM does not work.
## System and Setup $ lsb_release -a LSB Version: n/a Distributor ID: ManjaroLinux Description: Manjaro Linux Release: 21.0.4 Codename: Ornara
1. Smart card reader in the computer, commercial SIM attached, tested via pcsc_scan 2. simtrace2 attached to the computer via USB, tested via dfu-util --list and ./simtrace2-list 3. Oneplus 6T, rooted, attached via nano SIM breakout 4. Remote control via adb (optional)
## Building Things I was not satisfied with the AUR version of libosmocore and needed to build the firmware manually, so the following documents who to first build libosmocore, then simtrace, and then the cardem firmware.
### Libosmocore Both AUR versions didn't really work for me, I've tested with 2 due to 1 being out of date:
2 aur/libosmocore-git 0.9.6.r165.ff20641-1 (+1 0.00) Osmocom core library
1 aur/libosmocore 1.3.0-1 (+15 0.00) (Out-of-date: 2020-07-29) core libs for osmocom
#### Building libosmocore Installing the requirements was straightforward for libosmocore, so I'll skip it here. After the requirements, follow the wiki tutorial:
git clone git://git.osmocom.org/libosmocore.git cd libosmocore autoreconf -fi ./configure make sudo make install
Then the first problem occured: although libosmocore was installed successfully, simtrace would not find it when running ./configure:
configure: error: Package requirements (libosmocore >= 1.0.0) were not met: Package 'libosmocore', required by 'virtual:world', not found
The reason for this is chaos in the pkgconf paths. For me, manually adding the path did not help because the .pc files were not in the right place:
export PKG_CONFIG_PATH=/usr/local/lib/pkgconfig
The solution in my case was copying the .pc files from the libosmocore dir to the default pkgconf path:
sudo cp libosmocore/*.pc /usr/lib/pkgconfig
After that, the simtrace ./configure worked and I could build it.
#### Card Emulation To test different firmwares, I checked out origin/hoernchen/simtrace_cardem (others might also work) and built the cardem firmware manually. The cross-compile process on Arch/Manjaro introduced another problem resulting in stdlib not being found:
libosmocore/source/backtrace.c:28:10: fatal error: stdlib.h: No such file or directory 28 | #include <stdlib.h> | ^~~~~~~~~~
This can be fixed via
sudo pacman -S arm-none-eabi-gcc arm-none-eabi-newlib
I had arm-none-eabi-gcc installed, but only adding arm-none-eabi-newlib solved the problem for me. After that building the firmware worked well, in my particular setting I used
make APP=cardem BOARD=simtrace MEM=dfu
After that I could flash the firmware and the card emulation worked.
## Flashing and Runing cardem
### Preparation Check if the simtrace is detected and get the device information: dfu-util --list
Go to the simtrace repo: cd Documents/Repos/simtrace2/host/src
Flash the device, --device info might need to be adjusted: dfu-util --device 1d50:60e3 --cfg 1 --alt 1 --reset --download path-to-repo/simtrace2/firmware/bin/simtrace-cardem-dfu.bin
After flashing, it should look like this: ./simtrace2-list USB matches: 1 1d50:60e3 Addr=22, Path=6-1.2.3, Cfg=1, Intf=0, Alt=0: 255/2/0 (CardEmulator Modem 1)
### Running Cardem From the wiki with some extensions:
1. power off phone 2. insert card adapter cable into phone 3. insert card adapter cable SIMtrace v2 board 4. plug SIMtrace v2 board in host computer USB port 5. connect external card reader to host (any USB CCID reader should do the job) 6. ensure a card is present in the reader slot (not in the SIMtrace port) 7. check if the card is detected by the reader (use CTRL-C to exit)
For the next step it's important to use the correct device information and path: 8. sudo ./simtrace2-cardem-pcsc -V 1d50 -P 60e3 -C 1 -H "6-1.2.3" 9. power on phone
After fixing all the above, I could successfully push through the commercial SIM in the computer.
Yeeha :)
Hi Katharina,
sorry to hear about your somewhat lengthy journey. But the good part is you could all get it to work in the end.
cardem support in "master" of the simtrace2 firmware should be working since April 25 (commit c690a1f13042c5a1a464cf094b6d304dfb8b6288), which is when I merged/ported the relevant changes from 'hoernchen/simtrace_cardem'. That version has been successfully used both by myself and another user.
If you experience problems with cardem from "master", I would be very much interested in getting more details about that so we can hopefully get this resolved.
btw: If you'd like to register an user account at https://osmocom.org/ and share the account name with me, I'm happy to grant wiki editing permissions.
Thanks, Harald
Hi Harald,
I just switched to the master branch, rebuilt the firmware (simtrace-cardem-dfu), flashed again and tested: It doesn't seem to work and is back to a state where the phone doesn't even recognize it has a SIM (after reboot). Switching back to the hoernchen branch (+build + flash +run +reboot) still works.
So it seems there is a problem left in the master firmware, but I'll need to start debugging to find out more here.
Best, Katharina
On 5/20/21 4:22 PM, Harald Welte wrote:
Hi Katharina,
sorry to hear about your somewhat lengthy journey. But the good part is you could all get it to work in the end.
cardem support in "master" of the simtrace2 firmware should be working since April 25 (commit c690a1f13042c5a1a464cf094b6d304dfb8b6288), which is when I merged/ported the relevant changes from 'hoernchen/simtrace_cardem'. That version has been successfully used both by myself and another user.
If you experience problems with cardem from "master", I would be very much interested in getting more details about that so we can hopefully get this resolved.
btw: If you'd like to register an user account at https://osmocom.org/ and share the account name with me, I'm happy to grant wiki editing permissions.
Thanks, Harald
Hi Katharina,
On Thu, May 20, 2021 at 04:46:57PM +0200, Katharina Kohls wrote:
Hi Harald,
I just switched to the master branch, rebuilt the firmware (simtrace-cardem-dfu), flashed again and tested: It doesn't seem to work and is back to a state where the phone doesn't even recognize it has a SIM (after reboot). Switching back to the hoernchen branch (+build + flash +run +reboot) still works.
Thanks for your feedback. It would be great to get the log output of the host software in this scenario, and - if you have a serial cable - the debug UART (2.5mm stereo jack) of the SIMtrace2 device.
Regards, Harald
Hi Harald,
below is the serial output for the master firmware. I first flashed and reset to verify that the serial output is working, then started cardem on the simtrace, and then rebooted the phone. For reference I have attached a cropped version of the serial output with the hoernchen branch firmware (which is obviously much longer).
BTW while debugging this I realized that the pin layout might be documented in the wrong order: The wiki says TX is on 4 (pin 1 = GND, pin 4 = TX, pin 5 = RX), however, for me it only worked when hooking up pin 5 with the RX of my UART to USB. Is that a typo?
Best, Katharina
b'\r=============================================================================\n' b'\rSIMtrace2 firmware 0.7.0.103-c690-dirty, BOARD=simtrace, APP=cardem\n' b'\r(C) 2010-2019 by Harald Welte, 2018-2019 by Kevin Redon\n' b'\r=============================================================================\n' b'\r-I- Chip ID: 0x28900960 (Ext 0x00000000)\n' b'\r-I- Serial Nr. 51203220-574a4a52-32303620-32313037\n' b'\r-I- Reset Cause: user reset (NRST pin detected low)\n' b'\r-I- USB init...\n' b'\rUSBD_Init\n' b'SetAddr(11) -W- Sta 0x888A8 [0] -W- _ -W- Sta 0x888A8 [0] -W- _ -W- Sta 0x888A8 [0] -W- _ SetCfg(1) cfgChanged1 -I- calling configure of all configurations...\n' b'\r-I- Sniffer config\n' b'\r-I- calling init of config 1...\n' b'\r-I- Sniffer Init\n' b'\r-I- entering main loop...\n' b'\r-I- USB is now configured\n' b'-W- Sta 0x88828 [0] -W- _ ' b'-I- Changed to ISO 7816-3 state 1\n' b'\rreset de-asserted\n' b'-I- WT updated to 9600 ETU\n' b'\r-I- Changed to ISO 7816-3 state 0\n' b'\rreset asserted\n' b'\r-I- Changed to ISO 7816-3 state 1\n' b'\rreset de-asserted\n' b'-I- WT updated to 9600 ETU\n' b'\r-I- Changed to ISO 7816-3 state 0\n' b'\rreset asserted\n' b'\r-I- Changed to ISO 7816-3 state 1\n' b'\rreset de-asserted\n' b'-I- WT updated to 9600 ETU\n' b'\r-I- Changed to ISO 7816-3 state 0\n' b'\rreset asserted\n' b'\r-I- Changed to ISO 7816-3 state 1\n' b'\rreset de-asserted\n' b'-I- WT updated to 9600 ETU\n' b'\r-I- Changed to ISO 7816-3 state 0\n'
On 5/20/21 5:11 PM, Harald Welte wrote:
Hi Katharina,
On Thu, May 20, 2021 at 04:46:57PM +0200, Katharina Kohls wrote:
Hi Harald,
I just switched to the master branch, rebuilt the firmware (simtrace-cardem-dfu), flashed again and tested: It doesn't seem to work and is back to a state where the phone doesn't even recognize it has a SIM (after reboot). Switching back to the hoernchen branch (+build + flash +run +reboot) still works.
Thanks for your feedback. It would be great to get the log output of the host software in this scenario, and - if you have a serial cable - the debug UART (2.5mm stereo jack) of the SIMtrace2 device.
Regards, Harald
Hi Katharina,
thanks for your follow-up.
Can you please share which phone / modem models you have reproduced this with?
Maybe I can find the same in my collection.
I will try to run cardem on simtrace on a variety of different phones here and see which ones work or don't work.
On Wed, May 26, 2021 at 03:03:38PM +0200, Katharina Kohls wrote:
BTW while debugging this I realized that the pin layout might be documented in the wrong order: The wiki says TX is on 4 (pin 1 = GND, pin 4 = TX, pin 5 = RX), however, for me it only worked when hooking up pin 5 with the RX of my UART to USB. Is that a typo?
I've always using the 2.5mm stereo jack, as those are used in a lot of Osmocom projects starting with OsmocomBB more than a decade ago.
tHe 5-pin UART header was designed to match the FTDI USB-UART cable pin-out.
The schematics are available, they should definitely be the definitive source to answer those kind of questions.
It states: 1 GND 2 CTS 3 VCC 4 DRXD (SAM3) = TXD of your UART cable 5 DRXD (SAM3) = RXD of your UART 6 CTS
Maybe the wiki could be further clarified?
Hi Harald,
On 5/28/21 11:15 AM, Harald Welte wrote:
Hi Katharina,
thanks for your follow-up.
Can you please share which phone / modem models you have reproduced this with?
I am testing with a OnePlus 6T with a Qualcomm SDM845 Snapdragon 845
Maybe I can find the same in my collection.
I will try to run cardem on simtrace on a variety of different phones here and see which ones work or don't work.
On Wed, May 26, 2021 at 03:03:38PM +0200, Katharina Kohls wrote:
BTW while debugging this I realized that the pin layout might be documented in the wrong order: The wiki says TX is on 4 (pin 1 = GND, pin 4 = TX, pin 5 = RX), however, for me it only worked when hooking up pin 5 with the RX of my UART to USB. Is that a typo?
I've always using the 2.5mm stereo jack, as those are used in a lot of Osmocom projects starting with OsmocomBB more than a decade ago.
tHe 5-pin UART header was designed to match the FTDI USB-UART cable pin-out.
The schematics are available, they should definitely be the definitive source to answer those kind of questions.
It states: 1 GND 2 CTS 3 VCC 4 DRXD (SAM3) = TXD of your UART cable 5 DRXD (SAM3) = RXD of your UART 6 CTS
Maybe the wiki could be further clarified?
I think this already is a good explanation: The Wiki reads like pin 5 *is* the RX of the simtrace, but looking at the documentation above it *should be connected to* the RX of the UART adapter. I can clarify that in the Wiki.
Best, Katharina
Hi Katharina,
Joachim (Cc) was able to reproduce non-working cardem in current master, and we're trying to fix it ASAP.
If you feel adventurous, feel free to give the firmware of "laforge/cardem2" branch of simtrace2.git a try, and if that fails, fall back to "laforge/cardem1".
Regards, Harald
Hi Katherina and list,
I think I've now fixed master, so 'cardem' versions from e33c2907bcc113fca8e189bc69c36383615523e9 (current master) upwards should work at least for basic use cases. At least they do on those phones I've tested so far (which is not a lot yet, admittedly).
I've also updated our CI to actually build 'simtrace-cardem-dfu' images and publish those at https://ftp.osmocom.org/binaries/simtrace2/ which now has the build like https://ftp.osmocom.org/binaries/simtrace2/firmware/all/simtrace-cardem-dfu-...
I'm currently looking at a potential problem regarding to PTS, where the log output of simtrace2-cardem-pcsc looks like this:
... everything looks great but then a block like his happens:
SIMtrace <- 01 01 00 00 00 00 10 00 06 00 00 00 02 00 94 04 SIMtrace IRQ 01 04 00 00 00 00 15 00 13 00 00 00 00 00 01 01 0a 80 25 00 00 SIMtrace IRQ STATUS: flags=0x13, fi=1, di=1, wi=10 wtime=9600 SIMtrace IRQ 01 04 00 00 00 00 15 00 03 00 00 00 00 00 01 01 0a 80 25 00 00 SIMtrace IRQ STATUS: flags=0x3, fi=1, di=1, wi=10 wtime=9600 -> 01 07 00 00 00 00 15 00 04 ff 10 11 fe 00 00 ff 10 11 fe 00 00 => PTS req: ff 10 11 fe 00 00 -> 01 06 00 00 00 00 13 00 01 00 00 00 05 00 00 a4 00 04 02 => DATA: flags=1, 00 a4 00 04 02 : <= osmo_st2_cardem_request_pb_and_rx(a4, 2) SIMtrace <- 01 01 00 00 00 00 0f 00 08 00 00 00 01 00 a4 -> 01 06 00 00 00 00 10 00 02 00 00 00 02 00 3f 00 => DATA: flags=2, 3f 00 : SW=0x6e00, len_rx=0 <= osmo_st2_cardem_request_sw_tx(6e 00) SIMtrace <- 01 01 00 00 00 00 10 00 06 00 00 00 02 00 6e 00 -> 01 06 00 00 00 00 13 00 01 00 00 00 05 00 00 a4 00 04 02 => DATA: flags=1, 00 a4 00 04 02 : <= osmo_st2_cardem_request_pb_and_rx(a4, 2) SIMtrace <- 01 01 00 00 00 00 0f 00 08 00 00 00 01 00 a4 -> 01 06 00 00 00 00 10 00 02 00 00 00 02 00 3f 00 => DATA: flags=2, 3f 00 : SW=0x6e00, len_rx=0 <= osmo_st2_cardem_request_sw_tx(6e 00) SIMtrace <- 01 01 00 00 00 00 10 00 06 00 00 00 02 00 6e 00
where we see a PTS is happening, and afterwards a seemingly innocent APDU like "00 a4 00 04 02 3f 00" (SELECT MF) results in SW 6e00: Checking errors - Class not supported
-
Harald Welte -
Katharina Kohls