Mifare emulator

TomBu · 2009-08-24 10:20:20

Dear all,

Roel has been asking in the LibNFC forum if there was any interest for a device that is basically a PN532 RFiD chip connected to a microprocessor. See this post.

I have a PCB layout for a battery operated device that has one push button, 3 LEDs, a power management unit to load the battery via the mini USB and an Atmel ARM7 combined with a PN532. This board is for experimenting, testing and developing the core software. It has a lot of test point available and even a mini breadboard area. So even if there are mistakes in the design they probably can be corrected with some soldering.

Look at a 3D image of the board here.

If this proof of concept turns out well I plan to do a second iteration of the device which will have a touch screen, a CSR Bluetooth chip and maybe a real time clock.

With the first iteration I hope to achieve the folowing:
- emulate a stored Mifare card in software (including UID)
- detect MiFare card readers and retrieve the key
- conduct a MiFare card only attack and store the card content
- possibly set up some form of inter device communication via NFC

While chopping wood at HAR Roel solemnly swore by the holy axe that he would help me with developing software for this board. He suggested that LibNFC, a C library he made, could probably be used control the PN532. Even though he might have been a little intoxicated while uttering these thoughts I still think he might well be right. :-)

So that’s a big chunk of work that can be reused. However a lot more still needs to be done before the above mentioned functionality is implemented.

Now I want to start ordering parts and PCB boards on the 1st of September, hence I would like to know before that time if there are people interested in:
- purchasing the first iteration of the device (*)
- developing software for the board
My aim is to have the boards ready to ship near the end of September.

(*) My goal is to sell the device at the estimated production cost of 70 euro.
The device will come with an antenna and a rechargeable battery.
The cost of a JTAG interface (the physical plastic thing) is about 10 euro on Digikey so I'm thinking of including that only upon special request (and extra cost). The Atmel operates on the correct frequency for SAM-BA to work, so the JTAG should really only be for hardcore debugging.

Please respond here or via e-mail to:
t o m . b u e l e n s @ g m a i l . c o m

Kind regards,
Tom

Last edited by TomBu (2009-08-24 11:26:55)

shinechou · 2009-08-24 10:40:29

very interesting, how about shipment fee?

TomBu · 2009-08-24 10:57:12

Hi,

Good question. Didn't think of of shipment cost yet.

I guess I can send it in a bubble wrap envelop with the regular mail.
Then costs will be:
Inside Europ via regular mail 5 euro and priority 7 euro
Everywhere else via priority mail 11 euro

These are estimates if I only send one.
Other fees will apply when sending multiple at once; probably cheaper.

I was thinking of selling them via E-bay and then you'll see the exact costs.
This is just to check if there is any interest at all in them, so I can see how many I need to make (if at all). :-)

Kind regards,
Tom

Last edited by TomBu (2009-08-24 10:58:07)

henryk · 2009-08-24 12:09:27

TomBu wrote:

While chopping wood at HAR Roel solemnly swore by the holy axe that he would help me with developing software for this board. He suggested that LibNFC, a C library he made, could probably be used control the PN532.

Yes, I've already something similar working inside a different project: https://openbeacon.svn.sourceforge.net/ … openpicc2/ (application/nfc/ is the code relating to the PN532 interface and libnfc glue code; application/libnfc/ is a, somewhat oldish, version of libnfc modified with the infrastructure to accept reader code outside of the libnfc code).

Don't be put off by the complexity, a lot of that code relates to the ... interesting and unique properties of NXP's SPI protocol and the subsequent problems of using the same bus with other devices (there are three other devices on the SPI on that board). Among them are:

Look ma, we're using a different bit order than every other SPI device in existence
No, you may not lower the chip select line while a communication exchange is active. This of course combines perfectly with ...
Frames have a variable size and the size is (sometimes indirectly) transmitted within the start of the frame

(Also, ignore the whole wait_queue mechanism, that is way over-engineered. I was initially expecting the responses to come out-of-order, and this is a way to match responses to requests from multiple sources in the firmware. Of course that doesn't apply, as I know now, commands may not be interleaved.)

When designing your board, keep in mind some of the (potential) gotchas that we have encountered:

Low VBat mode and the corresponding changes to the circuit (depending on which version of the PN532 you have)
Interface selection pins (P70_IRQ, P35). On our board they where right, through some sheer luck.
Handshake mode, which seems to be NXP's choice of words for normal IRQ-based operation.

rule · 2009-08-25 08:58:03

@ Henryk
I see it will be an challenge, with some spare-time and determination I see possibilities

@ Tom
Will it be possible to integrate the antenna into the design? (maybe even around the ICs)
This could make it way more robust/compacter ?;)

TomBu · 2009-08-25 09:08:39

henryk wrote:

When designing your board, keep in mind some of the (potential) gotchas that we have encountered:
Low VBat mode and the corresponding changes to the circuit (depending on which version of the PN532 you have)
Interface selection pins (P70_IRQ, P35). On our board they where right, through some sheer luck.
Handshake mode, which seems to be NXP's choice of words for normal IRQ-based operation.

Dear Henryk,

Thank you for your feedback.

I was under the impression that my PCB layout was done.
However I would like to verify that I did not make the mistakes you mentioned.

Could you elaborate a bit more on the gotchas you experienced?
Do you want or have schematics?

I've tried to find more info regarding the OpenBeacon however I couldn't find any schema or layout with a PN532 on it :-(.

Cheers,
Tom

Last edited by TomBu (2009-08-25 09:17:27)

TomBu · 2009-08-25 09:15:30

roel wrote:

Will it be possible to integrate the antenna into the design? (maybe even around the ICs)
This could make it way more robust/compacter ?;)

Hi Roel,

You are right it would make the device more robust and compact.
However in this is first version of the board I preferred flexibility over comfort.

If the PCB antenna would not be good for some reason or another you would have to do some difficult rework.
Now it will come with an antenna and if you don't like that one you can always change it yourself.

Cheers,
Tom

d18c7db · 2009-08-25 11:26:32

Tom I just finished drawing up a PCB of my Snapper token's antenna, see RFIDANT1356.zip in the files section (currently in Uploads). There's a PDF of what the PCB looks like if you don't have Eagle. Also a JPG of the original I based the drawing on, I made it as close as possible to the original using a microscope with a reticle to measure the dimensions then rounded to the nearest mil (1/1000 inch). No promisses on the accuracy but it may be close enough to work

This antenna fits on the output stage of a PN531 chip which is the same as the output stage of a PN532 based on the datasheets.

Oh one more thing, in the picture the antenna PCB is de-soldered but normally it would sit 4mm above the main PCB via that 3 pin header.

Last edited by d18c7db (2009-08-25 11:29:24)

henryk · 2009-08-25 17:01:35

Moin,

TomBu wrote:

I was under the impression that my PCB layout was done.

Do you have the layout and schematics online for cross-checking?

TomBu wrote:

I've tried to find more info regarding the OpenBeacon however I couldn't find any schema or layout with a PN532 on it :-(.

Yes, I think it's not online anywhere. The OpenPICC2 project is basically cancelled, the hardware is now exclusively used as txtr.mini, which lies more or less dormant in favor of the real txtr hardware.

TomBu wrote:

Could you elaborate a bit more on the gotchas you experienced?

See the datasheets and application notes for the PN532 (and be sure to look at the right version, e.g. PN532C104 vs. PN532C106). With regards to the interface selection pins: See UM0502-06 PN532 User Manual (doc 126606) section 2 (for ...C104) and AN10609_2 PN532 Application note, C106 appendix (doc 153710) section 2.1 (for ...C106).

The gist of it: The PN532 can be operated in several modes and will select the mode by looking at two pins during the reset phase: P70_IRQ and P35. Version C104 will boot in normal mode if both pins are low or both pins are high. If P70_IRQ is high and P35 is low it will boot into a perfect PN512 emulation mode (using only the slow speed UART), if P70_IRQ is low and P35 is high it will enter a special test mode that continuously powers the RF field (and, IIRC, disables the internal over-temperature shutdown). Version C106 will boot in normal mode when P70_IRQ is high (P35 can be high or low). If P70_IRQ is low, and P35 is low it will enter the RF field on test mode, if P35 is high it will enter "EmuJoiner mode" (not described any further).

TomBu · 2009-08-25 18:37:47

henryk wrote:

Do you have the layout and schematics online for cross-checking?

Here are the schematics.
How do you want the layouts?

Thanks for all the feedback.
Will process it later :-)

Kind regards,
Tom

d18c7db · 2009-08-25 21:05:58

Tom you can export the schematic and PCB from Altium as a multi page PDF, I'll email it to you as I've already done it. You should be OK as both pins mentioned (in fact all IO pins of the PN532) connect to the ARM IO lines so you could set whatever levels you want on them then toggle reset but Henry's input is still relevant during the software phase as you need to be aware of that as you (or Roel) write the initialization code.

Last edited by d18c7db (2009-08-25 21:07:39)

henryk · 2009-08-25 22:34:00

Ok, I see you have connected the reset line to a pull-down, which will keep the PN532 in reset until the proper configuration is set. From what I can see, I guess you want to operate the PN532 through the High Speed UART? I've never used the USART in the AT91SAM7 so I can't comment on that specifically, but ... shouldn't you connect the Tx line from the PN532 to the Rx line of the AT91SAM7 and vice versa?

Further notes:

For SAM-BA operation, PA16 must be connected to the USB pull-up, inverted. I think you have your pull-up on PA0. Also, for SAM-BA operation it would be best to offer the AT91 TEST signal on a (what's that thing called where you place jumpers on?). You can see both properties on the OpenPICC schematics.
You have connected NFC_TESTEN to a PIO. The NXP documentation suggests tying it permanently to ground, and there is no info on what would happen if it were high. So, you can safely disconnect it from the PIO and connect it to ground, if you see that you are short of PIOs.
I recommend connecting NFC_AUX1/2 to a PIO on the AT91, there might be interesting signals on there. Of course, keep it on a testpad additionally.
SIGIN/OUT/CLK should be connected to the SSC peripheral of the AT91 for additional possibilities (that way you can simulate a SAM with the AT91).
I'd recommend connecting both UARTs of the PN532 (the HSU and the Debug UART) to the two USARTs on the AT91 (TXD0/RXD0 and TXD1/RXD1), that way you can also enable the PN512 emulation mode of the PN532.
For added funkyness: prefer timer and pwm outputs for the LED connections (PWMx, TIOAx/TIOBx, try to keep the dual-color LEDs on the same TIOA/Bx), so that the brightness of the LEDs can be dimmed.
If you are prepared to commit to using the PN532 HSU instead of I2C or SPI, you can tie the host interface selection pins (I0/I1) to ground to free up PIOs if necessary.

(Note that I'm a digital and firmware guy, I can't comment on the analog part at all.)

henryk · 2009-08-26 01:31:42

Ok, I have come up with a pin assignment that covers all connection possibilities that I can think of, when using the High Speed UART of the PN532.

On the PN532:

I0 (pin 16) to GND
I1 (pin 17] to GND
TESTEN (pin 18) to GND
MISO/P71 (pin 29) not connected
SCK/P72 (pin 30) not connected

Between AT91 and PN532:

PA2 (as GPIO) from NFC_AUX1 (AUX1, pin 12), for test signals, low priority, also on test pad
PA3 (as GPIO) from NFC_AUX2 (AUX2, pin 13), for test signals, low priority, also on test pad
PA4 (as GPIO) to NFC_P35 (P35, pin 19), for mode configuration
PA5 (as RXD0) from NFC_TX (MOSI/SDA/HSU_TX, pin 28), high speed UART
PA6 (as TXD0) to NFC_RX (NSS/P50_SCL/HSU_RX, pin 27), high speed UART
PA7 (as GPIO) to/from NFC_P70_IRQ (P70_IRQ, pin 25), for mode configuration, for host interrupt
PA8 (as GPIO) to/from NFC_RSTOUT_N (RSTOUT_N, pin 26), for reset indication, low priority
PA11 (as GPIO) to NFC_P32_INT0 (P32_INT0, pin 32), for host request
PA12 (as GPIO) to/from NFC_P33_INT1 (P33_INT1, pin 33), for what? low priority, I guess
PA13 (as GPIO) to NFC_RSTPD_N (RSTPD_N, pin 38), for reset and power down, pull-down
PA17 (as TD) to NFC_SIGIN (SIGIN, pin 36), for SAM emulation
PA18 (as RD) from NFC_SIGOUT (SIGOUT, pin 35), for SAM emulation
PA19 (as RK) from NFC_SIC_CLK (P34/SIC_CLK, pin 34), for SAM emulation
PA20 (as GPIO) from NFC_SVDD (SVDD, pin 37), low priority
PA21 (as RXD1) to/from NFC_DTX (P31/UART_TX, pin 31), for handshake configuration, for debug UART
PA22 (as TXD1) to NFC_DRX (P30/UART_RX, pin 24), for debug UART

Between AT91 and the rest of the board:

PA0 only connected to test pad, offers GPIO or TIOA0
PA1 only connected to test pad, offers GPIO or TIOB0
PA9 only connected to test pad, offers GPIO or Debug UART RX
PA10 only connected to test pad, offers GPIO or Debug UART TX
PA14 only connected to test pad, offers GPIO or PWM3
PA15 (as TIOA1) from /CHRG (U4, pin 7), for frequency and duty cycle measurement of charger state
PA16 (as GPIO) to USB_PUP_PRE, inverted USB pull-up
PA23 (as PWM0) to blue LED
PA24 (as PWM1) to green/red 1 (D4, pin 2)
PA25 (as PWM2) to green/red 1 (D4, pin 1)
PA26 (as TIOA2) to green/red 2 (D5, pin 2)
PA27 (as TIOB2) to green/red 2 (D5, pin 1)
PA28 (as GPIO) to D0, charger configuration, pull-down
PA29 (as GPIO) to D1, charger configuration, pull-down
PA30 (as GPIO) to D2, charger configuration, pull-down
PA31 (as GPIO) to SW1, user input

Pins I marked as low priority can, I think, be safely discarded without losing core functionality. PAx used as GPIO can be freely relocated (with the notable exception of PA16). I ended up with 5 free PAx and choose the assignment so that the free pins, when connected to a test pad, would offer a maximum in additional flexibility: There's a timer/counter channel (those are worth their weight in gold, for a lot of applications), a PWM output and the debug UART.

I don't know with which criteria you added pull-downs to your original schematic, but I explicitly noted the places where they are absolutely essential. Especially the pull-downs on D0/D1/D2 are fun to forget (I have seen that twice, in two different projects): Since the AT91 has internal pull-ups the pins would read high for the LTC4088, which would make it only offer minute amounts of power if the battery is empty. This in turn means that the AT91 can not boot and can not set the proper configuration, essentially leaving the device dead once the battery is exhausted.

One notable omission: There is no remaining free USART on the AT91, so if you want to connect a smart card to it, you'll have to bit-bang the interface.

For added security you might even consider distributing the five pins that I have disconnected from the PN532 over the five free AT91 pins, but then I strongly suggest adding 0Ohm resistors to have the choice of both ways.

Last edited by henryk (2009-08-26 01:43:54)

d18c7db · 2009-08-26 04:56:16

Tom, although I haven't used Altium Designer before, I might be able to make most of those changes, free of charge. Let me know if you're interested. Would be interesting getting to learn a new CAM package.

TomBu · 2009-08-26 11:58:01

Dear Henryk & d18c7db,

I'm not into hardware and into PCB design at all.

I'm just a guy with an idea that wants to make an open source MiFare "software" implementation. I think that, especially when this device is combined with bluetooth communications, the open source version can offer unbeatable advantages.

To the best of my knowledge there are no legal restrictions that prevent me from doing so. MiFare is 'only' a TradeMark of NXP. The Crypto1 cypher is not patented. I'm interested to see proof that shows me wrong.

Thus I would love to make this an Open Source project. Does anyone have an idea how to do this?

To make a small start, here are the Altium files.

Now, I value Henryk's input and experience very much.
And d18c7db, thank you for your offer to make the changes in Altium.
Please do feel free to make them and post the results somewhere.
However I'm going to ask the original designer to review the above comments and ask him to act (or react) on them.

Kind regards,
Tom

TomBu · 2009-08-26 12:47:08

d18c7db wrote:

Tom you can export the schematic and PCB from Altium as a multi page PDF, I'll email it to you as I've already done it.

Hi d18c7db,

I've placed your export here.

Cheers,
Tom

henryk · 2009-08-26 20:12:19

I've just talked with Milosch Meriac, since I wanted to take over some additional features from the OpenPICC2/txtr.mini board. For example, Tom's design doesn't have a power switch at all, it will just operate as long as the battery is connected. Also, you can't measure the current battery voltage.

Milosch says he still has a sizeable quantity of PN532 that he wanted to turn into a product anyway, and suggested starting an OpenPCD2 project, laying both OpenPICC2 and OpenPCD to rest in the process. Fundamentally this would be like the OpenPICC2/txtr.mini but without the ebook components (capacitive touch interface, interface to eInk controller), notably including an AT91SAM7SE512 and PN532. Since this just consists of removing things from the original design, the design could be done in one week, with an additional three weeks for production.

Then the discussion went over to what you would be able to do with the device, and here I'll need input from Roel: How was the original design supposed to be a Mifare emulator? I added the SAM connection, but I think we might face the same problems that the original OpenPICC had with timing and jitter. At HAR you mentioned in passing something about Mifare emulation capability, how would that work? Does it need the SAM interface or is the main PN532 communication interface enough?

This would be central to some detail questions: For one, the ...SE512 has an external SDRAM interface, which could come in extremely handy for continuous sampling, however, you can't have 32bit SDRAM and SSC at the same time (it might work with 16bit SDRAM). One possible addition would be placing an FPGA between PN532 and AT91, this might cover for the time domain conversion difficulties when using the SAM interface. Simply inserting an FPGA shouldn't add much delay to the time estimate above, however, replacing the AT91SAM7SEx with an AT91SAM7Sx probably would.

d18c7db · 2009-08-26 21:13:26

I won't rush into routing the board then I made the changes to the schematic as you suggested in [13] above, including the pulldowns on D0-D2

Or are you proposing scrapping Tom's design completely and just modifying the OpenPICC design?

TomBu · 2009-08-26 22:51:56

Hi Henryk,

Please keep in mind that this design is intended to be a Proof of Concept and was not meant to be a fully featured product. This is sort of a homegrown demo board which would be ideal to experiment with and hopefully achieve some cool results.

henryk wrote:

Tom's design doesn't have a power switch at all, it will just operate as long as the battery is connected.

Well, the idea was that the software brings the whole device into low power mode when not active for some time. Disadvantage: not completely off, although you have the battery connector for that :-)
Advantage: device can react quickly to any RFID field that's near.

henryk wrote:

Also, you can't measure the current battery voltage.

Good point. What's the use? Since there's no display to show the voltage? (at this stage of the development)

henryk wrote:

Milosch says he still has a sizeable quantity of PN532 that he wanted to turn into a product anyway,

I was having a difficult time finding those babies. In the end someone pointed me to a guy in Shenzen (HongKong, mainland China) that could sell them to me. Somehow I would prefer to buy them from Milosch instead. :-) Could you ask him if he would consider selling some, let's say 25 or so?

henryk wrote:

Then the discussion went over to what you would be able to do with the device,

When working on a software emulator with LibNFC on a PC and a TouchaTag I found out, or maybe Roel mentioned to me, that the lack of speed of the USB bus is the restricting factor when trying to emulate a card. Because of that I wanted to bring the CPU closer to the PN532 :-) I would prefer to not use or emulate a SAM at all and instead just give direct instructions to the PN532 what to 'say'. I also would not like to use the encryption possibilities of the PN532 but have it all done in software.

Do you think such is possible? Or if not then why.

henryk wrote:

This would be central to some detail questions: For one, the ...SE512 has an external SDRAM interface, which could come in extremely handy for continuous sampling, however, you can't have 32bit SDRAM and SSC at the same time (it might work with 16bit SDRAM).

I do not see the need for "continuous sampling". Can you please explain?
Why should the RAM and the flash memory not be enough?

It's just a Proof Of Concept to see if it works and then advance to another design.
My aim is to keep it simple and make small improvements in every new design.

Looking forward to your comments.

Kind regards,
Tom

Last edited by TomBu (2009-08-27 09:54:01)

TomBu · 2009-08-28 10:11:39

Hi,

d18c7db has been so nice as to update the schema with the changes Henryk mentioned in #13.
Here's the new schema.

Dear Henryk, would you mind reviewing the new schema?
I'll ask the original designer to update the layout as soon as you've confirmed the updates.

If you want the old schema's and layouts just ask, the links wont work any longer.

Cheers,
Tom

d18c7db · 2009-08-29 00:28:08

Ohh, you're messing with my mind while I'm hung over LOL

When I opened the link to the PDF I thought "that doesn't look like the new schema", then I noticed you've appended the new schema to the old one so the updated schema starts at page 6

henryk · 2009-08-31 02:42:26

Sorry for not answering earlier, I'm just back from taking a long weekend off. One thing that occurred to me while away is that I was wrong earlier: The original design didn't have the USB Pull-up on PA0, but on PA31, and on PA0 is something that is probably supposed to be a voltage divider to detect the presence of an USB host. Now, analog stuff is not my strong suit, but aren't the input and output of the voltage divider reversed? E.g. you want a divider which lets you detect the presence of a 5V signal on a 3.3V microprocessor. E.g. what you want is

 5V input --- resistor approx 1*x Ohms --+-- resistor approx 2*x Ohms -- GND
                                         `-- 3.3V output

but what you got is

 5V input --+-- resistor approx 2*x Ohms -- GND
            `-- resistor approx 1*x Ohms -- 5V output

(I think this would be a current divider)

As for your updated schematics:

The same applies, I think the voltage divider on PA0 needs to be fixed
I think (again, this is way to analog for me) the pull-up on PA16 is still not correct, it needs to be inverted. If PA16 is high (it has an internal pull-up, so this is the reset state) the USB pull-up must be disabled. If PA16 is low, the USB pull-up must be enabled. See the OpenPICC schematics for an example: http://www.openpcd.org/dl/openpicc/Open … _3_SCH.pdf
The rest seems to be ok.

d18c7db · 2009-08-31 22:37:13

Henryk you're of course correct. I beleive the designer meant to use a p-channel mosfet on PA16 which would accomplish the inversion required. This design illustrates what I mean.

I really don't know what he was trying to do on PA0 with that voltage divider, so I'll go ahead and assume he was trying detect if the USB bus is connected (powered) so I'll update the schematics based on that and send them to Tom.

d18c7db · 2009-08-31 23:24:19

Actually I think he may have tried to replicate the schematic off the Atmel dev. board (see page 22) and failed. There's a resistor divider there in the same configuration. If there are no objections, I could update Tom's schematic to be the same as the dev board regarding the USB pullup (except use PA0 for VBUS detection instead of PA13 which the dev board uses).

Everybody happy with that?

0blar · 2009-09-08 10:01:55

Hello

Do you have any news regarding the new hardware ?

Regards

TomBu · 2009-09-08 10:34:09

Hi all,

It's been quiet but not without progress.

First of, I've baptized the project Mikey and because that domain was already taken you can now find stuff on mikeycard.org. Just check it out and see what happens if you put www, forum, blog, wiki or other things in front of it. Anyway that will become the place to dump all stuff related to this project. Please feel free to contribute. Send me a note if you want to become an admin or stuff like that. By the way, the project could do with a nice logo, for instance. :-)

On the hardware side of things, I've had a green light from Henryk on the latest and greatest review. So now I have an updated PCB layout which I want to send to EuroCircuits sometime today or tomorrow. Yesterday I've received the PN532's (that's the rfid chip from NXP) and ordered some crystals and leds from Farnell. Hopefully I'll get the big Digikey order (500 euro) out today and then I'll have to wait till it all arrives.

I have no experience in soldering so I figured that I'll be best if I don't start with this project. :-) Hence I'm going to work with solder paste, Kapton stencils and a toaster oven to bake the assembled boards. The first batch will be 10 pieces and I wish some can withstand my mistreatment. :-))

Hope this satisfies your news hunger a bit. Thanks for your interest. I'll keep you posted here and on MiKeyCard.org

Cheers,
Tom

0blar · 2009-09-08 22:27:36

Hi

Thanks for your response
Unfortunately I'm not an electonic or software guy, but I can build one PCB for testing purpose if you need it

regards

TomBu · 2009-09-22 13:29:17

The information on my website has been lagging a bit. Sorry for that. I've finally managed to get some content up there. This page has links to the demoboard.

Wanna help with keeping the website up to date and stuff? Drop me a line!

Cheers,
Tom

TomBu · 2009-10-18 23:06:16

Hi,

Together with Roel and djRevMoon I've managed to get two boards assembled.
And of course there are some problems.
- The device ID that I get via the JTAG interface is a bit funky
- The ARM keeps on running and won't ever get into halt mode.

For more up to date info see the blog

If you have seen this before or think you can help out otherwise then please don't feel shy.

Cheers,
Tom

TomBu · 2009-10-21 08:57:32

Hi for those of you who care to know and haven't found their way to the blog....
Yesterday evening the device started working as expected, after removing R6 and attaching a battery to it.

Proxmark3 community

Announcement

#1 2009-08-24 10:20:20

Mifare emulator

#2 2009-08-24 10:40:29

Re: Mifare emulator

#3 2009-08-24 10:57:12

Re: Mifare emulator

#4 2009-08-24 12:09:27

Re: Mifare emulator

#5 2009-08-25 08:58:03

Re: Mifare emulator

#6 2009-08-25 09:08:39

Re: Mifare emulator

#7 2009-08-25 09:15:30

Re: Mifare emulator

#8 2009-08-25 11:26:32

Re: Mifare emulator

#9 2009-08-25 17:01:35

Re: Mifare emulator

#10 2009-08-25 18:37:47

Re: Mifare emulator

#11 2009-08-25 21:05:58

Re: Mifare emulator

#12 2009-08-25 22:34:00

Re: Mifare emulator

#13 2009-08-26 01:31:42

Re: Mifare emulator

#14 2009-08-26 04:56:16

Re: Mifare emulator

#15 2009-08-26 11:58:01

Re: Mifare emulator

#16 2009-08-26 12:47:08

Re: Mifare emulator

#17 2009-08-26 20:12:19

Re: Mifare emulator

#18 2009-08-26 21:13:26

Re: Mifare emulator

#19 2009-08-26 22:51:56

Re: Mifare emulator

#20 2009-08-28 10:11:39

Re: Mifare emulator

#21 2009-08-29 00:28:08

Re: Mifare emulator

#22 2009-08-31 02:42:26

Re: Mifare emulator

#23 2009-08-31 22:37:13

Re: Mifare emulator

#24 2009-08-31 23:24:19

Re: Mifare emulator

#25 2009-09-08 10:01:55

Re: Mifare emulator

#26 2009-09-08 10:34:09

Re: Mifare emulator

#27 2009-09-08 22:27:36

Re: Mifare emulator

#28 2009-09-22 13:29:17

Re: Mifare emulator

#29 2009-10-18 23:06:16

Re: Mifare emulator

#30 2009-10-21 08:57:32

Re: Mifare emulator

Quick reply

Board footer