17 Dec
2010
17 Dec
'10
12:03 a.m.
I ordered a SAM7-P64 board for running Simtrace (received board today, but
still waiting for the REBELSIm connectors). When compiling the code (using
Gnuarm3.4.3) I got two errors:
1) the --g($DEBUGF) option was not understood; omitting this, made the
Makefile (for dfu and main) working
2) in /lib/vsprintf.c I had to add #include <limits.h> in order to prevent
errors related to MAX_INT etc.
Are there any ideas for making a man-in-the-middle SIM device? One master
interface to a real SIM, another slave interface providing a SIM interface
towards a phone with the possibility to filter certain APDU's or to add
files or commands on top of the real SIM. This would need an additional SIM
master interface (to send and receive APDU's to the real SIM) on top of what
already is in SIMtrace and the slave interface should be capable of sending
messaged back to the real SIM master. I will look into it, first starting
with implementing a simple SIM card master on the other UART.
17 Dec
17 Dec
8:12 a.m.
Hi Ste7an,
good to see there are multiple pepole with interest in SIMtrace.
On Fri, Dec 17, 2010 at 12:03:35AM +0100, ste7an wrote:
I ordered a SAM7-P64 board for running Simtrace
(received board today, but
still waiting for the REBELSIm connectors). When compiling the code (using
Gnuarm3.4.3) I got two errors:
1) the --g($DEBUGF) option was not understood; omitting this, made the
Makefile (for dfu and main) working
2) in /lib/vsprintf.c I had to add #include <limits.h> in order to prevent
errors related to MAX_INT etc.
those are probably all related to the fact that
Are there any ideas for making a man-in-the-middle SIM
device? One master
interface to a real SIM, another slave interface providing a SIM interface
towards a phone with the possibility to filter certain APDU's or to add
files or commands on top of the real SIM.
sure, there are ideas for this. The easiest way is to implement transmit
support in the SIMtrace firmware + host software and use that implementation as
the 'card emulation' part. You can then use any pcsc-lite supported card
reader to actually talk to the card, and write some PC software that passes
and filters or even manipulates the APDUs.
This would need an additional SIM master interface (to
send and receive
APDU's to the real SIM) on top of what already is in SIMtrace and the slave
interface should be capable of sending messaged back to the real SIM master.
I will look into it, first starting with implementing a simple SIM card
master on the other UART.
Implementing the reader side inside the SAM7S (on the other UART) will work,
too - but at the expense of having to write your own card reader firmware.
Depending on where you want to go, simply using an existing USB card reader for
the SIM will be the quicker road to success.
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)
9:45 a.m.
Sorry, I was missing the second half of one sentence:
On Fri, Dec 17, 2010 at 08:12:32AM +0100, Harald Welte wrote:
On Fri, Dec 17, 2010 at 12:03:35AM +0100, ste7an
wrote:
... you are using a different toolchain than the gnuarm-4.0.2 that we use for
OsmocomBB as well as OpenPCD and SIMtrace cross-compilation.
--
- 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)
I ordered a SAM7-P64 board for running Simtrace
(received board today, but
still waiting for the REBELSIm connectors). When compiling the code (using
Gnuarm3.4.3) I got two errors:
1) the --g($DEBUGF) option was not understood; omitting this, made the
Makefile (for dfu and main) working
2) in /lib/vsprintf.c I had to add #include <limits.h> in order to prevent
errors related to MAX_INT etc.
those are probably all related to the fact that
24 Dec
24 Dec
1:09 p.m.
SimTrace compiles, I got the P64 board to load the main program. Connected
the RebelSim flatcable+SIM. Without connecting the P64 board, the phione can
use the SIm without a problem. When connecting the I/O and clk to the
PA6+PA1 and PA2+PA4 pins the phone shows a SIM error.
Is there a need for a resistor between the SIM signals and the P64 pins?
Is there a need for a resistor between the input and output ports on the
P64, or can they be directly connected?
In some cases I got the ATR sniffed. The value was consistent with other
readings. So, part of it i working.
17 Dec
17 Dec
10:21 a.m.
I am using the toolchain provided by the summon-arm-toolchain script
from esden.
it uses binutils 2.20, newlib 1.18.0, and gcc 4.5.1
1) the --g($DEBUGF) option was not understood;
omitting this, made the
Makefile (for dfu and main) working
I do not get this error
2) in /lib/vsprintf.c I had to add #include
<limits.h> in order to
prevent errors related to MAX_INT etc.
I also get this error and solve it the same way
Additionally, I get :
error : uses hardware FP, whereas main_simtrace.elf uses software FP
which I could not get rid off yet.
Are there any ideas for making a man-in-the-middle SIM device?
I am designing some SIMtrace hardware. I think the schema is almost
finished. I will publish it in the next days and begin with the board if
no one finds an error. I already ordered most of the parts to build the PCB.
Kevin
4886
days inactive
4887
days old
baseband-devel@lists.osmocom.org
4 comments
3 participants
participants (3)
-
Harald Welte -
ml＠mail.tsaitgaist.info -
ste7an