14b RAW - accessing the iso7816 layer on a 14b tag.

[iceman1001]

[using the latest code from github and my fork :) ]

14b RAW - accessing the iso7816 layer on a 14b tag.
I can get the tag to be selected and get it into a active state where it listens to iso7816 apdu frames.
If I send a correct apdu, it doesn't block&resets and I can re-run correct apdus over and over.
But I never get the answer from the tag. e.g. 90 00, I have printed debugs to see if it is the uart/demod but no. I tried increasing the timeout from 2000 to 200000. Nada. The demod never get anything in... its like the FPGA doesn't pick up the signal.
--relevant fpga code would be in regard to these modes:
FPGA_MAJOR_MODE_HF_READER_RX_XCORR | FPGA_HF_READER_RX_XCORR_848_KHZ
@pwpiwi help!

-- as seen below, the select is working, but no answer to the apdu is received.
pm3 --> hf 14b raw -c -p -s 02 94 a4 00 00 00
REQB : 50 26 58 4B 0C 00 00 00 00
ATTRIB : 00 78 F0

db# max behindby = 3, samples = 262144, gotFrame = 0, Demod.len = 0, Demod.sumI = 1, Demod.sumQ = 1

received 0 octets

[pwpiwi]

Can we please see the rest of the response to REQB? It is truncated to 9 bytes.

[iceman1001]

here you go.
pm3 --> hf 14b raw -c -p 05 00 08
received 14 octets
[LEN 14] 50 26 58 4B 0C 00 00 00 00 00 71 81 [CA D7] OK

[pwpiwi]

Thanks. I just wanted to check if the card supports iso14443-4 (it does) and if the timeout is enough (it is).

But I am not sure if your command is correct.
02 would be the iso14443-4 PCB with a block number of 0, no CID, no NAD. That looks good.
94 a4 00 00 00 would then be the apdu with 94 being the CLA byte, which would be a proprietary (non ISO7816) one. Probably not what you intended?
a4 00 00 would then be a SELECT command with parameters P1=0 and P2=0
And the last 00 is superfluous?

I think that your card simply doesn't understand the command and therefore doesn't respond (there is no NACK in this case).

btw: in your TransmitFor14443B() are some additional code lines which I don't understand. Merge conflicts ????

[iceman1001]

The CLA 0x94, is very intended. Navigo has a propritary command.
The command is taken from the https://github.com/pterjan/cardpeek-navigo project, which can read Navigo cards, and I tried several versions of the command.
The last 0x00, is for saying the len of added bytes is zero, also in the standard.
Its a bare APDU, which should get at least a NACK back.

-If you are talking about the spindelay in "TransmittFor14443B()", its for letting the tag to get some time to powerup before sending the first time.

-If you are talking about the StartCountSspClk( in "TransmittFor14443B()", I saw the EPA changes had this one in its setup, https://github.com/Proxmark/proxmark3/blob/master/armsrc/iso14443b.c#L989 and thought I could test it too.

[pwpiwi]

A length byte of 0x00 starts an extended length and two more bytes would be expected. Length 0 is declared by omitting the length byte.

[iceman1001]

according to iso7816, the master/slave setup means that the slave (ie tag) must answer to a apdu no matter what. If the apdu is formatted wrong, it should always answer. So I'm not buying your idea that a wrong apdu is making the tag not-responding.

And, I got a snoop, from cardpeek and tag.
http://www.proxmark.org/forum/viewtopic.php?pid=17159#p17159

[pwpiwi]

Did you try the command similar to the snoop? (hf 14b raw -c -p -s 02 94 a4 00 00 02 20 00 00)

[iceman1001]

yes I did, and I guess the last 0x00 is the expected response len.. But that doesnt match the snoop response.. however, the following up answer to your question is I didn't get a response from the tag.

[iceman1001]

well, the user who took the snoop tried and run against his tag.
And he got an answer (after reqb, attrib) to the command: hf 14b raw -c -p 02 94 a4 00 00 02 20 00 00
wrong crc to it, but at least an answer...

So question is now, whats wrong with my tag...

[buggii]

Can it be a "disabled" (killed) tag? With iso15693 it is possible but tag will never answer back anymore... maybe it really need an auth of some kind?

Inviata dal mio dispositivo Android.

-----Original Message-----
From: Iceman notifications@github.com
To: Proxmark/proxmark3 proxmark3@noreply.github.com
Sent: Mer, 15 Lug 2015 20:39
Subject: Re: [proxmark3] 14b RAW - accessing the iso7816 layer on a 14b tag. (#128)

well, the user who took the snoop tried and run against his tag.
And he got an answer (after reqb, attrib) to the command: hf 14b raw -c -p 02 94 a4 00 00 02 20 00 00
wrong crc to it, but at least an answer...

So question is now, whats wrong with my tag...

---

Reply to this email directly or view it on GitHub:
#128 (comment)

[iceman1001]

As it looks like at the moment then that could be the case here with my tag...

[iceman1001]

Not a killed tag... but a brand new one, without a subscription on it.
This would explain why the tag doesn't answer to the AID "20 00" application directory.. It might not be there. But it doesn't explain why the tag doesn't follow iso7816 standard...

[iceman1001]

@pwpiwi I tried a another sqrt[ci^2 + cq^2), which works better for my setup. Don't know if it takes too long time to execute. You see it below. Feedback what you think about it would be nice.

My question is your "MAKE SOF DECISION", what does it do?

// The soft decision on the bit uses an estimate of just the
// quadrant of the reference angle, not the exact angle.
#define MAKE_SOFT_DECISION() {
v = (Demod.sumI > 0) ? ci : -ci;
if(Demod.sumQ > 0) {
v += cq;
} else {
v -= cq;
}
}

#define SUBCARRIER_DETECT_THRESHOLD 8

// Subcarrier amplitude v = sqrt(ci^2 + cq^2), approximated here by max(abs(ci),abs(cq)) + 1/2*min(abs(ci),abs(cq)))
#define CHECK_FOR_SUBCARRIER() {
ai = (abs(ci) >> 1);
aq = (abs(cq) >> 1);
v = MAX(abs(ci), abs(cq)) + MIN(ai, aq);
}

[pwpiwi]

Well, this version of CHECK_FOR_SUBCARRIER() gives the same result doesn't it? Why should it then work better?

I would agree that it is easier to comprehend, but it is slower. I don't know if it is too slow.

I had a hard time to understand MAKE_SOFT_DECISION() as well, but it indeed makes what it says: it checks if the vector (cq, ci) is in the same quadrant (+/- 45°) as the training vector (sumQ, sumI). If yes, then v > 0. Take a sheet of paper with a coordinate system and try some examples...

[iceman1001]

Don't know if it gives the same result, since this one works better for me. I can get @marshmellow42 "-s" to work, which wasn't before.

[iceman1001]

OK, seems neat, however not consistent.

if yes, v > 0
if no, v <= 0

           v, sumi, sumq, ci, cq

#db# ICE: 47 752 -13 43 -4
#db# ICE: -40 752 -13 -40 0
#db# ICE: 44 -648 -6 -44 0
#db# ICE: 41 -648 -6 -41 0
#db# ICE: 41 -648 -6 -40 -1
#db# ICE: 41 -648 -6 -41 0
#db# ICE: 41 -648 -6 -41 0
#db# ICE: 40 -648 -6 -40 0
#db# ICE: 41 -648 -6 -41 0
#db# ICE: 40 -648 -6 -40 0
#db# ICE: 41 -648 -6 -41 0
#db# ICE: 40 -648 -6 -40 0
#db# ICE: 41 -648 -6 -41 0
#db# ICE: 40 -648 -6 -40 0
#db# ICE: 42 -648 -6 -41 -1
#db# ICE: 40 -648 -6 -40 0
#db# ICE: 42 -648 -6 -41 -1
#db# ICE: 40 -648 -6 -40 0
#db# ICE: 41 -648 -6 -41 0
#db# ICE: 41 -648 -6 -44 3 -- false ( v should be negativ )
#db# ICE: -51 -648 -6 49 2
#db# ICE: 41 -645 -3 -41 0
#db# ICE: 41 -645 -3 -41 0
#db# ICE: 40 -645 -3 -40 0
#db# ICE: 41 -645 -3 -41 0

[pwpiwi]

This is still within the same quadrant +/-45°. Therefore OK and consistent. It would cross the 45° line for cq=44. Then v would become 0 and a phase shift would be detected.

[iceman1001]

hm I must be thinking this differently..
Quadrants.

-1,1 | 1,1

-1,-1 | 1,-1

sumi, sumq is -648, -6
i, q is -44, 3
two different quadrants.. Do you mean with +/-45° that its inside the bounding quadrants?

[pwpiwi]

Exactly. If the vector is in the adjacent half of the neighboring quadrants then this is considered "in phase" as well.

[iceman1001]

Since the original answer is answered, (the tag is not initialised yet for usage by navigo. I wonder if there is a way to detect that?)