- simtrace - lists.osmocom.org

by Harald Welte

Hi all, I'm thinking of starting a project that would allow us to * perform SIM and USIM card pre-personalization * read/dump and explore [U]SIM contents interactively * perform SIM card simulation The idea is to start with some generic data structure that can represent the filesystem tree (DFs, EFs) and their "external" properties, i.e. file type, size, permissions, FID, SFID, etc. This data structure could also have the actual file content associated with each EF. The second step would be some code that can take that data structure and program a freely-programmable card (like sysmoSIM-GR1) and create the files according to that structure. Another module would implement card-simulation (via BT SAP, SIMtrace or virtual PC/SC card). After all, only a few instructions have to be imilpemented if the filesystem and its content is already in a generic data structure that the program can access.. Next step would be to associate parser and generator routines for the content of each individual file as it is specified in TS 11.11. After that has been done, we could think of representing the FS tree and the parsed contents of each file in some kind of graphical / user friendly representation. The idea here is that the UI code would be generic and not know any of the actual ecnoding/decoding of the EF content. The biggest question is what language to use for this. Some kind of object orientation might very well resemble the idea of a 'file object' in a tree, with many different file types, each having it's own parser/encoder. On the other hand, Erlang's bit field syntax would probably come very handy in terms of encoding/decoding the various EF content. However, at least once we start to want some kidn of UI, Erlan really sucsk. Also, almost nobody here reads/writes Erlang [yet?]. Writing all this in C seems like a bit much of an effort, probably even more so on the UI side. However, we already have quite a bit of C code for parsing/generating things like LAI, etc. which are stored like 04.08 inside the sim card files. Python might be a good idea in terms of tons of available libraries/modules, object orientation and good UI bindings. The biggest problem here is that my python skills are really limited so far, so my productivity might not be as high as I expect. The individual components could even be written in different languages, but then we would have to have some common format for exchanging data back and forth - which might not be worth it, given the small scope of the project. any ideas / comments / feedback? -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

13 years, 6 months

4
5
0 0

[PATCH 0/5] DFU Address GCC warnings

by Holger Hans Peter Freyther

From: Holger Hans Peter Freyther <zecke(a)selfish.org> These address various compiler warnings, there is still one left related the flash handling but I will need to read a bit more on the EFC. I have flashed my device using DFU with these patches applied. Holger Hans Peter Freyther (5): dfu: The i variable to disable interrupts shadows the outer index dfu: udp_ep0_recv_clean is static and is not called anywhere dfu: Mark unsued variables as __unused for now dfu: Use {} for possible empty if statement (in case debug is off) dfu: Remove unused variable, mark method as not retuning firmware/include/asm/compiler.h | 3 +++ firmware/src/dfu/dfu.c | 36 +++++++++++------------------------- 2 files changed, 14 insertions(+), 25 deletions(-) -- 1.7.7.2

13 years, 7 months

2
6
0 0

New bugfix firmware v0.3 release (fi/di calculation)

by Harald Welte

Hi! Thanks to Bjoern Kerler, we now have some bugfixes in fi/di calculation, which apparently was broken for cerain newer phones like the HTC Raphael or GT-S7070. If you had any problems regarding PPS/PTS and higher baud rates of the SIM card interface, feel free to try this new version. The source code can be found in openpcd.git as usual. Firmware can be installed into the application partition using dfu-util. -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

13 years, 7 months

1
0
0 0

Updated usermanual and 'streamlining' of the wiki content

by Holger Hans Peter Freyther

Hi all, I have updated the usermanual and provided a section on the Firmware itself (getting, building, programming). This was written at night so I would be very happy if someone could proof read or provide feedback in any other way. I have moved some content in the Wiki as well, everything that is related to Hardware should be in the Hardware article[2] and everything related to the Firmware should be in the Firmware article[3]. I tried hard to not lose any information. Again please take a look. holger [1] http://bb.osmocom.org/trac/raw-attachment/wiki/SIMtrace/usermanual.pdf [2] http://bb.osmocom.org/trac/wiki/SIMtrace/Hardware [3] http://bb.osmocom.org/trac/wiki/SIMtrace/Firmware

13 years, 8 months

3
3
0 0

simtrace on Mac OSX

by Myonium

Hi I tried SIMTrace with Gemalto java smart cards and it is working great. Unfortunately I can’t run it on my shiny Mac OSX (Darwin Kernel Version 10.8.0), hosting Ubuntu in VMware. SIMtrace is flashed with the latest firmware (see http://lists.osmocom.org/pipermail/simtrace/2011-August/000109.html) If I connect it to my mac the red light is flashing periodically. In the kernel log I see the following messages: 9/28/11 9:47:05 PM kernel USBF: 428978. 89 [0xadd3100] The IOUSBFamily was not able to enumerate a device. 9/28/11 9:47:06 PM kernel USBF: 428979.493 [0xadd3100] The IOUSBFamily is having trouble enumerating a USB device that has been plugged in. It will keep retrying. (Port 4 of Hub at 0x6000000) 9/28/11 9:47:06 PM kernel USBF: 428979.493 [0xadd3100] The IOUSBFamily was not able to enumerate a device. 9/28/11 9:47:07 PM kernel USBF: 428980.898 [0xadd3100] The IOUSBFamily is having trouble enumerating a USB device that has been plugged in. It will keep retrying. (Port 4 of Hub at 0x6000000) 9/28/11 9:47:07 PM kernel USBF: 428980.898 [0xadd3100] The IOUSBFamily was not able to enumerate a device. 9/28/11 9:47:09 PM kernel USBF: 428982.303 [0xadd3100] The IOUSBFamily is having trouble enumerating a USB device that has been plugged in. It will keep retrying. (Port 4 of Hub at 0x6000000) .... with logging enabled: 9/29/11 9:10:33 PM kernel USBF: 1466.294 AppleUSBOHCI[0x7679000]::MakeDevice error setting address. err=0xe00002ed device=0x96d3400 - releasing device 9/29/11 9:10:33 PM kernel USBF: 1466.294 **5** AppleUSBHubPort[0x77d5c00]::AddDeviceResetChangeHandler - Port 4 of Hub at 0x6000000, unable to set device 0 to address 0 - disabling port 9/29/11 9:10:33 PM kernel USBF: 1466.296 AppleUSBHubPort[0x77d5c00]::DetachDevice Port 4 of Hub at 0x6000000 being detached (_attachRetry = 0) 9/29/11 9:10:33 PM kernel USBF: 1466.296 [0x77d5c00] The IOUSBFamily is having trouble enumerating a USB device that has been plugged in. It will keep retrying. (Port 4 of Hub at 0x6000000) 9/29/11 9:10:33 PM kernel USBF: 1466.296 AppleUSBHubPort[0x77d5c00]::DetachDevice - Port 4 of Hub at 0x6000000 - device has gone away 9/29/11 9:10:33 PM kernel USBF: 1466.296 [0x77d5c00] The IOUSBFamily was not able to enumerate a device. 9/29/11 9:10:34 PM kernel USBF: 1467.700 AppleUSBOHCI[0x7679000]::MakeDevice error setting address. err=0xe00002ed device=0x96d3400 - releasing device 9/29/11 9:10:34 PM kernel USBF: 1467.700 **5** AppleUSBHubPort[0x77d5c00]::AddDeviceResetChangeHandler - Port 4 of Hub at 0x6000000, unable to set device 0 to address 0 - disabling port 9/29/11 9:10:34 PM kernel USBF: 1467.702 AppleUSBHubPort[0x77d5c00]::DetachDevice Port 4 of Hub at 0x6000000 being detached (_attachRetry = 0) 9/29/11 9:10:34 PM kernel USBF: 1467.702 [0x77d5c00] The IOUSBFamily is having trouble enumerating a USB device that has been plugged in. It will keep retrying. (Port 4 of Hub at 0x6000000) 9/29/11 9:10:34 PM kernel USBF: 1467.702 AppleUSBHubPort[0x77d5c00]::DetachDevice - Port 4 of Hub at 0x6000000 - device has gone away 9/29/11 9:10:34 PM kernel USBF: 1467.702 [0x77d5c00] The IOUSBFamily was not able to enumerate a device. 9/29/11 9:10:36 PM kernel USBF: 1469.107 AppleUSBOHCI[0x7679000]::MakeDevice error setting address. err=0xe00002ed device=0x96d3400 - releasing device 9/29/11 9:10:36 PM kernel USBF: 1469.107 **5** AppleUSBHubPort[0x77d5c00]::AddDeviceResetChangeHandler - Port 4 of Hub at 0x6000000, unable to set device 0 to address 0 - disabling port 9/29/11 9:10:36 PM kernel USBF: 1469.109 AppleUSBHubPort[0x77d5c00]::DetachDevice Port 4 of Hub at 0x6000000 being detached (_attachRetry = 0) 9/29/11 9:10:36 PM kernel USBF: 1469.109 [0x77d5c00] The IOUSBFamily is having trouble enumerating a USB device that has been plugged in. It will keep retrying. (Port 4 of Hub at 0x6000000) 9/29/11 9:10:36 PM kernel USBF: 1469.109 AppleUSBHubPort[0x77d5c00]::DetachDevice - Port 4 of Hub at 0x6000000 - device has gone away 9/29/11 9:10:36 PM kernel USBF: 1469.109 [0x77d5c00] The IOUSBFamily was not able to enumerate a device. 9/29/11 9:10:37 PM kernel USBF: 1470.512 AppleUSBOHCI[0x7679000]::MakeDevice error setting address. err=0xe00002ed device=0x96d3400 - releasing device Please find attached also the trace logs form USBProber and usbtracer. Any ideas how this could be fixed? Ben

13 years, 8 months

7
35
0 0

[osmocom-announce] patched wireshark now on git.osmocom.org

by Harald Welte

Hi all, we have accumulated a number of wireshark patches, and by far not all of them have been merged into mainline wireshark so far (volunteers, anyone?) Some people have complained that it is hard to build them, as you first have to find a wireshark version to which they apply, etc. We have now created a wireshark.git repository at git.osmocom.org in which you will be able to find the latest mainline wireshark version ('trunk' branch) as well as our patches in 'master': http://cgit.osmocom.org/cgit/wireshark/ the read-onIy clone url is 'git://git.osmocom.org/wireshark' So the recommended option for everyone needing patched wireshark for one or the other reason (e.g. simtrace) now is to clone that wireshark.git repository and build from there. Like before, we will rebase our patches in irregular intervals, so you may have to do a 'pull -f' instead of 'pull' at that time. Regards, Harald -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

13 years, 9 months

1
0
0 0

Any progress reports / experience with SIMtrace?

by Harald Welte

Hi all, it's now something like two weeks after the first 60 or so SIMtrace kits have been sold - but remarkably quite in here. I've been busy with mostly non-technical stuff, so I couldn't spend any more time improving the firmware/software. However, at least some of the SIMtrace owners should have used the device until now and gathered some data and/or experience. Please feel free to share your progress or problems here, including topics like * firmware update * simtrace host software * wireshark dissector Regards, Harald -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

13 years, 9 months

4
4
0 0

OT: Chinese C118 supply?

by Harald Welte

Hi all, at the CCC Camp two weeks ago, a Chinese guy approached me, stating that there he has contacts to a considerable supply of very inexpensive C1xx family phones in China. Unfortunately we didn't exchange contact details, so I'm trying this route. If you are the person that has talked to me about this topic, pleaes contact me by private e-mail. I would love to use this opportunity to provide inexpensive C1xx phones to the larger OsmocomBB user community. Thanks in advance, Harald -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

13 years, 9 months

1
0
0 0

Webshop for the SIMtrace hardware

by Holger Hans Peter Freyther

Hi all, I have toyed with spreecommerce[1] on and off and would like to have some friendly users to see if the whole checkout process is working. The shop can be found here[2] but I would like to share some technical details with you. My patched spreecommerce can be found on gitorious[3], for some of the changes I should have created an extension but right now I think I prefer git pull --rebase to see what changed. If you enter your EUVAT number you should not be charged VAT (unless you are in Germany). We are using a CA Cert signed certificate, your browser will tell you that it is dangerous, I think we prefer putting the money into future HW products than getting a signature from a 'trust worthy' org. Shipping cost calculation is a bit of a mess, does anyone know if DHL offers an API for it? The installation has four zones (Germany, EUVAT region, USA, World Wide)? Terms/Conditions and Privacy Policy are very basic and need to be refined, with best effort I tried to make short and clear. Technical feedback, specially on caching, rails (security), etc. is very welcome. holger [1] spreecommerce.com [2] https://shop.sysmocom.de [3] https://gitorious.org/sysmocom-spreecommerce

13 years, 9 months

1
0
0 0

availability through web shop?

by Dirk Kirsten

Hi, I just wanted to ask for a short heads up of the release schedule. I know you have been selling the boards at the CCC camp, but I haven't been there. It was mentioned on the list that you are planning to sell it through a web shop in the "2nd half of august". I am sorry for being in such a hurry, but I'd really like to have the boards on my desk in august, due to my holidays afterwards. Cheers, Dirk

13 years, 9 months

4
4
0 0

samba precondition

by Kevin Redon

Hi, I think I found a small hardware bug while fixing the v1.0p boards (adding a 100nF capacitor near the LDO pin 4). When I want to put the SAM7S in SAM-BA mode (shorting TEST and 3.3V pins), it does not work, even after waiting a lot of time. The 2 LEDs are on, and when I touch PA0 (pin 48 on the right upper corner of the SAM7S, near the "A") with a piece of metal, the LEDs switch off and putting into SAM-BA mode works. maybe PA0 needs to be low/up but it is not connected and probably floating. The solution is easy, but should we correct that for the next version (if it is a real bug)? Also, simtrace seems to load sam_ba module, which I have to remove so I can use sam7util multiple times: sudo rmmod cdc_acm && sudo rmmod sam_ba && sudo ./sam7 --exec set_clock --exec unlock_regions --exec "flash ../openpcd/firmware/main_simtrace.samba" thanks, kevin

13 years, 9 months

5
5
0 0

'no simcard' bug / SIMtrace firmware update

by Harald Welte

Hi all, I have meanwhile solved the first half of the bug that was causing a lot of problems during the CCC Camp 2011. In git commit fa7297b93f4187bce9439bb676874815f66d8f21 to openpcd.git, I have made the following changes: * make sure SIMtrace remains completely passive even in case of (alleged) parity errors * prevent an IRQ storm by properly clearing error flags in the USART, which have lead to a watchdog triggered reset which in turn caused a USB disconnect So right now, you should not see the "No SIM card" or "SIM card error" in the display of your phone, no matter what phone / simcard is used. However, the data logged by SIMtrace still is incorrect in those cases. I hope to release a fix for that soon. The updated 'main_simtrace.bin' firmware is attached to this mail. You can install it by using "dfu-util -d 16c0:0762 -a0 -D ./main_simtrace.bin -R" which should produce something like: ======= dfu-util - (C) 2005-2008 by Weston Schmidt, Harald Welte and OpenMoko Inc. This program is Free Software and has ABSOLUTELY NO WARRANTY dfu-util does currently only support DFU version 1.0 Opening USB Device 0x16c0:0x0762... Claiming USB DFU Runtime Interface... Determining device status: state = appIDLE, status = 0 Device really in Runtime Mode, send DFU detach request... Resetting USB... Opening USB Device... Found Runtime: [0x16c0:0x0762] devnum=41, cfg=0, intf=0, alt=0, name="SimTrace DFU Interface - Application Partition" Claiming USB DFU Interface... Setting Alternate Setting #0 ... Determining device status: state = dfuIDLE, status = 0 dfuIDLE, continuing Device returned transfer size 256 bytes_per_hash=415 Copying data from PC to DFU device Starting download: [##################################################] finished! state(7) = dfuMANIFEST, status(0) = No error condition is present state(2) = dfuIDLE, status(0) = No error condition is present Done! can't detach: error sending control message: Broken pipe Resetting USB to switch back to runtime mode ======== After that, the new firmware has been programmed into your SIMtrace and you can immediately use it again (no reset/re-plug/... needed) Regards, Harald -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

13 years, 10 months

2
2
0 0

TST PIN and SIMtrace Schematic question

by Holger Hans Peter Freyther

Hi all, I have a stupid schematic question. I read section 6.2 of the SAM7 datasheet (as in the git tree) and it mentions that besides TST high also PA0, PA1 and PA2 needs to be high, and PA0, PA1 should not be low as this leads to unpredictable results. So I wonder about the following: - PA0 is not connected, default state should be high - PA1 is connected with a trace that leads to PA6 - PA2 is connected with a trace that leads to PA4 will PA4, PA6 work like a pull down (I am not sure of Table 10-3)? cheers holger

13 years, 10 months

2
2
0 0

Connecting the FTDI cable

by Stefan Petersen

Hello! I skimmed over the schematic and noticed that the power output from the FTDI cable is connected directly to the 3.3V line. In my experience the output from the FTDI cable is 5V even though it is the 3.3V version. I have actually fried some designs due to this. I'm not 100% sure about this, but my tips is to check it before you connect it. Best regards, /Stefan

13 years, 10 months

4
3
0 0

SIMtrace usermanual

by Holger Hans Peter Freyther

Hi all, there is a doc/ directory in the simtrace source and the documentation is done with docbook. The result of the document can be seen here[1]. It is still missing proof reading, sections on building the patched wireshark, building the firmware and more content. comments welcome holger [1] http://bb.osmocom.org/trac/attachment/wiki/SIMtrace/usermanual.pdf

13 years, 10 months

1
1
0 0

[PATCH 1/3] Include <stdlib.h> for malloc() and free()

by Peter Stuge

--- host/main.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/host/main.c b/host/main.c index a1e5600..1823857 100644 --- a/host/main.c +++ b/host/main.c @@ -19,6 +19,7 @@ #include <errno.h> #include <unistd.h> #include <stdio.h> +#include <stdlib.h> #include <string.h> #include <stdint.h> #include <time.h> -- 1.7.4.1.343.ga91df.dirty

13 years, 10 months

2
3
0 0

tags for the hardware

by Holger Hans Peter Freyther

Hi all, are there tags for the v1.0p hardware and other prototypes? I don't see them with git tag -l. holger

13 years, 10 months

2
1
0 0

[PATCH] fix simtrace crash when unpluging usb

by Luka Perkov

This patch should fix the crash from simtrace app when SIMtrace hardware is unpluged from usb or when it is reseted. This feature was proposed on simtrace workshop on ccc camp. Signed-off-by: Luka Perkov < lists ->-to->- lukaperkov.net > --- diff --git a/host/main.c b/host/main.c index a1e5600..61656be 100644 --- a/host/main.c +++ b/host/main.c @@ -187,7 +187,14 @@ int main(int argc, char **argv) rc = usb_bulk_read(udev, SIMTRACE_IN_EP, buf, sizeof(buf), 100000); if (rc < 0 && rc != -EAGAIN) { fprintf(stderr, "Error submitting BULK IN urb: %s\n", usb_strerror()); - exit(1); + while (1) { + udev = usb_find_reopen(SIMTRACE_USB_VENDOR, SIMTRACE_USB_PRODUCT); + if (!udev) { + usleep(1000000); + } else { + break; + } + } } if (rc > 0) { //printf("URB: %s\n", osmo_hexdump(buf, rc)); diff --git a/host/usb_helper.c b/host/usb_helper.c index 231363a..97ea7b6 100644 --- a/host/usb_helper.c +++ b/host/usb_helper.c @@ -28,6 +28,8 @@ #include <usb.h> +static struct usb_dev_handle *hdl; + static struct usb_device *find_usb_device (uint16_t vendor_id, uint16_t product_id) { struct usb_bus *bus; @@ -46,8 +48,6 @@ static struct usb_device *find_usb_device (uint16_t vendor_id, uint16_t product_ struct usb_dev_handle *usb_find_open(uint16_t vendor_id, uint16_t product_id) { struct usb_device *dev; - struct usb_dev_handle *hdl; - usb_init(); usb_find_busses(); usb_find_devices(); @@ -56,7 +56,7 @@ struct usb_dev_handle *usb_find_open(uint16_t vendor_id, uint16_t product_id) if (!dev) { fprintf(stderr, "Cannot find matching USB Device. " "Are you sure it is connected?\n"); - exit(1); + return NULL; } hdl = usb_open(dev); @@ -74,3 +74,12 @@ struct usb_dev_handle *usb_find_open(uint16_t vendor_id, uint16_t product_id) return hdl; } + +struct usb_dev_handle *usb_find_reopen(uint16_t vendor_id, uint16_t product_id) +{ + if (hdl) { + usb_detach_kernel_driver_np(hdl, 0); + } + + return usb_find_open(vendor_id, product_id); +} diff --git a/host/usb_helper.h b/host/usb_helper.h index 13f96f8..0a9714c 100644 --- a/host/usb_helper.h +++ b/host/usb_helper.h @@ -22,5 +22,6 @@ #include <stdint.h> struct usb_dev_handle *usb_find_open(uint16_t vendor_id, uint16_t product_id); +struct usb_dev_handle *usb_find_reopen(uint16_t vendor_id, uint16_t product_id); #endif

13 years, 10 months

1
0
0 0

SIMtrace poster for the Camp?

by Harald Welte

Hi all! I know it's a bit on short hand notice now, but maybe somebody is interested in doing a SIMtrace poster that we can put up in the Radio Village at the CCC Camp. It doesn't have to be super-fancy / super-glossy, just something that draws a bit of attention that SIMtrace is present there, and what it is. Some ideas for bullet points: * trace communication between phone and SIM * man-in-the-middle * analyze + debug SIM Toolkit * analyze proactive SIM * SIM firewall * SIM card emulation Printing the poster shouldn't be a problem, if somebody just wants to do the design as SVG. Thanks in advance if anyone finds time for doing it... -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

13 years, 10 months

2
1
0 0

at91lib / multi-configuration device

by Harald Welte

Hi! It took me quite a long time to fix all the bugs I discovered in the at91lib USB stack, particularly in the CCID code. The next problem was that the core USB code could not deal wit devices that implement multiple configurations correctly. But finally I got it to work. There is now a multi-configuration project which is part of the git://git.gnumonks.org/at91work.git git repository. Curious people can type 'make' in the usb-device-multi-project sub-directory, which will render a usb-device-multi-project-simtrace-at91sam7s128-flash_dfu.bin file. That file can be flashed into the simtrace using dfu-util like this: dfu-util -a0 -D ./usb-device-multi-project-simtrace-at91sam7s128-flash_dfu.bin -R The firmware doesn't really do anything yet, but it should show up on USB as a device with three configurations (one for sniffer, one for reader and one for MITM). I've started to port over my sniffer code from the openpcd repository, but I'm not sure when I'll have time to finish it. Maybe still before the camp, we'll see... Regards, Harald -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

13 years, 10 months

1
0
0 0

Simtrace production hardware

by Harald Welte

Hi all, the 100 SIMtrace production units have recently arrived from the SMT factory. While this is good news, there are some bad news as well: 1) blocking capacitor C12 too far from LDO causing power oscillations This problem can easily be re-worked by manually soldering a capacitor immediately to the LDO input pin. Even though 60-75% of the units seem to work without the re-work, we're adding it to make sure there are no issues later on. 2) something like 20 to 25% of the units have some problem related to the initial programming of the SAM-BA loader. Everything works fine if the flashing is been done via JTAG, or later using sam7dfu + dfu-util. The problem is still under investigation, but despite something like 6 hours debugging and soldering additional capacitors, even replacing the entire SAM7S have not rendered any results. Please don't ask me to ship some units yet, as we are still testing them. As per our original schedule, we will start to sell them at the CCC Camp and then offer a webshop from the second half of August onwards. Regards, Harald -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

13 years, 10 months

1
0
0 0

Roadmap for SIMtrace firmware

by Harald Welte

Hi all! I just waned to give you a heads-up of where I want to be heading with regard to the simtrace firmware. Right now we still use a hacked add-on to the OpenPCD firmware I wrote some 5 years ago. This was a quick way to get something working, as I knew the code base. It has served that purpose: We quickly had a firmware for sniffing mode. That code had been developed before Atmel started to publish ther at91lib software packages which contain a lot of (probably better tested and more portable) code supporting a wide range of Atmel ARM devices. at91lib is especially strong on the USB side, where there are not only implementations of CDC-ACM (serial), CCID (smartcard reader), mass storage, usb-audio, etc. - but also composite devies out of multiple of the above. So what I have in mind for simtrace now is to move forward using at91lib. However, at91lib does (obviously) not support my sam7dfu boot loader / flasher. DFU has been proven an exremely helpful tool for R&D type projects, where you need quick turn-around times for testing new code in absence of a JTAG setup. Using the SAM-BA loader is pretty annoying even after a short time, the constant cycles of usb-plug/unplug, jumper closing and opeing quickly wears out not only your nerves but even the usb plug or socket. I know people who have built USB cables with a power switch in the Vbus line, but even that does only half the trick. So what I'm now doing is adding linker scripts + startup magic to at91lib so it can build .bin files that can be downloaded using the sam7dfu bootloader on the device, and dfu-util on the host PC. Once that is finished, I intend to: * port over the existing 'sniffer mode' code from the openpcd.git repository and 'glue' it behind a CDC-ACM device. This means that in the future, all operatign systems will only see a serial device with APDUs coming out of them. * use the at91lib-provided CCID code to build a second firmware image for a 'reader mode', where the PC can use simtrace as smartcard reader * later merge the two into a single firmware with two alternative USB configurations * finally, add a 'softsim' mode, where the PC can simulate the SIM card to the phone. I'm not sure what I'll do on the USB protocol side for this. Chances are high it's again CDC-ACM - but this time simultaneously with CCID for the reader side, for man-in-the-middle. The advantage here is that we don't need to work with libusb, which apparently can be challenging for users of legacy operating systems ;) Thus, the ideal situation would be a single firmware image that provides three alternate configurations: Sniffer, Cardreader and MITM. Any help is of course very much appreciated. I'll push my at91lib git tree with sam7dfu support as soon as I've done some testing (I'm travelling and unfortunately forgot my 2.5mm jack USB-serial cable). Regards, Harald -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

13 years, 10 months

1
1
0 0

capacitor at Vcc of the card

by Harald Welte

Hi all, just before I forget it agan: I recently read in a completely different context that ISO7816 mandates a capacitor being placed very close to the acutak SIM card socket. It would be good to check the specs and see if this is true. If yes, we might add it to the next version of the hardware, just to be sure. Regards, Harald -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

13 years, 11 months

1
0
0 0

Bounce action notification

by mailman＠lists.osmocom.org

This is a Mailman mailing list bounce action notice: List: simtrace Member: andre(a)ac.nl.eu.org Action: Subscription disabled. Reason: Excessive or fatal bounces. The triggering bounce notice is attached below. Questions? Contact the Mailman site administrator at mailman(a)lists.osmocom.org.

13 years, 11 months

1
0
0 0

Active Manipulation SIM-ME

by Dirk Kirsten

Hello, We would like to do some active manipulation between our ME and the SIM card. As I understood correctly, the hardware SIMtrace project is just about passive monitoring the traffic in between, am I right? So this seems to be inappropriate for our aims. So we thought about a solution more like the RebelSIM card, which is documented as well in the osmocomBB wiki. Unfortunately, the information given there are also very vague. So maybe it is just outdated: Does anybody worked with the RebelSIM card in a way that they try to manipulate the responses from the SIM (or do something else, except from unlocking their phone)? Is it possible to flash it via SIM card interface?! What we actually want to do is to replace same values, e.g. we want to provide another Kc than the SIM card in fact has (this is solely a research project). So maybe there is some other way to do is, except the approach based on RebelSIM? If so I would be grateful for your valuable feedback. Cheers, Dirk

13 years, 11 months

6
9
0 0

GPL version of SIMtrace

by Holger Hans Peter Freyther

Hi Harald, it looks like that simtrace (the host application) is licensed under GPLv2? Is this on purpose? holger

13 years, 11 months

2
1
0 0

SIMtrace production has started

by Harald Welte

Hi all, JFYI: The SIMtrace v1.0p bulk production has started. It will take about two weeks for the PCBs to be produced, after that we will do SMT. We expect to get the fully assembled boards by July 27th, which gives us some time for testing + programming before the Camp. We expect the boards to be available at the 27C3, and after that from the sysmocom webshop. Meanwhile, I have discovered that Atmels at91lib includes code for a USB CCID implementation. So we could provide something like a multi-configuration device, that has a default configuration for the sniffer, and a different configuration to behave like a regular CCID smart card reader. I'm not certain when I will get around doing that, but it definitely seems like an interesting option. Regards, Harald -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

13 years, 11 months

2
1
0 0

SIMtrace v1.0 status report

by Harald Welte

Hi all, the SIMtrace v1.0 is a big success. No re-work required, it worked out of the box after soldering. We are in discussion with the manufacturer for some small footprint/component changes to reduce the number of special components that he doesn't already have in tape reels in his SMT machines. After that discussion is finished (hopefully soon), we will build 100 units (in Germany). Left as a TODO item is still the SIM card adapters. We're working to make sure they will be ready at the same time the SIMtrace boards will be ready. Thanks again to Kevin for his work on the schematics + layout side. Regards, Harald -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

13 years, 11 months

1
0
0 0

Simtrace prototype progress

by Harald Welte

Hi all, Kevin and I have been making great progress today, spending about 12 hours with debugging, re-working and re-designign simtrace. The previous malfanction seemed to be caused by attachign the Vcc from the phone to the AD7 input of the SAM7. Apparently the Vcc of the phone was >= 50mV higher than the Vcc of the SAM7, and this caused the phone (/smartcard reader) to give up as it could not raise the power line to the level it wanted to raise it, even before switching on clock to the card. Aside from the one prototype, we have also received 5 units made by some friends of K2 in china, who unfortunately used a previous gerber that had even more bugs. Nonetheless, three out of those 5 units have been re-worked, and are now functional, too. We will do a very quick 2nd prototype spin with the following changes * fix all the bugs as per the trac tickets * use the new bus switch with lower resistance * use a LDO with two outputs (and two enable inputs) so we can use a GPIO to supply the SIM card with voltage ourselves * add a power distribution switch with < 1Ohm Rds-on so we can alternatively switch through the Vcc from the phone to the SIM * add a resistive divider between VCC_phone and the ADC input * use angled jumpers so the overall unit remains flat The gerber will be sent off tomorrow for a '3 working days' quick PCB, the corresponding digikey order, too. Kevin has offered to solder the next prototype. If everything works well, we will immediately go into production of something like 100 units to make sure they're ready before the CCC Camp (where some people might be interested in obtaining one). Regards, Harald -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

13 years, 11 months

3
7
0 0

SIMtrace hardware update

by Harald Welte

Hi all, unfortunately the number of hardware bugs is quite numerous. for those interested in the details, feel free to read the ticket list in trac. None of the bugs that I've found so far is too serious for a manual re-work of the prototype. My device is now already enumerating its SAM-BA loader on the USB. JTAG is working, too: I can set the red/green LED via JTAG. I'll do some further testing (SPI, SIM card interface) as soon as I find time... -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

13 years, 11 months

3
7
0 0

SIMtrace PCBs / prototype progress

by Harald Welte

Hi all! Today the PCBs have arrived and I spent some tiem building the first prototype. Soldering after a long time was quite fun but worked great. However, I got stuck for way too long due to two pin-out problems: * the voltage regulator pinout is completely mixed up * the reset switch pinout is wrong and causes the device to be in nRESET all the time I've now applied some re-work and the CPU seems running. However, due to some unknown (probably USB pull-up related) problem, I cannot see it enumerate on USB yet. Will keep you posted about my further progress. I've created tickets for the bugs in our trac (http://bb.osmocom.org/trac/query) Regards, Harald -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

13 years, 12 months

2
3
0 0

prototype PCBs have been drilled

by Harald Welte

See the attached image... -- - Harald Welte <hwelte(a)sysmocom.de> http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Schivelbeiner Str. 5 * 10439 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Directors: Holger Freyther, Harald Welte

14 years

2
2
0 0

SIMTRACE components have arrived

by Harald Welte

Hi all, JFYI: The components for the SIMTRACE prototypes have arrived. The PCB will be shipping on June 9, so I guess it will arrive after the whitsunday holidays and we should be able to build the first unit[s] on June 14 or 15. Kevin: Do you have some time around those dates? Regards, Harald -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

14 years

2
1
0 0

FPC SIM adapters

by Harald Welte

Hi! It really seems like the FPCB (Flexible PCB) SIM card adapters have been removed from the rebelsimcard.com store. A couple of months ago, you could buy them separately from their "Hex Scanner". I have sent them an inquiry indicating my interest in buying bulk quantities (100 pieces). Let's see if that works. IF not, we may have to develop a 'plan B' in this area :( Regards, Harald -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

14 years

1
0
0 0

SIMtrace PCB and components have been ordered

by Harald Welte

Hi Kevin and others, I've just ordered 4 prototype PCBs as well as components for at least 10 units. I'll keep you posted about the progress. We should have them in less than two weeks. Regards, Harald -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

14 years

1
0
0 0

SIMtrace v0.9+

by Kevin Redon

Hi, The BOM (bill of material) is ready. I finished the netlist, footprint drawing, and footprint selection. all available at : https://gsm.tsaitgaist.info/SIMtrace/v0.9+/ next task : place the components on the board (i'll try smart card size) and route the lines. Kevin

14 years

3
13
0 0

softSIM

by Kevin Redon

Hi, softSIM is out : http://bb.osmocom.org/trac/wiki/softSIM It's not fully implemented but already working (I hope). The osmocomBB use/cooperation will come out soon. Other tools are coming next week (I need to clean them). Have fun, tsaitgaist

14 years, 1 month

2
1
0 0

Osmocom project vs. sysmocom GmbH

by Harald Welte

Hi all! As some of you already know, Holger and I have recently started a new company called "sysmocom - systems for mobile communications GmbH". The process of establishing the new company has now formally concluded. Before some rumours start to spread, we would like to clarify some points and make sure there is mutual understanding between the Osmocom community and the sysmocom company. sysmocom is intended to provide commercial offerings related to the Osmocom projects. This is not entirely new. Especially on the network side, people like Holger and I have been doing quite a lot of paid development to bring those projects forward. We would not have many of the features we have today, if it wasn't for customers who actually pay us for development of OpenBSC, OsmoBSC, OsmoSGSN and the various side projects more targetted at a real network operator like cellmgr-ng, bsc-nat, gb_proxy - just to name a few. However, this has always only been freelancing development of Software. With sysmocom, we want to go one step further and work on hardware products related to the various Free Software projects. Right now I don't want to talk too much about unfinished products, but we are working towards an inexpensive BTS product, we are funding the prototypes for Osmocom SIMtrace, and we will likely also see stuff like OpenBSC appliances. Given our past involvement and exposure into other projects that share a split Free Software / business set-up, we think we understand very well where potential issues of conflict between the two sides may be. Let me make some more clarification what this is not about: * sysmocom is not about creating proprietary derivates of Osmocom software. We work on Free Software which is publicly available under OSI approved and FSF endorsed licenses. We may offer proprietary hardware and sometimes software - but those are independent projects from existing Osmocom software. * we specifically will not have a public and a non-public version of the same program with differences in features. * sysmocom is not a VC-funded startup. It's a very small company run out of personal funds with no intention to take external funding or grow rapidly. Nobody but Holger and I determine where it goes and what it does. * sysmocom does not hold any copyright on the Free Software projects. The copyrights stay distributed with the major authors such as Holger, Onwaves, Sylvain, Dieter, Andreas and myself. None of the others have any affiliation with sysmocom. I have (personally, unrelated to sysmocom) asked some of the smaller contributors for a copyright transfer to make sure we could do the AGPLv3 transition, or future re-licensing decisions without having to ask dozens and dozens of people. sysmocom does not seek to control the Free Software projects. * we will maintain a strict separation between the community side of things and the business side. Unlike some other popular projects, we will not end up in a situation where the osmocom.org websites will be full of advertisements and hidden links that lure you on the company website. * we will keep a strict separation of naming. Osmocom is for the FOSS projects, sysmocom for the business. The company will use the term "Osmocom" only in descriptive context, not as a product name, brand or for advertisement. If you do have any concerns, please feel free to share them. However, I'd like to avoid cross-posting them throguh different mailing lists. Please follow-up-to openbsc(a)lists.osmocom.org Regards, Harald -- - Harald Welte <hwelte(a)sysmocom.de> http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Schivelbeiner Str. 5 * 10439 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Directors: Holger Freyther, Harald Welte

14 years, 1 month

1
0
0 0

simtrace hardware kicad project now part of simtrace.git

by Harald Welte

Hi all! The kicad project for the simtrace hardware that Kevin has been working on is now available as part of the simtrace.git repository on git.osmocom.org. This will allow us to document the revision history of any modifications to the hardware in the commit messages, and it allows us to see differences between individual versions. Regards, Harald -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

14 years, 1 month

1
0
0 0

SIMtrace v0.8

by Kevin Redon

hi, here v0.8 : https://gsm.tsaitgaist.info/SIMtrace/v0.8/ Compared to v0.7+, I added 2 1n4148 after the parallel voltage regulator outputs. I wanted to avoid the regulators to fuzz each other, but I don't know if it's right. Maybe an additional zener diode is also required. Now I'm looking for the parts and footprints. Kevin

14 years, 1 month

3
6
0 0

packet-gsm_sim wireshark

by K2

It is assumed in the dissector that the TERMINAL PROFILE has a len of 17, which is not the case with the SIM i'm currently using. I fixed it replacing with: case 0x10: /* TERMINAL PROFILE */ offset += DATA_OFFS; if(p3 >= 1) proto_tree_add_bitmask(tree, tvb, offset++, hf_tprof_b1, ett_tprof_b1, tprof_b1_fields, FALSE); if(p3 >= 2) proto_tree_add_bitmask(tree, tvb, offset++, hf_tprof_b2, ett_tprof_b2, tprof_b2_fields, FALSE); if(p3 >= 3) proto_tree_add_bitmask(tree, tvb, offset++, hf_tprof_b3, ett_tprof_b3, tprof_b3_fields, FALSE); if(p3 >= 4) proto_tree_add_bitmask(tree, tvb, offset++, hf_tprof_b4, ett_tprof_b4, tprof_b4_fields, FALSE); if(p3 >= 5) proto_tree_add_bitmask(tree, tvb, offset++, hf_tprof_b5, ett_tprof_b5, tprof_b5_fields, FALSE); if(p3 >= 6) proto_tree_add_bitmask(tree, tvb, offset++, hf_tprof_b6, ett_tprof_b6, tprof_b6_fields, FALSE); if(p3 >= 7) proto_tree_add_bitmask(tree, tvb, offset++, hf_tprof_b7, ett_tprof_b7, tprof_b7_fields, FALSE); if(p3 >= 8) proto_tree_add_bitmask(tree, tvb, offset++, hf_tprof_b8, ett_tprof_b8, tprof_b8_fields, FALSE); if(p3 >= 9) proto_tree_add_bitmask(tree, tvb, offset++, hf_tprof_b9, ett_tprof_b9, tprof_b9_fields, FALSE); if(p3 >= 10) proto_tree_add_bitmask(tree, tvb, offset++, hf_tprof_b10, ett_tprof_b10, tprof_b10_fields, FALSE); if(p3 >= 11) proto_tree_add_bitmask(tree, tvb, offset++, hf_tprof_b11, ett_tprof_b11, tprof_b11_fields, FALSE); if(p3 >= 12) proto_tree_add_bitmask(tree, tvb, offset++, hf_tprof_b12, ett_tprof_b12, tprof_b12_fields, FALSE); if(p3 >= 13) proto_tree_add_bitmask(tree, tvb, offset++, hf_tprof_b13, ett_tprof_b13, tprof_b13_fields, FALSE); if(p3 >= 14) proto_tree_add_bitmask(tree, tvb, offset++, hf_tprof_b14, ett_tprof_b14, tprof_b14_fields, FALSE); if(p3 >= 15) proto_tree_add_bitmask(tree, tvb, offset++, hf_tprof_b15, ett_tprof_b15, tprof_b15_fields, FALSE); if(p3 >= 16) proto_tree_add_bitmask(tree, tvb, offset++, hf_tprof_b16, ett_tprof_b16, tprof_b16_fields, FALSE); if(p3 >= 17) proto_tree_add_bitmask(tree, tvb, offset++, hf_tprof_b17, ett_tprof_b17, tprof_b17_fields, FALSE); /* FIXME */ break;

14 years, 1 month

2
1
0 0

SIMtrace v0.7

by Kevin Redon

Hi The corrections have been applied. I hope I did not forget anything. The main changes : - reset is a jumper - bootloader switch added - 100k resistors used (instead of 4.7k, I hope it does not break anything) - jack connector added (for the debug) - WP from flash connected - USB voltage regulator TPS73633 used (lower capacitance) - USB buffer used instead of the openPCB solution (thus no pull-up and reset connection). saves space and complexity - pin renamed - QS3244 instead of QS3245 used, I/O and other pins are controlled separately - ... To make the changes I used the AT91SAM7X-EK Evaluation Board User Guide. The overall capacitance is reduced, but I think the 22uF for the battery should be kept. files : https://gsm.tsaitgaist.info/SIMtrace/v0.7/ good luck, Kevin

14 years, 1 month

2
6
0 0

SIMtrace v0.6 schema

by Kevin Redon

Hi, here the schema. all the components are on it, but I don't know if the electrical part is right. Any comments/advices are welcome. schema : https://gsm.tsaitgaist.info/SIMtrace/v0.6/SIMtrace.ps source (KiCAD) : https://gsm.tsaitgaist.info/SIMtrace/v0.6/

14 years, 1 month

3
4
0 0

Re: SPI flash

by Kevin Redon

Hi, I never tried WSON, but I think it's still possible to solder it. To do it (as most of the smd), I use a heating plate and a hot air gun (with soldering paste), and not a soldering iron. So it might also work with this package. But the SOIC package is easier for others. Even it's it two time the price, it's not too expensive. So you can choose any. Kevin On 06.05.2011 11:34, Harald Welte wrote: > Hi! > > I think one of the big concerns is to use components that can still be > soldered manually (like SOIC-8). All the larger-than-32MBit (4MByte) > SPI flashes that I could find were in smaller cases with no leads > extending from the case (like WSON). > > This one looks fine to me, and is available from digikey: > http://search.digikey.com/scripts/DkSearch/dksus.dll?Detail&name=SST25VF032… > datasheet: http://ww1.microchip.com/downloads/en/DeviceDoc/S71327_04.pdf > > Regards, > Harald >

14 years, 1 month

1
0
0 0

None

by Luca Bongiorni

14 years, 1 month

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

simtrace