API re-design

[GoogleCodeExporter]

This is a feature request (or maybe something stupid, sorry if It's that but 
I'm newbie on proxmark).

I saw that proxmark works with some components; a fgpa and an arm chipset. The 
OS running on ARM is working with logical layer and It is in communication with 
fpga who works with the physical layer. And there is an "external" component; 
the computer who talks with proxmark using USB interface.

I also saw that most of the logic are included into ARM OS (like card 
read/write instructions, some card emulations, etc) and I think that this can 
be a mistake. In my opinion the OS inside ARM has to do just little things and 
the big ones must to be implemented into PC side. The idea is that Proxmark OS 
provides a basic API raw_read/raw_write and "protocols" (and attacks) like 
mifare can be implemented on PC side.

In the same way, the sniffing (or snooping) feature can stream the information 
directly to PC to manage the information instead of fill a internal buffer.

I'm not sure if all of that It's stupid and can't be done because USB is too 
slow for some things that need to be fast on phisical layer. If It's that just 
tell me.

Thanks you for your work.

Original issue reported on code.google.com by alb...@puigsech.com on 13 Aug 2012 at 9:22

[GoogleCodeExporter]

In my opinion it would make sense to implement some sort of pass-through 
mechanism on the proxmark to allow protocols to be implemented on the PC with 
the PM3 only relaying commands, offering e.g. PC/SC-compatibility.

However, there's a benefit to keeping protocols implemented on the ARM 
processor itself: Speed. You don't have the additional delays from the PM3-PC 
USB connection and if you want to measure exact timings of complete protocol 
executions, this can be an essential benefit.

Since the implementation of a pass-through mechanism should be quite slim, I 
think it should be possible to add it without having to remove protocol 
implementations from the firmware. That way you would always be able to choose 
whether you want to use the PM3's native protocols or whether you want to use 
implementations running on the PC.

A similar argument can be made for the snooping functionality. While it would 
increase the maximum amount of messages that can be logged, it would also take 
away the opportunity to look at previous messages from inside protocol 
implementations running on the microprocessor itself. A solution that offers a 
choice between storing the history on the ARM and passing it to the client 
(maybe even doing both) would be best.

I guess the main problem is that porting all the functionality to the client 
side is a monstrous task, even if you standardize the interface between the 
devices.

Original comment by fred-pub...@posteo.de on 26 Aug 2012 at 1:32

[GoogleCodeExporter]

First of all, If you want to discuss, I think the forum is better - I have a 
suspicion that noone really checks the googlecode issue-list. 
Anyway, there are pros and cons. On the device, we have the ability to have 
exact timing, so e.g we are capable to time 65535 tag-cycles in mifare 
cracking. Over usb, there enters lag from different sources. 

However, some things are better on the host side. Noone will rewrite the entire 
pm3 because, but if there's anything specific you want, try opening up a 
specific ticket for that, or write in the forum about it. I'll close this, 
because it's not a defect, and it's not a specific bug.  

Original comment by martin.holst on 27 Feb 2014 at 6:22

• Changed state: WontFix