search

BusPirate / Bus_Pirate

Community driven firmware and hardware for Bus Pirate version 3 and 4
628 stars 130 forks source link

2WIRE macros do not work #17

Closed agatti closed 7 years ago

agatti commented 8 years ago

From the report in #7:

MACRO(1) and MACRO(2) in 2WIRE protocol they do not work. For what I can understand MACRO(1) fails due a wrong order in the lsb/MSB of the emitted bytes. Also MACRO(2) fails but I do not know why, perhaps for the same reason of MACRO(1).

agatti commented 8 years ago

Marking it as v4 too as it was not tested on such hardware yet.

USBEprom commented 7 years ago

Hi guys. I am figuring how fix the problem of macro (1) and macro(2) in raw2wire mode. I found some clues here

http://dangerousprototypes.com/forum/viewtopic.php?f=28&t=6097#p56809

where is stated that the issue could be in raw2wire.c and bitbang.c

raw2wire.c (lines 183-188)

// R2W macros

//ISO 7813-3 Answer to reset macro for smartcards // syntax: a0%255@^a // depricated, some cards are MSB first forces LSB format for easy use // now uses CS pin instead of AUX pin because 1,2,3 have build in pullups on CS but not AUX

bitbang.c (lines 191-206)

unsigned int bbReadByte(void){
   unsigned int i,di,dat=0;

   //bbi();//prepare for input
   bbR(MOSI); //setup for input

   for(i=0;i<modeConfig.numbits;i++){
      bbH(CLK,bitbang.delayClock);//set clock high
      di=bbR(MOSI); //same as MISO on 2-wire
      bbL(CLK,bitbang.delayClock);;//set clock low

[b]      //get MSB first
      dat=dat<<1;//shift the data input byte bits
      if(di)dat++;//if datapin in is high, set LBS[/b]
   }
   return dat;
}

In the same link it is even stated that firmware v4.2 have not any problem there, so first I started looking for its source code but no joy. I found the source code of the version 4.3 though. By looking inside it I saw a lot of differences compared on the latest releases, mostly obout the scheme of the messages. That said I took some lines of the old code and I put them into the recent one, also uncommenting some remark. I added lines 192-194 from the old release

//force LSB fist setting for ISO compliance
//c=modeConfig.lsbEN;//store origional setting
//modeConfig.lsbEN=1;

between line 216 and 217 of the new one so that I got this:

// R2W macros

//ISO 7813-3 Answer to reset macro for smartcards // syntax: a0%255@^a // depricated, some cards are MSB first forces LSB format for easy use // now uses CS pin instead of AUX pin because 1,2,3 have build in pullups on CS but not AUX void r2wMacro_78133Write(void){

//bpWline("ISO 7816-3 ATR (RESET on CS)");
//bpWline("RESET HIGH, CLOCK TICK, RESET LOW");
BPMSG1145;

//Reset needs to start low
bbCS(0); //bpAuxLow();
bp_delay_us(0xff);

//RESET HIGH
bbCS(1);

//clock tick
bbClockTicks(1);

//reset low again
bbCS(0); //bpAuxLow();

}

void r2wMacro_78133Read(void){
unsigned char m[4];//macro buffer... unsigned char c; unsigned int i;

//bpWstring("ISO 7816-3 reply (uses current LSB setting): ");
BPMSG1146;

//force LSB fist setting for ISO compliance
c=modeConfig.lsbEN;//store origional setting
modeConfig.lsbEN=1;

I made changes only on raw2wire.c, do not for bitbang.c, which I do not even know how to do there. In the end it is appeared that raw2wire.c is like the old one from the release 4.3, but unfortunately it does not work, macros act same like before of the modifications. I wonder if it fails because also bitbang.c must be modified.

agatti commented 7 years ago

Thanks a lot for the report. As the comment for r2wMacro_78133Write says, some cards are wired to use MSB rather than LSB as per ISO compliance so your changes would make those cards unusable.

Would it be possible for you to set your BP into LSB mode and try again without any code modifications? Also, something that would help would be some captures from a logic analyzer for the "wrong" command sequences and the "right" command sequences so we can make the code work better.

USBEprom commented 7 years ago

@agatti

Normally I already use LSB setting purposely doing stuff on chip cards like sle4442. I tried to set MSB instead of LSB and vice versa too, but nothing changes. The output on the terminal is always wrong, it is 0x45 0xC8 0x08 0x89 instead of 0xA2 0x13 0x10 0x91. The firmware that I built from myself acts exactly the same way as the official ones released after version 4.2 I have no any logic analyzer so a friend of mine did some captures for me. His analyzer does not allow for 2WIRE, or as it is the correct name that I do not know, so he used SPI how it is explained here:

http://dangerousprototypes.eu/forum/viewtopic.php?f=4&t=7914#p63509

For what I can see seems that macro(1) is issued correctly but then the bytes in the terminal are put always MSB with no regard to LSB/MSB setting of the Bus Pirate, in fact analyzer shows always 0xA2 0x13 0x10 0x91 that is the correct answer. So totally it depends on a wrong order while printing the results into the terminal.

macro 1

Instead for macro(2) seems that the problem, or one of the possible problems, is that RESET is not emitted at all, so analyzer can not trigger the start event and by forcing it only clock is captured.

agatti commented 7 years ago

Now things are much clearer, thanks! I'll look into this as soon as possible.

agatti commented 7 years ago

@USBEprom, can you please try this:

before void r2wMacro_78133Read(void){ please add:


uint8_t reverse_byte(uint8_t value) {
    uint8_t reversed = 0;
    uint8_t bitmask;

    for (bitmask = 0b00000001; bitmask != 0; bitmask = bitmask << 1) {
        reversed = reversed << 1;    
        if (value & bitmask) {
            reversed |= 0b00000001;
        }
    }

    return reversed;
}

and inside r2wMacro_78133Read this:


    //read and display ISO 7813-3 bytes
    for(i=0; i<4; i++){
        m[i]=bbReadByte();        
        bpWhex(m[i]);
        bpSP;
    }
    bpBR;

should become:


//read and display ISO 7813-3 bytes
for(i=0; i<4; i++){
  m[i]=bbReadByte();
  if (mode_configuration.lsbEN) {
    m[i] = reverse_byte(m[i]);
  }
  bpWhex(m[i]);
  bpSP;
}
bpBR;

This will flip the byte order of the data as it is recorded, thus make board honour the LSB/MSB setting you set before. If this works, I'll go on and patch this for next release.

USBEprom commented 7 years ago

@agatti

I made the changes you have written but MPLABX compiler gives me some errors as follow:

"F:\MPLABX\XC16\bin\xc16-gcc.exe" ../raw2wire.c -o build/BusPirate_v3/production/_ext/1472/raw2wire.o -c -mcpu=24FJ64GA002 -MMD -MF "build/BusPirate_v3/production/_ext/1472/raw2wire.o.d" -g -omf=elf -DXPRJ_BusPirate_v3=BusPirate_v3 -no-legacy-libc -mlarge-code -mlarge-data -O2 -I"../../microchip/include" -I".." -I"../translations" -msmart-io=1 -Werror -Wall -msfr-warn=off -save-temps ../raw2wire.c: In function 'r2wMacro_78133Read': ../raw2wire.c:235:23: error: 'value' undeclared (first use in this function) nbproject/Makefile-BusPirate_v3.mk:436: recipe for target 'build/BusPirate_v3/production/_ext/1472/raw2wire.o' failed make[2]: Leaving directory 'F:/MPLAB/Bus_Pirate-master_28102016/Bus_Pirate-master/Firmware/busPirate.X' nbproject/Makefile-BusPirate_v3.mk:84: recipe for target '.build-conf' failed make[1]: Leaving directory 'F:/MPLAB/Bus_Pirate-master_28102016/Bus_Pirate-master/Firmware/busPirate.X' nbproject/Makefile-impl.mk:39: recipe for target '.build-impl' failed ../raw2wire.c:235:23: note: each undeclared identifier is reported only once for each function it appears in make[2]: * [build/BusPirate_v3/production/_ext/1472/raw2wire.o] Error 255 make[1]: * [.build-conf] Error 2 make: *\ [.build-impl] Error 2

BUILD FAILED (exit value 2, total time: 10s)

In attachment there are the modified raw2wire.c and the error log as text. Thanks!

Please note that github does not allow me to attach raw2wire.c unless I do not rename it as a text file, so it is need to change its extension from .txt to .c in order to make it working.

ERROR.txt

raw2wire.TXT

agatti commented 7 years ago

@USBEprom my bad, I edited the post after I found the same error myself, probably you didn't get the edited version. I changed the code in https://github.com/BusPirate/Bus_Pirate/issues/17#issuecomment-257312046 - please try again and let me know. Also, can you please try the code in both LSB and MSB mode? So I can make sure to flip the values only on the right LSB setting.

USBEprom commented 7 years ago

@agatti

OK, thank you! I made what yuo have written and now it works! By querying a 4442 card I get 0xA2 0x13 0x10 0x91 when in Bus Pirate the order of the bytes is set for LSB, while instead 0x45 0xC8 0x08 0x89 when it is set MSB. Issue in macro(1) is gone, now it works by honoring LSB/MSB setting (L/l syntax command of the Bus Pirate) in the right way in accordance with the type of card used. Here are the output of the terminal for chip card 4442 in the case of bytes order LSB (right) and then MSB (wrong):

2WIRE>L LSB set: LEAST sig bit first 2WIRE>(1) ISO 7816-3 ATR (RESET on CS) RESET HIGH, CLOCK TICK, RESET LOW ISO 7816-3 reply (uses current LSB setting): 0xA2 0x13 0x10 0x91 Protocol: 2 wire Read type: to end Data units: 256 Data unit length (bits): 8

2WIRE>l MSB set: MOST sig bit first 2WIRE>(1) ISO 7816-3 ATR (RESET on CS) RESET HIGH, CLOCK TICK, RESET LOW ISO 7816-3 reply (uses current LSB setting): 0x45 0xC8 0x08 0x89 Protocol: unknown Read type: variable length Data units: 32768 Data unit length (bits): 1

Obviously macro(2) is not affected by the changes so still it does not works, probably because of the failure of the chip enable select. About that a friend of mine who own an oscilloscope is doing some verifications.

2WIRE>(2) ISO 7816-3 reply (uses current LSB setting): 0xFF 0xFF 0xFF 0xFF Protocol: RFU Read type: variable length Data units: RFU Data unit length (bits): 128

Close up view macro(2)

2WIRE>(2) ISO 7816-3 reply (uses current LSB setting): 0xFF 0xFF 0xFF 0xFF Protocol: RFU Read type: variable length Data units: RFU Data unit length (bits): 128

is not so different from macro(1)

2WIRE>(1) ISO 7816-3 ATR (RESET on CS) RESET HIGH, CLOCK TICK, RESET LOW ISO 7816-3 reply (uses current LSB setting): 0xA2 0x13 0x10 0x91 Protocol: 2 wire Read type: to end Data units: 256 Data unit length (bits): 8

Thanks so much!

agatti commented 7 years ago

@USBEprom thank you for confirming this works!

Incidentally, the changes I applied are only for macro (2). If that still fails then I guess I have to set myself up a hardware rig to perform further tests. In fact, macro (1) is nothing more than a CS line pulse and then macro (2) being executed shortly after.

USBEprom commented 7 years ago

@agatti

first, many thanks for having fix macro(1)!

Then, because I am babo and I do not know programming, I can not but note that it appears that in macro(2) there is no trigger to start it. I mean, in macro(1) there is something like this

//Reset needs to start low

bbCS(0); //bpAuxLow();

bp_delay_us(0xff);

//RESET HIGH

bbCS(1);

//clock tick

bbClockTicks(1);

//reset low again

bbCS(0); //bpAuxLow();

that seems to prepare the start of the procedure, instead in macro(2) nothing. I never saw and not even know if it is existed a firmware where macro(2) was working. I know in firmware v4.2 macro(1) was working but macro(2) was not already in the time. I have not the source code of v4.2, I have only the hexadecimal file, but I have the one of the official release v4.3 and is no trigger at all there for starting macro(2) inside it. I believe some code is missing from the beginning. I guess macro(1) and macro(2) are not so different. More or less them perform the same task with macro(2) that is responsible for parsing the ATR string acquired. By performing macro(1) without any card in the reader the result that can be obtained is something very similar to what is obtained with macro(2), does not matter if card is or is not inserted inside the reader. This thing is instrumentally corroborated by logic analyzer and oscilloscope giving an evidence that actually no starting signal for the procedure is issued when performing macro(2). Maybe it would be enough to simply copy and paste into macro(2) the same code that inside macro (1) is intended to prepare and start the procedure. And more, maybe it would be also need to add the same or similar changes introduced to make macro(1) functioning, who knows.

agatti commented 7 years ago

@USBEprom take a look at this:

void R2Wmacro(unsigned int c)
{
    switch(c)
    {   case MENU:
            //bpWstring(OUMSG_R2W_MACRO_MENU);
            BPMSG1144;
            break;
        case ISO78133ATR:
            r2wMacro_78133Write();
        case ISO78133ATR_PARSE:
            r2wMacro_78133Read();
            break;
        default:
            //bpWmessage(MSG_ERROR_MACRO);
            BPMSG1016;
    }
}

the c variable is the macro number you call from the menu. 0 will print the options menu, 1 will pulse CS and perform a bus read, while 2 will just perform the bus read. case ISO78133ATR: does not have a break statement so execution will flow into case ISO78133ATR_PARSE: and read the data from the bus.

If the device does not send any data unless an ATR signal is sent to it, then of course calling (2) will not read anything, so things work as intended. I am not really familiar with ISO 7813-3 myself (and apparently it costs money to obtain a copy) so I don't know if there are cases in which the device will send an ATR header on the bus without an ATR signal first.

That said, I'll merge this in since you can at least read ATR data after an ATR signal, which was not working before.

agatti commented 7 years ago

Fixed with 3efb35903aa79e41af5ebab00024e3be4bc881a1

agatti commented 7 years ago

If there are further development on this, feel free to reopen the issue so I can take another look at it.

Thanks for your help!

USBEprom commented 7 years ago

@agatti.

Sorry to bother you again. I am babo for sure but something is weird in the latest Bus_Pirate-master.zip that I have just downloaded here from github (https://github.com/BusPirate/Bus_Pirate/archive/master.zip). In there the file raw2wire.c is different from what you have just written. Starting from its line 162 until line 182 there is

void R2Wmacro(unsigned int macro) { switch(macro) { case MENU: //bpWstring(OUMSG_R2W_MACRO_MENU); BPMSG1144; break;

    case ISO78133ATR:
    r2wMacro_78133Write();
    /* Intentional pass-through. */

    case ISO78133ATR_PARSE:
        r2wMacro_78133Read();
        break;

    default:
    //bpWmessage(MSG_ERROR_MACRO);
    BPMSG1016;
    break;
}

}

which is pretty different from what you are written here above. Maybe that is intentionally correct, but inside the file raw2wire.c there are not even the changes made in order to fix macro(1). However I built myself a new version of the firmware on the base of this very latest Bus_Pirate-master.zip released today. Now macro(1) does not work anymore, perhaps it would be more correct to write that behaves as before the patch issued yesterday from you, even macro(2) acts weird. Here is the output of the terminal while querying the usual chip card 4442:

2WIRE>(1) ISO 7816-3 ATR (RESET on CS) RESET HIGH, CLOCK TICK, RESET LOW ISO 7816-3 reply (uses current LSB setting): 0x00 0x00 0x00 0x00 Protocol: unknown Read type: to end Data units: no indication Data unit length (bits): 1

2WIRE>(2) ISO 7816-3 reply (uses current LSB setting): 0x0B 0x06 0x00 0x00 Protocol: unknown Read type: to end Data units: no indication Data unit length (bits): 64

The results seems to honour LSB/MSB order as set on the Bus Pirate, but them are totally wrong. The firmware is working for sure because by manually issuing the ATR request I get the right answer:

2WIRE>a0%255@^arrrr AUX LOW WRITE: 0x00 DELAY 1ms WRITE: 0xFF AUX INPUT/HI-Z, READ: 0 CLOCK TICKS: 0x01 AUX LOW READ: 0xA2 READ: 0x13 READ: 0x10 READ: 0x91 2WIRE>

In attachment I put the file raw2wire.c (its name is raw2wire_macro(1)_agatti_FIX.c) that yesterday I have modified following your indications and that is functioning. Later I will try to put in it the changes you have written in your previous post and I will see what happen. Please note that github does not allow me to attach raw2wire_macro(1)_agatti_FIX.c unless I do not rename it as a text file, so it is need to change its extension from .txt to .c in order to make it working.

raw2wire_macro(1)_agatti_FIX.txt

Generally talking about macro(2) my thinking is pretty different. I have always thought that it queries the chip card for its ATR string then, once acquired it, does the parsing of the answer acquired from the card on the base of what is explained in the datasheet for the specific type of card. For instance for the type 4442, based on what is stated in its data sheet on page 25. I also put that document as attachment.

SLE4442.zip

Looking closely at the abovementioned page 25 of the data sheet that I provided and comparing what is written there with what is reported starting from the line 247 untill the end in file raw2wire.c (for convenience what I have attached), likely ISO 7813-3 is a mere typo because actually that is ISO 7816-3 based on the scheme shown in the data sheet. So in the end from my point of view macro(2) does almost the same as macro(1). The main difference is that macro (2) should do the parsing of ATR. But probably I am wrong and you right because in the raw2wire.c both the macros are labeled as 7816-3 and their structure is pretty identical

RAW2WIRE>(1) ISO 7816-3 ATR (RESET on CS) RESET HIGH, CLOCK TICK, RESET LOW ISO 7816-3 reply (uses current LSB setting): Protocol: Read type: Data units: Data unit length (bits):

RAW2WIRE>(2) ISO 7816-3 reply (uses current LSB setting): Protocol: Read type: Data units: Data unit length (bits):

so that it does not make sense write them as twice. If that is correct then it would explain why macro(1) has its own enable signal for start and macro(2) no. In the case macro(1) should be properly labeled as 7816-3, while macro(2) as 7813-3. Thanks!

agatti commented 7 years ago

@USBEprom sorry, you're right - I missed one line when patching. I'll fix this right away.

Regarding changing the functions name, that's also correct as they do not match the prompts. Moreover, maybe the reason macro (2) exists is to listen for data on the bus when the ATR signal is being sent from something else - which in a way is what the Bus Pirate was meant to be used for.

Anyway, I'll do the necessary updates now, thanks again!

agatti commented 7 years ago

@USBEprom I added a proper fix with d3e0173a9ea6f8389087a00431399a827e35845c - apologies for the inconvenience.

USBEprom commented 7 years ago

@agatti

You are really great! Now it work correctly, many thanks! I do not even know how you are able to do all this alone, actually you are doing all the hard work by yourself, while at me the eyes are crossed after 2 seconds. I fully agree with your latest explanations regarding changing the functions name and about the possible reason whereby macro(2) exists to listen for data on the bus when the ATR signal is being sent from something else, which in a way is just what the Bus Pirate was meant to be used for. So thank you very much for having fixed also this! Of course I just built a new firmware starting from the latest Bus_Pirate-master.zip (https://github.com/BusPirate/Bus_Pirate/archive/master.zip) and it works as expected just out of the box without any need for changes. So totally it works! Thanks again sir!

coyotte4845 commented 2 years ago

@USBEprom, @agatti

Hi USBEprom, agatti

could you share the hex file with this improvement already implemented?

I'm a complete novice in mplab X and to be honest I'm not sure how to proceed... 😔

i already tried the different version 6.0 6.1 6.3. Same issues detected with sle4442.

Thank you very much,

USBEprom commented 2 years ago

Hi coyotte4845. The first version with the fix for macro (1) and macro (2) is in busPirate.FULL_1.zip which you can find here:

http://dangerousprototypes.com/forum/index.php?topic=8498.msg65500#msg65500

The latest updated versions are S_1-29092019.hex and U_1-29092019.hex which you can find here:

http://dangerousprototypes.com/forum/index.php?topic=8498.msg70165#msg70165

Be seeing you.

U.Sb

coyotte4845 commented 2 years ago

Hi Usb

For the second link, I didn’t fin any .hex attached ☹

Thx for your help

From: USBEprom @.> Sent: mardi 15 février 2022 14:48 To: BusPirate/Bus_Pirate @.> Cc: coyotte4845 @.>; Comment @.> Subject: Re: [BusPirate/Bus_Pirate] 2WIRE macros do not work (#17)

Hi coyotte4845. The first version with the fix for macro (1) and macro (2) is in busPirate.FULL_1.zip which you can find here:

http://dangerousprototypes.com/forum/index.php?topic=8498.msg65500#msg65500

The latest updated versions are S_1-29092019.hex and U_1-29092019.hex which you can find here:

http://dangerousprototypes.com/forum/index.php?topic=8498.msg70165#msg70165

Be seeing you.

U.Sb

— Reply to this email directly, view it on GitHubhttps://github.com/BusPirate/Bus_Pirate/issues/17#issuecomment-1040295422, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ASCFPHQYTOJG3BUF3KENS4DU3JKRBANCNFSM4CQEZNBA. Triage notifications on the go with GitHub Mobile for iOShttps://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Androidhttps://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub. You are receiving this because you commented.Message ID: @.**@.>>

coyotte4845 commented 2 years ago

It’s very strange,

Just for your info, I tried to read a SLE4442.

Bus Pirate v3.5 Community Firmware v7.0 - goo.gl/gCzQnW [HiZ 1-WIRE UART I2C SPI 2WIRE 3WIRE KEYB LCD PIC DIO] Bootloader v255.255 DEVID:0x0447 REVID:0x3046 (24FJ64GA002 B8)

Pinstates: 1.(BR) 2.(RD) 3.(OR) 4.(YW) 5.(GN) 6.(BL) 7.(PU) 8.(GR) 9.(WT) 0.(Blk) GND 3.3V 5.0V ADC VPU AUX SCL SDA - - P P P I I I O I O I GND 3.30V 5.06V 0.00V 5.16V L L H L H POWER SUPPLIES ON, Pull-up resistors ON, Open drain outputs (H=Hi-Z, L=GND) LSB set: LEAST sig bit first, Number of bits read/write: 8 a/A/@ controls CS pin R2W (spd hiz)=( 0 1 )

Macro (1) returns the good ATR

ISO 7816-3 ATR (RESET on CS) RESET HIGH, CLOCK TICK, RESET LOW ISO 7816-3 reply (uses current LSB setting): 0xA2 0x13 0x10 0x91 Protocol: 2 wire Read type: to end Data units: 256 Data unit length (bits): 8

And this command returned some trouble data regarding ATR. @First, it seems that the data is in MSB mode but in this case, the ATR should be displayed like this: 0x45 0xC8 0x08 0x89

2WIRE>{0x30 0 0xff} r:255 r:10 (-/-)I2C START BIT WRITE: 0x30 WRITE: 0x00 WRITE: 0xFF (\/-)I2C STOP BIT READ: 0x45 0x27 0x20 0x22 0xFF 0xFF 0x03 0x2B 0xFE 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xA5 0xED 0x00 0x00 0x08 0x00 0xFE 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF READ: 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF

So, if you have an idea…..

Could be very nice,

Many thx for your help.

From: USBEprom @.> Sent: mardi 15 février 2022 14:48 To: BusPirate/Bus_Pirate @.> Cc: coyotte4845 @.>; Comment @.> Subject: Re: [BusPirate/Bus_Pirate] 2WIRE macros do not work (#17)

Hi coyotte4845. The first version with the fix for macro (1) and macro (2) is in busPirate.FULL_1.zip which you can find here:

http://dangerousprototypes.com/forum/index.php?topic=8498.msg65500#msg65500

The latest updated versions are S_1-29092019.hex and U_1-29092019.hex which you can find here:

http://dangerousprototypes.com/forum/index.php?topic=8498.msg70165#msg70165

Be seeing you.

U.Sb

— Reply to this email directly, view it on GitHubhttps://github.com/BusPirate/Bus_Pirate/issues/17#issuecomment-1040295422, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ASCFPHQYTOJG3BUF3KENS4DU3JKRBANCNFSM4CQEZNBA. Triage notifications on the go with GitHub Mobile for iOShttps://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Androidhttps://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub. You are receiving this because you commented.Message ID: @.**@.>>

USBEprom commented 2 years ago

@coyotte4845

Due to forum update the link I wrote has lost attachments so I am attaching the missing hex files here:

S_1-29092019.hex & U_1-29092019.hex.zip

2WIRE>{0x30 0 0xff} r:255 r:10 is a wrong command for READ MAIN MEMORY, the correct syntax is 2WIRE>{0x30 0 0xff}\ r:255 r:10, or or even better 2WIRE>{0x30 0 0xff}\ r:255 r:1 r:9 (2WIRE>{0x30 0 0xff}\ r:255 r r:9).

About macro(2) please pay attention it does not have any trigger because it is likely that it exists to listen for data on the bus when the ATR signal is being sent from something else that the Bus Pirate, which in a way is just what the Bus Pirate was meant to be used for.

Out of curiosity, am I pushy if I ask what is Bootloader v255.255? You wrote Bus Pirate v3.5 Community Firmware v7.0 - goo.gl/gCzQnW [HiZ 1-WIRE UART I2C SPI 2WIRE 3WIRE KEYB LCD PIC DIO] Bootloader v255.255 DEVID:0x0447 REVID:0x3046 (24FJ64GA002 B8) that it sounds really weird at me.

Be seeing you.

U.Sb

coyotte4845 commented 2 years ago

Hey USB,

Many thx for your help and support.

@first, thx a lot for the attachment. I will test it tomorrow.

@Regarding 2WIRE read command, to be honest. I’m lost. I'm a real novice and i've just dived into the world of bus pirate. What’s difference between my command and yours? On different forum, guys used this one😔. Is there possibility to learn these commands? it’s C language or….? Do you know them by heart or? 😁.

@Other question regarding 2WIRE write command. I m looking for a command to write a byte @ a specific memory address.

@for the end, i just flashed the fw7.0 with a pickit2 without using a bootloader and it’s worked. I supposed that i don’t need always a bootloader. Bus pirate returned bl 255.255.

Thx for your help man. Very appreciated.

Coy

Le 15 févr. 2022 à 21:56, USBEprom @.***> a écrit :



@coyotte4845https://github.com/coyotte4845

Due to forum update the link I wrote has lost attachments so I am attaching the missing hex files here:

S_1-29092019.hex & U_1-29092019.hex.ziphttps://github.com/BusPirate/Bus_Pirate/files/8074523/S_1-29092019.hex.U_1-29092019.hex.zip

2WIRE>{0x30 0 0xff} r:255 r:10 is a wrong command for READ MAIN MEMORY, the correct syntax is 2WIRE>{0x30 0 0xff}\ r:255 r:10, or or even better 2WIRE>{0x30 0 0xff}\ r:255 r:1 r:9 (2WIRE>{0x30 0 0xff}\ r:255 r r:9).

About macro(2) please pay attention it does not have any trigger because it is likely that it exists to listen for data on the bus when the ATR signal is being sent from something else that the Bus Pirate, which in a way is just what the Bus Pirate was meant to be used for.

Out of curiosity, am I pushy if I ask what is Bootloader v255.255? You wrote Bus Pirate v3.5 Community Firmware v7.0 - goo.gl/gCzQnW [HiZ 1-WIRE UART I2C SPI 2WIRE 3WIRE KEYB LCD PIC DIO] Bootloader v255.255 DEVID:0x0447 REVID:0x3046 (24FJ64GA002 B8) that it sounds really weird at me.

Be seeing you.

U.Sb

— Reply to this email directly, view it on GitHubhttps://github.com/BusPirate/Bus_Pirate/issues/17#issuecomment-1040784049, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ASCFPHU643QH2FNWRHCKSX3U3K4WPANCNFSM4CQEZNBA. Triage notifications on the go with GitHub Mobile for iOShttps://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Androidhttps://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub. You are receiving this because you were mentioned.Message ID: @.***>

USBEprom commented 2 years ago

coyotte4845 wrote: @Regarding 2WIRE read command, to be honest. I’m lost. I'm a real novice and i've just dived into the world of bus pirate. What’s difference between my command and yours?

2 WIRE protocol requires specific syntax for its use, expecially in order to manage clock. Please take a look at this:

http://dangerousprototypes.com/docs/Bus_Pirate_menu_options_guide#.2F_or_.5C_Toggle_clock_level_high_.28.2F.29_and_low_.28.5C.29

In order to manage chip cards (SLE4442 or any other version ) you need the right syntax as per datasheet and it is need to drive clock in the correct way, so you have to use \ (clock low). Pressing "?" in the terminal of the Bus Pirate will be shown the Help menu with syntax and options, please take a look at it about protocol interaction \ CLK lo. Other useful information here:

https://wherelabs.wordpress.com/bus-pirate-manual/

coyotte4845 wrote: On different forum, guys used this one😔.

Am I pushy asking a link to the post where you read it? Thanks.

coyotte4845 wrote: Is there possibility to learn these commands? it’s C language or….? Do you know them by heart or? 😁.

It is not C or something else programming language, it is simply the syntax required by the Bus Pirate. Please, take a look at these:

http://dangerousprototypes.com/docs/Bus_Pirate http://dangerousprototypes.com/docs/Bus_Pirate_menu_options_guide#Configuration_commands

For an example please see here:

http://dangerousprototypes.com/docs/SLE4442_(FedEx_Kinko%27s)_smart_card_update

coyotte4845 wrote: @Other question regarding 2WIRE write command. I m looking for a command to write a byte @ a specific memory address.

You need to read the datasheet of the card there it is clearly explained how to do it. You must first unlock the card with its correct PSC, otherwise trying to access the data after 3 attempts with the wrong PSC will burn the card, permanently blocking it without the possibility of being able to do anything else.
It is all written in the datasheet of the card which must be read carefully. As for your specific question, a couple of examples could be these:

WRITE PROTECTION MEMORY (write protect without erase 0x20 in address 5 start from 0)= {0x3C 5 0x20}\ ^:124 WRITE PROTECTION MEMORY (erase and write protect 0x20 in address 5 start from 0)= {0x3C 5 0x20}\ ^:255

Other useful examples could be the following, bearing in mind that reading and understanding the datasheet are essential to be able to proceed successfully and not burn the card:

ATR (Answer To Reset)= @^ar:4 READ MAIN MEMORY (read 255byte+1byte+9bytes for safety)= {0x30 0 0xff}\ r:255 r:1 r:9 READ SECURITY MEMORY (ErrorCounter+PSC visible if issued)= {0x31 0 0}\ r:4 COMPARE VERIFICATION DATA (write without erase PSC byte 1 as [FF])= {0x33 1 0xFF}\ ^:124 COMPARE VERIFICATION DATA (write without erase PSC byte 2 as [FF])= {0x33 2 0xFF}\ ^:124 COMPARE VERIFICATION DATA (write without erase PSC byte 3 as [FF])= {0x33 3 0xFF}\ ^:124 COMPARE VERIFICATION DATA (erase and write PSC byte 1 as [FF])= {0x33 1 0xFF}\ ^:255 COMPARE VERIFICATION DATA (erase and write PSC byte 1 as [FF])= {0x33 1 0xFF}\ ^:255 COMPARE VERIFICATION DATA (erase and write PSC byte 2 as [FF])= {0x33 2 0xFF}\ ^:255 COMPARE VERIFICATION DATA (erase and write PSC byte 3 as [FF])= {0x33 3 0xFF}\ ^:255 READ PROTECTION MEMORY (read 4bytes Data Protection Register)= {0x34 0 0}\ r:4 UPDATE MAIN MEMORY (write 0x2F in address 0x2E start from 0)= {0x38 0x32 0x65}\ ^:255 UPDATE SECURITY MEMORY (ErrorCounter zeroset to 3 tries)= {0x39 0 0xFF}\ ^:255 UPDATE SECURITY MEMORY (set ErrorCounter to 3 tries)= {0x39 0 7}\ ^:255 UPDATE SECURITY MEMORY (set ErrorCounter to 2 tries)= {0x39 0 6}\ ^:255 UPDATE SECURITY MEMORY (set ErrorCounter to 1 tries)= {0x39 0 5}\ ^:255 UPDATE SECURITY MEMORY (set ErrorCounter to 0 tries)= {0x39 0 0}\ ^:255

coyotte4845 wrote: @for the end, i just flashed the fw7.0 with a pickit2 without using a bootloader and it’s worked. I supposed that i don’t need always a bootloader. Bus pirate returned bl 255.255.

OK, many thanks for the clarification, honestly I did not think about it.

Out of mere curiosity, do you know these?

https://yaehob.wordpress.com/2014/08/26/sle4442-smart-card-bus-pirate-gui/ https://yaehob.wordpress.com/2014/08/26/bus-pirate-smart-card-shield/

Maybe they could be useful to you. About the shield please pay attention to the fact that poer supply is 5 volt and the GUI use the control pin AUX of the Bus Pirate instead of the most common CS (probably for a question of compatibility with the old firmware for the Bus Pirate being that firmware v2.1+ moves the SLE4442 RESET control from AUX to the CS pin) and actually Bus Pirate v2go/v3/later already has its own pull up resistors on MOSI, CLOCK, MISO and CS wires (no matter which one is used, the only noteworthy thing to which to pay attention is the value of the pull up resistor on MOSI wire because early versions of the Bus Pirate use a 10 kohm while latest ones a 2 kohm in order to drive correctly 1-Wire protocol devices), so regardless of the actual pull-up resistor values (10 kohm or 2 kohm) used into the version of the Bus Pirate used for the project, there on the circuit board already are the pull up resistors, so the new ones on the smart card shield will end up in parallel to those already present, obtaining resistance values lower than the lowest value of the constituent parallel, that could be a problem. Problem or not, it is best to avoid parallel for the pull up resistors hence it should be better add on the smart card shield only the pull up resistor for the AUX signal and use the ones already there on the Bus Pirate for the other wires even because the software designed to deal with the shield surely use the pull up features of the Bus Pirate. So in the end actually you need only one [2 kΩ - 10 kΩ] as pull up resistor for the C2=RST +AUX wire. A wise thing into the project is the possibility to provide or not +5V on it in order to activate/deactivate it. Summing up, given that the pull-up resistors are already provided by the Bus Pirate as hardware on MOSI, CLOCK, MISO and CS it is no need to add them on the shield but only add a new one resistor for the AUX wire where instead by default is not provided for pull-up on the Bus Pirate Revision 3.

coyotte4845 commented 2 years ago

Hi usb,

Thx again for all of these informations. Very interesting.

Am I pushy asking a link to the post where you read it?

https://hackaday.com/2008/11/25/how-to-read-a-fedex-kinkos-smart-card-sle4442/ Command used: {0x30 0 0xff} 0r255 0r10

http://dangerousprototypes.com/blog/2009/08/31/bus-pirate-sle4442-smart-card-update/

Just checked, same command as you sent ☺️👌. ———— Regarding the different example given by you, all is clear and very interesting, only this one is really difficult to understand?!

UPDATE MAIN MEMORY (write 0x2F in address 0x2E start from 0)= {0x38 0x32 0x65}\ ^:255

————

Just for your info regarding my project. I succeeded to dump my existing card 😁. My card is not written protected. So all 32bytes protection are writable.

The goal is now to send all bytes from the existing to another blankcard.

Is there a command to send all main memory bytes in one time? The goal is to avoid to send byte per byte 😊.

Thx again for your help,

Coy

Le 16 févr. 2022 à 13:28, USBEprom @.***> a écrit :



coyotte4845 wrote: @regardinghttps://github.com/regarding 2WIRE read command, to be honest. I’m lost. I'm a real novice and i've just dived into the world of bus pirate. What’s difference between my command and yours?

2 WIRE protocol requires specific syntax for its use, expecially in order to manage clock. Please take a look at this:

http://dangerousprototypes.com/docs/Bus_Pirate_menu_options_guide#.2F_or_.5C_Toggle_clock_level_high_.28.2F.29_and_low_.28.5C.29

In order to manage chip cards (SLE4442 or any other version ) you need the right syntax as per datasheet and it is need to drive clock in the correct way, so you have to use \ (clock low). Pressing "?" in the terminal of the Bus Pirate will be shown the Help menu with syntax and options, please take a look at it about protocol interaction \ CLK lo. Other useful information here:

https://wherelabs.wordpress.com/bus-pirate-manual/

coyotte4845 wrote: On different forum, guys used this one😔.

Am I pushy asking a link to the post where you read it? Thanks.

coyotte4845 wrote: Is there possibility to learn these commands? it’s C language or….? Do you know them by heart or? 😁.

It is not C or something else programming language, it is simply the syntax required by the Bus Pirate. Please, take a look at these:

http://dangerousprototypes.com/docs/Bus_Pirate http://dangerousprototypes.com/docs/Bus_Pirate_menu_options_guide#Configuration_commands

For an example please see here:

http://dangerousprototypes.com/docs/SLE4442_(FedEx_Kinko%27s)_smart_card_update

coyotte4845 wrote: @otherhttps://github.com/other question regarding 2WIRE write command. I m looking for a command to write a byte @ a specific memory address.

You need to read the datasheet of the card there it is clearly explained how to do it. You must first unlock the card with its correct PSC, otherwise trying to access the data after 3 attempts with the wrong PSC will burn the card, permanently blocking it without the possibility of being able to do anything else. It is all written in the datasheet of the card which must be read carefully. As for your specific question, a couple of examples could be these:

WRITE PROTECTION MEMORY (write protect without erase 0x20 in address 5 start from 0)= {0x3C 5 0x20}\ ^:124 WRITE PROTECTION MEMORY (erase and write protect 0x20 in address 5 start from 0)= {0x3C 5 0x20}\ ^:255

Other useful examples could be the following, bearing in mind that reading and understanding the datasheet are essential to be able to proceed successfully and not burn the card:

ATR (Answer To Reset)= @^ar:4 READ MAIN MEMORY (read 255byte+1byte+9bytes for safety)= {0x30 0 0xff}\ r:255 r:1 r:9 READ SECURITY MEMORY (ErrorCounter+PSC visible if issued)= {0x31 0 0}\ r:4 COMPARE VERIFICATION DATA (write without erase PSC byte 1 as [FF])= {0x33 1 0xFF}\ ^:124 COMPARE VERIFICATION DATA (write without erase PSC byte 2 as [FF])= {0x33 2 0xFF}\ ^:124 COMPARE VERIFICATION DATA (write without erase PSC byte 3 as [FF])= {0x33 3 0xFF}\ ^:124 COMPARE VERIFICATION DATA (erase and write PSC byte 1 as [FF])= {0x33 1 0xFF}\ ^:255 COMPARE VERIFICATION DATA (erase and write PSC byte 1 as [FF])= {0x33 1 0xFF}\ ^:255 COMPARE VERIFICATION DATA (erase and write PSC byte 2 as [FF])= {0x33 2 0xFF}\ ^:255 COMPARE VERIFICATION DATA (erase and write PSC byte 3 as [FF])= {0x33 3 0xFF}\ ^:255 READ PROTECTION MEMORY (read 4bytes Data Protection Register)= {0x34 0 0}\ r:4 UPDATE MAIN MEMORY (write 0x2F in address 0x2E start from 0)= {0x38 0x32 0x65}\ ^:255 UPDATE SECURITY MEMORY (ErrorCounter zeroset to 3 tries)= {0x39 0 0xFF}\ ^:255 UPDATE SECURITY MEMORY (set ErrorCounter to 3 tries)= {0x39 0 7}\ ^:255 UPDATE SECURITY MEMORY (set ErrorCounter to 2 tries)= {0x39 0 6}\ ^:255 UPDATE SECURITY MEMORY (set ErrorCounter to 1 tries)= {0x39 0 5}\ ^:255 UPDATE SECURITY MEMORY (set ErrorCounter to 0 tries)= {0x39 0 0}\ ^:255

coyotte4845 wrote: @forhttps://github.com/for the end, i just flashed the fw7.0 with a pickit2 without using a bootloader and it’s worked. I supposed that i don’t need always a bootloader. Bus pirate returned bl 255.255.

OK, many thanks for the clarification, honestly I did not think about it.

Out of mere curiosity, do you know these?

https://yaehob.wordpress.com/2014/08/26/sle4442-smart-card-bus-pirate-gui/ https://yaehob.wordpress.com/2014/08/26/bus-pirate-smart-card-shield/

Maybe they could be useful to you. About the shield please pay attention to the fact that poer supply is 5 volt and the GUI use the control pin AUX of the Bus Pirate instead of the most common CS (probably for a question of compatibility with the old firmware for the Bus Pirate being that firmware v2.1+ moves the SLE4442 RESET control from AUX to the CS pin) and actually Bus Pirate v2go/v3/later already has its own pull up resistors on MOSI, CLOCK, MISO and CS wires (no matter which one is used, the only noteworthy thing to which to pay attention is the value of the pull up resistor on MOSI wire because early versions of the Bus Pirate use a 10 kohm while latest ones a 2 kohm in order to drive correctly 1-Wire protocol devices), so regardless of the actual pull-up resistor values (10 kohm or 2 kohm) used into the version of the Bus Pirate used for the project, there on the circuit board already are the pull up resistors, so the new ones on the smart card shield will end up in parallel to those already present, obtaining resistance values lower than the lowest value of the constituent parallel, that could be a problem. Problem or not, it is best to avoid parallel for the pull up resistors hence it should be better add on the smart card shield only the pull up resistor for the AUX signal and use the ones already there on the Bus Pirate for the other wires even because the software designed to deal with the shield surely use the pull up features of the Bus Pirate. So in the end actually you need only one [2 kΩ - 10 kΩ] as pull up resistor for the C2=RST +AUX wire. A wise thing into the project is the possibility to provide or not +5V on it in order to activate/deactivate it. Summing up, given that the pull-up resistors are already provided by the Bus Pirate as hardware on MOSI, CLOCK, MISO and CS it is no need to add them on the shield but only add a new one resistor for the AUX wire where instead by default is not provided for pull-up on the Bus Pirate Revision 3.

— Reply to this email directly, view it on GitHubhttps://github.com/BusPirate/Bus_Pirate/issues/17#issuecomment-1041442524, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ASCFPHWGHOMYU7EPIDQOKQDU3OJ7FANCNFSM4CQEZNBA. Triage notifications on the go with GitHub Mobile for iOShttps://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Androidhttps://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub. You are receiving this because you were mentioned.Message ID: @.***>

coyotte4845 commented 2 years ago

Hi usb,

Thx again for all of these informations. Very interesting.

Am I pushy asking a link to the post where you read it?

https://hackaday.com/2008/11/25/how-to-read-a-fedex-kinkos-smart-card-sle4442/ Command used: {0x30 0 0xff} 0r255 0r10

http://dangerousprototypes.com/blog/2009/08/31/bus-pirate-sle4442-smart-card-update/

Just checked, same command as you sent ☺️👌. ———— Regarding the different example given by you, all is clear and very interesting, only this one is really difficult to understand?!

UPDATE MAIN MEMORY (write 0x2F in address 0x2E start from 0)= {0x38 0x32 0x65}\ ^:255

————

Just for your info regarding my project. I succeeded to dump my existing card 😁. My card is not written protected. So all 32bytes protection are writable.

The goal is now to send all bytes from the existing to another blankcard.

Is there a command to send all main memory bytes in one time? The goal is to avoid to send byte per byte 😊.

Thx again for your help,

Coy

Le 16 févr. 2022 à 13:28, USBEprom @.***> a écrit :



coyotte4845 wrote: @regardinghttps://github.com/regarding 2WIRE read command, to be honest. I’m lost. I'm a real novice and i've just dived into the world of bus pirate. What’s difference between my command and yours?

2 WIRE protocol requires specific syntax for its use, expecially in order to manage clock. Please take a look at this:

http://dangerousprototypes.com/docs/Bus_Pirate_menu_options_guide#.2F_or_.5C_Toggle_clock_level_high_.28.2F.29_and_low_.28.5C.29

In order to manage chip cards (SLE4442 or any other version ) you need the right syntax as per datasheet and it is need to drive clock in the correct way, so you have to use \ (clock low). Pressing "?" in the terminal of the Bus Pirate will be shown the Help menu with syntax and options, please take a look at it about protocol interaction \ CLK lo. Other useful information here:

https://wherelabs.wordpress.com/bus-pirate-manual/

coyotte4845 wrote: On different forum, guys used this one😔.

Am I pushy asking a link to the post where you read it? Thanks.

coyotte4845 wrote: Is there possibility to learn these commands? it’s C language or….? Do you know them by heart or? 😁.

It is not C or something else programming language, it is simply the syntax required by the Bus Pirate. Please, take a look at these:

http://dangerousprototypes.com/docs/Bus_Pirate http://dangerousprototypes.com/docs/Bus_Pirate_menu_options_guide#Configuration_commands

For an example please see here:

http://dangerousprototypes.com/docs/SLE4442_(FedEx_Kinko%27s)_smart_card_update

coyotte4845 wrote: @otherhttps://github.com/other question regarding 2WIRE write command. I m looking for a command to write a byte @ a specific memory address.

You need to read the datasheet of the card there it is clearly explained how to do it. You must first unlock the card with its correct PSC, otherwise trying to access the data after 3 attempts with the wrong PSC will burn the card, permanently blocking it without the possibility of being able to do anything else. It is all written in the datasheet of the card which must be read carefully. As for your specific question, a couple of examples could be these:

WRITE PROTECTION MEMORY (write protect without erase 0x20 in address 5 start from 0)= {0x3C 5 0x20}\ ^:124 WRITE PROTECTION MEMORY (erase and write protect 0x20 in address 5 start from 0)= {0x3C 5 0x20}\ ^:255

Other useful examples could be the following, bearing in mind that reading and understanding the datasheet are essential to be able to proceed successfully and not burn the card:

ATR (Answer To Reset)= @^ar:4 READ MAIN MEMORY (read 255byte+1byte+9bytes for safety)= {0x30 0 0xff}\ r:255 r:1 r:9 READ SECURITY MEMORY (ErrorCounter+PSC visible if issued)= {0x31 0 0}\ r:4 COMPARE VERIFICATION DATA (write without erase PSC byte 1 as [FF])= {0x33 1 0xFF}\ ^:124 COMPARE VERIFICATION DATA (write without erase PSC byte 2 as [FF])= {0x33 2 0xFF}\ ^:124 COMPARE VERIFICATION DATA (write without erase PSC byte 3 as [FF])= {0x33 3 0xFF}\ ^:124 COMPARE VERIFICATION DATA (erase and write PSC byte 1 as [FF])= {0x33 1 0xFF}\ ^:255 COMPARE VERIFICATION DATA (erase and write PSC byte 1 as [FF])= {0x33 1 0xFF}\ ^:255 COMPARE VERIFICATION DATA (erase and write PSC byte 2 as [FF])= {0x33 2 0xFF}\ ^:255 COMPARE VERIFICATION DATA (erase and write PSC byte 3 as [FF])= {0x33 3 0xFF}\ ^:255 READ PROTECTION MEMORY (read 4bytes Data Protection Register)= {0x34 0 0}\ r:4 UPDATE MAIN MEMORY (write 0x2F in address 0x2E start from 0)= {0x38 0x32 0x65}\ ^:255 UPDATE SECURITY MEMORY (ErrorCounter zeroset to 3 tries)= {0x39 0 0xFF}\ ^:255 UPDATE SECURITY MEMORY (set ErrorCounter to 3 tries)= {0x39 0 7}\ ^:255 UPDATE SECURITY MEMORY (set ErrorCounter to 2 tries)= {0x39 0 6}\ ^:255 UPDATE SECURITY MEMORY (set ErrorCounter to 1 tries)= {0x39 0 5}\ ^:255 UPDATE SECURITY MEMORY (set ErrorCounter to 0 tries)= {0x39 0 0}\ ^:255

coyotte4845 wrote: @forhttps://github.com/for the end, i just flashed the fw7.0 with a pickit2 without using a bootloader and it’s worked. I supposed that i don’t need always a bootloader. Bus pirate returned bl 255.255.

OK, many thanks for the clarification, honestly I did not think about it.

Out of mere curiosity, do you know these?

https://yaehob.wordpress.com/2014/08/26/sle4442-smart-card-bus-pirate-gui/ https://yaehob.wordpress.com/2014/08/26/bus-pirate-smart-card-shield/

Maybe they could be useful to you. About the shield please pay attention to the fact that poer supply is 5 volt and the GUI use the control pin AUX of the Bus Pirate instead of the most common CS (probably for a question of compatibility with the old firmware for the Bus Pirate being that firmware v2.1+ moves the SLE4442 RESET control from AUX to the CS pin) and actually Bus Pirate v2go/v3/later already has its own pull up resistors on MOSI, CLOCK, MISO and CS wires (no matter which one is used, the only noteworthy thing to which to pay attention is the value of the pull up resistor on MOSI wire because early versions of the Bus Pirate use a 10 kohm while latest ones a 2 kohm in order to drive correctly 1-Wire protocol devices), so regardless of the actual pull-up resistor values (10 kohm or 2 kohm) used into the version of the Bus Pirate used for the project, there on the circuit board already are the pull up resistors, so the new ones on the smart card shield will end up in parallel to those already present, obtaining resistance values lower than the lowest value of the constituent parallel, that could be a problem. Problem or not, it is best to avoid parallel for the pull up resistors hence it should be better add on the smart card shield only the pull up resistor for the AUX signal and use the ones already there on the Bus Pirate for the other wires even because the software designed to deal with the shield surely use the pull up features of the Bus Pirate. So in the end actually you need only one [2 kΩ - 10 kΩ] as pull up resistor for the C2=RST +AUX wire. A wise thing into the project is the possibility to provide or not +5V on it in order to activate/deactivate it. Summing up, given that the pull-up resistors are already provided by the Bus Pirate as hardware on MOSI, CLOCK, MISO and CS it is no need to add them on the shield but only add a new one resistor for the AUX wire where instead by default is not provided for pull-up on the Bus Pirate Revision 3.

— Reply to this email directly, view it on GitHubhttps://github.com/BusPirate/Bus_Pirate/issues/17#issuecomment-1041442524, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ASCFPHWGHOMYU7EPIDQOKQDU3OJ7FANCNFSM4CQEZNBA. Triage notifications on the go with GitHub Mobile for iOShttps://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Androidhttps://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub. You are receiving this because you were mentioned.Message ID: @.***>

USBEprom commented 2 years ago

coyotte4845 wrote: https://hackaday.com/2008/11/25/how-to-read-a-fedex-kinkos-smart-card-sle4442/ Command used: {0x30 0 0xff} 0r255 0r10

http://dangerousprototypes.com/blog/2009/08/31/bus-pirate-sle4442-smart-card-update/

Ok, thanks, now I understand.

https://hackaday.com/2008/11/25/how-to-read-a-fedex-kinkos-smart-card-sle4442/
There the link points to a very old document (the reference year is 2008) where the example described refers to an early firmware release for the Bus Pirate, so the syntax is different from the current one.

http://dangerousprototypes.com/blog/2009/08/31/bus-pirate-sle4442-smart-card-update/ The same as above, in fact, already at the beginning it is possible to read the message: This is an old version, see the latest [http://dangerousprototypes.com/docs/SLE4442(FedEx_Kinko%27s)_smart_cardupdate] version on the documentation wiki. This is why the syntax used in the example is different from the current one.

coyotte4845 wrote: Regarding the different example given by you, all is clear and very interesting, only this one is really difficult to understand?!

UPDATE MAIN MEMORY (write 0x2F in address 0x2E start from 0)= {0x38 0x32 0x65}\ ^:255

Sorry, my bad, I was wrong to write. The correct description is:

UPDATE MAIN MEMORY (write 0x65 in address 0x32 start from 0)= {0x38 0x32 0x65}\ ^:255

coyotte4845 wrote: Just for your info regarding my project. I succeeded to dump my existing card 😁. My card is not written protected. So all 32bytes protection are writable.

Thanks for making this clear, however to be able to write data on the card it is need first unlock it by sending its correct PSC.

coyotte4845 wrote: Is there a command to send all main memory bytes in one time? The goal is to avoid to send byte per byte 😊.

As far as I know there are two alternatives. The first is to use a terminal or GUI for the Bus Pirate that allows scripting (e.g. BuccaneersDen, BPConsole, friendly-buspirate, PirateShip GUI, and so on).

The second one, which is the one I think is best, is to use shield and GUI that I have already reported to you so that you can do everything with a simple copy and paste. Look at these, please:

https://yaehob.wordpress.com/2014/08/26/sle4442-smart-card-bus-pirate-gui/ https://yaehob.wordpress.com/2014/08/26/bus-pirate-smart-card-shield/

coyotte4845 commented 2 years ago

Hey USB,

Thx for clarification and explanation,

Regarding Yaehob website, already read it but unfortunately, all links attachment are dead 😔.

Regarding Command in putty, it make sense if i send :

{0x38 0x32 0x65FF0102}\ ^:255

0x32 will be set with 65 0x33 FF 0x34 01 0x35 02

Could be great to use putty command to do that.

Thx again and nice evening,

Le 16 févr. 2022 à 22:25, USBEprom @.***> a écrit :



coyotte4845 wrote: https://hackaday.com/2008/11/25/how-to-read-a-fedex-kinkos-smart-card-sle4442/ Command used: {0x30 0 0xff} 0r255 0r10

http://dangerousprototypes.com/blog/2009/08/31/bus-pirate-sle4442-smart-card-update/

Ok, thanks, now I understand.

https://hackaday.com/2008/11/25/how-to-read-a-fedex-kinkos-smart-card-sle4442/ There the link points to a very old document (the reference year is 2008) where the example described refers to an early firmware releases for the Bus Pirate, so the syntax is different from the current one.

http://dangerousprototypes.com/blog/2009/08/31/bus-pirate-sle4442-smart-card-update/ The same as above, in fact, already at the beginning it is possible to read the message: This is an old version, see the latest [http://dangerousprototypes.com/docs/SLE4442(FedEx_Kinko%27s)smart_card_update] version on the documentation wiki. This is why the syntax used in the example is different from the current one.

coyotte4845 wrote: _Regarding the different example given by you, all is clear and very interesting, only this one is really difficult to understand?!

UPDATE MAIN MEMORY (write 0x2F in address 0x2E start from 0)= {0x38 0x32 0x65}\ ^:255_

Sorry, my bad, I was wrong to write. The correct description is:

UPDATE MAIN MEMORY (write 0x65 in address 0x32 start from 0)= {0x38 0x32 0x65}\ ^:255

coyotte4845 wrote: Just for your info regarding my project. I succeeded to dump my existing card 😁. My card is not written protected. So all 32bytes protection are writable.

Thanks for making this clear, however to be able to write data on the card it is need first unlock it by sending its correct PSC.

coyotte4845 wrote: Is there a command to send all main memory bytes in one time? The goal is to avoid to send byte per byte 😊.

As far as I know there are two alternatives. The first is to use a terminal or GUI for the Bus Pirate that allows scripting (e.g. BuccaneersDen, BPConsole, friendly-buspirate, PirateShip GUI, and so on).

The second one, which is the one I think is best, is to use shield and GUI that I have already reported to you so that you can do everything with a simple copy and paste. Look at these, please:

https://yaehob.wordpress.com/2014/08/26/sle4442-smart-card-bus-pirate-gui/ https://yaehob.wordpress.com/2014/08/26/bus-pirate-smart-card-shield/

— Reply to this email directly, view it on GitHubhttps://github.com/BusPirate/Bus_Pirate/issues/17#issuecomment-1042324481, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ASCFPHRRXXF6F3V36MXNUKLU3QI3JANCNFSM4CQEZNBA. Triage notifications on the go with GitHub Mobile for iOShttps://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Androidhttps://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub. You are receiving this because you were mentioned.Message ID: @.***>

USBEprom commented 2 years ago

@coyotte4845

Sadly I do not think {0x38 0x32 0x65FF0102}\ ^:255 will does work. You need something like these:

{0x38 0x32 0x65}\ ^:255 {0x38 0x33 0x66}\ ^:255 {0x38 0x34 0x66}\ ^:255 {0x38 0x35 0x68}\ ^:255 ...

Putty would be fine (BuccaneersDen or BPConsole even much better than Putty), but I remain of the opinion that what Yaehob describes is the best solution, so I attach the necessary here: SLE4442_BusPirateGUI_0.1.zip

coyotte4845 commented 2 years ago

Hi usb

Ok clear, thx!!!!

Unfortunately, the link you attached is dead. Dropbox returns folder deleted.

Thx in advance,

Le 16 févr. 2022 à 22:59, USBEprom @.***> a écrit :



@coyotte4845https://github.com/coyotte4845

Sadly I do not think {0x38 0x32 0x65FF0102}\ ^:255 will does work. You need something like these:

{0x38 0x32 0x65}\ ^:255 {0x38 0x33 0x66}\ ^:255 {0x38 0x34 0x66}\ ^:255 {0x38 0x35 0x68}\ ^:255 ...

Putty would be fine (BuccaneersDen or BPConsole even much better than Putty), but I remain of the opinion that what Yaehob describes is the best solution, so I attach the necessary here: SLE4442_BusPirateGUI_0.1.ziphttps://github.com/BusPirate/Bus_Pirate/files/8083867/SLE4442_BusPirateGUI_0.1.zip

— Reply to this email directly, view it on GitHubhttps://github.com/BusPirate/Bus_Pirate/issues/17#issuecomment-1042351521, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ASCFPHVXPQO6UKD5C3HZW6TU3QM4PANCNFSM4CQEZNBA. Triage notifications on the go with GitHub Mobile for iOShttps://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Androidhttps://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub. You are receiving this because you were mentioned.Message ID: @.***>

coyotte4845 commented 2 years ago

Ok sorry,

The link worked 😁,

I will do some test this afternoon.

Many thx

Coy

Le 17 févr. 2022 à 06:32, Arnaud Brialmont @.***> a écrit :

 Hi usb

Ok clear, thx!!!!

Unfortunately, the link you attached is dead. Dropbox returns folder deleted.

Thx in advance,

Le 16 févr. 2022 à 22:59, USBEprom @.***> a écrit :



@coyotte4845https://github.com/coyotte4845

Sadly I do not think {0x38 0x32 0x65FF0102}\ ^:255 will does work. You need something like these:

{0x38 0x32 0x65}\ ^:255 {0x38 0x33 0x66}\ ^:255 {0x38 0x34 0x66}\ ^:255 {0x38 0x35 0x68}\ ^:255 ...

Putty would be fine (BuccaneersDen or BPConsole even much better than Putty), but I remain of the opinion that what Yaehob describes is the best solution, so I attach the necessary here: SLE4442_BusPirateGUI_0.1.ziphttps://github.com/BusPirate/Bus_Pirate/files/8083867/SLE4442_BusPirateGUI_0.1.zip

— Reply to this email directly, view it on GitHubhttps://github.com/BusPirate/Bus_Pirate/issues/17#issuecomment-1042351521, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ASCFPHVXPQO6UKD5C3HZW6TU3QM4PANCNFSM4CQEZNBA. Triage notifications on the go with GitHub Mobile for iOShttps://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Androidhttps://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub. You are receiving this because you were mentioned.Message ID: @.***>