[Resolved] broken: LF T55xx commands.

iceman · 2014-09-06 15:05:14

I was fiddling around in the LF t55xx commands and was always suprised with not getting some values outputted with issuing a "lf t55xx readblock 1"..
At least it should have given more then the "db: done" thingy.

I looked into the code in "cmdlft55x.c" and realized that all functions only calls "sendcommand" but never waits for a respons.
I looked into the lfops.c in the ARMSRC, and sure enough, the read values is never sent back to the client.

So, yes, LF T55xx commands are fundamently flawed or can someone explain it to me how it is supposed to work.

I just fiddle a bit with it, and now are getting some kind of values back. But there is the strangeness with ie: zeroing the responsebuffer with 128, instead of zeros?? just doesnt make sense to me.

Last edited by iceman (2015-03-20 12:43:34)

iceman · 2014-09-07 22:48:28

LF t55xx readblock progress?..

Well, some times it works.. based on it is configured for manchester modulation... but otherwise no.
I don't know how to decode the bits.. is there a seq start / stop marker? Block read should only send the one block over and over... but ..

pm3 --> lf t55xx readblock 0
Reading block 0
 GOT :ff ff ff fb 00 ff ff ff ff ff ff ff fc f3 ec e4 dd d6 d0 ca c2 bf bb b4
 High  : 255 - 0
 CLOCK : 31
Manchester decoded bitstream
1 0 1 0 1 0 0 0 0 0 0 0 0 0 0 0
0 1 0 1 1 1 0 1 1 1 0 1 1 1 1 1
1 0 1 0 1 1 1 0 1 0 1 1 1 1 1 1
1 0 1 1 1 1 1 0 1 0 1 0 1 0 0 0
0 0 0 0 1 1 1 0 1 0 0 0 1 0 1 1
0 1 0 0 0 0 0 0 0 0 1 0 0 1 0 0
0 1 0 0 0 0 0 0 0 1 1 0 0 1 1 1
pm3 -->

diaconom · 2014-09-08 15:40:09

@iceman you might want to check out the following post http://www.proxmark.org/forum/viewtopic.php?id=2022 - go down to #11

iceman · 2014-09-08 17:46:29

That helped kind of. What I need is not the write output.. I'm doing the read commands. Somewhere I read in the datasheet that the data is sent without any extra bits when in "direct mode". Which the lf t55xx read commands does.

So the manchester demod should only give me n*32 bits of answer. Nothing else.

marshmellow · 2014-09-08 21:01:51

http://www.proxmark.org/forum/viewtopic.php?id=1917
#5 enio was trying to interpret the response from a block read. Might help.

marshmellow · 2014-09-08 21:02:52

He mentioned start and stop bits that messed up Manchester demod.

iceman · 2014-09-08 23:01:00

pm3 ~/client$ ./proxmark3.exe com3
pm3 --> lf read
#db# buffer samples: d6 d0 cb c6 c1 bc b8 b4 ...
pm3 --> data plot
pm3 --> lf t55xx readtrace
 Reading page 1 - tracedata
Applying Up Threshold: 70, Down Threshold: -60
 Detected clock: 64
 Manchester decoded bitstream : 108 bits
 0111000011111110
 1000001011110100
 1111111110000000
 0000000000000010
 0111000011111110
 1000001011110100
 111111111000
pm3 -->

So trying some of the tips given, with the dirtythreshold, askdemod, mandemod.. give me a nice plot, but 108bits is still more then 64bits that was expected.

marshmellow · 2014-09-08 23:04:29

It is a repeating pattern. Isolate the individual message. It looks to be about 64 bits

iceman · 2014-09-09 00:09:42

yes, a repeating pattern, but still this function is able to say which bit is the correct startbit? and where the pattern repeats?..
I don't know if it is usefull in its present state but atleast there is data coming out.

iceman · 2014-09-16 12:58:48

I forked the repository on Github, and published all my changes in there and all other changes I found / merged to aswell.

The whole Ultralight, UltralightC, (dumps working, detailed info) Iclass, hf 14a raw, hf mf (4k support), Lf t55xx rd/rdPWD/trace em4x/rd//rdpwd, functionality is in there.

The Desfire is under construction.. *not working*,

The whole repository is a copy working for my Win7/64b/ gcc4.8/mingw/QT5.3.1 setup.

Enjoy.

asper · 2014-09-17 05:40:09

I am not able to find the fork (github is not my best friend ), can you write down the link?

iceman · 2014-09-17 08:53:45

Sure, here you go.

https://github.com/iceman1001/proxmark3

And no, GitHub is not my best firend either.

iceman · 2014-09-18 12:30:56

Sorry, it seems like GitHub thought that I was a robot and made cloaked my profile. It should be working now.

Minus8 · 2014-09-18 22:22:33

Hi Iceman,

I try to compile your source but it seems some files are missing

I found 2 things :
Need a mkdir for this directory in MakeFile => obj/loclass/
The folder and the file is missing in the repo => openssl/des.h

iceman · 2014-09-18 23:04:49

You are correct and I'm not good at makefiles, so if you give me a working sample I'll put it in there.

For QT5 , the /client/platforms folder is also missing, but it contains huge qt files [qwindows.dll 1.2mb, qwindowsd.dll 15.7mb] and it is better if you install those yourself.
If you have the old QT4, it shouldn't complain so much.

However the openssl/des.h is not in the repo since it supposed to be in the MinGW environment. Basically, you need to install openssl.

holiman · 2014-09-19 08:09:23

You are not supposed to need openssl or openssl/des.h, at least not unless iceman has added that requirement. For loclass, there should be a des.h there already, I probably made some error in the build files somewhere. The loclass-stuff should be fully self-reliant, but I've heard reports earlier about missing files on the windows-build side, but noone gave me a specific build error. I'll try to fix all build-issues on both windows and linux..

iceman · 2014-09-19 08:23:18

There are 2 ref to openssl/des.h in my fork. One is for the pentura /midnitesnakes Ultralight-c funtionality "hf mfu"
and one in my "hf mfdes" ... which is not using the crypto yet.

holiman · 2014-09-19 08:47:14

Ok, so it's not something that came from loclass, gotcha.

iceman · 2014-09-19 09:01:07

when it comes to makefiles, I think there are several mkdir missing. among one is the obj/loclass

I usually just create the folders manually and forget about it but I see the need for the creation in the makefile.

holiman · 2014-09-19 09:26:39

Well, no, that was a problem once upon a time. See https://github.com/Proxmark/proxmark3/tree/master/client/obj/loclass - I did the same 'fix' that someone had already done on noncetokey: https://github.com/Proxmark/proxmark3/tree/master/client/obj/nonce2key

Just before I merged, I did a clean clone from github and make, and it all went through fine.

Last edited by holiman (2014-09-19 09:27:57)

iceman · 2014-10-04 09:22:08

LF T55XX: Progress report
--------------------------------------------------------
pm3 --> lf read
#db# buffer samples: ae 89 6a 50 3b 29 1a 0d ..
pm3 --> lf t55xx rd 5
Reading page 0 block : 5
First Low : 209
First High : 218
ST Ends : 346
Clock : 32
startindex : 346
Path A
Manchester decoded bitstream : 29 bits
11111111111111111111100111111
pm3 --> data plot

Right now the manchester decoder doesn't quite match up. There is 32 distinct spikes, you can see the ST's clear.

The ST, Sequence terminator dampening field:

A block read with all 0xFF

iceman · 2014-10-06 16:23:38

Never give up.
Next step is the Page 0 / Block 0 ...

pm3 --> lf t55xx trace
 Clock       : 32
 startindex  : 21
 Manchester decoded  : 73 bits
 01212111000000001010100001010001
 10101000011100010110000010100000
 110011212

-- T55xx Trace Information ----------------------------------
-------------------------------------------------------------
 ACL Allocation class (ISO/IEC 15963-1)  : 0xE0 (224)
 MFC Manufacturer ID (ISO/IEC 7816-6)    : 0x15 (21)
 CID                                     : 0x01 (1)
 ICR IC Revision                         : 2
 Manufactured
   Year/Quarter : 2003/1
   Number       : 1080
   Wafer number : 22
   Die Number   : 1286
-------------------------------------------------------------
 Raw Data
     Block 0  : E0150A35
     Block 1  : 0E2C1419
-------------------------------------------------------------

marshmellow · 2014-10-06 16:34:47

question: what is the 2 in the bit stream?

(pretty sweet work though)

also, is this for a chip configured to Manchester rf/64 in the configuration block (as the read will be different for each configured modulation)

Last edited by marshmellow (2014-10-06 16:39:34)

iceman · 2014-10-06 17:45:09

And a simpel configuration command is in place... However since I only can detect manchester encoded information.

pm3 --> lf t55xx info
 Reading page 0 block : 0
 Clock       : 32
 startindex  : 21
 Manchester decoded  : 41 bits
 01211000000000000100010000000111
 010001211

-- T55xx Configuration --------------------------------------
-------------------------------------------------------------
 Safer key               : 0
 reserved                : 0
 Data bit rate           : 2 - RF/32
 eXtended mode           : No
 Modulation              : 8 - Manschester
 PSK clock freq          : 0
 AOR - Answer on Request : No
 OTP - One Time Pad      : No
 Max block               : 7
 Password mode           : No
 SST - Sequence Start Terminator : Yes
 Fast Write              : No
 Inverse data            : No
 POR-Delay               : No
-------------------------------------------------------------
 Raw Data
     Block 0  : 000880E8
-------------------------------------------------------------

iceman · 2014-10-06 17:46:45

Yes, the 2 is the so called "dampening field" in the Sequence start terminator. It's not a 1 or 0... it's with in 40% from the mean value of the signal.

iceman · 2014-10-06 17:48:35

And no, the clock is determined to 32.. and the configuration block confirms it to "RF/32 manchester".. This is a catch 22 momenten.

iceman · 2014-10-06 19:46:59

Interesting stuff:

if pwd bit is set and maxblock == 7, the password is readable with: lf t55xx rd 7
if pwd bit is set and maxblock < 7, try the default passwords like 00000000, 11111111, 51243648

Make sure that the OTP bit is *not* set .
Check the safer key setting.
if 6 AND extendend mode bit is true, then the test-mode is disabled.
if 9 AND extendend mode bit is true, then the extendend mode is enabled.

I think I will write an addition that takes a "suggested" configblock settings and shows what it says.

iceman · 2014-10-07 18:58:48

And finally a dump command.

pm3 --> lf t55xx dump
     Block 0  : 0x000880E8  00000000000010001000000011101000
     Block 1  : 0xFF83C033  11111111100000111100000000110011
     Block 2  : 0x22A646E4  00100010101001100100011011100100
     Block 3  : 0x387BC5EB  00111000011110111100010111101011
     Block 4  : 0x5198DE04  01010001100110001101111000000100
     Block 5  : 0xDEADBEEF  11011110101011011011111011101111
     Block 6  : 0x00000000  00000000000000000000000000000000
     Block 7  : 0x00000000  00000000000000000000000000000000
pm3 -->

marshmellow · 2014-10-07 22:09:07

SWEET! Great work.

how hard is it to adjust this to work with different block 0 configurations?

iceman · 2014-10-07 22:29:59

the clock rate is automatic but different encoding as : fsk, psk, biphase it can't read it since I only can decode manchester. However... the data is in the Graphbuffer (data plot) , so you could use all the data commands

marshmellow · 2014-10-08 03:45:35

FSK is probably the next most popular modulation configuration. I could try and help you decode FSK if you feel like going further. I'm not good with the code, or I'd try. As it is this will be a great addition to the proxmark. Thanks.

iceman · 2014-10-08 07:40:34

Looking at the fskdemod-function in the cmddata.c it seems kind of clean to implement.

I'm not sure how to detect what modulation the tag (t55x7) is using. Right now, you can issue a "lf t55xx rd 0" (read block 0) command and the function loads the data in the Graphbuffer, and tries to manchester demodulate it.
If it fails, there will be only garabage returning. If you issue a "data fskdemod" afterwards, it does what you want basically.

iceman · 2014-10-08 07:44:15

if you want to try it out, I published it to my fork here. https://github.com/iceman1001/proxmark3

iceman · 2014-10-08 07:45:23

I need some feedback regardless to see how the dampeningfield detection works on different tags/antennas.

asper · 2014-10-08 10:32:13

Which commands do you need to be tested ?

iceman · 2014-10-08 10:42:53

Asper, if you have time then these commands needs to be tested against different antennas/tags
I would be grateful if you did.

lf t55xx rd
lf t55xx trace
lf t55xx info
lf t55xx dump

iceman · 2014-10-08 10:49:17

and when you at it, if you have a fsk configurated t55x7 tag, then see if you can read it with:

data plot
lf t55xx rd 0
data fskdemod

And also, I changed the start up sequence for the lf t55xx cmds to use the same as "lf read" so you dont have to execute that one first.

asper · 2014-10-08 11:46:25

I have problems compiling:

I added the missing .h files (on the left) in client\openssl but now I have the problems listed in the right shell window.

Last edited by asper (2014-10-08 11:57:53)

iceman · 2014-10-08 11:52:01

My fork has the Qt5.3.1
if you have the old Qt installed, you can see the differences between the makefiles (use a compare proggie)

iceman · 2014-10-08 11:59:35

Another user here fixed their makefile to this one: http://www.icesql.se/proxmark3/code/linuxMakefile.txt

Don't know if that helps you.

Last edited by iceman (2014-10-08 11:59:59)

asper · 2014-10-08 12:11:03

Solved the Qt issue (copied the 3 missing .dlls in \MinGW\qt\lib). What about crypto.dll ? Where can I find it ? It seems not to be in openssl...

iceman · 2014-10-08 12:15:41

try compiling without -lcrypto since that assumes MinGW has openssl installed.

asper · 2014-10-08 12:18:10

Without it I got lot of "undefined reference" errors, I think it is necessary.

iceman · 2014-10-08 12:18:19

otherwise we can mail instead of fill this thread.

iceman at iuse se

asper · 2014-10-08 12:29:42

Still problems. If someone have crypto.dll or libcrypto.dll or cryptolib.dll please upload them somewhere.

iceman · 2014-10-08 12:35:50

proxguiqt.cpp looks like a Qt problem still.

marshmellow · 2014-10-08 14:13:55

I am willing to run tests but cannot compile, is a pre-compiled executable out of the question?

iceman · 2014-10-08 15:54:32

I don't know if you can use it. It's a compiled windows client, and you need to flash the osimage.elf aswell.

http://www.icesql.se/proxmark3/code/bin0.0.rar

asper · 2014-10-08 17:42:33

Manged to run your compiled version !

Here is my test:

pm3 --> lf t55xx rd 0
Block 0 : 0xEDDFF3F4 22220220222022222222200222222020
pm3 -->
pm3 --> lf t55xx trace
-- T55xx Trace Information ----------------------------------
-------------------------------------------------------------
ACL Allocation class (ISO/IEC 15963-1) : 0x1D8 (472)
MFC Manufacturer ID (ISO/IEC 7816-6) : 0x175 (373)
CID : 0x26 (38)
ICR IC Revision : 14
Manufactured
Year/Quarter : 2000/0
Lot ID : 0
Wafer number : 0
Die Number : 0
-------------------------------------------------------------
Raw Data - Page 1
Block 0 : 0xD9753E00 22202200212221212011222200000000
Block 0 : 0x00000000 00000000000000000000000000000000
-------------------------------------------------------------
pm3 -->
pm3 --> lf t55xx info
Block 0 : 0x7AFFF3F6 01222212022222222222200222222022
-- T55xx Configuration --------------------------------------
-------------------------------------------------------------
Safer key : 6 - pasdwd
reserved : 214
Data bit rate : 14 - (Unknown)
eXtended mode : Yes - Warning
Modulation : 0x3E (Unknown)
PSK clock freq : 4
AOR - Answer on Request : No
OTP - One Time Pad : Yes - Warning
Max block : 14
Password mode : Yes
Sequence Start Terminator : Yes
Fast Write : No
Inverse data : Yes
POR-Delay : Yes
-------------------------------------------------------------
Raw Data - Page 0
Block 0 : 0x7AFFF3F6 01222212022222222222200222222022
-------------------------------------------------------------
pm3 -->
pm3 --> lf t55xx dump
Block 0 : 0xFF6ECEE3 12222222202202220220022202220011
Block 1 : 0xFD9FBBEC 22222221220022222202220222220220
Block 2 : 0x3EFDD7DA 00122222022222202221212222202202
Block 3 : 0xF7000000 22222022200000000000000000000000
Block 4 : 0xECFF1766 22220220022222222000212221220022
Block 5 : 0x7CEED53E 01222220022202220221202020122222
Block 6 : 0xFCFEFE5E 22222220022222220222222200202222
Block 7 : 0x79BD7396 01222201120222212022201022012122
pm3 -->
pm3 --> data plot
pm3 -->
pm3 --> lf t55xx rd 0
Block 0 : 0x3E7D754E 20122222012222202122212021200222
pm3 -->
pm3 --> data fskdemod
actual data bits start at sample 4389
length 50/50
bits: '011000101011111110000100101000000111101110000'
hex: 00000c57 f0940f70
pm3 -->

Last edited by asper (2014-10-08 17:50:34)

iceman · 2014-10-08 17:48:27

Some Qt5 dlls.

http://icesql.se/proxmark3/code/qt5dlls.rar

Proxmark3 community

Announcement

#1 2014-09-06 15:05:14

[Resolved] broken: LF T55xx commands.

#2 2014-09-07 22:48:28

Re: [Resolved] broken: LF T55xx commands.

#3 2014-09-08 15:40:09

Re: [Resolved] broken: LF T55xx commands.

#4 2014-09-08 17:46:29

Re: [Resolved] broken: LF T55xx commands.

#5 2014-09-08 21:01:51

Re: [Resolved] broken: LF T55xx commands.

#6 2014-09-08 21:02:52

Re: [Resolved] broken: LF T55xx commands.

#7 2014-09-08 23:01:00

Re: [Resolved] broken: LF T55xx commands.

#8 2014-09-08 23:04:29

Re: [Resolved] broken: LF T55xx commands.

#9 2014-09-09 00:09:42

Re: [Resolved] broken: LF T55xx commands.

#10 2014-09-16 12:58:48

Re: [Resolved] broken: LF T55xx commands.

#11 2014-09-17 05:40:09

Re: [Resolved] broken: LF T55xx commands.

#12 2014-09-17 08:53:45

Re: [Resolved] broken: LF T55xx commands.

#13 2014-09-18 12:30:56

Re: [Resolved] broken: LF T55xx commands.

#14 2014-09-18 22:22:33

Re: [Resolved] broken: LF T55xx commands.

#15 2014-09-18 23:04:49

Re: [Resolved] broken: LF T55xx commands.

#16 2014-09-19 08:09:23

Re: [Resolved] broken: LF T55xx commands.

#17 2014-09-19 08:23:18

Re: [Resolved] broken: LF T55xx commands.

#18 2014-09-19 08:47:14

Re: [Resolved] broken: LF T55xx commands.

#19 2014-09-19 09:01:07

Re: [Resolved] broken: LF T55xx commands.

#20 2014-09-19 09:26:39

Re: [Resolved] broken: LF T55xx commands.

#21 2014-10-04 09:22:08

Re: [Resolved] broken: LF T55xx commands.

#22 2014-10-06 16:23:38

Re: [Resolved] broken: LF T55xx commands.

#23 2014-10-06 16:34:47

Re: [Resolved] broken: LF T55xx commands.

#24 2014-10-06 17:45:09

Re: [Resolved] broken: LF T55xx commands.

#25 2014-10-06 17:46:45

Re: [Resolved] broken: LF T55xx commands.

#26 2014-10-06 17:48:35

Re: [Resolved] broken: LF T55xx commands.

#27 2014-10-06 19:46:59

Re: [Resolved] broken: LF T55xx commands.

#28 2014-10-07 18:58:48

Re: [Resolved] broken: LF T55xx commands.

#29 2014-10-07 22:09:07

Re: [Resolved] broken: LF T55xx commands.

#30 2014-10-07 22:29:59

Re: [Resolved] broken: LF T55xx commands.

#31 2014-10-08 03:45:35

Re: [Resolved] broken: LF T55xx commands.

#32 2014-10-08 07:40:34

Re: [Resolved] broken: LF T55xx commands.

#33 2014-10-08 07:44:15

Re: [Resolved] broken: LF T55xx commands.

#34 2014-10-08 07:45:23

Re: [Resolved] broken: LF T55xx commands.

#35 2014-10-08 10:32:13

Re: [Resolved] broken: LF T55xx commands.

#36 2014-10-08 10:42:53

Re: [Resolved] broken: LF T55xx commands.

#37 2014-10-08 10:49:17

Re: [Resolved] broken: LF T55xx commands.

#38 2014-10-08 11:46:25

Re: [Resolved] broken: LF T55xx commands.

#39 2014-10-08 11:52:01

Re: [Resolved] broken: LF T55xx commands.