[Resolved] broken: LF T55xx commands.

asper · 2014-10-08 17:56:17

If someone is using my official trunk releases these are all the needed .dlls (verified 1 by 1) for the iceman compiled pack: download.

Is my test enough ? Unfortunately I have this t5557 only.

Last edited by asper (2014-10-08 17:56:51)

iceman · 2014-10-08 18:01:45

Bummer, doesn't look good at all. The data is all wrong.

Could you run

data plot
lf t55xx rd 0

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

Now it seems to be a lot better (I think problem was positiong the tag ove the antenna):

pm3 --> lf t55xx rd 0
Block 0 : 0x01480400 00000001010010000000010000000000
pm3 -->
pm3 --> lf t55xx trace
-- T55xx Trace Information ----------------------------------
-------------------------------------------------------------
ACL Allocation class (ISO/IEC 15963-1) : 0x01 (1)
MFC Manufacturer ID (ISO/IEC 7816-6) : 0x50 (80)
CID : 0x14 (20)
ICR IC Revision : 0
Manufactured
Year/Quarter : 2008/0
Lot ID : 1117
Wafer number : 1
Die Number : 16583
-------------------------------------------------------------
Raw Data - Page 1
Block 0 : 0x0150A081 00000001010100001010000010000001
Block 0 : 0x1743031E 00010111010000110000001100011110
-------------------------------------------------------------
pm3 -->
pm3 --> lf t55xx info
Block 0 : 0x01480400 00000001010010000000010000000000
-- T55xx Configuration --------------------------------------
-------------------------------------------------------------
Safer key : 0
reserved : 10
Data bit rate : 2 - RF/32
eXtended mode : No
Modulation : 0 - direct
PSK clock freq : 1
AOR - Answer on Request : No
OTP - One Time Pad : No
Max block : 0
Password mode : No
Sequence Start Terminator : No
Fast Write : No
Inverse data : No
POR-Delay : No
-------------------------------------------------------------
Raw Data - Page 0
Block 0 : 0x01480400 00000001010010000000010000000000
-------------------------------------------------------------
pm3 -->
pm3 --> lf t55xx dump
Block 0 : 0x01480400 00000001010010000000010000000000
Block 1 : 0xF962003F 11111001011000100000000000111111
Block 2 : 0x0C6141C0 00001100011000010100000111000000
Block 3 : 0x00000000 00000000000000000000000000000000
Block 4 : 0x00000000 00000000000000000000000000000000
Block 5 : 0x00000000 00000000000000000000000000000000
Block 6 : 0x00000000 00000000000000000000000000000000
Block 7 : 0x00000000 00000000000000000000000000000000
pm3 -->
pm3 --> data plot
pm3 -->
pm3 --> lf t55xx rd 0
Block 0 : 0x01480400 00000001010010000000010000000000
pm3 -->
pm3 --> data fskdemod
actual data bits start at sample 5433
length 50/50
bits: '011100000111001101001001011100000111001001111'
hex: 00000e0e 692e0e4f
pm3 -->

I managed to solve the Qt compiling problem (same name .dll files unde the Qt folder, some under tools and some under mingw, tested different combination and it worked) but now I still have this:

any hint ?

iceman · 2014-10-08 18:25:56

The data looks correct now.
And your compile issue is the -lcrypto thing,
It's the "Mifare Ultralight" functionality, (cmdhfmfu) whichs references the openssl/des.h.

Your solution with a local copy of openssl should work...

iceman · 2014-10-08 18:28:00

Asper, do you have a tag that uses FSK?

asper · 2014-10-08 18:32:45

Yeah but I am not able to find the crypto.dll file anywhere... downloaded many but no one seems to be good... can you share your one ?

I can program the t55 to have an fsk modulation... but no, I don't have any native fsk tag.

asper · 2014-10-08 19:01:10

Ok I solved the DES error (used openssl libeay32.dll renamed to crypto.dll as suggested in some forums) but I still have those errors:

I think this is a wrong .dll I am using... any help ?

I reinstalled openssl just to be sure but the problem persist.

Last edited by asper (2014-10-08 19:09:54)

iceman · 2014-10-08 19:14:33

still the proxguiqt.moc.. you need the qt5 moc file?

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

If you install qt5.3.1 ??

This is the rest of the files in my Qt5\bin folder. Has a moc.exe...

http://www.icesql.se/proxmark3/code/qt5bin.rar

asper · 2014-10-08 19:22:18

5.3.1 installed. I will try again later.

Last edited by asper (2014-10-08 19:22:42)

iceman · 2014-10-08 19:25:20

I tried;:

--set fsk modulation
lf t55xx wr 000480e8 0

-- read block 0
lf t55xx rd 0

-- fsk demod
data fskdemod

-- set manchester modulation
lf t55xx wr 000880e8 0

It work to change it to FSK, but the "data fskdemod" could not read the data.

marshmellow · 2014-10-08 22:39:42

try block 0 at 00107060 for fsk mode

iceman · 2014-10-08 22:53:41

nop, still didn't work with "data fskdemod"

Your suggestion is: rf/50 , fsk2a

marshmellow · 2014-10-08 23:04:43

iceman wrote:

Your suggestion is: rf/50 , fsk2a

correct, that is the most common fsk setting i've seen.

i took a look at the plot I currently get with the existing lf t55xx readblock 0 - data samples 4000 - data plot commands

it appears there is a lot of garbage in my plot (random stray high waves) are you seeing the same thing?

marshmellow · 2014-10-08 23:07:20

you probably will have to trim out the start sequence as well since the fsk demod will not know how to handle that
(usually about 200-250 samples)

Last edited by marshmellow (2014-10-08 23:11:53)

iceman · 2014-10-09 05:20:01

running a "lf t55xx rd 0" on a fsk configurated tag, I get a nice thick plot of values.
afterwards when I run "data fskdemod" on the dataset, it changes to high waves and low wave, with random spikes..

I will take a printscreen to show what I mean,

iceman · 2014-10-09 05:32:46

lf t55xx rd 0

data fskdemod

marshmellow · 2014-10-09 13:37:20

from the first set to about 1744 I see 00107060. it works, just not with fskdemod (too much garbage?). (it helps if you do a "data grid 50 0")

you plot actually looks a lot cleaner than mine (you have a better antenna . you only need about 2000 samples for a single block read.

iceman · 2014-10-09 13:45:37

There was someone on the forum that made some IIR filter for the LF signal in the fpga which made all my traces really nice.
If you haven't gotten that fix, you should. If you use my fork and flashed bootrom/fpga/os then you should have gotten it aswell.

Sorry but I'm blind. I just can't see "fsk" demodulated in a trace. It helped with adding a data grid, but still...

iceman · 2014-10-09 13:57:09

I think that "data fskdemod" is based on fsk1, rf/40 5 = 0 & 8 = 1
So it can't demodulate your fsk2a rf/50...

now, lets see, what would a configblock be for fsk1 rf/40 ?

marshmellow · 2014-10-09 15:16:11

for fsk1a rf/40 it is 000C6060
for fsk1 rf/40 it is 000C4060

But I've had fskdemod work for standard HID prox cards and those are FSK2a rf/50...

iceman · 2014-10-09 15:32:19

well, there is a "lf hid fskdemod" that you might have used?

There is:

data fskdemod
lf hid fskdemod
lf io fskdemod

and I think "lf indalademod" is also fsk-based...

SO with that I have said nothing at all. I will try the different configs from you.

marshmellow · 2014-10-09 18:17:21

indalademod is PSK not FSK.

lf hid fskdemod usually only works with a 26 bit prox card (in my tests)

I usually use data fskdemod, but it won't output binary unless conditions are perfect (for some reason) even though the wave form it adjusts properly.

lf io fskdemod (based on my tests is FSK2a RF/64)

iceman · 2014-10-09 20:24:14

Sweet!
I don't have access to any hid,indala or ioprox tags so I can't test it.

There is plenty of fsk demods in the codebase but nothing uniform.

marshmellow · 2014-10-09 20:35:57

if you look at the second screen shot you gave, put a 50 grid on it and align the grid so the first up wave is between 2 grid lines that is the 1 in the 0001(binary) of the "1" in 00107060 (hex)

iceman · 2014-10-09 20:46:01

Like the new manchester demod in t55xx, it's all about alignment with the first startup modulation... 1-off-1-off but in FSK.
I need to understand the FSK thingy to be able to find the correct starting point.

asper · 2014-10-11 19:41:19

Compiling issue solved (it was a simple problem with Qt dir folder: export QTDIR=/c/Qt/Qt5.3.2/5.3/mingw482_32/); I can make more tests if you need.

Last edited by asper (2014-10-11 20:00:24)

iceman · 2014-10-11 19:48:35

If you have different kinds of t55x7 tags, try reading, dumping, writing to them... I want to know how stabil it is.

If you have some desfire-cards you can test them also

asper · 2014-10-12 19:10:32

I think I found some sort of bug; while I was testing my block0 was: 01480400 and I was able to dump full tag content; after testing it became 01580400 and now all the blocks show block0 content; I NEVER used the write command.

Another interesting thing is that I am practically sure that my original block0 WAS absolutely NOT 01480400 so I think that the commands I sent to test wrote something inside the tag... can this be possible ?

I am also not able to write to the tag anymore using pm3, I will try with another dedicated programmer.

Last edited by asper (2014-10-12 19:11:47)

iceman · 2014-10-12 19:14:21

Hm, thats strange. And no, the read commands (read/dump/info) is readonly. They don't write.
Could be a memorybug ?, restart client? Did you look at the data plot?

iceman · 2014-10-12 19:15:27

And the "dump" command uses the "read" / "readpwd" commands internally.

asper · 2014-10-12 19:28:14

Well the behaviour is strange; using a dedicated T55x7 reader I obtain the correct values (the tests I made were done with a T55x7 programmed to be an EM4100).

Another strange thing is that lf em4x 410read command is not able to detect the cloned EM4100 but it can when I previously send an lf em4x 410watch command.

Also the lf em4x 410spoof hangs.

Are all those things normal ? Sorry but I am not in 125kHz field (except for descrambling IDs).

EDIT:

I double checked and the bits read by the pm3 commands are totally wrong. My block0 is 000880E8 (taken from official reader and it works) while pm3 reads 0xE0150A08 or 0x00150A08

EDIT2:
This is the (incorrect) dump done by pm3:
pm3 --> lf t55xx dump
Block 0 : 0xE0150A08 11100000000101010000101000001000
Block 1 : 0xE0150A08 11100000000101010000101000001000
Block 2 : 0xE0150A08 11100000000101010000101000001000
Block 3 : 0xFF962003 11111111100101100010000000000011
Block 4 : 0xE0150A08 11100000000101010000101000001000
Block 5 : 0xFF962003 11111111100101100010000000000011
Block 6 : 0xE0150A08 11100000000101010000101000001000
Block 7 : 0xE0150A08 11100000000101010000101000001000

I tested various tag positions over the antenna.

EDIT3:

Well something is wrong in bits... when my tag is in EM4100 emulation mode block0 read by pm3 is 0150A081 (my official reader is not able to read the block0 when tag is in EM4100 emultaion mode but I think this is normal using a T55x7); while when t55x7 is not in emulation mode it reads E0150A08 (and it must be 000880E8 = taken from official reader - those are the bytes wrote by my official software to the T55x7 block0 to take it out of the EM4100 emulation mode); I change modes with the official programmer+software.
As you can see the 1st nibble seems to be changed for pm3 so it is able to read a difference but the value shown is not correct.

Last edited by asper (2014-10-12 22:22:05)

iceman · 2014-10-12 20:05:38

data plot
lf t55xx rd 0

Can you give me a image on the plot? As you say, the read commands has a inital delay now which is about letting the tag inital phase settle down before starting to read the sample data. if your tag block values are wrong, this might be it. So I'm grateful that you are testing it.

iceman · 2014-10-12 20:06:39

No direct need to test the "dump/info" commands, since they use the readblock command themselfs.

iceman · 2014-10-12 20:08:02

The lf em4x read commands, was also "broken" or not implemented, and I tried to make one based on the t55xx commands. So don't expect them to work right now.

asper · 2014-10-12 22:31:10

iceman · 2014-10-13 08:27:28

looks like the ST - detection doesn't work.. Your tag has a slower from zero to max line than mine. And the Max to median sloop looks steeper. Could you make pic with zoom 1.000 ?

asper · 2014-10-13 08:46:44

Is there any optional parameter you can add to the commands so I can make more tests without recompiling the source ?

iceman · 2014-10-13 09:18:43

Thanks! You got a better antenna than me, I notice. Really clean signal. And looks like the my ST-dectection doesn't work with your signal.

asper · 2014-10-13 09:33:29

Those are my tunes with and without the tag on the antenna:

pm3 --> hw tune
pm3 --> 
pm3 --> #db# Measuring antenna characteristics, please wait...                 
pm3 --> #db# Measuring complete, sending report back to host                 
pm3 -->           
pm3 --> # LF antenna: 17.59 V @   125.00 kHz          
pm3 --> # LF antenna: 32.49 V @   134.00 kHz          
pm3 --> # LF optimal: 32.49 V @   133.33 kHz          
pm3 --> # HF antenna:  0.00 V @    13.56 MHz          
pm3 --> # Your HF antenna is unusable.          
pm3 --> hw tune
pm3 --> 
pm3 --> #db# Measuring antenna characteristics, please wait...                 
pm3 --> #db# Measuring complete, sending report back to host                 
pm3 -->           
pm3 --> # LF antenna: 27.93 V @   125.00 kHz          
pm3 --> # LF antenna: 35.45 V @   134.00 kHz          
pm3 --> # LF optimal: 40.01 V @   129.03 kHz          
pm3 --> # HF antenna:  0.00 V @    13.56 MHz          
pm3 --> # Your HF antenna is unusable.

I sent you an email.

Last edited by asper (2014-10-13 09:34:58)

iceman · 2014-10-13 09:37:09

You got a really good antenna, much better then the ones I use.

However, it's not your signal that is wrong. It is my assumptions of the signal I used to detect the ST-marker. The ST looks like: 1-off-1-off (not 1-0-1-0) off is a dampening field. I assume that if 50% if the measured points is within the dampening field it is a "off" -state. ie 2 (in my dumps) This is what needs to be adjusted,

MilkThief · 2014-10-14 17:10:21

Please, help me in compiling on linux.
I receive this error:

[== Undefined ==]
loclass/fileutils.c: In function ‘fileExists’:
loclass/fileutils.c:14:15: error: storage size of ‘fileStat’ isn’t known
loclass/fileutils.c:15:2: warning: implicit declaration of function ‘_stat’ [-Wimplicit-function-declaration]
loclass/fileutils.c:14:15: warning: unused variable ‘fileStat’ [-Wunused-variable]
make[1]: *** [obj/loclass/fileutils.o] Error 1
make[1]: Leaving directory `/opt/pm3_iceman1001/client'
make: *** [client/all] Error 2

Any idea?

iceman · 2014-10-14 17:35:56

I think there is an "underscore" sign, "struct _stat fileStat"; around row 14..

For linux I think you need to remove that underscore.

MilkThief · 2014-10-14 17:42:57

Perfect! Error fixed. Thank you so much!
A new error is come out...

[== Undefined ==]
/usr/bin/ld: cannot find -lgdi32
collect2: error: ld returned 1 exit status
make[1]: *** [proxmark3] Error 1
make[1]: Leaving directory `/opt/pm3_iceman1001/client'
make: *** [client/all] Error 2

I can't find on google what is "lgdi32"...

iceman · 2014-10-14 18:16:20

if you look at my answer #40 in this thread, there is a makefile for linux people.. You might find it useful

MilkThief · 2014-10-14 23:44:06

iceman wrote:

if you look at my answer #40 in this thread

Ops... sorry... working during the night gives not always best performances.
make worked succesfully... Is it correct I have to place that makefile in the "client" directory?
I'm having a suspect response launching the "dump" command... then pm3 client crashes

[== Undefined ==]
pm3 --> lf t55xx dump
*** glibc detected *** ./proxmark3: munmap_chunk(): invalid pointer: 0xb5f54bbc ***
======= Backtrace: =========
/lib/i386-linux-gnu/i686/cmov/libc.so.6(+0x70f01)[0xb64f1f01]
/lib/i386-linux-gnu/i686/cmov/libc.so.6(+0x7217e)[0xb64f317e]
./proxmark3[0x8061a07]
./proxmark3[0x807dade]
======= Memory map: ========
08048000-080c1000 r-xp 00000000 08:01 1062808    /opt/pm3_iceman1001/client/proxmark3
080c1000-080c3000 rw-p 00078000 08:01 1062808    /opt/pm3_iceman1001/client/proxmark3
080c3000-092cd000 rw-p 00000000 00:00 0 
09399000-094ea000 rw-p 00000000 00:00 0          [heap]
b2a11000-b2a24000 r--p 00000000 08:01 955977     /usr/share/fonts/opentype/cantarell/Cantarell-Regular.otf
b2a24000-b2a2d000 r-xp 00000000 08:01 392579     /lib/i386-linux-

[CUT]

b7707000-b7708000 r--p 00000000 08:01 402688     /usr/lib/locale/sr_RS/LC_NUMERIC
b7708000-b7709000 r--p 00000000 08:01 437677     /usr/lib/locale/it_IT.utf8/LC_TIME
b7709000-b770a000 r--p 00000000 08:01 418454     /usr/lib/locale/sc_IT/LC_MONETARY
b770a000-b770b000 r--p 00000000 08:01 402885     /usr/lib/locale/ne_NP/LC_MESSAGES/SYS_LC_MESSAGES
b770b000-b770c000 r--p 00000000 08:01 402684     /usr/lib/locale/sr_RS/LC_PAPER
b770c000-b770d000 r--p 00000000 08:01 281030     /usr/lib/locale/cy_GB.utf8/LC_NAME
b770d000-b770e000 r--p 00000000 08:01 420577     /usr/lib/locale/gv_GB.utf8/LC_ADDRESS
b770e000-b770f000 r--p 00000000 08:01 281029     /usr/lib/locale/cy_GB.utf8/LC_TELEPHONE
b770f000-b7710000 r--p 00000000 08:01 402695     /usr/lib/locale/sr_RS/LC_MEASUREMENT
b7710000-b7717000 r--s 00000000 08:01 295075     /usr/lib/i386-linux-gnu/gconv/gconv-modules.cache
b7717000-b7718000 r--p 00000000 08:01 437763     /usr/lib/locale/en_GB.utf8/LC_IDENTIFICATION
b7718000-b771a000 rw-p 00000000 00:00 0 
b771a000-b771b000 r-xp 00000000 00:00 0          [vdso]
b771b000-b7737000 r-xp 00000000 08:01 395880     /lib/i386-linux-gnu/ld-2.13.so
b7737000-b7738000 r--p 0001b000 08:01 395880     /lib/i386-linux-gnu/ld-2.13.so
b7738000-b7739000 rw-p 0001c000 08:01 395880     /lib/i386-linux-gnu/ld-2.13.so
bf956000-bf977000 rw-p 00000000 00:00 0          [stack]
Aborted
root@mole:/opt/pm3_iceman1001/client#

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

You need to flash bootrom, fgpa, os before you use the client...

MilkThief · 2014-10-15 10:31:27

iceman wrote:

You need to flash bootrom, fgpa, os before you use the client...

I did it, with the elf files located inside the obj directory of both armsrc and bootrom.
If you are sure that error comes from there, I should suspect the flashing procedure did not work (exiting with "OK").
So I would try to flash it via jtag...

iceman · 2014-10-15 11:52:37

You should build all code with "make clean && make all" and flash it.

In that case all compiled code will work for your setup.

MilkThief · 2014-10-15 11:57:29

Ok, iceman, thank you for the support (I apologize for my lack of knowledge) .
Could you confirm that the linux makefile should be placed into the "client" directory instead the root of the project?

Proxmark3 community

Announcement

#51 2014-10-08 17:56:17

Re: [Resolved] broken: LF T55xx commands.

#52 2014-10-08 18:01:45

Re: [Resolved] broken: LF T55xx commands.

#53 2014-10-08 18:18:59

Re: [Resolved] broken: LF T55xx commands.

#54 2014-10-08 18:25:56

Re: [Resolved] broken: LF T55xx commands.

#55 2014-10-08 18:28:00

Re: [Resolved] broken: LF T55xx commands.

#56 2014-10-08 18:32:45

Re: [Resolved] broken: LF T55xx commands.

#57 2014-10-08 19:01:10

Re: [Resolved] broken: LF T55xx commands.

#58 2014-10-08 19:14:33

Re: [Resolved] broken: LF T55xx commands.

#59 2014-10-08 19:18:37

Re: [Resolved] broken: LF T55xx commands.

#60 2014-10-08 19:22:18

Re: [Resolved] broken: LF T55xx commands.

#61 2014-10-08 19:25:20

Re: [Resolved] broken: LF T55xx commands.

#62 2014-10-08 22:39:42

Re: [Resolved] broken: LF T55xx commands.

#63 2014-10-08 22:53:41

Re: [Resolved] broken: LF T55xx commands.

#64 2014-10-08 23:04:43

Re: [Resolved] broken: LF T55xx commands.

#65 2014-10-08 23:07:20

Re: [Resolved] broken: LF T55xx commands.

#66 2014-10-09 05:20:01

Re: [Resolved] broken: LF T55xx commands.

#67 2014-10-09 05:32:46

Re: [Resolved] broken: LF T55xx commands.

#68 2014-10-09 13:37:20

Re: [Resolved] broken: LF T55xx commands.

#69 2014-10-09 13:45:37

Re: [Resolved] broken: LF T55xx commands.

#70 2014-10-09 13:57:09

Re: [Resolved] broken: LF T55xx commands.

#71 2014-10-09 15:16:11

Re: [Resolved] broken: LF T55xx commands.

#72 2014-10-09 15:32:19

Re: [Resolved] broken: LF T55xx commands.

#73 2014-10-09 18:17:21

Re: [Resolved] broken: LF T55xx commands.

#74 2014-10-09 20:24:14

Re: [Resolved] broken: LF T55xx commands.

#75 2014-10-09 20:35:57

Re: [Resolved] broken: LF T55xx commands.

#76 2014-10-09 20:46:01

Re: [Resolved] broken: LF T55xx commands.

#77 2014-10-11 19:41:19

Re: [Resolved] broken: LF T55xx commands.

#78 2014-10-11 19:48:35

Re: [Resolved] broken: LF T55xx commands.

#79 2014-10-12 19:10:32

Re: [Resolved] broken: LF T55xx commands.

#80 2014-10-12 19:14:21

Re: [Resolved] broken: LF T55xx commands.

#81 2014-10-12 19:15:27

Re: [Resolved] broken: LF T55xx commands.

#82 2014-10-12 19:28:14

Re: [Resolved] broken: LF T55xx commands.

#83 2014-10-12 20:05:38

Re: [Resolved] broken: LF T55xx commands.

#84 2014-10-12 20:06:39

Re: [Resolved] broken: LF T55xx commands.

#85 2014-10-12 20:08:02

Re: [Resolved] broken: LF T55xx commands.

#86 2014-10-12 22:31:10

Re: [Resolved] broken: LF T55xx commands.

#87 2014-10-13 08:27:28

Re: [Resolved] broken: LF T55xx commands.

#88 2014-10-13 08:46:44

Re: [Resolved] broken: LF T55xx commands.

#89 2014-10-13 09:18:43

Re: [Resolved] broken: LF T55xx commands.