The part in the sniffing to extract the needed auth exchange is needed to then run the much improved key recovery.
Haven't seen anyone do it however.
]]>I merged the PR today and if you want to give it a test spin, You can find it under /tools/hitag2crack/crack5opencl on RRG/Iceman repo.
Just a awesome contribution!
]]>just a little update.
I looked again at the traces and their is a page read before going into crypto mode.
Investigating this it seems to be a "company brand" to exclude hitag 1 fabric new cards.
I also got the same value for this page from the key fob, but the cards are not responding to the command.
After sending it, no more rx is recieved. But it seems correct as the fob responds.
My bet is, that it is a timing problem. Also I've recognized, that if i use to much dbprintf, the timings are go to high.
Is their a possibillity to log the exact timings, without interferring the send and recieve?
So that i can look after comm for it.
Also it would be nice to know, if I can see the com on the data plot.
Also I've got the following problem:
case RHT1_UID_CONF: { //RHT1_UID_CONF
c = (UsbCommand){ CMD_READER_HITAG_1 };
c.arg[1] = param_get64ex(Cmd, 1, 0, 0); //tag mode
} break;
case RHT1_READ_PAGE: {
c = (UsbCommand){ CMD_READER_HITAG_1 };
c.arg[1] = param_get64ex(Cmd, 1, 0, 0); // tag mode
c.arg[2] = param_get64ex(Cmd, 2, 0, 0); // page
} break;
In the RHT1_UID_CONF the tag mode is transmitted to the reader command.
In case of the RHT1_READ_PAGE i got no tag mode and no page.
It's really anoying....
I hope anyone can help me with an idea.
Thank you very much!
]]>*moved*
Thanks Iceman, clearly posted this in the wrong area!
]]>000, START_AUTH
11000, START_AUTH
11000, START_AUTH
11000, START_AUTH
11000, START_AUTH
11000, START_AUTH
11000, START_AUTH
11000, START_AUTH
11000, START_AUTH
11000, START_AUTH
11000, START_AUTH
XXXXXXXXXXXX, PWD:NOT SHOWING
1110010111, READ_PAGE:4
1110101010, READ_PAGE:5
1111010011, READ_PAGE:6
1111100000, READ_PAGE:7
11000, START_AUTH