Skip to main content
Topic: PSC Code SLE4442 (Read 827 times) previous topic - next topic

PSC Code SLE4442

Hello Everybody,

someone could explain me how setup my Bus Pirate v3.6a for sniff the communication between a Smart Card Reader and SLE4442?
I need to discovery the PSC code.

Thanks in advance
Fuego

Re: PSC Code SLE4442

Reply #1
Hi elfuego.
Trusting that your goal is aimed at personal education and there are absolutely no fraudulent intentions of any kind, to my knowledge there are two ways to get what you want.
The first is to use the Bus Pirate as a logic analyzer and acquire the data traffic exchanged on the data bus in search of the PSC, namely connect the Bus Pirate to the data bus using 4 of the 5 available channels according to this scheme:

CH0 = Bus Pirate CS  = SLE4442 RESET
CH1 = Bus Pirate MISO = SLE4442 CLK
CH2 = Bus Pirate CLK  = SLE4442 I/O
CH3 = Bus Pirate MOSI = SLE4442 SOCKET SC_PRES
CH4 = Bus Pirate AUX  = not used

In the SUMP client set the SPI decoder as follows:

MOSI [2-'MOSI']
MISO [None]
Clock[1-'clk']
Enable[None]
Least Significant Bit First
8 Bits per Transfer (Standard)
Clock is Low when inactive (CPOL = 0)
Data is Valid on Clock Leading Edge (CPHA = 0)
Enable line is Active Low (Standard)

Then select channel 1 as a trigger by setting it to negative edge.

Start the acquisition and save it, then in it you have to search for sequences 0x33 0x01 0xXX, 0x33 0x02 0xXX, 0x33 0x03 0xXX corresponding to the three bytes of the PSC possibly ordering them, since it is possible that for reasons of security the bytes are not issued in sequence but rather in random order (i.e. third byte of the PSC first, first byte of the PSC as second and second byte of the PSC as third).
For SLE4442 cards the maximum speed for the clock is only 50kHz, so using the Bus Pirate as a logic analyzer is fine.
The Bus Pirate is not a proper logic analyzer, but it can capture 4K samples and is known to work properly with I2C traffic running at 400kHz clock.
By sampling at 100kHz, twice of the clock frequeny of the 4442 card (50kHz x 2 = 100kHz) the logic analyzer client can capture up 4096 samples in about ~41ms of time span, actually more long lasting since the RLE compression is active.
Unluckily though seems that acquisition delayed does not work with the Bus Pirate, so with long acquisitions it could be tricky to reach the goal:

viewtopic.php?f=4&t=7759&sid=24ee166057782fa2b627288ddc7604ca#p63216


The second way is to use the SPI sniffer even if in reality the method used to exchange data with the SLE4442 card is closer to the 2-WIRE protocol than to the SPI one.
Actually it is no need to use any 2-WIRE sniffer because it is possible to use the SPI sniffer utility designed for the Bus Pirate.
Simply collect data using SPIsniffer.v0.3, which at so low speed it can store a lot of data for long lasting time.
It is need to set SPIsniffer.v0.3 for SPI mode 0 and define the I/O line as MOSI and the CLK as the clock.
The wanted traffic is only on I/O signal (MOSI), so it is need to pay attention to it and ignore everything else, noting that the data format is 8bit LSB first (Least Significant Bit First):

viewtopic.php?f=4&t=7914&p=63509&hilit=rle#p63509

Be seeing you.

U.Sb

Re: PSC Code SLE4442

Reply #2
Hi USBEprom,
Thank you for reply and support. I'm studying SLE4442 there is no fraudulent intentions.

I would like try Bus Pirate as a logic analyzer and I have some questions:

1. CH3 = Bus Pirate MOSI = SLE4442 SC_PRES ...what it's the PIN SC_PRES on SLE4442?
2. I'm using ols-0.9.7.2 like SUMP Client, it's ok or there is another version?

Thanks and Regards
Fuego

Re: PSC Code SLE4442

Reply #3
Hi Fuego.

[quote author="elfuego"]Hi USBEprom,
Thank you for reply and support. I'm studying SLE4442 there is no fraudulent intentions.
[/quote]

OK, good.
Mine was just a dutiful and legitimate warning, nothing else.

[quote author="elfuego"]
I would like try Bus Pirate as a logic analyzer and I have some questions:

1. CH3 = Bus Pirate MOSI = SLE4442 SC_PRES ...what it's the PIN SC_PRES on SLE4442?
[/quote]

In truth there is a typo and a part is missing, the correct indication is CH3 = Pirate Bus MOSI = SLE4442 SOCKET SC_PRES, sorry about that.
SLE4442 SC_PRES / SLE4442 SOCKET SC_PRES means the signal managed by the switch which is activated when the smart card is inserted into the socket and which therefore indicates when it is present and when it is not.
I have indicated it because it could also be used as a trigger to start the acquisition, however simplifying it can be ignored, so that the connection scheme becomes the following which uses 3 of the 5 channels available with the Bus Pirate used as a logic analyzer:

CH0 = Bus Pirate CS  = SLE4442 RESET
CH1 = Bus Pirate MISO = SLE4442 CLK
CH2 = Bus Pirate CLK  = SLE4442 I/O
CH3 = Bus Pirate MOSI = not used
CH4 = Bus Pirate AUX  = not used

Note also that in some cases the I/O signal on the SLE4442 card is called DATA, it is exactly the same thing with different names, just like further information.

[quote author="elfuego"]
2. I'm using ols-0.9.7.2 like SUMP Client, it's ok or there is another version?
[/quote]

In my opinion ols-0.9.7.2 SUMP Client is fine.
Actually the ols-0.9.8 version has been released, but unfortunately the path https://drone.io/jawi/OLS-client/files is no longer reachable, but it is also found here:

https://github.com/jawi/ols

Of course also the ols-0308 client (http://http://gadgetfactory.net/logicsniffer/index.php?n=LogicSniffer.Download) or any other that supports the SUMP protocol is suitable for the purpose.
However I think it is more convenient to evaluate the firmware loaded on the Bus Pirate rather than the SUMP client version, because some firmware releases lack the SUMP support, so therefore, before proceeding, make sure that the firmware running on the Bus Pirate supports the SUMP protocol.
All the firmwares v5.10, v6.1, v6.2 and v6.3 for the Bus Pirate are working with SUMP, the others, unfortunately also the v7.x version, do not work:

https://github.com/BusPirate/Bus_Pirate/issues/109

viewtopic.php?f=28&t=8921

Be seeing you.

U.Sb

Re: PSC Code SLE4442

Reply #4
Hi USBEprom,

Thank you, all clear but I have two more things before test it...

You describe channel connection :

CH0 = Bus Pirate CS = SLE4442 RESET
CH1 = Bus Pirate MISO = SLE4442 CLK
CH2 = Bus Pirate CLK = SLE4442 I/O

1. Bus Pirate MISO = SLE4442 CLOCK and Bus Pirate CLK = SLE4442 I/O... They are reversed or it's correct?

and you describe settings for SPI decoder:

MOSI [2-'MOSI']
MISO [None]
Clock[1-'clk']
Enable[None]
Least Significant Bit First
8 Bits per Transfer (Standard)
Clock is Low when inactive (CPOL = 0)
Data is Valid on Clock Leading Edge (CPHA = 0)
Enable line is Active Low (Standard)

2. MISO is set for acquisition but for SPI decoder is set MOSI. It's correct?

Regards
Fuego

Re: PSC Code SLE4442

Reply #5
Hi Fuego.

[quote author="elfuego"]

Thank you, all clear but I have two more things before test it...

You describe channel connection :

CH0 = Bus Pirate CS = SLE4442 RESET
CH1 = Bus Pirate MISO = SLE4442 CLK
CH2 = Bus Pirate CLK = SLE4442 I/O

1. Bus Pirate MISO = SLE4442 CLOCK and Bus Pirate CLK = SLE4442 I/O... They are reversed or it's correct?
[/quote]

It is correct, they are not reversed.
Keep in mind that you are using your Bus Pirate as a logic analyzer, so actually the pins on it are simply the inputs of a logic analyzer, so that in this scenario those pins are not related to the function they have in normal operation.
From here:

http://dangerousprototypes.com/docs/Logic_analyzer_mode

When the Bus Pirate is used as a logic analyzer, this is the arrangement of its inputs:

Channel 0 = CS
Channel 1 = MISO
Channel 2 = CLK
Channel 3 = MOSI
Channel 4 = AUX

You could easily use any of the inputs, but to make things easier for you it would be better if you used the inputs I wrote you, so you will not have to worry about configuring anything else: see the following of my answer.

[quote author="elfuego"]

and you describe settings for SPI decoder:

MOSI [2-'MOSI']
MISO [None]
Clock[1-'clk']
Enable[None]
Least Significant Bit First
8 Bits per Transfer (Standard)
Clock is Low when inactive (CPOL = 0)
Data is Valid on Clock Leading Edge (CPHA = 0)
Enable line is Active Low (Standard)

2. MISO is set for acquisition but for SPI decoder is set MOSI. It's correct?
[/quote]

Please, do not worry, that too is correct.
The names you read are those that have been assigned to the channels as a label to distinguish them each other.
It has been written that in the scenario that interests you the wanted traffic is only on I/O signal.
Therefore it is need to set in the SPI decoder CH2 = Bus Pirate CLK = SLE4442 I/O as MOSI and since the clock signal is also required, CH1 = Bus Pirate MISO = SLE4442 CLK.
Indeed it is:

MOSI [2-'MOSI ']

and

Clock [1-'clk']

Which means that the signal that the SPI decoder will treat as MOSI is related to the channel 2 labeled precisely 'MOSI ' and the signal that the SPI decoder will treat as Clock is related to the channel 1 labeled precisely 'clk'.
So that is absolutely correct.
As has already been explained, for practical reasons the SPI protocol is being adapted to the data bus of the SLE4442 smart card which in reality is much more similar to the 2-WIRE protocol rather than to the SPI one.
For this reason some labels seem inconsistent, but in the scenario it is only need to acquire data and decode them so that it is possible to identify the sequences 0x33 0x01 0x??, 0x33 0x02 0x??, 0x33 0x03 0x?? corresponding to the 3 bytes of the PSC maybe ordering them appropriately.

Be seeing you.

U.Sb

Re: PSC Code SLE4442

Reply #6
Hi USB Eprom,

I tested but there's a strange Behavior.
BP go out from acquisition mode too early and I always obtain ~1850 samples, no more.

Below ols-0.9.7.2 config:
[attachment=3]
[attachment=2]
[attachment=1]
[attachment=0]

I have few samples data and I don't see the command code 0x33.
Do you have any idea why?

Re: PSC Code SLE4442

Reply #7
Hi Fuego.
I am pretty busy right now, so I can not answer in detail by going too far, sorry.
Later I will try to give you a more detailed answer.
Anyway I suspect that the Bus Pirate is not able to acquire data for the necessary time, especially since as I have already written the delay option in the SUMP client does not work with it.
To be sure that the settings and connections are right, it would be possible to looking for the ATR signal that is issued when the SLE4442 card is initialized and there must be, or otherwise there is a problem.
Try to see if you find the 0xA2 0x13 0x10 0x91 string among the approximately 1850 samples you have, maybe trying to change some parameters in the SPI decoder, such as setting the trigger (/CS) on channel 1 or setting the [SPI mode] parameter to 'auto'.
Also try searching for the ATR string as 0x45 0xC8 0x08 0x89 in the case for any reason it does not honoring LSB order.
I believe, however, that you would have less problems using the Bus Pirate with the SPIsniffer.v0.3 utility rather than using it as a logic analyzer, because you would surely manage to acquire data for a much longer time.
Keep in mind that you need to acquire data in the hope of getting the moment when the PSC is issued and unless you can force that situation, request for the PSC and its subsequent issue, you must acquire for a fairly huge long time if you want to hope to capture the event that you are looking for.
I hope I explained myself.

Be seeing you.

U.Sb

Re: PSC Code SLE4442

Reply #8
Hi Fuego.
The behavior you described could be caused by multiple factors that from a distance it is rather difficult to isolate.
However it seems that using the Bus Pirate with SUMP client the RLE format is not supported, so the span of the acquisition time can not be furthermore increased.
At this point one thing that can be done and that has already been suggested is to search among the about ~1850 samples acquired the ATR string 0xA2 0x13 0x10 0x91.
This would allow to understand if the connections are right and the acquisition system works.
Are you sure that this is really a SLE4442 card?
To ascertain this it would be possible to use the indications described here:

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

And by measuring the clock signal, what is its frequency?
Just to understand if the 100kHz for which the SUMP client is set is enough.
Another thing could be to use as a trigger the CS signal or the SLE4442 SC_PRES / SLE4442 SOCKET SC_PRES on the socket for the SLE4442 smart card.
Whatever the thing, it is need to repeat the acquisitions in the hope of running into the event of issuing the PSC and this could require several attempts as well it could also never happen due to the small sampling memory of the Bus Pirate used as a logic analyzer.
If this is possible, it could be also possible to try to force access to the SLE4442 card via PSC so as to reduce the number of acquisitions need to reach the goal.
As already written you would probably encounter fewer problems using the SPIsniffer.v0.3 utility, rather than using the Bus Pirate as a logic analyzer.
One last thing, if possible.
What is the firmware installed on your Bus Pirate?

Be seeing you.

U.Sb

Re: PSC Code SLE4442

Reply #9
HI USBEProm,

Thank you so much for all support!
My BP is a v3.6a (Sparkfun), Firmware v6.3-beta1 r2088  Bootloader v4.4, DEVID:0x0447 REVID:0x3046 (24FJ64GA002 B8)

I tested several ways:

I connected directly MOSI, CLK and GND BP to the Smart Card Reader pins I/O, CLK and GND.
I put in Card SLE4442 and manage the content with a custom software.

I tried I2C sniffer and this is the result:
[0x0C+0x00+][0x0C-0x00+][0x0C+0x80+][0x0C-0x80+][0x0C+0x40+][0x0C-0x40+]...
Data seem correct and I can see the PSC verification sequence (0x31,0x39,0x33,0x33,0x33,0x39,0x31) but just the command code not the PSC code.

I tried SPI sniffer using teraterm directly on BP and this is the result:
0x45 0xC8 0x08 0x89 0x86 0x18 0x00 0x30 0x05...
Here I can see 0x45 0xC8 0x08 0x89.
Unfortunately, I cannot read PSC verification sequence like I2C sniffer. Randomly I detect "0xCC 0x80..." or "0xCC 0x40..." or "0xCC 0xC0..."
translated they are "0x33 0x01..." or "0x33 0x02..." or "0x33 0x03..."

After last test in Logic Analyzer Mode, data are similar like SPI sniffer but the Analyzer go timeout after few samples.
I sampling 100kHz and trigger is set on MOSI and CLK pins.
After sampling I analyze data with SPI mode 0.
When I connect the Card I see the correct ATR:
[attachment=0]

I have already tried SPIsniffer.v0.3 utility but I obtain result like SPI sniffer using teraterm. In my little test I simple run "SPIsniffer -d COM5" into SPIsniffer.bat
However, I would like to tried one more time but before could you explain me your idea about connect the BP and what's the right configuration for SPIsniffer.v0.3 utility?

I'm stuck because I optain always the same results.
I cannot go on :-( and now I'm not sure if BP is the right hardware for my job. Maybe there's alternatives?

Thanks and Regards,
Fuego

Re: PSC Code SLE4442

Reply #10
Hi Fuego.

[quote author="elfuego"]
My BP is a v3.6a (Sparkfun), Firmware v6.3-beta1 r2088  Bootloader v4.4, DEVID:0x0447 REVID:0x3046 (24FJ64GA002 B8)
[/quote]

Thanks for the details you added.

[quote author="elfuego"]
I connected directly MOSI, CLK and GND BP to the Smart Card Reader pins I/O, CLK and GND.
I put in Card SLE4442 and manage the content with a custom software.
[/quote]

Honestly I did not understand well what you did exactly, I guess you mean that you have filled your SLE4442 card with known values to later simplify the verification of the good functioning of the connections used with the Bus Pirate.
It is correct?
Thanks.


[quote author="elfuego"]
I tried I2C sniffer and this is the result:
[0x0C+0x00+][0x0C-0x00+][0x0C+0x80+][0x0C-0x80+][0x0C+0x40+][0x0C-0x40+]...
Data seem correct and I can see the PSC verification sequence (0x31,0x39,0x33,0x33,0x33,0x39,0x31) but just the command code not the PSC code.
[/quote]

In my opinion I2C sniffer cannot work there, since the way in which data is exchanged with the SLE4442 card is based on a different protocol, just consider the issue of ACK and NACK for each sequence of data, which makes the I2C protocol unusable for the specific scenario.
Probably you see the command codes for the PSC verification but not the PSC itself because the I2C protocol answers NACK for each of them because it does not recognize them and could not be otherwise given that the communication protocol implemented in the SLE4442 card is completely different, incompatible at all.

[quote author="elfuego"]
I tried SPI sniffer using teraterm directly on BP and this is the result:
0x45 0xC8 0x08 0x89 0x86 0x18 0x00 0x30 0x05...
Here I can see 0x45 0xC8 0x08 0x89.
Unfortunately, I cannot read PSC verification sequence like I2C sniffer. Randomly I detect "0xCC 0x80..." or "0xCC 0x40..." or "0xCC 0xC0..."
translated they are "0x33 0x01..." or "0x33 0x02..." or "0x33 0x03..."
[/quote]

This is good, translating the byte that follows them and maybe ordering the whole sequence properly, that is the PSC you are looking for.
As I have already written, it is not said that the PSC is issued in sequence, nor ordered correctly, it is need to identify the parts helping itself with the suffix that precedes them indicating the command (0x33 0x01 0x?? ... 0x33 0x02 0x?? ... 0x33 0x03...) and putting them together adequately, this is.
You will have such a thing:

0xCC 0x80 0xPSC_byte2 ... 0xCC 0x40 0xPSC_byte1 ... 0xCC 0xC0 0xPSC_byte0

Of course you will have to do the reverse traslation of 0xPSC_byteX to get the actual LSB value.
The SPI sniffer in the Pirate Bus as a macro for the SPI protocol is surely adequate for the purpose you set yourself and therefore good.
You can search for the bytes you need simply by considering what are not enclosed in brackets (), as you are only interested in I/O data traffic which in this case is treated as a MOSI signal:

http://dangerousprototypes.com/docs/SPI

I had suggested the SPIsniffer.v0.3 utility because it allows you to automatically save the result of the acquisition in a file, whereas with the macro already present in the SPI protocol of the Bus Pirate this would have to be done manually.
Since the data is exchanged LSB with the SLE4442 card while in the SPI protocol the default is MSB, you must set the Bus Pirate with the command 'l / L Bitorder (msb / LSB)' to have the correct representation, this is why you had to translate what you got to be able to understand it.

I do not know if you already know this:

https://yaehob.wordpress.com/2014/08/26 ... irate-gui/

Once the probable PSC has been extracted from the collected data, you could use it with the Bus Pirate to verify its correctness.
Be careful, however, not to burn the SLE4442 card by overcoming the 3 attempts.
Since I understand you have access to the device that manages that SLE4442 card, you can always reset the error counter and so the 3 attempts simply by entering it there.

[quote author="elfuego"]
After last test in Logic Analyzer Mode, data are similar like SPI sniffer but the Analyzer go timeout after few samples.
I sampling 100kHz and trigger is set on MOSI and CLK pins.
After sampling I analyze data with SPI mode 0.
When I connect the Card I see the correct ATR:
[/quote]

This is great because it shows that the system works, it is only affected by the small number of samples that can be managed with the Bus Pirate used as a logic analyzer.
Sadly it must be said that currently with the latest firmware the SUMP protocol is broken in the Bus Pirate and therefore it can no longer be used as a logic analyzer:

https://github.com/BusPirate/Bus_Pirate/issues/109

[quote author="elfuego"]
I have already tried SPIsniffer.v0.3 utility but I obtain result like SPI sniffer using teraterm. In my little test I simple run "SPIsniffer -d COM5" into SPIsniffer.bat
However, I would like to tried one more time but before could you explain me your idea about connect the BP and what's the right configuration for SPIsniffer.v0.3 utility?
[/quote]

That is pretty normal, as both more or less do the same thing.
However, according to what is described here:

http://dangerousprototypes.com/docs/Bus ... er_utility

The setting you need to use is this:

SPIsniffer  -d <serial port> -e 1 -p 0 -s <port speed> -r <output mode>

[quote author="elfuego"]
I'm stuck because I optain always the same results.
I cannot go on :-( and now I'm not sure if BP is the right hardware for my job. Maybe there's alternatives?
[/quote]

The fact that you always get the same results in terms of acquired data is not a bad thing, rather the opposite.
The system probably works, you just need to extract the right data.
About alternatives to the Bus Pirate, surely any cheap logic analyzer simplifies and make easy the work.
However, years ago I used my Bus Pirate v3 and SPIsniffer.v0.3 to successfully complete the same thing, so for sure the Bus Pirate alone is enough for the purpose.

As a simple curiosity.
By measuring the clock signal, what is its frequency?

Be seeing you.

U.Sb

Re: PSC Code SLE4442

Reply #11
Hi USBEprom,

I'm little bit busy with other activities.

I don't have any tool for meauring the clock frequency...

I will still try to measure signals with SPI sniffer utility 0.3 but I'm not expect a great result.

One thing: I never connected external pullup resistors (2k-10k) on signals. Could be a problem?

I'm thinking to buy and try an "Open Bench Logic Sniffer".

For now, thank you for support  8) . I will let you know something

Regards
Fuego

Re: PSC Code SLE4442

Reply #12
Hi Fuego.
Do not worry, no problem.
However measuring the clock frequency is quite simple, you do not need a frequency meter, an oscilloscope or any other tool, it is enought that you use the "Measure" panel of the SUMP client by checking the "Enabled" flag and put the mouse pointer on the signal.
If you saved the acquisition you posted last August 20th you can reload it in the SUMP client and perform the measurement without having to repeat the acquisition.
However mine is a simple curiosity, nothing else.

Be seeing you.

U.Sb