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

rule · 2013-04-15 09:50:10

Then I think it would better to revert again to the old descriptor

en4rab · 2013-04-22 13:09:49

I have just tested the svn 698 version of the proxmark code and found that the "data samples" command was still broken giving the message "Waiting for a response from the proxmark..."
I have made a horrid bodge to the code that at least seems to make data samples work, well i can run "lf indalademod" after and get the UID of my card, but i quite quite sure my efforts will make real coders cry, it still seems sort of broken in that in my first attempt 2000 samples wasnt enough to retrieve an indala UID when it was with the older HID firmware im sure this is some confusion on my part with bytes and words so i just grabbed 4x as many samples as were asked for (told you you would cry) that seemed to work and gave a reasonably sane looking graph (to me anyway).
If i understood what i was looking at the problem with data samples was it wasnt creating a buffer to put the data in (i based this assumption on the function GetFromBigBuf in data.c and how CmdHF14AList called this) and it wasnt passing the requested number of bytes to download in the UsbCommand (i assume the HID firmware always returned 48 bytes) and it waits for CMD_ACK which i believe is now used to signal completion of a transfer, my samples function now looks like this:

int CmdSamples(const char *Cmd)
{
  int cnt = 0;
  int n;
  
  n = strtol(Cmd, NULL, 0);
  if (n == 0) n = 128;
  if (n > 16000) n = 16000;
  
  uint8_t got[n*4];
  sample_buf_len = 0;
  sample_buf = got;
  
  PrintAndLog("Reading %d samples\n", n);

  for (int i = 0; i < n*4; i += 512) {
    UsbCommand c = {CMD_DOWNLOAD_RAW_ADC_SAMPLES_125K, {i, 512, 0}};
    SendCommand(&c); 
    WaitForResponse(CMD_ACK,NULL);
    for (int j = 0; j < 512; j++) {
	  GraphBuffer[cnt++] = ((int)sample_buf[j]) - 128;
    }
  }
  PrintAndLog("Done!\n");
  GraphTraceLen = n*4;
  RepaintGraphWindow();
  return 0;

I tried it just asking for all the samples in one go but that caused occasional transfer timeout messages, so i grabbed the data as a series of 512 byte chunks to avoid this, dont use this fix directly as its crap. For instance it will grab the requested samples to the nearest 512 bytes not how many you ask for, and i really dont understand why i needed to grab n*4 samples to make it work like it used to . I hope this will help somebody who knows what they are doing to fix it properly. Im fairly sure the same issues apply to data hexsamples and data bitsamples and they can be fixed in the same way.
I hope this helps
en4rab

en4rab · 2013-04-22 22:17:44

Ok i think i have something a bit nicer, I noticed all the HF code was calling GetFromBigBuff() instead of sending usb commands directly which seems nicer, so I fixed CmdSamples to work that way too, it seems to be fine and im not seeing timeouts which im guessing were caused by all the printf's i had while testing, oops
This is the result which i am almost proud of, with the exception of it still gets 4 times the number of samples you request, but if i read it right the original HID code was requesting 2000 dwords and reading them as bytes i think, which would explain the discrepancy.
I have also reduced the max number of samples to 10000 (40000 real samples) as in the brief tests i did i saw garbage after that point in the graph. How big is the bigbuff??
Anyway here is a not quite so grotty fix:

int CmdSamples(const char *Cmd)
{
  int cnt = 0;
  int n;

  n = strtol(Cmd, NULL, 0);
  if (n == 0) n = 128;
  if (n > 10000) n = 10000;

  PrintAndLog("Reading %d samples\n", n);
    uint8_t got[n*4];
    GetFromBigBuf(got,sizeof(got),0);
    WaitForResponse(CMD_ACK,NULL);
    for (int j = 0; j < n*4; j++) {
      GraphBuffer[cnt++] = ((int)got[j]) - 128;
    }
  
  PrintAndLog("Done!\n");
  GraphTraceLen = n*4;
  RepaintGraphWindow();
  return 0;
}

rule · 2013-04-23 20:51:38

Thank you very much!

Nice contribution, I didn't tested it thoroughly yet, but I'm sure others in this community will soon enough

I slightly changed the buffer allocation to avoid problems with sizeof() etc. and just committed the following code into the SVN repository:

#define MAX_SAMPLE_COUNT 10000
int CmdSamples(const char *Cmd)
{
  int cnt = 0;
  int n;
  
  n = strtol(Cmd, NULL, 0);
  if (n == 0) n = 128;
  if (n > MAX_SAMPLE_COUNT) n = MAX_SAMPLE_COUNT;
  
  PrintAndLog("Reading %d samples\n", n);
  uint8_t got[MAX_SAMPLE_COUNT * 4];
  GetFromBigBuf(got,sizeof(got),0);
  WaitForResponse(CMD_ACK,NULL);
  for (int j = 0; j < n*4; j++) {
    GraphBuffer[cnt++] = ((int)got[j]) - 128;
  }
  
  PrintAndLog("Done!\n");
  GraphTraceLen = n*4;
  RepaintGraphWindow();
  return 0;
}

en4rab · 2013-04-23 21:52:56

I believe i have also managed to fix hexsamples and bitsamples as they have the same issue, I will post my fix for them here, im sorry to paste code as i still havent susse out making diffs, i promise i will work that out soon.
Below is my hopefully fixed code for hex samples, it had the same problem of sending the usb command directly rather than calling GetFromBigBuff.
One important thing is the communications seem to have changed (as far as i can tell) in the change to CDC, it looks to me like the HID code was all based around 4 byte dwords when requesting data but the CDC is based on number of bytes, with that in mind my fix for hexsamples uses the arguments to request a given number of bytes *not* 4byte blocks, also there doesnt appear to be any constraint on the offset the bytes are fetched from.
That is as far as i can tell they no longer have to be fetched from a 4 byte boundary so i removed the alignment check, it seem to still work ok.
Due to the way the function prints 8 bytes at a time i changed the minimum number of bytes returned to 8 so it doesnt print garbage, you can request one byte but you get one actual byte and 7 bytes of junk, so calling it with no size or a size less than 8 returns 8 bytes.
There is no bounds checking on reading past the end of big buff.
Im still umming and aaahing about this dword bytes thing, but im leaning towards the idea the commands should use bytes as their arguments since that how the CDC code works, i think perhaps samples should work that way too even if it will trip me up that 2000 samples isnt enough to get an indala UID anymore, any opinions on this???

Anyway here is my hexsamples:

int CmdHexsamples(const char *Cmd)
{
  int n;
  int requested = 0;
  int offset = 0;
  sscanf(Cmd, "%i %i", &requested, &offset);

  int delivered = 0;

  if (requested < 8) {
    n = 8;
    requested = 8;
  } else {
    n = requested;
  }

  uint8_t got[n];
  GetFromBigBuf(got,sizeof(got),offset);
  WaitForResponse(CMD_ACK,NULL);

  for (int j = 0; j < n; j += 8) {
    PrintAndLog("%02x %02x %02x %02x %02x %02x %02x %02x",
      sample_buf[j+0],
      sample_buf[j+1],
      sample_buf[j+2],
      sample_buf[j+3],
      sample_buf[j+4],
      sample_buf[j+5],
      sample_buf[j+6],
      sample_buf[j+7],
      sample_buf[j+8]
    );
    delivered += 8;
    if (delivered >= requested)
      break;
  }
  return 0;
}

en4rab · 2013-04-23 21:57:09

And here is by bitsamples, since it has no args i just multiplied the requested blocks by 4 so it should still work the way it did before in the amount of data returned. It does need proper testing but seems to work for me.

int CmdBitsamples(const char *Cmd)
{
  int cnt = 0;
  int n = 12288;

  uint8_t got[n];
  GetFromBigBuf(got,sizeof(got),0);
  WaitForResponse(CMD_ACK,NULL);

    for (int j = 0; j < n; j++) {
      for (int k = 0; k < 8; k++) {
        if(got[j] & (1 << (7 - k))) {
          GraphBuffer[cnt++] = 1;
        } else {
          GraphBuffer[cnt++] = 0;
        }
      }
  }
  GraphTraceLen = cnt;
  RepaintGraphWindow();
  return 0;
}

en4rab · 2013-04-23 22:00:54

Just as a headsup CmdLegicDecode() and CmdLegicSave() in cmdhflegic.c also look like they have this problem, i will try to fix it at the weekend but I dont have any legic tags to test any fix with.

rule · 2013-04-24 09:47:37

Good work! Would be nice if you could make a diff file, it is pretty easy, run the following from the main folder of your local repository.

To screen output:

$svn diff

Or put it into a file:

$svn diff > file

One small remark, in plain 'c', you can not allocate an array with a dynamic number. So basically, you can not do the following:

uint8_t got[n];

Where 'n' is not a statically defined number. If you want to do that, you need to use malloc() and free().

Anyway, if there is a maximum number for 'n', then better just use that for memory allocation, this way you are always on the safe side and you don't need to dynamically allocate.

Cheers,

Roel

en4rab · 2013-04-26 21:14:12

Thankyou, if you cant tell im not a programmer
I had another go at making everything work and defining the size of got.
In this patch I also changed the way samples works so its argument is the number of samples to get not 4 sample blocks and changed the help to reflect this.
It seemed sensible to me that it should actually get the number of samples you ask for not 4x as many even if this will change what people are used to.
I attempted to add some sanity checking to hexsamples so it wont read past the end of the buffer, and although it will allow you to specify any number of bytes it rounds this to up the nearest 8 bytes so that everything printed is valid data.
Im not entirely happy with that since that means the command isnt doing exactly what you ask of it but I couldnt work out how to display just the number you ask for and felt that ensuring everything printed was valid was better than printing what was requested + up to 7 bytes of junk.
I would appreciate your comments on this so i can fix any mistakes and have it considered for inclusion. the patch is against r707 I uploaded it to pastebin here:
http://pastebin.com/y8bJSSHp

rule · 2013-04-26 21:45:50

Thanks for your contributions, I committed the patch into the SVN. If you want access yourself, drop me an email with your google account.

I'll look soon into your problem of aligning the data to 8 bytes. I think it is not so hard to solve. Allocate a char[] string(buffer), put the hex (%02x) samples in a small loop (that runs to maximum of 8) into this string first. Then, give this string to PrintAndLog(). Make sure, you clear the string for the next 8 samples. If you have less than 8 left, the loop just runs shorter

That should do the trick Just let me know if you don't get it working.

en4rab · 2013-05-02 11:07:28

Roel thankyou kindly for your offer of SVN access but if it is ok with you I would rather post any patches here for you or someone else who knows what they are doing to check i havent done anything stupid
I had a go at making hexsamples print an arbitrary number of bytes and i believe i have it working, in the process i realised what a pigs ear i made of it the first time, it was still referencing sample_buff[] not got[] and i shouldnt have had else{} round n=requested. oops
After a very long night pinching examples off stackoverflow i think this fixes it properly, it might not be the neatest but as far as i can test it is working.
Also included is a fix for the "em410xwatch" command which i broke by changing the samples command to bytes instead of blocks, it merely needed the argument changing to 8000.
I will try to sort out the legic commands once this is done but i dont have a legic card to test with.
I would appreciate your comments on this so i can fix any mistakes and have it considered for inclusion. the patch is against r708 I uploaded it to pastebin here:
http://pastebin.com/ARYyfLdi

Neuer_User · 2013-05-02 11:41:41

Hi en4rab

em410xwatch seems to work now. Thanks for fixing it.

I tried hexsamples and the output looked fine for me (but I do not hove much experience here).

I could get a legic prime here, if you want me to test the next patch.

Cheers,

Michael

en4rab · 2013-05-02 13:56:30

Neuer_User if you have or can get for free a legic card I have an untested patch here for CmdLegicDecode() which i think will fix it.
Dont worry if you cant get a card as I have just bought a legic MIM 256 off ebay to test with, it should be here in a week or so.

I found trying to follow the logic of the nested loops in CmdLegicDecode painfull but if i understood it correctly it was just to undo the fragmentation caused by the old HID code and get 1024 bytes into a buffer. I think the buffer was sized to 1032 to allow for the loop to run once more than needed, since GetFromBigBuf just lets you say how many bytes you want precisely i reduced the data_buf to 1024 and changed its type to uint8_t as its holding bytes.
I think this is correct and trying legic reader (without a card which reads 1024 bytes of 00) followed by legic decode now prints stuff instead of hanging, but as to the validity of the data, i cannot test that yet.
While im waiting for my card if anyone has any saved example dumps of legic cards i could load into the proxmark to test with that would be handy.
Fixing legic save will take a little more time as it will need messing about with strings like the hexsamples fix and id like to know if my fix for that is acceptable before trying to fix legic save.
An untested fix for legicdecode written by someone who barely knows C can be found here:
http://pastebin.com/jJHQ40TY

Neuer_User · 2013-05-02 17:45:29

Hi En4rab

I had a legic prime here, but gave it back to my client last week. I can get it again probably next week. I will then test it directly.

By the way, many sim commands no longer work. Could that be due to the same problems? If you can try a hf mf sim or a hf 14a sim.

holiman · 2013-05-05 00:12:02

I started using r651 on Ubuntu 12.10, where things worked ok. Until I ran into this old problem:

proxmark3> hf mf mifare
-------------------------------------------------------------------------
Executing command. It may take up to 30 min.
Press the key on the proxmark3 device to abort both proxmark3 and client.
-------------------------------------------------------------------------
.................

isOk:01          


uid(404ee155) nt(d2253279) par(264e0e666e46863e) ks(060b0f040b0a0709)

          
|diff|{nr}    |ks3|ks3^5|parity         |
+----+--------+---+-----+---------------+
| 00 |00000000| 6 |  3  |0,1,1,0,0,1,0,0|
| 20 |00000020| b |  e  |0,1,1,1,0,0,1,0|
| 40 |00000040| f |  a  |0,1,1,1,0,0,0,0|
| 60 |00000060| 4 |  1  |0,1,1,0,0,1,1,0|
| 80 |00000080| b |  e  |0,1,1,1,0,1,1,0|
| a0 |000000a0| a |  f  |0,1,1,0,0,0,1,0|
| c0 |000000c0| 7 |  2  |0,1,1,0,0,0,0,1|
| e0 |000000e0| 9 |  c  |0,1,1,1,1,1,0,0|
#db# COMMAND mifare FINISHED                 
00ffb065|00ff3e7f
------------------------------------------------------------------
Key found:%012I64x 
          
Found valid key:%012I64x

So, it seems a valid key is found, but a string formatting error hides it from me.
Anyway, I opted to get the latest and greatest, flashing and compiling went fine:

proxmark3> hw version
#db# Prox/RFID mark3 RFID instrument                 
#db# bootrom: svn 709 2013-05-04 22:15:52                 
#db# os: svn 709 2013-05-04 22:15:53                 
#db# FPGA image built on 2012/ 1/ 6 at 15:27:56

However, running the same operation again, against the same card, just ticks and ticks and does not even get the key.

proxmark3> hf mf mifare
-------------------------------------------------------------------------
Executing command. It may take up to 30 min.
Press the key on the proxmark3 device to abort both proxmark3 and client.
-------------------------------------------------------------------------
................................#db# COMMAND mifare FINISHED                 


isOk:01          


uid(404ee155) nt(d2253279) par(00000e666e46863e) ks(060b0f040b0a0709)

          
|diff|{nr}    |ks3|ks3^5|parity         |
+----+--------+---+-----+---------------+
| 00 |00000000| 6 |  3  |0,0,0,0,0,0,0,0|
| 20 |00000020| b |  e  |0,0,0,0,0,0,0,0|
| 40 |00000040| f |  a  |0,1,1,1,0,0,0,0|
| 60 |00000060| 4 |  1  |0,1,1,0,0,1,1,0|
| 80 |00000080| b |  e  |0,1,1,1,0,1,1,0|
| a0 |000000a0| a |  f  |0,1,1,0,0,0,1,0|
| c0 |000000c0| 7 |  2  |0,1,1,0,0,0,0,1|
| e0 |000000e0| 9 |  c  |0,1,1,1,1,1,0,0|
Key not found (lfsr_common_prefix list is null). Nt=d2253279          
-------------------------------------------------------------------------
Executing command. It may take up to 30 min.

The output from the two runs are quite similar, except for the two first rows in the parity-colunm. Not that I'm an expert on this (yet), but that looks fishy to me - any ideas about what's happening, and why the recent version fails?

holiman · 2013-05-05 21:10:55

I dived a little bit deeper into the strange mysterious parity bits. I wanted to check if this was a host-problem or an ARM-problem, so I used wireshark to check the traffic.

The Proxmark unit consistently reports the first two bytes of parity-list as 00 00 .
Dump from wireshark - uid (4b) starts at 0200, then follows nt (4), parity_list( 8b) and ks_list (8b):

0000   ff 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00
0010   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0020   40 4e e1 55 05 e0 04 63 00 00 c3 7b 33 1b 4b 23
0030   03 0a 02 00 05 05 0a 00 60 54 99 37 9f 51 b7

Interpreted on the host as
uid(404ee155) nt(05e00463) par(0000c37b331b4b23) ks(030a020005050a00)

Which seems correct. So, something seems to be fishy within the on-device code, which is a bit more difficult for me to debug, since I need to flash it if I want to test something.

Any ideas what could be causing this? I checked the differences between older and newer armsrc, and the only obvious thing that caught my eye concerning these parts were some timeouts that were set differently, a SpinDelay(50); which used to be 200 (armsrc/iso14443a.c around line 1858)

holiman · 2013-05-05 23:11:26

Continuing my search.. The error had nothing to do with the spindelay, in fact, even lower values worked fine.

Instead, I made the following printout:

$ svn diff iso14443a.c
Index: iso14443a.c
===================================================================
--- iso14443a.c	(revision 709)
+++ iso14443a.c	(working copy)
@@ -1852,7 +1852,7 @@
 	{
 		LED_C_OFF();
 		FpgaWriteConfWord(FPGA_MAJOR_MODE_OFF);
-		SpinDelay(50);
+		SpinDelay(40);
 		FpgaWriteConfWord(FPGA_MAJOR_MODE_HF_ISO14443A | FPGA_HF_ISO14443A_READER_MOD);
 		LED_C_ON();
 		SpinDelay(2);
@@ -1894,7 +1894,7 @@
 			if(led_on) LED_B_ON(); else LED_B_OFF();
 			par_list[nt_diff] = par;
 			ks_list[nt_diff] = receivedAnswer[0] ^ 0x05;
-
+			Dbprintf("Setting par_list[%d] = %x",nt_diff, par);
 			// Test if the information is complete
 			if (nt_diff == 0x07) {
 				isOK = 1;
@@ -1913,7 +1913,7 @@
 			}
 		}
 	}
-
+	Dbprintf("Parity list: %x,%x,%x,%x,%x,%x,%x,%x):",par_list[0],par_list[1],par_list[2], par_list[3], par_list[4], par_list[5], par_list[6], par_list[7]);
 	LogTrace(nt, 4, 0, GetParity(nt, 4), TRUE);
 	LogTrace(par_list, 8, 0, GetParity(par_list, 8), TRUE);
 	LogTrace(ks_list, 8, 0, GetParity(ks_list, 8), TRUE);

This is the output:

proxmark3> hf mf mifare
-------------------------------------------------------------------------
Executing command. It may take up to 30 min.
Press the key on the proxmark3 device to abort both proxmark3 and client.
-------------------------------------------------------------------------
...................#db# Setting par_list[0] = 26                 
#db# Setting par_list[1] = 4e                 
...#db# Setting par_list[2] = e                 
#db# Setting par_list[3] = 66                 
.#db# Setting par_list[4] = 6e                 
#db# Setting par_list[5] = 46                 
.#db# Setting par_list[6] = 86                 
#db# Setting par_list[7] = 3e                 
#db# Parity list: 0,0,e,66,6e,46,86,3e):                 
#db# COMMAND mifare FINISHED                 


isOk:01          


uid(404ee155) nt(d2253279) par(00000e666e46863e) ks(060b0f040b0a0709)

          
|diff|{nr}    |ks3|ks3^5|parity         |
+----+--------+---+-----+---------------+
| 00 |00000000| 6 |  3  |0,0,0,0,0,0,0,0|
| 20 |00000020| b |  e  |0,0,0,0,0,0,0,0|
| 40 |00000040| f |  a  |0,1,1,1,0,0,0,0|
| 60 |00000060| 4 |  1  |0,1,1,0,0,1,1,0|
| 80 |00000080| b |  e  |0,1,1,1,0,1,1,0|
| a0 |000000a0| a |  f  |0,1,1,0,0,0,1,0|
| c0 |000000c0| 7 |  2  |0,1,1,0,0,0,0,1|
| e0 |000000e0| 9 |  c  |0,1,1,1,1,1,0,0|
Key not found (lfsr_common_prefix list is null). Nt=d2253279

As you can see, somewhere along the line, the first two bytes (26 4e) are discarded by the algorithm. Haven't dived into why yet, it's late at night here.

On a related note - I get severe crashes if I use the flasher after having used the proxmark3, or vice versa. I mean very severe, total freeze without ctrl-alt-f1 or similar, and no syslog entries either. So this debugging have been quite painful

Neuer_User · 2013-05-06 07:32:18

holiman wrote:

On a related note - I get severe crashes if I use the flasher after having used the proxmark3, or vice versa. I mean very severe, total freeze without ctrl-alt-f1 or similar, and no syslog entries either. So this debugging have been quite painful

What system are you using? Windows or Linux?
What USB port do you use? USB2.0 or USB3.0?

I had extremely severy crashes on Linux (Ubuntu) with USB3.0. THe only help was to switch the computer to one without USB2.0.

holiman · 2013-05-06 07:44:38

I am on Ubuntu 12.10, and I was probably using usb3 most of the time - maybe every time. I'll see if it happens on usb2 aswell.

holiman · 2013-05-06 07:50:08

This post http://www.proxmark.org/forum/viewtopic.php?id=1556 seems to have the same problem as the one I've been hitting, with parity list being corrupted.

Neuer_User · 2013-05-06 08:16:49

holiman wrote:

I am on Ubuntu 12.10, and I was probably using usb3 most of the time - maybe every time. I'll see if it happens on usb2 aswell.

In my case it was definitely the xhci_hcd driver (USB3.0) that crashed. I reported a bug at the kernel bugtracker, but got no reply so far (https://bugzilla.kernel.org/show_bug.cgi?id=55761).

Now that I switched computers (the new one definitely only with USB2.0) I did not have any further crashes.

If your system has USB3.0 and USB2.0, make sure in syslog that proxmark3 is using USB2.0 (ehci_hcd instead of xhci_hcd).

Hope this helps.

Michael

holiman · 2013-05-06 14:52:20

Solved it. A fiunction (iso14443a_select_card) took a pointer to a local variable. The variable was 8 bytes, but 10 bytes of memory was cleared - and there was much confusion, since another local variable (par_list) was affected, even though it wasn't even used in the call. Direct memory referencing can produce very nasty bugs..

$ svn diff armsrc/iso14443a.c
Index: armsrc/iso14443a.c
===================================================================
--- armsrc/iso14443a.c	(revision 709)
+++ armsrc/iso14443a.c	(working copy)
@@ -1625,7 +1625,7 @@
 	
   // clear uid
   if (uid_ptr) {
-    memset(uid_ptr,0,10);
+    memset(uid_ptr,0,8);
   }
 
   // OK we will select at least at cascade 1, lets see if first byte of UID was 0x88 in

I saw some other references in the neighbourhood that also cleared 10 bytes, can someone who knows the code better check if that correct also?
E.g this:

 memset(p_hi14a_card->uid,0,10);

holiman · 2013-05-06 14:53:21

Neuer_User wrote:

holiman wrote:
I am on Ubuntu 12.10, and I was probably using usb3 most of the time - maybe every time. I'll see if it happens on usb2 aswell.
In my case it was definitely the xhci_hcd driver (USB3.0) that crashed. I reported a bug at the kernel bugtracker, but got no reply so far (https://bugzilla.kernel.org/show_bug.cgi?id=55761).
Now that I switched computers (the new one definitely only with USB2.0) I did not have any further crashes.
If your system has USB3.0 and USB2.0, make sure in syslog that proxmark3 is using USB2.0 (ehci_hcd instead of xhci_hcd).
Hope this helps.
Michael

Yep, using pure usb2.0 fixed it, thanks!

Neuer_User · 2013-05-06 15:49:09

holiman wrote:

Solved it. A fiunction (iso14443a_select_card) took a pointer to a local variable. The variable was 8 bytes, but 10 bytes of memory was cleared - and there was much confusion, since another local variable (par_list) was affected, even though it wasn't even used in the call. Direct memory referencing can produce very nasty bugs..
$ svn diff armsrc/iso14443a.c
Index: armsrc/iso14443a.c
===================================================================
--- armsrc/iso14443a.c	(revision 709)
+++ armsrc/iso14443a.c	(working copy)
@@ -1625,7 +1625,7 @@
 	
   // clear uid
   if (uid_ptr) {
-    memset(uid_ptr,0,10);
+    memset(uid_ptr,0,8);
   }
 
   // OK we will select at least at cascade 1, lets see if first byte of UID was 0x88 in
I saw some other references in the neighbourhood that also cleared 10 bytes, can someone who knows the code better check if that correct also?
E.g this:
 memset(p_hi14a_card->uid,0,10);

This sounds like a quite important finding. Could you also post this in the Mifare subforum?

Thanks

Michael

asper · 2013-05-06 21:18:03

Great finding man !!! Thank you !!! Do you have svn access to apply the changes ?

Can it also be the cause of that: http://www.proxmark.org/forum/viewtopic.php?id=1613 ?

Last edited by asper (2013-05-06 21:19:03)

holiman · 2013-05-06 21:21:31

Thanks! And nope, I dont..

That particular bug could not be the cause of that issue, however, I have seen the value '44' being used in exactly the same way. Take your pick:

martin@lenovox2:~/tools/proxmark3-trunk
$ grep "memset(.*44" armsrc/*
armsrc/iclass.c:    memset(trace, 0x44, RECV_CMD_OFFSET);
armsrc/iclass.c:  memset(trace, 0x44, TRACE_SIZE);
armsrc/iclass.c:	memset(receivedCmd, 0x44, RECV_CMD_SIZE);
armsrc/iclass.c:		memset(receivedCmd, 0x44, RECV_CMD_SIZE);
armsrc/iclass.c:    	memset(trace, 0x44, RECV_CMD_OFFSET);
armsrc/iso14443a.c:  memset(trace, 0x44, TRACE_SIZE);
armsrc/iso14443a.c:	memset(receivedCmd, 0x44, RECV_CMD_SIZE);
armsrc/iso14443a.c:		memset(receivedCmd, 0x44, RECV_CMD_SIZE);
armsrc/iso14443a.c:	memset(rAUTH_NT, 0x44, 4);
armsrc/iso14443.c:    memset(receivedCmd, 0x44, 400);
armsrc/iso14443.c:        memset(receivedCmd, 0x44, 32);
armsrc/iso14443.c:    memset(BigBuf, 0x44, 400);
armsrc/iso14443.c:    memset(trace, 0x44, DEMOD_TRACE_SIZE);
armsrc/mifarecmd.c:	memset(uid, 0x44, 4);
armsrc/mifarecmd.c:	memset(uid, 0x44, 4);
armsrc/mifarecmd.c:	memset(uid, 0x44, 4);
armsrc/mifarecmd.c:	memset(uid, 0x44, 4);
armsrc/mifarecmd.c:	memset(uid, 0x44, 4);
armsrc/mifarecmd.c:	memset(uid, 0x44, 4);
armsrc/mifarecmd.c:	memset(uid, 0x44, 4);
armsrc/mifarecmd.c:	memset(data, 0x44, 4);
armsrc/mifaresniff.c:	memset(trace, 0x44, TRACE_SIZE);

Last edited by holiman (2013-05-06 21:25:50)

asper · 2013-05-06 21:22:56

Nope = "no svn access" or "no, the bug you suggested here is not related to my finding" ?

holiman · 2013-05-06 21:27:05

@asper Sorry, noticed the question too late and edited my response - but you were quicker.

asper · 2013-05-06 21:30:09

Thank you for your really quick answer holiman ! So you think this can be solved ? I mean those 44 44 44 44 are hiding real data so it is a really nasty bug... I am not so good at source code but I think that this can be solved quite easily, isn't it ? Can you show me how ?

holiman · 2013-05-06 22:30:40

asper wrote:

Thank you for your really quick answer holiman ! So you think this can be solved ? I mean those 44 44 44 44 are hiding real data so it is a really nasty bug... I am not so good at source code but I think that this can be solved quite easily, isn't it ? Can you show me how ?

I don't have any chinese cards to test with, but I took a look anyway, and it seems quite straightforward.
This inconspicious little thing looks very guilty:
mifarecmd.c:955

	// add trace trailer
	memset(data, 0x44, 4);
	LogTrace(data, 4, 0, 0, TRUE);

	LED_B_ON();
  cmd_send(CMD_ACK,isOK,0,0,data,18);

Explanation:
1. memset overwrites the first four bytes of 'data' with 0x44.
2. 18 byte data is sent. That's 16 bytes data, and two bytes crc.
=> Obviously, the data is now four bytes 'trace trailer', 12 bytes data and 2 bytes crc. I don't know how that could have ever worked, or what was intended, so I don't have a patch - it would be better if someone who knew the intention of it patched it correctly.

Just FYI, here's how to do it if it had been more complicated:

1. Check if it's an issue in the ARM-code or host. You can use wireshark to monitor usb traffic, and look for something with data containing those 44's as you perform a cgetblk.
2. If ARM, follow what it's doing. In this case, it looks like mifarecmd.c:881 - void MifareCGetBlock(... that does the job.
3. As you can see on line 961, the variable 'data' is the one to watch - it contains the result.
4. Add some debug printouts - same as I did

Dbprintf("data content 1-6 %x,%x,%x,%x,%x,%x", data[0],data[1],data[2],data[3],data[4],data[5])

5. Compile, flash, run the command. Hopefully, your printouts should alert you when the first four bytes become corrupted. If not, place more printouts until you can narrow it down.

There are probably other and better ways. You could also try and change all occurrences of '44'-initializers into 43,42,41,40,39 etc, and see which one it is that sneaks into your buffer. That might destroy some stuff though, I guess.

And yeah - the problematic instance was indeed one of those listed above

Last edited by holiman (2013-05-06 22:39:41)

holiman · 2013-05-06 22:35:41

Also, mifarecmd.c:865
This *can't* be right:

	
	// add trace trailer
	memset(uid, 0x44, 4);
	LogTrace(uid, 4, 0, 0, TRUE);

	LED_B_ON();
       cmd_send(CMD_ACK,isOK,0,0,uid,4);

asper · 2013-05-06 23:17:40

Thank you for your clear explanation !

I can tell you that the command (cgetsec or cgetblk) is going right to the card and also the answer to PM3 is correct (using LIST command after a command you can see data sent and received in the last transaction and it does not contains any 44, only the real good bytes !).
Knowing that can you make a guess on where the 44 "obfuscation" happens ? I need a patch but I am not so got at source code to make one this time...

Last edited by asper (2013-05-06 23:18:42)

holiman · 2013-05-07 08:01:14

I submitted the bugs above to the 'issues'-list on googlecode now.

asper · 2013-05-07 09:26:08

I am in debt

Maybe you can find also this interesting (I was ablet o solve with a dirty code hack) but I don't know if it is really a bug or a normal mifare standard behaviour, the fact is that it is conflicting with the purpose of Chinese Changeable UID cards...

holiman · 2013-05-11 13:53:59

I got the commit-bit by roel, so now the code is committed. I also added some documentation to flasher and client. About that - how is port specified under windows - and how is flashing performed?

Right now, the 'example' usage in flasher is :

Example:
	 client/flasher path/to/osimage.elf path/to/fpgaimage.elf

I didn't remove that, but it looks like it's outdated. I added a linux-example:

Example (Linux):
	 client/flasher  /dev/ttyACM0 armsrc/obj/fullimage.elf

gaucho · 2013-06-13 12:55:36

@Roel: sorry for the Offtopic, I don't know how to contact you. Could you send me an email for the group buy? http://www.proxmark.org/forum/viewtopic.php?id=1599&p=2
I wrote here cause this is your last thread.
Thank you.

Last edited by gaucho (2013-06-13 12:56:33)

piwi · 2013-07-08 19:46:01

UIDs in ISO14443 can be 4, 7 or 10 Bytes long and the iso14443a_select_card() must be able to handle this. It is therefore required to increase the buffers in the calling functions from 8 to 10 Bytes.

Fixed in r754.

moebius · 2013-07-09 23:18:04

Hello! While using svn754 I'm able to use the Client by Gaucho successfully but using the standard client specifying the com port I have to send the command a few times to get a response.

This behaviour is common right now?

Thanks.

moebius · 2013-07-09 23:22:15

Oh! Also, I'm compiling from source, and using the proxmark3.exe client I get:

proxmark3> hf mf mifare
-------------------------------------------------------------------------
Executing command. It may take up to 30 min.
Press the key on the proxmark3 device to abort both proxmark3 and client.
-------------------------------------------------------------------------

but using the other client (Gaucho scripting one):

proxmark3> hf mf mifare
-------------------------------------------------------------------------
Executing command. Expected execution time: 25sec on average :-)
Press the key on the proxmark3 device to abort both proxmark3 and client.
-------------------------------------------------------------------------

What's going on here? Any ideas?

thanks!

holiman · 2013-07-12 21:05:05

moebius wrote:

Oh! Also, I'm compiling from source, and using the proxmark3.exe client I get:
proxmark3> hf mf mifare
-------------------------------------------------------------------------
Executing command. It may take up to 30 min.
Press the key on the proxmark3 device to abort both proxmark3 and client.
-------------------------------------------------------------------------

Do a 'hw version' with this client. I don't think it is really at r754. Compilation errors that you didn't notice perhaps?

moebius · 2013-07-15 01:45:31

Thanx Holiman for your answer.. look:

proxmark3> hw version
#db# Prox/RFID mark3 RFID instrument
#db# bootrom: svn 754 2013-07-09 17:22:17
#db# os: svn 754-unclean 2013-07-10 01:32:53
#db# FPGA image built on 2012/ 1/ 6 at 15:27:56
proxmark3> hf mf mifare
-------------------------------------------------------------------------
Executing command. It may take up to 30 min.
Press the key on the proxmark3 device to abort both proxmark3 and client.
-------------------------------------------------------------------------

Really weird.. the above output is using the proxmark3 client after compiling from source... but using the precompiled stuff from Asper & co. using the GauchGUI and the proxmark3.exe the stuff is running fine... I'm not pretty sure what's going on...

holiman · 2013-07-18 19:19:26

Could it be that you're on 754, but in a branch and not in trunk? The r754-awesomesauce is only in the trunk.

moebius · 2013-07-18 19:24:57

Uhmm could be... I'm using the proxspace env. with svntort. since rev600 aprox... I'll check that...

Navster · 2017-07-13 05:17:10

i get this message on my mac:

svn checkout http://proxmark3.googlecode.com/svn/trunk proxmark3
svn: E170013: Unable to connect to a repository at URL 'http://proxmark3.googlecode.com/svn/trunk'
svn: E160013: '/svn/trunk' path not found

iceman · 2017-07-13 07:07:37

I think last time someone used googlecode/svn was about the last time this thread was active before you raised it from the dead.
I also understand that you didn't read the recommended link.

The latest sourcecode is on GitHub, the latest official release is v3.0.1 and can be downloaded from there.

Proxmark3 community

Announcement

#101 2013-04-15 09:50:10

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

#102 2013-04-22 13:09:49

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

#103 2013-04-22 22:17:44

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

#104 2013-04-23 20:51:38

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

#105 2013-04-23 21:52:56

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

#106 2013-04-23 21:57:09

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

#107 2013-04-23 22:00:54

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

#108 2013-04-24 09:47:37

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

#109 2013-04-26 21:14:12

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

#110 2013-04-26 21:45:50

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

#111 2013-05-02 11:07:28

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

#112 2013-05-02 11:41:41

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

#113 2013-05-02 13:56:30

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

#114 2013-05-02 17:45:29

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

#115 2013-05-05 00:12:02

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

#116 2013-05-05 21:10:55

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

#117 2013-05-05 23:11:26

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

#118 2013-05-06 07:32:18

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

#119 2013-05-06 07:44:38

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

#120 2013-05-06 07:50:08

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

#121 2013-05-06 08:16:49

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

#122 2013-05-06 14:52:20

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

#123 2013-05-06 14:53:21

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

#124 2013-05-06 15:49:09

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

#125 2013-05-06 21:18:03

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

#126 2013-05-06 21:21:31

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

#127 2013-05-06 21:22:56

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

#128 2013-05-06 21:27:05

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

#129 2013-05-06 21:30:09

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

#130 2013-05-06 22:30:40

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

#131 2013-05-06 22:35:41

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

#132 2013-05-06 23:17:40

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

#133 2013-05-07 08:01:14

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

#134 2013-05-07 09:26:08

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

#135 2013-05-11 13:53:59

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

#136 2013-06-13 12:55:36

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

#137 2013-07-08 19:46:01

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

#138 2013-07-09 23:18:04

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

#139 2013-07-09 23:22:15

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