From jeremy.brookfield at percula.com Tue Jan 10 17:55:35 2012 From: jeremy.brookfield at percula.com (jeremy brookfield) Date: Tue, 10 Jan 2012 18:55:35 +0100 Subject: No output when tracing a Gemalto Cryptoflex ,NET card Message-ID: <262D58C5-D5A2-4219-AF63-09A8B0264DB4@percula.com> This is my first post to this list so a little introduction, I work in security engineering for a large company that uses smart cards for authentication and encryption. I am having trouble trying to use smart cards from an OSX client over Citrix. The same cards work from a Windows client. Hence the interest in being able to trace all APDUs in a non-OS specific format. When I use simtrace with e.g. Gemalto Cyberflex cards, the APDU are shown as I would expect. However, when the card type is a Gemalto Cryptoflex .NET alI see is the ATR APDU. The Cryptoflex .NET cards are newer and supports a higher baud rate. Could this explain why the APDUs are not shown? There's a somewhat vague statement in the simatrace documentation to this effect. From holger at freyther.de Tue Jan 10 18:23:19 2012 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Tue, 10 Jan 2012 19:23:19 +0100 Subject: No output when tracing a Gemalto Cryptoflex ,NET card In-Reply-To: <262D58C5-D5A2-4219-AF63-09A8B0264DB4@percula.com> References: <262D58C5-D5A2-4219-AF63-09A8B0264DB4@percula.com> Message-ID: <4F0C8217.9040303@freyther.de> On 01/10/2012 06:55 PM, jeremy brookfield wrote: > > However, when the card type is a Gemalto Cryptoflex .NET alI see is the ATR APDU. Hi, i think this is known[1], what happens is that ATR and the first APDU end in the same USB message and then on the host the apdu_split does not work correctly, the hack to prevent this is below. [1] http://lists.osmocom.org/pipermail/simtrace/2011-December/000193.html diff --git a/firmware/src/simtrace/iso7816_uart.c b/firmware/src/simtrace/iso7816_uart.c index 17303ca..16a7db3 100644 --- a/firmware/src/simtrace/iso7816_uart.c +++ b/firmware/src/simtrace/iso7816_uart.c @@ -258,6 +258,8 @@ transition_to_tck(struct iso7816_3_handle *ih) /* If only T=0 supported, there is no TCK but we * immediately transition to APDUs */ set_atr_state(ih, ATR_S_DONE); + /* send off the USB context */ + ih->rctx_must_be_sent = 1; return ISO7816_S_WAIT_APDU; } else { set_atr_state(ih, ATR_S_WAIT_TCK); From holger at freyther.de Tue Jan 10 18:25:43 2012 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Tue, 10 Jan 2012 19:25:43 +0100 Subject: Upgrading from v0.3 to v0.4 Message-ID: <4F0C82A7.6050005@freyther.de> Hi all, for the OSX USB fix (ZLP) I changed the signature of functions provided by the DFU/bootloader part of the firmware. The following procedure works for me. $ sudo dfu-util -a 1 -D ./dfu.bin $ sudo dfu-util -a 0 -D ./main_simtrace.bin reset the device From D.Parolin at gmx.net Wed Jan 11 12:42:31 2012 From: D.Parolin at gmx.net (Dominique Parolin) Date: Wed, 11 Jan 2012 13:42:31 +0100 Subject: MitM firmware status Message-ID: <20120111124231.276310@gmx.net> Hi, as I could not find any udpates since July 2011 about MitM capable firmware here, or on the Wiki page I wanted to check if there is currently active development of a MitM firmware ? I would like to use it to manipulate fields from a physical SIM / UICC in real-time, e.g. non user editable fields like EF OPLMNwAcT. As a next step I would like to develop a tool that simulates a UICC with several applications on it, so that only the authentication is being made by the real UICC / SIM and utilize the simtrace HW as the physical interface. However the key to this is a proper firmware to interact with the ME <-> UICC communication in real time. I have written some classes and decoder for specific fields in Python (using Smartcard and a PCSC compatible reader) that can read and write, authenticate etc. however I lack the ability to write the firmware on my own. Regards, Dominique From holger at freyther.de Wed Jan 11 14:31:57 2012 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Wed, 11 Jan 2012 15:31:57 +0100 Subject: MitM firmware status In-Reply-To: <20120111124231.276310@gmx.net> References: <20120111124231.276310@gmx.net> Message-ID: <4F0D9D5D.7080103@freyther.de> On 01/11/2012 01:42 PM, Dominique Parolin wrote: > Hi, Hi, it is not implemented, regarding SIM emulation there is Kevin's softsim[1]. holger [1] http://cgit.osmocom.org/cgit/softsim/ From lukash at backstep.net Thu Jan 12 03:58:02 2012 From: lukash at backstep.net (Lukas Kuzmiak) Date: Thu, 12 Jan 2012 04:58:02 +0100 Subject: MitM firmware status In-Reply-To: <20120111124231.276310@gmx.net> References: <20120111124231.276310@gmx.net> Message-ID: If you have Ki of some real SIM I believe you could get some programmable SIM like those which were on cccamp 2011 and make those files there. i just think it might be less time consuming than implementing all the commands phone may be using (not sure what's implemented in softsim tho, never used it). cheers, lukash On Wed, Jan 11, 2012 at 1:42 PM, Dominique Parolin wrote: > Hi, > > as I could not find any udpates since July 2011 about MitM capable > firmware here, or on the Wiki page I wanted to check if there is currently > active development of a MitM firmware ? > > I would like to use it to manipulate fields from a physical SIM / UICC in > real-time, e.g. non user editable fields like EF OPLMNwAcT. > > As a next step I would like to develop a tool that simulates a UICC with > several applications on it, so that only the authentication is being made > by the real UICC / SIM and utilize the simtrace HW as the physical > interface. > > However the key to this is a proper firmware to interact with the ME <-> > UICC communication in real time. > > I have written some classes and decoder for specific fields in Python > (using Smartcard and a PCSC compatible reader) that can read and write, > authenticate etc. however I lack the ability to write the firmware on my > own. > > Regards, > Dominique > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From D.Parolin at gmx.net Thu Jan 12 10:18:32 2012 From: D.Parolin at gmx.net (Dominique Parolin) Date: Thu, 12 Jan 2012 11:18:32 +0100 Subject: MitM firmware status In-Reply-To: References: <20120111124231.276310@gmx.net> Message-ID: <20120112101832.282710@gmx.net> Thanks Lukash, > If you have Ki of some real SIM I believe you could get some programmable > SIM like those which were on cccamp 2011 and make those files there. I am actually less interested in cloning a SIM, rather than the development of the actual SW than can do this stuff. As it is yet impossible to extract the Ki of current SIMs / UICCs and the algorithm used can be a modified one, there won't be any use for such an emulated one in a real NW. However to get full control over fields that the actual SIM/UICC holds and that are only editable by using ADM codes the MitM firmware would be a great tool. You could force certain roaming scenarios, force failures for testing etc. I understand that this might not really be useful in the scope of what simtrace is intended for. Will look deeper into softsim, maybe start reimplementing it in Python in the scope of "RFC: Generic (U)SIM software" Already have certain Python functionality to read/write/decode EFs on SIM and USIM, I am yet lacking the physical interface to an actual phone. Regards, Dominique From kevredon at mail.tsaitgaist.info Thu Jan 12 10:04:14 2012 From: kevredon at mail.tsaitgaist.info (Kevin Redon) Date: Thu, 12 Jan 2012 11:04:14 +0100 Subject: MitM firmware status In-Reply-To: References: <20120111124231.276310@gmx.net> Message-ID: <1326362408-sup-2349@dennou> here more general info about softsim: - to use it you must first dump the sim card data (tool available). softsim will use this dump. - it can not handle Ki. it either uses the auth-tuples it dumped, or forwards the requests to the real sim. - it implements most (used) SIM commands (but not USIM at all). happy to help, kevin Excerpts from Lukas Kuzmiak's message of Thu Jan 12 04:58:02 +0100 2012: > If you have Ki of some real SIM I believe you could get some programmable > SIM like those which were on cccamp 2011 and make those files there. > > i just think it might be less time consuming than implementing all the > commands phone may be using (not sure what's implemented in softsim tho, > never used it). > > cheers, > lukash > > On Wed, Jan 11, 2012 at 1:42 PM, Dominique Parolin wrote: > > > Hi, > > > > as I could not find any udpates since July 2011 about MitM capable > > firmware here, or on the Wiki page I wanted to check if there is currently > > active development of a MitM firmware ? > > > > I would like to use it to manipulate fields from a physical SIM / UICC in > > real-time, e.g. non user editable fields like EF OPLMNwAcT. > > > > As a next step I would like to develop a tool that simulates a UICC with > > several applications on it, so that only the authentication is being made > > by the real UICC / SIM and utilize the simtrace HW as the physical > > interface. > > > > However the key to this is a proper firmware to interact with the ME <-> > > UICC communication in real time. > > > > I have written some classes and decoder for specific fields in Python > > (using Smartcard and a PCSC compatible reader) that can read and write, > > authenticate etc. however I lack the ability to write the firmware on my > > own. > > > > Regards, > > Dominique > > > > > > > > > > > > From peter at stuge.se Thu Jan 12 10:25:46 2012 From: peter at stuge.se (Peter Stuge) Date: Thu, 12 Jan 2012 11:25:46 +0100 Subject: MitM firmware status In-Reply-To: <20120112101832.282710@gmx.net> References: <20120111124231.276310@gmx.net> <20120112101832.282710@gmx.net> Message-ID: <20120112102546.4495.qmail@stuge.se> Dominique Parolin wrote: > I understand that this might not really be useful in the scope of > what simtrace is intended for. I think simtrace is intended for the use cases you can think of! It can certainly be used for mitm! //Peter From myonium at gmail.com Sat Jan 14 15:13:50 2012 From: myonium at gmail.com (Myonium) Date: Sat, 14 Jan 2012 16:13:50 +0100 Subject: git repository up to date? Message-ID: <0305ABA7-6397-47F4-B9EF-34567F735EC2@gmail.com> Hi Which version of the firmware is on git repository "git://git.gnumonks.org/openpcd.git"? There are v.02 , v.03 and v.04 firmwares mentioned. But I could not find any branches nor version information in the master branch ... I would like to patch the latest osx branch with the ATR /APDU patch ... [1] http://lists.osmocom.org/pipermail/simtrace/2011-December/000193.html However I get strange effects: Only a few bytes are shown on Smartcard inserts and the ATR's reported back to the application on the Mac are incorrect . Btw. does firmware version and simtace client version have to match? Thanks, Ben From holger at freyther.de Sat Jan 14 16:29:10 2012 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Sat, 14 Jan 2012 17:29:10 +0100 Subject: git repository up to date? In-Reply-To: <0305ABA7-6397-47F4-B9EF-34567F735EC2@gmail.com> References: <0305ABA7-6397-47F4-B9EF-34567F735EC2@gmail.com> Message-ID: <4F11AD56.3070609@freyther.de> On 01/14/2012 04:13 PM, Myonium wrote: > Hi > > Which version of the firmware is on git repository "git://git.gnumonks.org/openpcd.git"? > There are v.02 , v.03 and v.04 firmwares mentioned. But I could not find any branches nor version information in the master branch ... Firmware version: master > v0.4 > v0.3 > v0.2? As of yesterday master has one more patch compared to v0.4. The v0.3 -> v0.4 firmware change requires flashing both the bootloader and the simtrace app (as mentioned on this list). Hardware: v1.0 and v1.1p hardware (mostly identical, some changes in the layout/routing), you find documentation/changes of that in the wiki. > > I would like to patch the latest osx branch with the ATR /APDU patch ... [1] http://lists.osmocom.org/pipermail/simtrace/2011-December/000193.html > However I get strange effects: Only a few bytes are shown on Smartcard inserts and the ATR's > reported back to the application on the Mac are incorrect . What is the OSX branch? v0.4 includes the ZLP changes that fixed the enumeration on OSX, regarding your firmware, does compiling v0.4 as is work? Which compiler do you use to build the firmware? Did you read README.simtrace? cheers holger From jeremy.brookfield at percula.com Mon Jan 16 17:05:34 2012 From: jeremy.brookfield at percula.com (jeremy brookfield) Date: Mon, 16 Jan 2012 18:05:34 +0100 Subject: No output when tracing a Gemalto Cryptoflex ,NET card In-Reply-To: <4F0C8217.9040303@freyther.de> References: <262D58C5-D5A2-4219-AF63-09A8B0264DB4@percula.com> <4F0C8217.9040303@freyther.de> Message-ID: <6C500222-4EE9-4ABC-9B4B-53C069134307@percula.com> On Jan 10, 2012, at 7:23 PM, Holger Hans Peter Freyther wrote: > > i think this is known[1], what happens is that ATR and the first APDU end in the same USB message and then on the host the apdu_split does not work correctly, the hack to prevent this is below. > Thanks for the suggestion which I have been trying to implement - but without success. I am experiencing the same problem as Ben reported in http://lists.osmocom.org/pipermail/simtrace/2012-January/000227.html I can build the firmware and load it over dfu-util but the host application (a PKI debugging program that runs on OSX and Windows) is then returned an invalid APU (only the first byte is correct). I then had to use sam-ba to reload one of the pre-compiled binaries. My machine is running ubuntu 11.10. The toolchain is arm-elf-toolchain downloaded from the brung ppa (as per the instructions on your wiki) No errors were reported in the build. I then tried with unmodified firmware from the GIT repository. Same result. The simtrace program comes from your ppa. From holger at freyther.de Mon Jan 16 17:33:05 2012 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Mon, 16 Jan 2012 18:33:05 +0100 Subject: No output when tracing a Gemalto Cryptoflex ,NET card In-Reply-To: <6C500222-4EE9-4ABC-9B4B-53C069134307@percula.com> References: <262D58C5-D5A2-4219-AF63-09A8B0264DB4@percula.com> <4F0C8217.9040303@freyther.de> <6C500222-4EE9-4ABC-9B4B-53C069134307@percula.com> Message-ID: <4F145F51.5080605@freyther.de> On 01/16/2012 06:05 PM, jeremy brookfield wrote: > > My machine is running ubuntu 11.10. The toolchain is arm-elf-toolchain downloaded from the brung ppa (as per the instructions on your wiki) No errors were reported in the build. > > I then tried with unmodified firmware from the GIT repository. Same result. Hmm, this ubuntu-ppa builds quite an old gcc and "known-to-work" probably only applied to osmocomBB at some point. I have compiled 0.4+ with the attached diff. For your broken firmware, do you get proper output on the serial console? does the firmware even boot? does the red LED turn on? > > The simtrace program comes from your ppa. holger -------------- next part -------------- A non-text attachment was scrubbed... Name: dfu.bin Type: application/octet-stream Size: 16384 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: main_simtrace.bin Type: application/octet-stream Size: 20648 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: simtrace.diff Type: text/x-diff Size: 543 bytes Desc: not available URL: From jeremy.brookfield at percula.com Mon Jan 16 17:52:18 2012 From: jeremy.brookfield at percula.com (jeremy brookfield) Date: Mon, 16 Jan 2012 18:52:18 +0100 Subject: No output when tracing a Gemalto Cryptoflex ,NET card In-Reply-To: <4F145F51.5080605@freyther.de> References: <262D58C5-D5A2-4219-AF63-09A8B0264DB4@percula.com> <4F0C8217.9040303@freyther.de> <6C500222-4EE9-4ABC-9B4B-53C069134307@percula.com> <4F145F51.5080605@freyther.de> Message-ID: <10DD0FAA-180A-4C2D-BABC-B9DF75EAAC54@percula.com> On Jan 16, 2012, at 6:33 PM, Holger Hans Peter Freyther wrote: > For your broken firmware, do you get proper output on the serial console? does the firmware even boot? does the red LED turn on? Unfortunately I don't have a suitable cable for the serial port. I'll try to get one. The firmware does boot and the red line comes on (without blinking). On starting simtrace, I see "entering main loop" but on inserting the contact into a reader, the PC/MAC application receives "3b 04 00 00 01" instead of the correct ATR. dfu-util doesn't report any errors and I did load dfu.bin into "-a 1" (without that, the red line blinks) Thank you very much for the built 0.4 firmware. This loads and works. It now allows me to trace both types of cards, the Cyberflex cards that worked with the original firmware and the Cryptoflex cards (which have a short 7 byte ATR) which now work, From kevredon at mail.tsaitgaist.info Mon Jan 16 20:01:21 2012 From: kevredon at mail.tsaitgaist.info (Kevin Redon) Date: Mon, 16 Jan 2012 21:01:21 +0100 Subject: No output when tracing a Gemalto Cryptoflex ,NET card In-Reply-To: <6C500222-4EE9-4ABC-9B4B-53C069134307@percula.com> References: <262D58C5-D5A2-4219-AF63-09A8B0264DB4@percula.com> <4F0C8217.9040303@freyther.de> <6C500222-4EE9-4ABC-9B4B-53C069134307@percula.com> Message-ID: <1326743785-sup-4242@dennou> Hi, If you have a corrected firmware and it works with another phone/card, then I can provide some experience with a similar problem I got. Sometimes I did get random garbage instead of the correct APDU. The problem was hard to find but obvious: it was because of EMI. I used SIMtrace on a NFC capable phone and used the NFC. Because the FFC is not shielded (hard to do for such a flat cable) and the cable runs under the NFC antenna which is in the back cover of the phone, it interfered with the SIM traffic. The solution is to remove the cover, or if you still need to use the NFC to cover the NFC antenna using 1mm copper tape in the inside, so to protect the cable. good luck, kevin Excerpts from jeremy brookfield's message of Mon Jan 16 18:05:34 +0100 2012: > > On Jan 10, 2012, at 7:23 PM, Holger Hans Peter Freyther wrote: > > > > i think this is known[1], what happens is that ATR and the first APDU end in the same USB message and then on the host the apdu_split does not work correctly, the hack to prevent this is below. > > > > Thanks for the suggestion which I have been trying to implement - but without success. > > I am experiencing the same problem as Ben reported in > http://lists.osmocom.org/pipermail/simtrace/2012-January/000227.html > From jhk at sjefs.net Sat Jan 21 15:21:04 2012 From: jhk at sjefs.net (=?ISO-8859-1?Q?Jan_Henrik_Kr=E5gtorp?=) Date: Sat, 21 Jan 2012 16:21:04 +0100 Subject: Patching Wireshark-1.6 with simcard-for-wireshark-1.6.patch is failing Message-ID: I am having problems patching Wireshark with the simtracer patch. I am using a Debian VM: root at osmocom:/home/omsocom/simtrace/host# uname -a Linux osmocom 2.6.32-5-686 #1 SMP Thu Nov 3 04:23:54 UTC 2011 i686 GNU/Linux == The patching == root at osmocom:/home/osmocom/wireshark-1.6# cat simcard-for-wireshark-1.6.patch | patch -p 0 patching file epan/dissectors/packet-card_app_toolkit.c patching file epan/dissectors/packet-gsm_sim.c patching file epan/dissectors/packet-gsmtap.c Hunk #2 FAILED at 300. 1 out of 3 hunks FAILED -- saving rejects to file epan/dissectors/packet-gsmtap.c.rej patching file epan/dissectors/Makefile.common == The reject file of the patching attempt == root at osmocom:/home/osmocom/wireshark-1.6# cat epan/dissectors/packet-gsmtap.c.rej --- epan/dissectors/packet-gsmtap.c (revision 38554) +++ epan/dissectors/packet-gsmtap.c (working copy) @@ -300,6 +301,13 @@ col_set_str(pinfo->cinfo, COL_PROTOCOL, "GSMTAP"); + /* Some GSMTAP types are completely unrelated to the Um air interface */ + switch (type) { + case GSMTAP_TYPE_SIM: + call_dissector(sub_handles[GSMTAP_SUB_SIM], payload_tvb, pinfo, tree); + return; + } + if (arfcn & GSMTAP_ARFCN_F_UPLINK) { col_append_str(pinfo->cinfo, COL_RES_NET_SRC, "MS"); col_append_str(pinfo->cinfo, COL_RES_NET_DST, "BTS"); Any advice on how to solve this issue? regards Jan H -------------- next part -------------- An HTML attachment was scrubbed... URL: From holger at freyther.de Sat Jan 21 18:28:56 2012 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Sat, 21 Jan 2012 19:28:56 +0100 Subject: Patching Wireshark-1.6 with simcard-for-wireshark-1.6.patch is failing In-Reply-To: References: Message-ID: <4F1B03E8.90805@freyther.de> On 01/21/2012 04:21 PM, Jan Henrik Kr?gtorp wrote: > I am having problems patching Wireshark with the simtracer patch. > Hi, either grab my Ubuntu PPA and rebuild or take a patch from here: https://launchpad.net/~holger+lp/+archive/osmocom/+files/wireshark_1.6.2-1zecke2.debian.tar.gz (in debian/patches/) or compile the osmocom version of wireshark: http://cgit.osmocom.org/cgit/wireshark/ From martin at martinpaljak.net Wed Jan 25 09:40:28 2012 From: martin at martinpaljak.net (Martin Paljak) Date: Wed, 25 Jan 2012 11:40:28 +0200 Subject: Problems Message-ID: Hello, I have a v1.1p running Version 0.4 compiled 20120113-094258 by ich at sanmingze, connected between a Nokia 1616 and a macbook pro. Host side software (including libusb) is from Git and running inside a VMWare Fusion Debian 6 32bit VM. The SIM card is: http://smartcard-atr.appspot.com/parse?ATR=3b9f95801f438031e073362113574a330e09314100a9 Everything seems to work every now and then (I got a successful trace of the things that interest me yesterday) but it doesn't seem to be predictable. After following the "a problematic sim" thread I added more logging to the simtrace application and generated a log. The symptom is that everything works from phone startup, but then stalls. After some time (when starting the OTA SIM application) simtrace ends with "error usb bulk in .. -9" The serial debug console doesn't show more than the initial startup. Do I understand correctly that the fix proposed in "a problematic sim" is for the firmware, which is not yet present in my version? I attach the output from simtrace with the additional logging. Any ideas? Is it OK to use simtrace from virtual machine or is bare hardware required/best ? Thanks, Martin -------------- next part -------------- main(76): entering main (idle) loop (C) 2006-2011 by Harald Welte This software is FREE SOFTWARE licensed under GNU GPL Version 0.4 compiled 20120113-094258 by ich at sanmingze DEBUG Interface: 0) Set Pull-up 1) Clear Pull-up 2) Toggle LED1 3) Toggle LED2 9) Reset RSTC_SR=0x00010400 Inititalizing usbcmd_gen_init udp_open(437): entering USART Initializing pio_irq_register(109): registering handler 00107340 for PIOA 7 __pio_irq_demux(43): PIO_ISR_STATUS = 0xef7ffeff RST computed Fi(1) Di(1) ratio: 372 ISO_SW Initializing pio_irq_register(109): registering handler 00107a78 for PIOA 8 pio_irq_register(109): registering handler 00107a50 for PIOA 30 USART Entering Rx Mode RST computed Fi(1) Di(1) ratio: 372 MODE: SNIFFER -------------- next part -------------- A non-text attachment was scrubbed... Name: simtrace.log.gz Type: application/x-gzip Size: 23415 bytes Desc: not available URL: From martin at martinpaljak.net Wed Jan 25 13:55:25 2012 From: martin at martinpaljak.net (Martin Paljak) Date: Wed, 25 Jan 2012 15:55:25 +0200 Subject: Problems In-Reply-To: References: Message-ID: Hello, On Wed, Jan 25, 2012 at 11:40, Martin Paljak wrote: > Hello, > > I have a v1.1p running Version 0.4 compiled 20120113-094258 by > ich at sanmingze, connected between a Nokia 1616 and a macbook pro. > Host side software (including libusb) is from Git and running inside a > VMWare Fusion ?Debian 6 32bit VM. This seems to be a problem of the apdu_split method. After studying the protocol a bit and taking the URB-s from the generated log file and feeding it through some python, I can construct APDU-s that actually look sensible, but which are badly parsed by simtrace (not parsed at all, thus the "deadlock" feeling without extra logging) or some bytes get lost in between and the state machine breaks. I'm looking into it, maybe I can come up with a patch. Here is the troublesome part from the traffic: URB 20: 01 00 00 00 ff ff ff ff ff 90 00 00 a4 08 04 04 a4 7f ff 6f 07 61 1e 00 c0 00 00 1e c0 62 1c 82 02 41 21 83 02 6f 07 a5 03 da 01 02 8a 01 05 8b 03 6f 06 05 80 02 00 09 88 01 38 90 00 00 a4 08 04 04 a4 7f ff 6f 32 61 1d 00 c0 00 00 1d c0 62 1b 82 02 41 21 83 02 6f 32 a5 03 da 01 02 8a 01 05 8b 03 6f 06 05 80 02 01 2c 88 00 90 00 00 b0 00 00 00 b0 ff ff ff ff ff ff ff ff ff ff ff ff process_usb_msg(), payload: ff ff ff ff ff 90 00 00 a4 08 04 04 a4 7f ff 6f 07 61 1e 00 c0 00 00 1e c0 62 1c 82 02 41 21 83 02 6f 07 a5 03 da 01 02 8a 01 05 8b 03 6f 06 05 80 0 2 00 09 88 01 38 90 00 00 a4 08 04 04 a4 7f ff 6f 32 61 1d 00 c0 00 00 1d c0 62 1b 82 02 41 21 83 02 6f 32 a5 03 da 01 02 8a 01 05 8b 03 6f 06 05 80 02 01 2c 88 00 90 00 00 b0 00 00 00 b0 ff ff ff ff ff ff ff ff ff ff ff ff APDU: 00 b0 00 00 10 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 90 00 APDU: 00 a4 08 04 04 7f ff 6f 07 61 1e APDU: 00 c0 00 00 1e 62 1c 82 02 41 21 83 02 6f 07 a5 03 da 01 02 8a 01 05 8b 03 6f 06 05 80 02 00 09 88 01 38 90 00 APDU: 00 a4 08 04 04 7f ff 6f 32 61 1d APDU: 00 c0 00 00 1d 62 1b 82 02 41 21 83 02 6f 32 a5 03 da 01 02 8a 01 05 8b 03 6f 06 05 80 02 01 2c 88 00 90 00 URB 21: 01 00 00 00 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff process_usb_msg(), payload: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff URB 22: 01 00 00 00 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 90 00 00 a4 process_usb_msg(), payload: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 90 00 00 a4 URB 23: 01 00 00 00 00 04 02 a4 6f 40 61 20 00 c0 00 00 20 c0 62 1e 82 05 42 21 00 18 05 83 02 6f 40 a5 03 da 01 02 8a 01 05 8b 03 6f 06 06 80 02 00 78 88 00 90 00 00 a4 00 04 02 a4 6f 3b 61 20 00 c0 00 00 20 c0 62 1e 82 05 42 21 00 22 64 83 02 6f 3b a5 03 da 01 02 8a 01 05 8b 03 6f 06 07 80 02 0d 48 88 00 90 00 00 a4 00 04 02 a4 6f 49 61 20 00 c0 00 00 20 c0 62 1e 82 05 42 21 00 22 0a 83 process_usb_msg(), payload: 00 04 02 a4 6f 40 61 20 00 c0 00 00 20 c0 62 1e 82 05 42 21 00 18 05 83 02 6f 40 a5 03 da 01 02 8a 01 05 8b 03 6f 06 06 80 02 00 78 88 00 90 00 00 a4 00 04 02 a4 6f 3b 61 20 00 c0 00 00 20 c0 62 1e 82 05 42 21 00 22 64 83 02 6f 3b a5 03 da 01 02 8a 01 05 8b 03 6f 06 07 80 02 0d 48 88 00 90 00 00 a4 00 04 02 a4 6f 49 61 20 00 c0 00 00 20 c0 62 1e 82 05 42 21 00 22 0a 83 How exactly is the stream from the device supposed to be split into APDU-s, a la PC/SC, with a request and a response? The current format confuses me a bit. I understand that this is right now totally the reponsibility of the parser. I'm fairly new to the GSM/SIM world, but fairly well versed in layers above PC/SC (and some CCID), is there some documentation on how to get a grip on this? Best, Martin From martin at martinpaljak.net Wed Jan 25 14:58:04 2012 From: martin at martinpaljak.net (Martin Paljak) Date: Wed, 25 Jan 2012 16:58:04 +0200 Subject: apdu_split issue described (was: Re: Problems) Message-ID: Hello again. I took the place where simtrace fails to produce meaningful output and continued manually. Does the included file and comments make any sense? It will take me some time to bite through the concept of parsing the bytestream into APDU-s in the existing apdu_split code, maybe somebody more familiar recognizes a possible issue or a solution. Best, Martin On Wed, Jan 25, 2012 at 15:55, Martin Paljak wrote: > Hello, > > On Wed, Jan 25, 2012 at 11:40, Martin Paljak wrote: >> Hello, >> >> I have a v1.1p running Version 0.4 compiled 20120113-094258 by >> ich at sanmingze, connected between a Nokia 1616 and a macbook pro. >> Host side software (including libusb) is from Git and running inside a >> VMWare Fusion ?Debian 6 32bit VM. > > This seems to be a problem of the apdu_split method. After studying > the protocol a bit and taking the URB-s from the generated log file > and feeding it through some python, I can construct APDU-s that > actually look sensible, but which are badly parsed by simtrace (not > parsed at all, thus the "deadlock" feeling without extra logging) or > some bytes get lost in between and the state machine breaks. I'm > looking into it, maybe I can come up with a patch. Here is the > troublesome part from the traffic: > > > URB 20: 01 00 00 00 ff ff ff ff ff 90 00 00 a4 08 04 04 a4 7f ff 6f 07 > 61 1e 00 c0 00 00 1e c0 62 1c 82 02 41 21 83 02 6f 07 a5 03 da 01 02 > 8a 01 05 8b 03 6f 06 05 80 02 00 09 > 88 01 38 90 00 00 a4 08 04 04 a4 7f ff 6f 32 61 1d 00 c0 00 00 1d c0 > 62 1b 82 02 41 21 83 02 6f 32 a5 03 da 01 02 8a 01 05 8b 03 6f 06 05 > 80 02 01 2c 88 00 90 00 00 b0 00 00 00 > ?b0 ff ff ff ff ff ff ff ff ff ff ff ff > process_usb_msg(), payload: ff ff ff ff ff 90 00 00 a4 08 04 04 a4 7f > ff 6f 07 61 1e 00 c0 00 00 1e c0 62 1c 82 02 41 21 83 02 6f 07 a5 03 > da 01 02 8a 01 05 8b 03 6f 06 05 80 0 > 2 00 09 88 01 38 90 00 00 a4 08 04 04 a4 7f ff 6f 32 61 1d 00 c0 00 00 > 1d c0 62 1b 82 02 41 21 83 02 6f 32 a5 03 da 01 02 8a 01 05 8b 03 6f > 06 05 80 02 01 2c 88 00 90 00 00 b0 > 00 00 00 b0 ff ff ff ff ff ff ff ff ff ff ff ff > APDU: 00 b0 00 00 10 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 90 00 > APDU: 00 a4 08 04 04 7f ff 6f 07 61 1e > APDU: 00 c0 00 00 1e 62 1c 82 02 41 21 83 02 6f 07 a5 03 da 01 02 8a > 01 05 8b 03 6f 06 05 80 02 00 09 88 01 38 90 00 > APDU: 00 a4 08 04 04 7f ff 6f 32 61 1d > APDU: 00 c0 00 00 1d 62 1b 82 02 41 21 83 02 6f 32 a5 03 da 01 02 8a > 01 05 8b 03 6f 06 05 80 02 01 2c 88 00 90 00 > URB 21: 01 00 00 00 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > ff ff ff ff ff ff ff ff ff ff ff ff > ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > ff ff > ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > process_usb_msg(), payload: ff ff ff ff ff ff ff ff ff ff ff ff ff ff > ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > URB 22: 01 00 00 00 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > ff ff ff ff ff ff ff ff ff ff ff 90 00 00 a4 > process_usb_msg(), payload: ff ff ff ff ff ff ff ff ff ff ff ff ff ff > ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > ff ff ff ff ff ff ff ff ff ff ff ff ff ff 90 00 00 a4 > URB 23: 01 00 00 00 00 04 02 a4 6f 40 61 20 00 c0 00 00 20 c0 62 1e 82 > 05 42 21 00 18 05 83 02 6f 40 a5 03 da 01 02 8a 01 05 8b 03 6f 06 06 > 80 02 00 78 88 00 90 00 00 a4 00 04 02 a4 6f 3b 61 20 00 c0 00 00 20 > c0 62 1e 82 05 42 21 00 22 64 83 02 6f 3b a5 03 da 01 02 8a 01 05 8b > 03 6f 06 07 80 02 0d 48 88 00 90 00 00 a4 00 04 02 a4 6f 49 61 20 00 > c0 00 00 20 c0 62 1e 82 05 42 21 00 22 0a 83 > process_usb_msg(), payload: 00 04 02 a4 6f 40 61 20 00 c0 00 00 20 c0 > 62 1e 82 05 42 21 00 18 05 83 02 6f 40 a5 03 da 01 02 8a 01 05 8b 03 > 6f 06 06 80 02 00 78 88 00 90 00 00 a4 00 04 02 a4 6f 3b 61 20 00 c0 > 00 00 20 c0 62 1e 82 05 42 21 00 22 64 83 02 6f 3b a5 03 da 01 02 8a > 01 05 8b 03 6f 06 07 80 02 0d 48 88 00 90 00 00 a4 00 04 02 a4 6f 49 > 61 20 00 c0 00 00 20 c0 62 1e 82 05 42 21 00 22 0a 83 > > > How exactly is the stream from the device supposed to be split into > APDU-s, a la PC/SC, with a request and a response? The current format > confuses me a bit. I understand that this is right now totally the > reponsibility of the parser. > > I'm fairly new to the GSM/SIM world, but fairly well versed in layers > above PC/SC (and some CCID), is there some documentation on how to get > a grip on this? > > Best, > Martin -------------- next part -------------- (Original log) process_usb_msg(), payload: ff ff ff ff ff 90 00 00 a4 08 04 04 a4 7f ff 6f 07 61 1e 00 c0 00 00 1e c0 62 1c 82 02 41 21 83 02 6f 07 a5 03 da 01 02 8a 01 05 8b 03 6f 06 05 80 02 00 09 88 01 38 90 00 00 a4 08 04 04 a4 7f ff 6f 32 61 1d 00 c0 00 00 1d c0 62 1b 82 02 41 21 83 02 6f 32 a5 03 da 01 02 8a 01 05 8b 03 6f 06 05 80 02 01 2c 88 00 90 00 00 b0 00 00 00 b0 ff ff ff ff ff ff ff ff ff ff ff ff APDU: 00 b0 00 00 10 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 90 00 APDU: 00 a4 08 04 04 7f ff 6f 07 61 1e APDU: 00 c0 00 00 1e 62 1c 82 02 41 21 83 02 6f 07 a5 03 da 01 02 8a 01 05 8b 03 6f 06 05 80 02 00 09 88 01 38 90 00 APDU: 00 a4 08 04 04 7f ff 6f 32 61 1d APDU: 00 c0 00 00 1d 62 1b 82 02 41 21 83 02 6f 32 a5 03 da 01 02 8a 01 05 8b 03 6f 06 05 80 02 01 2c 88 00 90 00 process_usb_msg(), payload: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff process_usb_msg(), payload: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 90 00 00 a4 process_usb_msg(), payload: 00 04 02 a4 6f 40 61 20 00 c0 00 00 20 c0 62 1e 82 05 42 21 00 18 05 83 02 6f 40 a5 03 da 01 02 8a 01 05 8b 03 6f 06 06 80 02 00 78 88 00 90 00 00 a4 00 04 02 a4 6f 3b 61 20 00 c0 00 00 20 c0 62 1e 82 05 42 21 00 22 64 83 02 6f 3b a5 03 da 01 02 8a 01 05 8b 03 6f 06 07 80 02 0d 48 88 00 90 00 00 a4 00 04 02 a4 6f 49 61 20 00 c0 00 00 20 c0 62 1e 82 05 42 21 00 22 0a 83 (with my comments) process_usb_msg(), payload: ff ff ff ff ff 90 00 00 a4 08 04 04 a4 7f ff 6f 07 61 1e 00 c0 00 00 1e c0 62 1c 82 02 41 21 83 02 6f 07 a5 03 da 01 02 8a 01 05 8b 03 6f 06 05 80 02 00 09 88 01 38 90 00 00 a4 08 04 04 a4 7f ff 6f 32 61 1d 00 c0 00 00 1d c0 62 1b 82 02 41 21 83 02 6f 32 a5 03 da 01 02 8a 01 05 8b 03 6f 06 05 80 02 01 2c 88 00 90 00 (from the command output available above) APDU: 00 b0 00 00 10 -> ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff SW:90 00 APDU: 00 a4 08 04 04 7f ff 6f 07 -> SW:61 1e APDU: 00 c0 00 00 1e -> 62 1c 82 02 41 21 83 02 6f 07 a5 03 da 01 02 8a 01 05 8b 03 6f 06 05 80 02 00 09 88 01 38 SW:90 00 APDU: 00 a4 08 04 04 7f ff 6f 32 -> SW:61 1d APDU: 00 c0 00 00 1d -> 62 1b 82 02 41 21 83 02 6f 32 a5 03 da 01 02 8a 01 05 8b 03 6f 06 05 80 02 01 2c 88 00 SW:90 00 (simtrace apdu_split stops here, follows manual parsing with comments) This is not parsed any more: (Le 00 == "anything, up to 256" with case 2 APDU-s) APDU: 00 b0 00 00 00 -> b0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff SW:90 00 APDU: 00 a4 00 04 02 a4 6f 40 SW:61 20 # Le = 40, response is 20 APDU: 00 c0 00 00 20 -> c0 62 1e 82 05 42 21 00 18 05 83 02 6f 40 a5 03 da 01 02 8a 01 05 8b 03 6f 06 06 80 02 00 78 88 00 SW:90 00 APDU: 00 a4 00 04 02 a4 6f 3b SW:61 20 # Le = 3b, response is 20 APDU: 00 c0 00 00 20 -> c0 62 1e 82 05 42 21 00 22 64 83 02 6f 3b a5 03 da 01 02 8a 01 05 8b 03 6f 06 07 80 02 0d 48 88 00 SW:90 00 APDU: 00 a4 00 04 02 a4 6f 49 SW:61 20 # Le = 49, response is 20 APDU: 00 c0 00 00 20 -> c0 62 1e 82 05 42 21 00 22 0a 83 ... From jeremy.brookfield at percula.com Wed Jan 25 15:57:37 2012 From: jeremy.brookfield at percula.com (jeremy brookfield) Date: Wed, 25 Jan 2012 16:57:37 +0100 Subject: Problems In-Reply-To: References: Message-ID: <1E94155A-B7C0-41DA-9924-F70CD4A94235@percula.com> Hi Martin, I'm seeing a similar issue when running with certain card types. After a few,correctly parsed APDUs, Simtrace is reporting the APDU as 2 bytes more than it actually is. In your trace 90 00 00 0a is reported at the end of a payload 90 00 is often the last two bytes of a response and 00 0a is a common begin to a new APDU (00 0a often indicates a "select" instruction.) Jeremy On Jan 25, 2012, at 2:55 PM, Martin Paljak wrote: > > > How exactly is the stream from the device supposed to be split into > APDU-s, a la PC/SC, with a request and a response? The current format > confuses me a bit. I understand that this is right now totally the > reponsibility of the parser. > > > From martin at martinpaljak.net Wed Jan 25 16:10:13 2012 From: martin at martinpaljak.net (Martin Paljak) Date: Wed, 25 Jan 2012 18:10:13 +0200 Subject: Problems In-Reply-To: <1E94155A-B7C0-41DA-9924-F70CD4A94235@percula.com> References: <1E94155A-B7C0-41DA-9924-F70CD4A94235@percula.com> Message-ID: Hello, On Wed, Jan 25, 2012 at 17:57, jeremy brookfield wrote: > Hi Martin, > > I'm seeing a similar issue when running with certain card types. > > After a few,correctly parsed APDUs, Simtrace is reporting the APDU as 2 bytes more than it actually is. > > In your trace 90 00 00 0a is reported at the end of a payload > > 90 00 is often the last two bytes of a response and 00 0a is a common begin to a new APDU (00 0a often indicates a "select" instruction.) The problem and solution is actually pretty simple in my case. A patch is attached. Next task: fix some "malformed packets" in Wireshark, which seem to be unhandled opcodes for sim toolkit (?). Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-apdu_split-correctly-handle-Le-00-which-means-256.patch Type: application/octet-stream Size: 736 bytes Desc: not available URL: From laforge at gnumonks.org Wed Jan 25 17:45:55 2012 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 25 Jan 2012 18:45:55 +0100 Subject: Problems In-Reply-To: References: <1E94155A-B7C0-41DA-9924-F70CD4A94235@percula.com> Message-ID: <20120125174555.GI5184@prithivi.gnumonks.org> Hi Martin, On Wed, Jan 25, 2012 at 06:10:13PM +0200, Martin Paljak wrote: > > 90 00 is often the last two bytes of a response and 00 0a is a > > common begin to a new APDU (00 0a often indicates a "select" > > instruction.) > > The problem and solution is actually pretty simple in my case. > > A patch is attached. thanks a lot for your patience and time to debug this. Your fix seems correct and I've applied it to simtrace.git. > Next task: fix some "malformed packets" in Wireshark, which seem to be > unhandled opcodes for sim toolkit (?). yes, that may very well be the case. Feel free to share your pcap files (or only those messages that don't parse). Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From martin at martinpaljak.net Wed Jan 25 18:01:16 2012 From: martin at martinpaljak.net (Martin Paljak) Date: Wed, 25 Jan 2012 20:01:16 +0200 Subject: Problems In-Reply-To: <20120125174555.GI5184@prithivi.gnumonks.org> References: <1E94155A-B7C0-41DA-9924-F70CD4A94235@percula.com> <20120125174555.GI5184@prithivi.gnumonks.org> Message-ID: Hello, On Wed, Jan 25, 2012 at 19:45, Harald Welte wrote: >> Next task: fix some "malformed packets" in Wireshark, which seem to be >> unhandled opcodes for sim toolkit (?). > > yes, that may very well be the case. ?Feel free to share your pcap files > (or only those messages that don't parse). Hereyougo. The first one is the one needing parsing most. Actually I'd like to extend parsing to some payloads as well, but I'm 100% new to wireshark dissectors. Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: malformed1.pcap Type: application/octet-stream Size: 302 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: malformed_or_error2.pcap Type: application/octet-stream Size: 105 bytes Desc: not available URL: From laforge at gnumonks.org Wed Jan 25 19:50:29 2012 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 25 Jan 2012 20:50:29 +0100 Subject: LTE SIM traces, anyone? Message-ID: <20120125195029.GK5184@prithivi.gnumonks.org> Hi all, I was wondering if anyone has access to a LTE device (like a 4G USB dongle) and has been able to trace the communication between the SIM card and the device yet. If so, it would be great to get some traces. Feel free to patch out the IMSI, PIN number or any other private details (or simply filter those messages, if you care to). Thanks in advance, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From martin at martinpaljak.net Wed Jan 25 20:42:55 2012 From: martin at martinpaljak.net (Martin Paljak) Date: Wed, 25 Jan 2012 22:42:55 +0200 Subject: LTE SIM traces, anyone? In-Reply-To: <20120125195029.GK5184@prithivi.gnumonks.org> References: <20120125195029.GK5184@prithivi.gnumonks.org> Message-ID: Hello, On Wed, Jan 25, 2012 at 21:50, Harald Welte wrote: > Hi all, > > I was wondering if anyone has access to a LTE device (like a 4G USB > dongle) and has been able to trace the communication between the SIM > card and the device yet. Does it need to be in a 4G radio area or just with the device? Samsung GT-B3730 should be 4G. > If so, it would ?be great to get some traces. ?Feel free to patch out > the IMSI, PIN number or any other private details (or simply filter > those messages, if you care to). Is there some easy way to do this, like a readymade filter? I usually replace PIN codes with 1234 or similar, but how to strip network-related bits? Martin From laforge at gnumonks.org Wed Jan 25 21:10:15 2012 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 25 Jan 2012 22:10:15 +0100 Subject: LTE SIM traces, anyone? In-Reply-To: References: <20120125195029.GK5184@prithivi.gnumonks.org> Message-ID: <20120125211015.GT5184@prithivi.gnumonks.org> On Wed, Jan 25, 2012 at 10:42:55PM +0200, Martin Paljak wrote: > Hello, > > On Wed, Jan 25, 2012 at 21:50, Harald Welte wrote: > > Hi all, > > > > I was wondering if anyone has access to a LTE device (like a 4G USB > > dongle) and has been able to trace the communication between the SIM > > card and the device yet. > Does it need to be in a 4G radio area or just with the device? > > Samsung GT-B3730 should be 4G. > > > If so, it would ?be great to get some traces. ?Feel free to patch out > > the IMSI, PIN number or any other private details (or simply filter > > those messages, if you care to). > Is there some easy way to do this, like a readymade filter? I usually > replace PIN codes with 1234 or similar, but how to strip > network-related bits? there is no ready-made filter. But then, there isn't much privacy related detail apart from * reading EF.ICCID * reading EF.IMSI * writing EF.Kc / EF.KcGPRS * writing EF.LOCI (location area code) * writing the TMSI it shouldn't be too hard to filter those messages manually when looking at the trace. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From martin at martinpaljak.net Wed Jan 25 21:08:14 2012 From: martin at martinpaljak.net (Martin Paljak) Date: Wed, 25 Jan 2012 23:08:14 +0200 Subject: Problems In-Reply-To: References: <1E94155A-B7C0-41DA-9924-F70CD4A94235@percula.com> <20120125174555.GI5184@prithivi.gnumonks.org> Message-ID: On Wed, Jan 25, 2012 at 20:01, Martin Paljak wrote: > On Wed, Jan 25, 2012 at 19:45, Harald Welte wrote: >>> Next task: fix some "malformed packets" in Wireshark, which seem to be >>> unhandled opcodes for sim toolkit (?). >> >> yes, that may very well be the case. ?Feel free to share your pcap files >> (or only those messages that don't parse). One more (or same, from the same trace) Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: malformed2.pcap Type: application/octet-stream Size: 245 bytes Desc: not available URL: From 246tnt at gmail.com Wed Jan 25 23:45:46 2012 From: 246tnt at gmail.com (Sylvain Munaut) Date: Thu, 26 Jan 2012 00:45:46 +0100 Subject: LTE SIM traces, anyone? In-Reply-To: <20120125195029.GK5184@prithivi.gnumonks.org> References: <20120125195029.GK5184@prithivi.gnumonks.org> Message-ID: Hi, I tried doing some traces but had some issues. The first one was a missing entry in Fi_table. It's apparently used as '64' in some reader and 'unsupported' in some other. For simtrace I guess we should consider it 64. diff --git a/firmware/src/simtrace/iso7816_uart.c b/firmware/src/simtrace/iso7816_uart.c index 17303ca..2a92042 100644 --- a/firmware/src/simtrace/iso7816_uart.c +++ b/firmware/src/simtrace/iso7816_uart.c @@ -119,7 +119,7 @@ static const u_int16_t fi_table[] = { /* Table 7 from ISO 7816-3 */ static const u_int8_t di_table[] = { - 0, 1, 2, 4, 8, 16, 32, 0, + 0, 1, 2, 4, 8, 16, 32, 64, 12, 20, 2, 4, 8, 16, 32, 64, }; The second one is that that APDU split fails at some point : simtrace - GSM SIM and smartcard tracing (C) 2010 by Harald Welte Entering main loop URB: 01 05 00 00 ATR APDU: URB: 01 01 00 00 3b 9f 97 c0 0a 1f c7 80 31 e0 73 fe 21 1b 65 d0 01 10 09 22 81 00 f2 ATR APDU: 3b 9f 97 c0 0a 1f c7 80 31 e0 73 fe 21 1b 65 d0 01 10 09 22 81 00 f2 URB: 01 04 00 00 00 a4 00 04 02 URB: 01 04 00 00 a4 3f 00 URB: 01 04 00 00 61 38 00 c0 00 00 38 c0 62 36 82 02 78 21 83 02 3f 00 a5 0c 80 01 71 87 01 01 83 04 00 04 03 c0 8a 01 05 8b 03 2f 06 02 c6 12 90 01 78 83 01 01 83 01 0a 83 01 0b 83 01 0c 83 01 0d 81 02 ff ff 90 00 00 a4 08 04 02 a4 2f e2 61 1f 00 c0 00 00 1f c0 62 1d 82 02 41 21 83 02 2f e2 a5 03 c0 01 40 8a 01 05 8b 03 2f 06 03 80 02 00 0a 81 02 00 1c 90 00 00 b0 00 00 0a APDU: 00 a4 00 04 02 3f 00 61 38 APDU: 00 c0 00 00 38 62 36 82 02 78 21 83 02 3f 00 a5 0c 80 01 71 87 01 01 83 04 00 04 03 c0 8a 01 05 8b 03 2f 06 02 c6 12 90 01 78 83 01 01 83 01 0a 83 01 0b 83 01 0c 83 01 0d 81 02 ff ff 90 00 APDU: 00 a4 08 04 02 2f e2 61 1f APDU: 00 c0 00 00 1f 62 1d 82 02 41 21 83 02 2f e2 a5 03 c0 01 40 8a 01 05 8b 03 2f 06 03 80 02 00 0a 81 02 00 1c 90 00 URB: 01 04 00 00 b0 98 41 08 00 00 00 32 55 22 63 90 00 00 a4 08 04 02 a4 2f 05 61 1f 00 c0 00 00 1f c0 62 1d 82 02 41 21 83 02 2f 05 a5 03 c0 01 40 8a 01 05 8b 03 2f 06 05 80 02 00 06 81 02 00 18 90 00 00 a4 08 04 02 a4 2f 06 61 22 00 c0 00 00 22 c0 62 20 82 05 42 21 00 3f 0e 83 02 2f 06 a5 03 c0 01 40 8a 01 05 8b 03 2f 06 01 80 02 03 72 81 02 03 86 90 00 00 b2 05 04 3f APDU: 00 b0 00 00 0a 98 41 08 00 00 00 32 55 22 63 90 00 APDU: 00 a4 08 04 02 2f 05 61 1f APDU: 00 c0 00 00 1f 62 1d 82 02 41 21 83 02 2f 05 a5 03 c0 01 40 8a 01 05 8b 03 2f 06 05 80 02 00 06 81 02 00 18 90 00 APDU: 00 a4 08 04 02 2f 06 61 22 APDU: 00 c0 00 00 22 62 20 82 05 42 21 00 3f 0e 83 02 2f 06 a5 03 c0 01 40 8a 01 05 8b 03 2f 06 01 80 02 03 72 81 02 03 86 90 00 URB: 01 04 00 00 b2 80 01 02 a4 06 83 01 01 95 01 08 80 01 18 a4 06 83 01 0a 95 01 08 80 01 01 90 00 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 90 00 00 a4 08 0c 02 a4 2f 05 90 00 00 b0 00 00 06 APDU: 00 b2 05 04 3f 80 01 02 a4 06 83 01 01 95 01 08 80 01 18 a4 06 83 01 0a 95 01 08 80 01 01 90 00 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 90 00 APDU: 00 a4 08 0c 02 2f 05 90 00 URB: 01 04 00 00 b0 65 6e 65 73 ff ff 90 00 00 a4 08 04 02 a4 2f 00 61 25 00 c0 00 00 25 c0 62 23 82 05 42 21 00 26 04 83 02 2f 00 a5 03 c0 01 40 8a 01 05 8b 03 2f 06 06 80 02 00 98 81 02 00 ac 88 01 f0 90 00 00 a4 08 0c 02 a4 2f 06 90 00 00 b2 06 04 3f APDU: 00 b0 00 00 06 65 6e 65 73 ff ff 90 00 APDU: 00 a4 08 04 02 2f 00 61 25 APDU: 00 c0 00 00 25 62 23 82 05 42 21 00 26 04 83 02 2f 00 a5 03 c0 01 40 8a 01 05 8b 03 2f 06 06 80 02 00 98 81 02 00 ac 88 01 f0 90 00 APDU: 00 a4 08 0c 02 2f 06 90 00 URB: 01 04 00 00 b2 80 01 1a a4 06 83 01 0a 95 01 08 80 01 40 a4 06 83 01 0a 95 01 08 80 01 01 90 00 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 90 00 00 a4 08 0c 02 a4 2f 00 90 00 00 b2 01 04 26 APDU: 00 b2 06 04 3f 80 01 1a a4 06 83 01 0a 95 01 08 80 01 40 a4 06 83 01 0a 95 01 08 80 01 01 90 00 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 90 00 APDU: 00 a4 08 0c 02 2f 00 90 00 URB: 01 00 00 00 b2 61 18 4f 10 a0 00 00 00 87 10 02 f3 10 ff ff 89 08 00 00 ff 50 04 55 53 49 4d ff ff ff ff ff ff ff ff ff ff ff ff 90 00 00 b2 02 04 26 b2 61 18 4f 10 a0 00 00 00 87 10 04 f3 10 ff ff 89 08 00 00 ff 50 04 49 53 49 4d ff ff ff ff ff ff ff ff ff ff ff ff 90 00 00 b2 03 04 26 b2 61 18 4f 10 a0 00 00 03 43 10 02 f3 10 ff ff 89 02 00 00 ff 50 04 43 53 49 4d ff ff ff ff ff APDU: 00 b2 01 04 26 61 18 4f 10 a0 00 00 00 87 10 02 f3 10 ff ff 89 08 00 00 ff 50 04 55 53 49 4d ff ff ff ff ff ff ff ff ff ff ff ff 90 00 APDU: 00 b2 02 04 26 61 18 4f 10 a0 00 00 00 87 10 04 f3 10 ff ff 89 08 00 00 ff 50 04 49 53 49 4d ff ff ff ff ff ff ff ff ff ff ff ff 90 00 URB: 01 04 00 00 ff ff ff ff ff 90 00 00 b2 04 04 26 b2 61 0f 4f 05 a0 00 00 00 63 50 06 50 4b 43 53 31 35 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 90 00 80 10 00 00 1e 10 37 09 e8 ce 11 9c 00 07 9c 00 00 1f e2 60 00 00 43 d0 00 07 00 00 20 00 50 00 00 00 00 08 APDU: 00 b2 03 04 26 61 18 4f 10 a0 00 00 03 43 10 02 f3 10 ff ff 89 02 00 00 ff 50 04 43 53 49 4d ff ff ff ff ff ff ff ff ff ff 90 00 00 b2 As you can see on that last APDU, the 90 00 is not at the end ... not sure what happenned, why is the record 2 bytes shorter than what it should be ? Cheers, Sylvain From laforge at gnumonks.org Wed Jan 25 23:56:05 2012 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 26 Jan 2012 00:56:05 +0100 Subject: LTE SIM traces, anyone? In-Reply-To: References: <20120125195029.GK5184@prithivi.gnumonks.org> Message-ID: <20120125235605.GW5184@prithivi.gnumonks.org> Hi Sylvain, On Thu, Jan 26, 2012 at 12:45:46AM +0100, Sylvain Munaut wrote: > I tried doing some traces but had some issues. thanks. > The first one was a missing entry in Fi_table. It's apparently used as > '64' in some reader and 'unsupported' in some other. For simtrace I > guess we should consider it 64. thanks a lot, I've applied that patch. > As you can see on that last APDU, the 90 00 is not at the end ... not > sure what happenned, why is the record 2 bytes shorter than what it > should be ? I have no idea right now, sorry. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From holger at freyther.de Thu Jan 26 17:17:10 2012 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Thu, 26 Jan 2012 18:17:10 +0100 Subject: Problems In-Reply-To: <20120125174555.GI5184@prithivi.gnumonks.org> References: <1E94155A-B7C0-41DA-9924-F70CD4A94235@percula.com> <20120125174555.GI5184@prithivi.gnumonks.org> Message-ID: <4F218A96.8050507@freyther.de> On 01/25/2012 06:45 PM, Harald Welte wrote: > > thanks a lot for your patience and time to debug this. Your fix seems > correct and I've applied it to simtrace.git. Hi, I updated the simtrace/wireshark OBS, new packages for SuSE, Mandriva, Fedora, CentOS) are already available, I will need to update the PPA for Ubuntu and will do so tonight. Thanks for the patch! holger From holger at freyther.de Thu Jan 26 23:02:46 2012 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Fri, 27 Jan 2012 00:02:46 +0100 Subject: Problems In-Reply-To: <4F218A96.8050507@freyther.de> References: <1E94155A-B7C0-41DA-9924-F70CD4A94235@percula.com> <20120125174555.GI5184@prithivi.gnumonks.org> <4F218A96.8050507@freyther.de> Message-ID: <4F21DB96.4020309@freyther.de> On 01/26/2012 06:17 PM, Holger Hans Peter Freyther wrote: > On 01/25/2012 06:45 PM, Harald Welte wrote: > I updated the simtrace/wireshark OBS, new packages for SuSE, Mandriva, Fedora, > CentOS) are already available, I will need to update the PPA for Ubuntu and > will do so tonight. I updated the natty and oneiric PPA but it will take until the 28th that the new package will be built by the launchpad infrastructure. cheers holger From mat at spoked.ca Sun Jan 29 02:50:41 2012 From: mat at spoked.ca (Mat) Date: Sat, 28 Jan 2012 21:50:41 -0500 Subject: Getting started - unable to connect to the device Message-ID: <4F24B401.7040604@spoked.ca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hello, I have a v1.1p production board, and I am having problems getting started. I am running Arch Linux, so some things may be different from a Debian base. I have not yet tried interfacing the board from a Ubuntu/Debian workstation. I have succesfully compiled SIMtrace and its dependencies. The problem is at no point have I gotten a connection to the board. dmesg shows nothing and lsusb never shows the device. I have libusb configured on this system and programmed other avr devices. I tried to access the board with SAM-BA by following the firmware page. I only see the red LED faintly light when I'm jumping VCC to test, but nothing once I reconnect USB. I am right to assume that with a newly acquired board, I have to flash it with the firmware? Do you have any clues to help me talk to the SIMTrace board? I haven't found much explanation of bootloader and reset buttons on the wiki... Should I simply try with and Ubuntu/Debian workstation? Thanks, Mat -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAk8ks/kACgkQsluIOvRklphpcQEAvZNvtBPS376K5emsLfsYQhhk pQTKYwNy7US8/W8Z4GwBAKE8Qyu8URJmF4gZ1kzJgdzFQuo2918GmNaXSCTvT0nS =5g4w -----END PGP SIGNATURE----- From laforge at gnumonks.org Sun Jan 29 08:28:18 2012 From: laforge at gnumonks.org (Harald Welte) Date: Sun, 29 Jan 2012 09:28:18 +0100 Subject: Getting started - unable to connect to the device In-Reply-To: <4F24B401.7040604@spoked.ca> References: <4F24B401.7040604@spoked.ca> Message-ID: <20120129082818.GF1379@prithivi.gnumonks.org> Hi Mat! On Sat, Jan 28, 2012 at 09:50:41PM -0500, Mat wrote: > I tried to access the board with SAM-BA by following the firmware > page. This should not (have been / be) neccessarry. But once you have tried to erase the unit and install SAM-BA from rom, your only recovery option is SAM-BA, as the simtrace firmware and the bootloader have been erased :/ > I only see the red LED faintly light when I'm jumping VCC to test, but > nothing once I reconnect USB. Was this the same before you tried erasing the flash and installing the SAM-BA loader? What exactly do you mean by "jumping VCC to test"? The device is normally USB powered, therer is no need for any additional voltage supply. The state of the LEDs while in SAM-BA mode is undefined. However, 'faintly' might indicate a supply problem. Have you tried powering the board just from USB? Have you tried differen computers or an external USB hub? If you applied external VCC, what kind of power supply were you using? > I am right to assume that with a newly acquired board, I have to flash > it with the firmware? All boards sold in the sysmocom webshop ship flashed + tested, so it should just have enumerated on USB upon connection. I presume there was no visible mechanical damage to the unit upon arrival? Are you able to take a sharp photograph with good resolution and mail it privately to me? I just want to rule out any obvious hardware damage during shipping. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From holger at freyther.de Sun Jan 29 09:20:06 2012 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Sun, 29 Jan 2012 10:20:06 +0100 Subject: Problems In-Reply-To: <4F21DB96.4020309@freyther.de> References: <1E94155A-B7C0-41DA-9924-F70CD4A94235@percula.com> <20120125174555.GI5184@prithivi.gnumonks.org> <4F218A96.8050507@freyther.de> <4F21DB96.4020309@freyther.de> Message-ID: <4F250F46.6030309@freyther.de> On 01/27/2012 12:02 AM, Holger Hans Peter Freyther wrote: > I updated the natty and oneiric PPA but it will take until the 28th that the > new package will be built by the launchpad infrastructure. The PPA got compiled for i386 and AMD64 yesterday. holger From mat at spoked.ca Mon Jan 30 02:40:57 2012 From: mat at spoked.ca (Mat) Date: Sun, 29 Jan 2012 21:40:57 -0500 Subject: Getting started - unable to connect to the device In-Reply-To: <20120129082818.GF1379@prithivi.gnumonks.org> References: <4F24B401.7040604@spoked.ca> <20120129082818.GF1379@prithivi.gnumonks.org> Message-ID: <4F260339.7040607@spoked.ca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 I exchanged a couple of mails with Harald, and decided to post back a more complete report to the list because the issue is still unclear. > Was this the same before you tried erasing the flash and installing > the SAM-BA loader? What exactly do you mean by "jumping VCC to > test"? The device is normally USB powered, therer is no need for > any additional voltage supply. > > The state of the LEDs while in SAM-BA mode is undefined. However, > 'faintly' might indicate a supply problem. Have you tried powering > the board just from USB? Have you tried differen computers or an > external USB hub? > > If you applied external VCC, what kind of power supply were you > using? To clarify this point, I was just talking about jumping JP1 as instructed on SIMTrace/Firmware page. Please note that I did get a faint red LED while doing this. > All boards sold in the sysmocom webshop ship flashed + tested, so > it should just have enumerated on USB upon connection. When I received the device, I did not get any output from lsusb or dmesg when connecting it. I am working primarly on a recent T series Thinkpad. I opted to go down the SAM-BA / firmware flashing route. This did not help the device show up on my machine. So I went to an Ubuntu base workstation, and surprisingly, the device showed up without any problem. $ lsusb Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 004 Device 004: ID 03eb:6124 Atmel Corp. at91sam SAMBA bootloader $ dmesg [16867.212071] usb 4-2: new full speed USB device using uhci_hcd and address 4 [16867.375140] usbserial_generic 4-2:1.0: Generic device with no bulk out, not allowed. [16867.375152] usbserial_generic: probe of 4-2:1.0 failed with error -5 [16867.375199] usbserial_generic 4-2:1.1: generic converter detected [16867.375294] usb 4-2: generic converter now attached to ttyUSB0 When I plugged it back to my Arch laptop, I suddenly had the same output. But I was able to use sam7 to access the device. So I compiled all the software on Ubuntu and tried flashing from there. $ sudo ./sam7 --exec set_clock --exec unlock_regions --exec "flash ../openpcd/firmware/main_simtrace.samba" [sudo] password for mathilda: can't open "/dev/at91_0": No such file or directory Ok, let's go down the POSIX path: $ sudo rmmod usbserial $ sudo modprobe usbserial vendor=0x03EB product=0x6124 $ sudo ./sam7 -l /dev/ttyUSB0 --exec set_clock --exec unlock_regions - --exec "flash ../openpcd/firmware/main_simtrace.samba" Page size info of not known $ sudo ./sam7 -l /dev/ttyUSB0 --exec set_clock --exec unlock_regions - --exec "flash ../openpcd/firmware/main_simtrace.samba" ^C It just hangs there. I am stuck here, are there any tips on what I should do here? Sequence of operations? Other test commands? Should I, god forbid, try flashing it from a Windows workstation? I will end this post with strace output for the sam7 command: $ sudo strace ./sam7 -l /dev/ttyUSB0 --exec set_clock --exec unlock_regions --exec "flash ../openpcd/firmware/main_simtrace.samba" execve("./sam7", ["./sam7", "-l", "/dev/ttyUSB0", "--exec", "set_clock", "--exec", "unlock_regions", "--exec", "flash ../openpcd/firmware/main_s"...], [/* 15 vars */]) = 0 brk(0) = 0x8542000 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb78ee000 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) open("/etc/ld.so.cache", O_RDONLY) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=66517, ...}) = 0 mmap2(NULL, 66517, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb78dd000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/lib/libncurses.so.5", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\220\224\0\0004\0\0\0"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0644, st_size=227864, ...}) = 0 mmap2(NULL, 231632, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xf69000 mmap2(0xf9f000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x35) = 0xf9f000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/lib/libreadline.so.6", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\360\277\0\0004\0\0\0"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0644, st_size=204860, ...}) = 0 mmap2(NULL, 212492, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xab4000 mmap2(0xae3000, 16384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x2e) = 0xae3000 mmap2(0xae7000, 3596, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xae7000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/lib/libc.so.6", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0 at n\1\0004\0\0\0"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0755, st_size=1421892, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb78dc000 mmap2(NULL, 1427880, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x2b3000 mmap2(0x40a000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x157) = 0x40a000 mmap2(0x40d000, 10664, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x40d000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/lib/libdl.so.2", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0@\n\0\0004\0\0\0"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0644, st_size=9736, ...}) = 0 mmap2(NULL, 12408, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x120000 mmap2(0x122000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1) = 0x122000 close(3) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb78db000 set_thread_area({entry_number:-1 -> 6, base_addr:0xb78db6c0, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}) = 0 mprotect(0x122000, 4096, PROT_READ) = 0 mprotect(0x40a000, 8192, PROT_READ) = 0 mprotect(0xae3000, 4096, PROT_READ) = 0 mprotect(0xf9f000, 8192, PROT_READ) = 0 mprotect(0x804c000, 4096, PROT_READ) = 0 mprotect(0x448000, 4096, PROT_READ) = 0 munmap(0xb78dd000, 66517) = 0 open("/dev/ttyUSB0", O_RDWR) = 3 write(3, "N#", 2) = 2 nanosleep({0, 2000000}, NULL) = 0 read(3, Thanks, Mat -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAk8mAzkACgkQsluIOvRklpi6cwD6AwWIY1D+5BC0GRRah6dAGr0K J0OagmcFHcQucTuU3vsBAIIoX7391WAQ4Jxn7wbo0yPVl/jx/Ob8OVLDwrAeXKne =CN57 -----END PGP SIGNATURE----- From holger at freyther.de Mon Jan 30 05:22:25 2012 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Mon, 30 Jan 2012 06:22:25 +0100 Subject: Getting started - unable to connect to the device In-Reply-To: <4F260339.7040607@spoked.ca> References: <4F24B401.7040604@spoked.ca> <20120129082818.GF1379@prithivi.gnumonks.org> <4F260339.7040607@spoked.ca> Message-ID: <4F262911.9020501@freyther.de> On 01/30/2012 03:40 AM, Mat wrote: > Ok, let's go down the POSIX path: > > $ sudo rmmod usbserial > $ sudo modprobe usbserial vendor=0x03EB product=0x6124 > $ sudo ./sam7 -l /dev/ttyUSB0 --exec set_clock --exec unlock_regions > - --exec "flash ../openpcd/firmware/main_simtrace.samba" > Page size info of not known > $ sudo ./sam7 -l /dev/ttyUSB0 --exec set_clock --exec unlock_regions > - --exec "flash ../openpcd/firmware/main_simtrace.samba" Hi, try to enter the interactive mode and then issue the commands and see how far you get. holger From mat at spoked.ca Mon Jan 30 18:37:16 2012 From: mat at spoked.ca (Mat) Date: Mon, 30 Jan 2012 13:37:16 -0500 Subject: Getting started - unable to connect to the device In-Reply-To: <4F262911.9020501@freyther.de> References: <4F24B401.7040604@spoked.ca> <20120129082818.GF1379@prithivi.gnumonks.org> <4F260339.7040607@spoked.ca> <4F262911.9020501@freyther.de> Message-ID: <4F26E35C.9020507@spoked.ca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > try to enter the interactive mode and then issue the commands and > see how far you get. Good idea. Interestingly enough, the process hangs when launching the sam7 utility. I don't even get to the interactive command prompt. There is something I don't fully understand in the documentation. It says on ubuntu the device is mapped on /dev/ttyACMx using the cdc_cam. If I rmmod cdc_cam, the sam7 utility cannot find /dev/at91_0. To make it work I have to symlink /dev/ttyACM0 to /dev/at91_0... How does the device get mapped to /dev/at91_0? Trying to address with libusb this way, the strace ends with: open("/dev/at91_0", O_RDWR) = 3 write(3, "N#", 2) = 2 nanosleep({0, 2000000}, NULL) = 0 read(3, "\n", 2) = 1 nanosleep({0, 2000000}, NULL) = 0 write(3, "wFFFFF240,4#", 12) = 12 nanosleep({0, 2000000}, NULL) = 0 read(3, "\n", 4) = 1 nanosleep({0, 2000000}, NULL) = 0 fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb77bb000 write(1, "Page size info of not known\n", 29Page size info of not known ) = 29 exit_group(1) Trying to go down the POSIX path: open("/dev/ttyUSB0", O_RDWR) = 3 write(3, "N#", 2) = 2 nanosleep({0, 2000000}, NULL) = 0 read(3, ^C I also tried removing libusb before recompiling sam7, but this gives me the same output for POSIX. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAk8m41wACgkQsluIOvRklpiDQQEAnUan2RW7r1MzplXfE/wk1GXy 6++s2iDK7w1zQuTkB7gA/2FVqQQLp3RvHlv9d80Omxw7f+ZXRI0QEnXvMFqoSgI1 =tarC -----END PGP SIGNATURE----- From holger at freyther.de Mon Jan 30 21:01:34 2012 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Mon, 30 Jan 2012 22:01:34 +0100 Subject: Getting started - unable to connect to the device In-Reply-To: <4F26E35C.9020507@spoked.ca> References: <4F24B401.7040604@spoked.ca> <20120129082818.GF1379@prithivi.gnumonks.org> <4F260339.7040607@spoked.ca> <4F262911.9020501@freyther.de> <4F26E35C.9020507@spoked.ca> Message-ID: <4F27052E.6050204@freyther.de> On 01/30/2012 07:37 PM, Mat wrote: > There is something I don't fully understand in the documentation. It > says on ubuntu the device is mapped on /dev/ttyACMx using the cdc_cam. > If I rmmod cdc_cam, the sam7 utility cannot find /dev/at91_0. To make > it work I have to symlink /dev/ttyACM0 to /dev/at91_0... How does the > device get mapped to /dev/at91_0? No idea, I have only used sam7util (from our git repository) with the posix mode and /dev/ttyACM0..as device. So the device is really in the SAM-BA state? Are you sure /dev/ttyACM0 is really coming from the SIMtrace? holger From mat at spoked.ca Tue Jan 31 04:04:29 2012 From: mat at spoked.ca (Mat) Date: Mon, 30 Jan 2012 23:04:29 -0500 Subject: Getting started - unable to connect to the device In-Reply-To: <4F27052E.6050204@freyther.de> References: <4F24B401.7040604@spoked.ca> <20120129082818.GF1379@prithivi.gnumonks.org> <4F260339.7040607@spoked.ca> <4F262911.9020501@freyther.de> <4F26E35C.9020507@spoked.ca> <4F27052E.6050204@freyther.de> Message-ID: <4F27684D.3050006@spoked.ca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > No idea, I have only used sam7util (from our git repository) with > the posix mode and /dev/ttyACM0..as device. So the device is really > in the SAM-BA state? Are you sure /dev/ttyACM0 is really coming > from the SIMtrace? Yes, according to Harald, if the device identifies as Atmel Corp. at91sam SAMBA bootloader when issuing lsusb, this confirms it is in SAM-BA state. I quickly tried the dfu-util, and it did not recognize any device. I identified the hanging point to be at the very beginning of samba_init(void) in samba.ca. It stopped at the first if, never being able to read a response from the device. The great news is, I finally flashed it! The second workstation I was working from was Ubuntu 10.10. This time, I tried on another Ubuntu 10.04 workstation, which is in a fairly fresh install state. I I installed dependencies to build the firmware: The arm-elf-toolchain from bsprak PPA, and most importantly (my guess is, this changed something), libusb-dev and NOT libusb-1.0.0-dev. This is might seem strange, but the installed packages are libusb-0.1-4 libusb-1.0.0 and libusb-dev. Maybe this is a meta package and I'm wrong... After I ran strace on sam7 utility and it went much further, finally ending with something about USBDEVFS ressource busy. Simply rmmod cdc_acm and try again, et voila! Flashed! Device now boots with bright red LED and identifies as VOTI. Clearly, this all had to do with the USB interface being picky about something. Maybe someone more knowledgeable can explain. Thanks for all you help, Mat -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAk8naE0ACgkQsluIOvRklphMpQD/VmYICIdITFbmDkjLV7ubHEqH ongjJ4B288t1JzwPfZwA/RME0zt2Tr0tHxUflNjk7DsM3rpxfDTk7USbdlmozxG9 =PcxW -----END PGP SIGNATURE----- From peter at stuge.se Tue Jan 31 10:04:00 2012 From: peter at stuge.se (Peter Stuge) Date: Tue, 31 Jan 2012 11:04:00 +0100 Subject: Getting started - unable to connect to the device In-Reply-To: <4F27684D.3050006@spoked.ca> References: <4F24B401.7040604@spoked.ca> <20120129082818.GF1379@prithivi.gnumonks.org> <4F260339.7040607@spoked.ca> <4F262911.9020501@freyther.de> <4F26E35C.9020507@spoked.ca> <4F27052E.6050204@freyther.de> <4F27684D.3050006@spoked.ca> Message-ID: <20120131100400.20764.qmail@stuge.se> Mat wrote: > The great news is, I finally flashed it! The second workstation I was > working from was Ubuntu 10.10. This time, I tried on another Ubuntu > 10.04 workstation, which is in a fairly fresh install state. I I > installed dependencies to build the firmware: The arm-elf-toolchain > from bsprak PPA, and most importantly (my guess is, this changed > something), libusb-dev and NOT libusb-1.0.0-dev. This is might seem > strange, but the installed packages are libusb-0.1-4 libusb-1.0.0 and > libusb-dev. Maybe this is a meta package and I'm wrong... libusb-0.1 and libusb-1.0 are different APIs for doing the same thing; accessing USB devices. They are incompatible, meaning that they can not be used interchangeably. Ie. a program built for 0.1 can not use 1.0 directly. This also means that both can be installed at the same time, since they provide different things. There is additionally the libusb-compat-0.1 package which uses the 1.0 API and provides the 0.1 API. Using this is generally more desirable than using the original 0.1 package, but it's not a huge deal. I guess that sam7util uses the old API so you would need libusb-dev in order to build it. But the 0.1 files have literally not changed in years so Ubuntu 10.04 or 10.10 makes no difference. > After I ran strace on sam7 utility and it went much further, finally > ending with something about USBDEVFS ressource busy. A USBDEVFS message confirms that libusb is being used. On the contrary, the strace output you provided for "libusb" mode and "POSIX" mode were identical, and both clearly showed that libusb was *not* being used. Also note that Holger's point of making sure that you are using the correct ttyACM device is quite valid. Just because you see SAM-BA in lsusb does not mean that this piece of hardware will be ttyACM0. It might just as well be ttyACM1 or ttyACM2 or... Your strace output did however show a reply to N# on ttyACM0, indicating that indeed this was the correct port. > Clearly, this all had to do with the USB interface being picky about > something. Maybe someone more knowledgeable can explain. It's impossible to say anything without further analysis. The data you sent does not allow drawing a conclusion. I'm glad that the device works now. //Peter From kevredon at mail.tsaitgaist.info Tue Jan 31 14:38:20 2012 From: kevredon at mail.tsaitgaist.info (Kevin Redon) Date: Tue, 31 Jan 2012 15:38:20 +0100 Subject: Getting started - unable to connect to the device In-Reply-To: <4F26E35C.9020507@spoked.ca> References: <4F24B401.7040604@spoked.ca> <20120129082818.GF1379@prithivi.gnumonks.org> <4F260339.7040607@spoked.ca> <4F262911.9020501@freyther.de> <4F26E35C.9020507@spoked.ca> Message-ID: <1328020530-sup-9413@dennou> Hi, Excerpts from Mat's message of Mon Jan 30 19:37:16 +0100 2012: > > There is something I don't fully understand in the documentation. It > says on ubuntu the device is mapped on /dev/ttyACMx using the cdc_cam. > If I rmmod cdc_cam, the sam7 utility cannot find /dev/at91_0. To make > it work I have to symlink /dev/ttyACM0 to /dev/at91_0... How does the > device get mapped to /dev/at91_0? this is the output I got on Ubuntu when I did not installed libusb, or with the wrong version. Once the right version is installed, you have to recompile sam7utils (clean to be sure). Maybe you have/had the same error. kevin From mat at spoked.ca Tue Jan 31 15:11:18 2012 From: mat at spoked.ca (Mathieu Jolicoeur) Date: Tue, 31 Jan 2012 10:11:18 -0500 Subject: Getting started - unable to connect to the device In-Reply-To: <1328020530-sup-9413@dennou> References: <4F24B401.7040604@spoked.ca> <20120129082818.GF1379@prithivi.gnumonks.org> <4F260339.7040607@spoked.ca> <4F262911.9020501@freyther.de> <4F26E35C.9020507@spoked.ca> <1328020530-sup-9413@dennou> Message-ID: <4F280496.40608@spoked.ca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > On the contrary, the strace output you provided for "libusb" mode > and "POSIX" mode were identical, and both clearly showed that > libusb was *not* being used. I think this is important to note for future reference. > It's impossible to say anything without further analysis. The data > you sent does not allow drawing a conclusion. Thanks for your input Peter, you are right for saying we can't draw a conclusion from this. I understand now the different bases for libusb. > this is the output I got on Ubuntu when I did not installed > libusb, or with the wrong version. Once the right version is > installed, you have to recompile sam7utils (clean to be sure). > Maybe you have/had the same error. I think I was getting stuck because by I had installed SIMtrace before sam7utils. This way, I had already installed libusb-1.0-0-dev, so sam7utils would compile with that base. This might be important to clarify. Hopefully, this can be useful in the future. All the best, Mat -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAk8oBJYACgkQsluIOvRklpgGVQEAs7C9Up2cJ6dPACal+W9q021d z7/ivD2DXKj7w8Uwu/4BAIUAFKKGed2NQKEEHKCPkXZF19uPyYhvK3pv5qoXeCdV =3qrb -----END PGP SIGNATURE----- From peter at stuge.se Tue Jan 31 16:49:55 2012 From: peter at stuge.se (Peter Stuge) Date: Tue, 31 Jan 2012 17:49:55 +0100 Subject: Getting started - unable to connect to the device In-Reply-To: <4F280496.40608@spoked.ca> References: <4F24B401.7040604@spoked.ca> <20120129082818.GF1379@prithivi.gnumonks.org> <4F260339.7040607@spoked.ca> <4F262911.9020501@freyther.de> <4F26E35C.9020507@spoked.ca> <1328020530-sup-9413@dennou> <4F280496.40608@spoked.ca> Message-ID: <20120131164955.21532.qmail@stuge.se> Mathieu Jolicoeur wrote: > I think I was getting stuck because by I had installed SIMtrace > before sam7utils. This way, I had already installed > libusb-1.0-0-dev, so sam7utils would compile with that base. And since sam7utils has not yet been adapted to support libusb-1.0 it requires the libusb-dev package with the libusb-0.1 API. Having only libusb-1.0-0-dev and not libusb-dev means that libusb-dev is not available, and that is the only libusb which sam7utils currently can use. //Peter