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)
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)
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)
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.
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
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)
