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