Volunteers for testing new proxmark USB interface (using uart CDC/ACM)

rule · 2012-12-08 09:17:08

asper wrote:

New version always here: svn checkout http://proxmark3.googlecode.com/svn/branches/cdc ? Should I delete previous version before downlaoding it again ?

Nope you can use the following comand (in the /c/proxmark-cdc/ folder):

$svn update

It will automatically update the (changed) source files

asper · 2012-12-08 13:25:18

Thank you ! I sent you an email (using the one provided here: http://www.proxmark.org/contact) with some questions about received data through serial port, can you read and answer it if you know what is the "problem" ?

asper · 2012-12-08 23:53:31

Tested latest cdc bulid (I flashed the OS image only...); it is NOT working correctly right now; I only receive the answer:

#db#

without anything else, after hw version and hw tune... PM3 seems to work but client is not getting the right answer...

Anyway hf mf seems to work now (I don't have a real mifare to test at the moment but pm3 is answering the command).

Fixed something that broke something else ?

Last edited by asper (2012-12-09 00:14:02)

rule · 2012-12-09 10:09:45

Can you try the following in the root folder of the repository (/c/proxmark-cdc)

$make clean
$make

asper · 2012-12-09 10:18:55

I deleted the folder and downloaded it from scratch... without the make clean... isn't this the same ?
Anyway I will try again with "make clean"

Last edited by asper (2012-12-09 10:22:04)

asper · 2012-12-09 10:42:51

Here is my test after clean (the same as deleting the folder and re-downlaoding/making all):

hw version and hw tune do not receive a correct answer in the GUI.
hf mf nested seems not to be working (I tested having a mifare 1k over the antenna)

EDIT: I can confirm that also other commands do not seems to work (es. commands for chinese magic cards [I have 1]).

EDIT2: reverted back to OS r627 (politely compiled by radiowar) and all is working fine.

Last edited by asper (2012-12-09 11:08:55)

rule · 2012-12-09 13:59:13

No clue what happened, windows generate really unpredictable errors, changed struct again.

It should work fine now!

asper · 2012-12-10 11:44:18

Progesses but still problems:

1) now "hw tune" and "hw version" commands work perfectly

2) Unfortunately there still are problems in nested function and using the "chinese function" commands; here is the "log":

Specifically the block read from the chinese card sectors are wrong (what are all those 44 44 at the beginning ?!?!?!); about nested function now there are answers from pm3 but no card select is possible.

PS. When com port is opening through PM3 I receive absolutely no message at beginning while, using r627 or earlyer, at connection I receive a "welcome" message that say SN: ChangeMe; is this normal ?

Last edited by asper (2012-12-10 17:26:20)

o0o0o0o · 2012-12-11 06:15:10

Has something changed with rev 647 ?
Compilation is failing (win7x64)

I'm using yagarto toolchain

rule · 2012-12-11 13:23:33

Please download this environment and follow the instructions. You need the (x86/x64) gcc compiler as well, that one is embedded in the mingw environment.

xxootest · 2012-12-11 14:36:43

@roel

Bug: the same as @asper , Cant't select card . But sometimes ,it's OK . Here is the test-pic.
FluxBB bbcode test

xxootest · 2012-12-11 14:49:16

Sorry for double posted。
Here is another BUG。 when I flashed the osimage of your new cdc-version （r647）,the flasher.exe does not work anymore 。 It can't flash any other firmwares。 Just the Jtag can reflash .
it shows that “Waiting for Proxmark to appear on USB........................................................”

FluxBB bbcode test

rule · 2012-12-11 15:16:02

xxootest wrote:

Sorry for double posted。
Here is another BUG。 when I flashed the osimage of your new cdc-version （r647）,the flasher.exe does not work anymore 。 It can't flash any other firmwares。 Just the Jtag can reflash .
it shows that “Waiting for Proxmark to appear on USB........................................................”

Please hold button when plugging proxmark in. Then, while holding the button, start the flasher program.
Will fix that later, if everything works fine again!

asper · 2012-12-11 18:26:17

Roel, please, can you try to fix the errors with mifare and mifare chinese cards ? In r627 all is working fine so I think is something related to the new serial communication... I am making a VB software, tune and version are working, I am implementing support for chinese card but I cannto fully test if answers are wrong.

Last edited by asper (2012-12-11 18:27:19)

rule · 2012-12-11 22:04:02

Can you guys find a pattern, where does it go wrong. I tested the LF code for hitag, which still seems to work great.
Please report each feature that does not work (reliably) anymore. Is it only ISO14443A, or all HF features? Good to know where to look because it is kind of a strange error.

Also the Firmware got a lot bigger. Could you guys try to comment out some of these flag (in /armsrc/Makefile)

APP_CFLAGS = -O2 -DWITH_LF -DWITH_ISO15693 -DWITH_ISO14443a -DWITH_ISO14443b -DWITH_ICLASS -DWITH_LEGICRF -DWITH_HITAG

Maybe even only ISO14443a

APP_CFLAGS = -O2 -DWITH_ISO14443a

Be sure you do a make clean first! Build it again and see if the same problem still arises?

asper · 2012-12-12 08:03:53

The problem seems to be related to something "internal" to the PM3 because it perfectly works on r627. I have the same issues as xxootest:

1) hf 14a reader fails 19 times on 20

2) hf mf cgetsc (try to read a chinese card) fails 4 times on 5 attempts and, when it works, read wrong values and those wrong values are not always the same.

Here is a COM logging try to read sector 0 (successfully) of a chinese card: http://pastebin.com/cmJn5GyK

I test ANY antenna-tag position/configuration. I always delete the folder and re-download the code from scratc; I also tryed to flash the new compiled FPGA with the same results. Only thing not testes is re-flashing the bootrom but, reading your answers, I don't think this will lead to something better.

rule · 2012-12-12 08:37:27

asper wrote:

Only thing not testes is re-flashing the bootrom but, reading your answers, I don't think this will lead to something better.

So you did test compiling only iso14443a compatibility only (see earlier post), and it did not work?

APP_CFLAGS = -O2 -DWITH_ISO14443a

asper · 2012-12-12 08:51:47

Sorry, I don't understand (I am not good at C)... should I have to modify the code myself to do the test you ask ? I just compiled the svn branched version without any modifications.

After compiling the branched version I flashed fpga and os images (not the bootrom) and I tested only a mifare and a chinese mifare (so yes, I tested only ISO14443A if this is what you need to know)... I don't know what "APP_CFLAGS = -O2 -DWITH_ISO14443a" means, or better I can find it in the code but then what have I am supposed to do ?

Waiting for your answer I will try to modify the code myself (/armsrc/Makefile) by changing only this string in the code

APP_CFLAGS = -O2 -DWITH_LF -DWITH_ISO15693 -DWITH_ISO14443a -DWITH_ISO14443b -DWITH_ICLASS -DWITH_LEGICRF -DWITH_HITAG"

with

APP_CFLAGS = -O2 -DWITH_ISO14443a

and re-test !

EDIT:
So I re-flashed and tested both "OS-Only" and "OS+FPGA" with the make mods you seems to have suggested and the results are the same (PM3 working bad):

read bad and reads often different values from each others

90% of the time is not able to select the card

So probably the problem is INSIDE DWITH_ISO14443a, right ?

Last edited by asper (2012-12-12 09:10:01)

Cex · 2012-12-14 13:38:33

asper wrote:

The problem seems to be related to something "internal" to the PM3 because it perfectly works on r627. I have the same issues as xxootest:
1) hf 14a reader fails 19 times on 20
2) hf mf cgetsc (try to read a chinese card) fails 4 times on 5 attempts and, when it works, read wrong values and those wrong values are not always the same.
Here is a COM logging try to read sector 0 (successfully) of a chinese card: http://pastebin.com/cmJn5GyK
I test ANY antenna-tag position/configuration. I always delete the folder and re-download the code from scratc; I also tryed to flash the new compiled FPGA with the same results. Only thing not testes is re-flashing the bootrom but, reading your answers, I don't think this will lead to something better.

This behaviour is similar to what happens with LCD version of proxmark3 and Mifare cards, so maybe it is a timing issue or there's something wrong with the Mifare implementation that work on origianl HW/SW due to some coindicence.

xxootest · 2012-12-17 11:46:50

The most possible reason for these ... is the problems with USB communication 。

gregy · 2013-01-22 13:11:28

Hi guys,
I think fixed the issue with hf 14a read not working properly

My think the problem was in usb_cdc.c where you use AT91C_PIO_PA16 as usb pull up pin but according to docs this is SSP_CLK.
I included config_gpio.h and used the alias GPIO_USB_PU defined there instead of AT91C_PIO_PA16.

Seems everything works fine now

Gregy

asper · 2013-02-22 09:35:55

gregy wrote:

Hi guys,
I think fixed the issue with hf 14a read not working properly
My think the problem was in usb_cdc.c where you use AT91C_PIO_PA16 as usb pull up pin but according to docs this is SSP_CLK.
I included config_gpio.h and used the alias GPIO_USB_PU defined there instead of AT91C_PIO_PA16.
Seems everything works fine now
Gregy

Is this fix already implemented ? If so from what revision number is it implemented ? Gregy can you provide a compiled version in order for me to test your fix ?

Last edited by asper (2013-02-22 09:37:14)

gregy · 2013-02-22 09:58:53

I do not have write access to svn so it is not implemented (unless someone else did it). Also my version is modified to work as simple reader...but I can post the patch with the changes described above if you want.

asper · 2013-02-22 10:05:24

yes please ! thank you

gregy · 2013-02-22 10:31:36

Here it is:

--- armsrc/usb_cdc.c    (revision 653)
+++ armsrc/usb_cdc.c    (working copy)
@@ -34,6 +34,7 @@
 
 #include "usb_cdc.h"
 #include "util.h"
+#include "config_gpio.h"
 
 #define MIN(a, b) (((a) < (b)) ? (a) : (b))
 #define MAX(a, b) (((a) > (b)) ? (a) : (b))
@@ -246,11 +247,11 @@
   
   // Enable UDP PullUp (USB_DP_PUP) : enable & Clear of the corresponding PIO
   // Set in PIO mode and Configure in Output
-  AT91C_BASE_PIOA->PIO_PER = AT91C_PIO_PA16; // Set in PIO mode
-       AT91C_BASE_PIOA->PIO_OER = AT91C_PIO_PA16; // Configure as Output
+  AT91C_BASE_PIOA->PIO_PER = GPIO_USB_PU; // Set in PIO mode
+       AT91C_BASE_PIOA->PIO_OER = GPIO_USB_PU; // Configure as Output
   
   // Clear for set the Pul up resistor
-       AT91C_BASE_PIOA->PIO_CODR = AT91C_PIO_PA16;
+       AT91C_BASE_PIOA->PIO_CODR = GPIO_USB_PU;
   
   // Disconnect and USB device
   usb_disable();

asper · 2013-02-22 23:11:27

Can you explain me exactly what have I to substitute/delete in the original file ?

Please, remember that I am compiling the http://proxmark3.googlecode.com/svn/branches/cdc branch !

If it's not a problem for you can you paste/upload your mod somewhere ?

Thank you really much !

EDIT: I managed to remove/add the lines as you mentioned (+++ or ---), I will test it tomorrow.

I still have problems compiling the base source (non-cdc)... I am not able to obtain the compile client (I get the "rom" files but no client: I receive a QA error file not found... I think am missing some install files...)

Last edited by asper (2013-02-23 08:24:23)

asper · 2013-02-23 08:23:55

YOU ARE THE BOSS MAN ! It works now ! THANK YOU !

rule · 2013-02-28 04:03:18

Hey gregy/asper,

Thank you for your contribution and testing, I patched the CDC branch with your update.

Cheers,

Roel

asper · 2013-02-28 21:17:46

Hi roel and thank you for your update !

A question: after flashing the new bootrom will it be compatible with the normal svn flashing software ? Or should we need to compile the specific cdc version ? If I have problems do I need to revert back to the old bootloader ?

EDIT:
I have a problem compiling the client:

so now I am not able to produce valid .exe files

If you need further information please tell me.

PS: Rev653 is compiling fine.

Last edited by asper (2013-02-28 21:37:04)

vos · 2013-02-28 22:01:54

roel, whoa! New CDC build feels really great! Awesome job

Had some trouble compiling though, almost solely because WIN32 isn't defined in my MinGW (latest ProxSpace environment).

Here is some noob-ish FAQ-y thingy on how to build and use CDC, about the things that i encountered and how i solved them:

1. nonce2key/crapto1.h: implicit declaration of function 'asm'
Replace asm with __asm in the file client/nonce2key/crapto1.h

2. util.c: something about termios.h
Add #define WIN32 at the top of the file client/util.c

3. proxendian.h: Define BYTE_ORDER to be equal to either LITTLE_ENDIAN or BIG_ENDIAN
Add #define BYTE_ORDER LITTLE_ENDIAN at the top of the file client/proxendian.h

4. flash.c: undefined reference to 'sleep'
Add #define WIN32 at the top of the file client/sleep.h

---- At this point, it should compile OK ----
(however flasher still somehow only sleeps for 1 msec while waiting for device to come up)

5. I've flashed new bootrom, and i cannot use old flasher to flash anything else. New flasher doesn't work either
- After flashing new CDC bootrom, the bootrom code spawns a new device with VID_2D2D&PID_504D, that requires you to specify this driver INF: http://proxmark3.googlecode.com/svn/branches/cdc/driver/proxmark3.inf
(should already be in your proxmark-cdc/driver/ folder if you've done svn checkout)
- New tools accept one more parameter, in form of COMx. E.g. after installing the INF, my device has the name "Proxmark3 (COM6)", so i flash with "flasher.exe COM6 fullimage-cbc.elf" and i use proxmark with "proxmark3.exe COM6"

Hope that helps someone. Again, great new proto!

rule · 2013-02-28 23:53:36

Thank you guys for the quick feedback!

I just committed a new version that should compile in Windows correctly (no warnings anymore). Also, I hope I fixed now this 64-bit formatting pointer crap for good. But who knows...

Best regards,

Roel

asper · 2013-03-01 09:07:31

Thank YOU for your work and quick feedback ! Now client compiles fine

I also updated the flasher program! This means you need to use the old flasher program to flash the new bootrom

Sorry for the noob question but can somone write a mini-guide on how to flash the new bootloader ? I don't want to risk a brick for my stupidity...

What I understand is: use old flasher.exe to update the bootrom (while holding the button on pm3) then you can use the new flasher without holding tha button and specifying the com port... is that right ?

My actual hw version command says this:

bootrom: svn 625-unclean 2012-10-19 11:44:22
os: version information not available
FPGA image built on 2012 / 1 / 6 at 15:27:56

(os version is not available anymore after flashing the new OS but pm3 seems to be working fine)

EDIT

BUG

I tested hf mf commands, nested and chk (for mifare) and cgetsc and cgetblk (for chinese cards) and they work fine but:
dump, rdbl and rdsc are not working:

hf mf rdsc 0 a ffffffffffff
--sector no:00 key type:01 key:ff ff ff ff ff ff

Cmd Error: 04
Read sector/block error
READ BLOCK FINISHED
isOk:00

(dump is giving an all 000000 dump except for the correctly extracted keys with nested command).

Maybe some timeout issues ?

EDIT2: after resetting the PM3 (disconnetc/reconnect) data seems to be read but with difficulties because some reads give:

Command2 execute timeout

after reading a block or 2

Maybe antenna issues ? 10V without card, 7.5V with card

EDIT3: after further tests I think the problem is in the mifare card I am trying to use because 5 cards out of 6 are reading fine (although I must correct the distance from the antenna using different cards), that one is REALLY DIFFICULT to read ! So this is probably not a bug; can test and tell me if they had problems with reading/writing ?

Last edited by asper (2013-03-01 12:29:26)

casper112 · 2013-03-03 16:23:38

Finally:

proxmark3> hw version
#db# Prox/RFID mark3 RFID instrument
#db# bootrom: svn 664 2013-03-03 09:02:41
#db# os: svn 664 2013-03-03 09:02:52
#db# FPGA image built on 2012/ 1/ 6 at 15:27:56
proxmark3>

I got a 2 bug:

1º When I tried to load a .eml to a promark memory with hf mf eload XXXX it stopped and nothing happen.

2º When I tried a nested atack with mifare 4K card, all keys are craked fine but finally it dont show the resume key and it don´t write a dumpkey.bin file.

Thanks

asper · 2013-03-03 17:39:29

I found another bug:

hf mf read block commands shows all 00; while read sector is working fine... can someone test this ?

casper112 · 2013-03-03 19:40:30

asper wrote:

I found another bug:
hf mf read block commands shows all 00; while read sector is working fine... can someone test this ?

Yeah that is a bug:

proxmark3> hf mf rdbl
Usage:  hf mf rdbl    <block number> <key A/B> <key (12 hex symbols)>
        sample: hf mf rdbl 0 A FFFFFFFFFFFF
proxmark3> hf mf rdbl 3 A a0a1a2a3a4a5
--block no:03 key type:00 key:a0 a1 a2 a3 a4 a5
#db# READ BLOCK FINISHED
isOk:01 data:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
proxmark3> hf mf rdbl 2 A a0a1a2a3a4a5
--block no:02 key type:00 key:a0 a1 a2 a3 a4 a5
#db# READ BLOCK FINISHED
isOk:01 data:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
proxmark3> hf mf rdbl 1 A a0a1a2a3a4a5
--block no:01 key type:00 key:a0 a1 a2 a3 a4 a5
#db# READ BLOCK FINISHED
isOk:01 data:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
proxmark3> hf mf rdbl 0 A a0a1a2a3a4a5
--block no:00 key type:00 key:a0 a1 a2 a3 a4 a5
#db# READ BLOCK FINISHED
isOk:01 data:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
proxmark3> hf mf rdbl 0 A a0a1a2a3a4a6
--block no:00 key type:00 key:a0 a1 a2 a3 a4 a6
#db# Authentication failed. Card timeout.
#db# Auth error
#db# READ BLOCK FINISHED
isOk:00
proxmark3>

PM · 2013-03-10 22:46:17

Hello.

I didn't used my Proxmark for months. I just downloaded last SVN code, and I discovered this post.
My case : I have an old firmware (few months), so my Proxmark doesn't communicated through "serial", yes ? So with the new client, which now asks for a <port>, I don't know what to do to flash and update the firmware. Is it an hidden feature in new flasher used to flash "old" Proxmarks ? Or should I take an other "flasher" program to flash the new .elf first ?

Note : I'm using ArchLinux and will happy to send you feedbacks

ikarus · 2013-03-16 19:54:48

Hi,

I have the same problem like xxootest here http://www.proxmark.org/forum/viewtopic … 6210#p6210
(only on linux).

I flashed the bootlaoder to r680 from the master branch (with the old flasher version).
After that I am no longer able to flash. If I'm holding down the button, the proxmark shows
up on /dev/ttyACM0. So far so good. But using the new flasher version (with the port parameter) to flash
the osimage does not work.

sudo ./client/flasher /dev/ttyACM0 armsrc/obj/osimage.elf
Loading ELF file 'armsrc/obj/osimage.elf'...
Loading usable ELF segments:
1: V 0x00110000 P 0x00110000 (0x000126f6->0x000126f6) [R X] @0xb8
2: V 0x00200000 P 0x001226f8 (0x000029b8->0x000029b8) [RWX] @0x127b0
Note: Extending previous segment from 0x126f6 to 0x150b0 bytes
Note: 0x2-byte hole created

Waiting for Proxmark to appear on USB... Found.
Sending bytes to proxmark failed

Is it possible to fix this? (without JTAG?!)
Was it wrong to first flash the bootrom?
How do I update the proxmark in the right way to cbc mode (svn r680)?

Kind regards
ikarus

Last edited by ikarus (2013-03-17 19:04:03)

rule · 2013-03-16 21:59:22

This seems to be rare, but I've seen a similar problem on a linux (ubuntu) computer that has a modem and "modem-manager" running. Maybe you could have quick look in your system if there is no service/deamon running that tries to claim/send bytes to a newly registered CDC/ACM device? Right know the bootloader doesn't like that. Let's see if we can pinpoint these problems, so we can address them in a next bootrom update.

cupido · 2013-03-17 14:22:07

I had the same issue Ikarus is dealing with. The problem seems to occur when flashing the new bootrom (r680 in my case) and having an older osimage on the PM3 (r648 in my case). The combination of new bootrom and old osimage caused that the flasher (both new and old version) did not work anymore (because the pm3 simply did not appear on usb).
After giving it several tries I decided to use a JTAG to reload the old bootrom again. That worked. Then I started a second try. This time I flashed the new osimage file first. Then I flashed the new bootrom again. Now the pm3 was recognized as com-port device. The new flasher is working as well now.

ikarus · 2013-03-17 19:03:36

roel wrote:

This seems to be rare, but I've seen a similar problem on a linux (ubuntu) computer that has a modem and "modem-manager" running. Maybe you could have quick look in your system if there is no service/deamon running that tries to claim/send bytes to a newly registered CDC/ACM device? Right know the bootloader doesn't like that. Let's see if we can pinpoint these problems, so we can address them in a next bootrom update.

You sir, are the best!

I am using Ubuntu and the "modem-manager" was running!
I disabled it like described here http://askubuntu.com/questions/45726/ki … er-process
(killing the process is not enough...)

...And then I was able to flash the osimage!
(The first time with pressed button. After that flashing is back to normal.)

Everything works now and is up to date!
(And no JTAG was needed!)
Thanks!

Kind regards
ikarus

PM · 2013-03-23 18:12:29

roel : Is it possible to get "basic" information about new interface (baud rate, new command codes, etc) ? I looked a source code some months ago, and it seems only USB interface has changed, but not command codes, am I right ? (currently trying to communicate with my Proxmark with my Android phone, and the small victory is that I can get "Unknown command" from the device ^^)

EDIT : Mea culpa, Java is fuc*** Big Endian, so just invert bytes before sending data. For baud rate, 9600 works great (but according to C client code, it is possible to choose another rate)

Last edited by PM (2013-03-23 18:28:25)

vivat · 2013-03-26 15:09:28

What new command

make recovery

does? Flushes bootrom, os, fpga-image areas in ARM with 0xFF?

Neuer_User · 2013-03-26 16:15:45

vivat wrote:

What new command
make recovery
does? Flushes bootrom, os, fpga-image areas in ARM with 0xFF?

Hmm, it probably generates BIN files to flash via JTAG.

b0ngokarl · 2013-04-02 17:19:54

Hi!

Mine is a

proxmark3> hw version
#db# Prox/RFID mark3 RFID instrument
#db# bootrom: svn 671 2013-03-07 17:12:17
#db# os: svn 692 2013-03-27 23:12:21
#db# FPGA image built on 2012/ 1/ 6 at 15:27:56

if i do data samples 2000

I'll get

Waiting for a response from the proxmark...
Don't forget to cancel its operation first by pressing on the button

and nothing happens. Is it just mine?

Thanks

Neuer_User · 2013-04-02 20:12:59

It's a bug in the new version. See here http://www.proxmark.org/forum/viewtopic.php?id=1564

Neuer_User · 2013-04-12 14:42:10

So, what will happen with the new interface? Will there be further development?

jonor · 2013-04-12 21:47:26

I have a problem with lastest SVN 696, in my linux box with kernel 2.6.27 the device is detect but not as CDC.

usb 4-1: new full speed USB device using uhci_hcd and address 11
usb 4-1: configuration #1 chosen from 1 choice
usb 4-1: New USB device found, idVendor=2d2d, idProduct=504d
usb 4-1: New USB device strings: Mfr=1, Product=0, SerialNumber=0
usb 4-1: Manufacturer: proxmark.org

In another linux box with kernel 3.8.6 device is detect as CDC device.
I have used other devices with USB CDC ADM builded with PIC, AVR or ARM STM32 and work well in my linux box with kernel 2.6.27, only proxmark3 doesn't work.

Last edited by jonor (2013-04-12 21:48:02)

jonor · 2013-04-12 22:33:37

I propose a patch for my problem

Index: common/usb_cdc.c
===================================================================
--- common/usb_cdc.c    (revision 696)
+++ common/usb_cdc.c    (working copy)
@@ -81,7 +81,7 @@
        0x01, // bNumEndpoints
        0x02, // bInterfaceClass
        0x02, // bInterfaceSubclass
-       0x00, // bInterfaceProtocol
+       0x01, // bInterfaceProtocol
        0x00, // iInterface

        /* Header Functional Descriptor */

With bInterfaceProtocol at 0x01 (1 AT-commands (v.25ter)) device CDC ACM is detected also with kernel 2.6.27.

rule · 2013-04-13 06:15:46

Thank you Jonor, I patched your contribution into the trunk!

jonor · 2013-04-13 08:38:51

Thank you roel for accept my simple patch.
I have found also another solution, without touch the firmware. Add VID e PID to module cdc_acm at runtime.

# modprobe cdc_acm
# echo "2d2d 504d"> /sys/bus/usb/drivers/cdc_acm/new_id

With a simple udev rules is automatic
/etc/udev/rules.d/99-proxmarkcdc.rules

SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device",ATTRS{idVendor}=="2d2d", ATTRS{idProduct}=="504d", RUN+="/bin/proxmark_cdc.sh"

/bin/proxmark_cdc.sh

#!/bin/bash

/sbin/modprobe cdc_acm
/bin/echo '2d2d 504d' > /sys/bus/usb/drivers/cdc_acm/new_id

after the write of new udev rule, just execute

udevadm control --reload-rules

however my initial patch, not make any problems to windows user.

Proxmark3 community

Announcement

#51 2012-12-08 09:17:08

Re: Volunteers for testing new proxmark USB interface (using uart CDC/ACM)

#52 2012-12-08 13:25:18

Re: Volunteers for testing new proxmark USB interface (using uart CDC/ACM)

#53 2012-12-08 23:53:31

Re: Volunteers for testing new proxmark USB interface (using uart CDC/ACM)

#54 2012-12-09 10:09:45

Re: Volunteers for testing new proxmark USB interface (using uart CDC/ACM)

#55 2012-12-09 10:18:55

Re: Volunteers for testing new proxmark USB interface (using uart CDC/ACM)

#56 2012-12-09 10:42:51

Re: Volunteers for testing new proxmark USB interface (using uart CDC/ACM)

#57 2012-12-09 13:59:13

Re: Volunteers for testing new proxmark USB interface (using uart CDC/ACM)

#58 2012-12-10 11:44:18

Re: Volunteers for testing new proxmark USB interface (using uart CDC/ACM)

#59 2012-12-11 06:15:10

Re: Volunteers for testing new proxmark USB interface (using uart CDC/ACM)

#60 2012-12-11 13:23:33

Re: Volunteers for testing new proxmark USB interface (using uart CDC/ACM)

#61 2012-12-11 14:36:43

Re: Volunteers for testing new proxmark USB interface (using uart CDC/ACM)

#62 2012-12-11 14:49:16

Re: Volunteers for testing new proxmark USB interface (using uart CDC/ACM)

#63 2012-12-11 15:16:02

Re: Volunteers for testing new proxmark USB interface (using uart CDC/ACM)

#64 2012-12-11 18:26:17

Re: Volunteers for testing new proxmark USB interface (using uart CDC/ACM)

#65 2012-12-11 22:04:02

Re: Volunteers for testing new proxmark USB interface (using uart CDC/ACM)

#66 2012-12-12 08:03:53

Re: Volunteers for testing new proxmark USB interface (using uart CDC/ACM)

#67 2012-12-12 08:37:27

Re: Volunteers for testing new proxmark USB interface (using uart CDC/ACM)

#68 2012-12-12 08:51:47

Re: Volunteers for testing new proxmark USB interface (using uart CDC/ACM)

#69 2012-12-14 13:38:33

Re: Volunteers for testing new proxmark USB interface (using uart CDC/ACM)

#70 2012-12-17 11:46:50

Re: Volunteers for testing new proxmark USB interface (using uart CDC/ACM)

#71 2013-01-22 13:11:28

Re: Volunteers for testing new proxmark USB interface (using uart CDC/ACM)

#72 2013-02-22 09:35:55

Re: Volunteers for testing new proxmark USB interface (using uart CDC/ACM)

#73 2013-02-22 09:58:53

Re: Volunteers for testing new proxmark USB interface (using uart CDC/ACM)

#74 2013-02-22 10:05:24

Re: Volunteers for testing new proxmark USB interface (using uart CDC/ACM)

#75 2013-02-22 10:31:36

Re: Volunteers for testing new proxmark USB interface (using uart CDC/ACM)

#76 2013-02-22 23:11:27

Re: Volunteers for testing new proxmark USB interface (using uart CDC/ACM)

#77 2013-02-23 08:23:55

Re: Volunteers for testing new proxmark USB interface (using uart CDC/ACM)

#78 2013-02-28 04:03:18

Re: Volunteers for testing new proxmark USB interface (using uart CDC/ACM)

#79 2013-02-28 21:17:46

Re: Volunteers for testing new proxmark USB interface (using uart CDC/ACM)

#80 2013-02-28 22:01:54

Re: Volunteers for testing new proxmark USB interface (using uart CDC/ACM)

#81 2013-02-28 23:53:36

Re: Volunteers for testing new proxmark USB interface (using uart CDC/ACM)

#82 2013-03-01 09:07:31

Re: Volunteers for testing new proxmark USB interface (using uart CDC/ACM)

#83 2013-03-03 16:23:38

Re: Volunteers for testing new proxmark USB interface (using uart CDC/ACM)

#84 2013-03-03 17:39:29

Re: Volunteers for testing new proxmark USB interface (using uart CDC/ACM)

#85 2013-03-03 19:40:30

Re: Volunteers for testing new proxmark USB interface (using uart CDC/ACM)

#86 2013-03-10 22:46:17

Re: Volunteers for testing new proxmark USB interface (using uart CDC/ACM)

#87 2013-03-16 19:54:48

Re: Volunteers for testing new proxmark USB interface (using uart CDC/ACM)

#88 2013-03-16 21:59:22

Re: Volunteers for testing new proxmark USB interface (using uart CDC/ACM)

#89 2013-03-17 14:22:07

Re: Volunteers for testing new proxmark USB interface (using uart CDC/ACM)