[solved] an indala clone or a lf search issue in version 3.0.1?

ntk · 2017-06-24 04:33:38

I have only few types of simple tags, I ran test with lf sea and feel it was somehow not 100% reliable there. Some in the past known tag is now sometimes reported as unknown ...

I am calling on the forum, could you run lf sea against your tag. Pls run 3 times consecutive and place the result here. V3.0.1 is powerful but also a monster version, help in testing and feed back, would make sure that all the new changes and ideas are 100% tested and working and not just on an edge

AWID 26 bit

 

proxmark3> lf awid clone 26 118
proxmark3> lf sea 
AWID Found - BitLength: 26, FC: 26, Card: 118 - Wiegand: 23400ec, Raw: 011db1d8112dd11111111111          
Valid AWID ID Found!

INDALA
work when run search on tag which has been created with older SW

proxmark3> lf search  u
NOTE: some demods output possible binary
  if it finds something that looks like a tag          
False Positives ARE possible
Checking for known tags:
BitLen: 64          
Indala UID=0000000000000000
0000000000000110
0010000101000011
1011111001010111
 (62143be57)          
Valid Indala ID Found!          
Valid T55xx Chip Found
Try lf t55xx ... commands
proxmark3>

After using lf indala clone 62143be57
reported:
proxmark3> lf indala clone 62143be57
Cloning 64bit tag with UID 62143be57
proxmark3>
proxmark3> #db# DONE!

but lf search failed to detected the just cloned tag

proxmark3> lf indala clone 62143be57
Cloning 64bit tag with UID 62143be57          
proxmark3> 
proxmark3> #db# DONE!          
proxmark3> lf search  u
demodoffset 0, clk 0          
NOTE: some demods output possible binary
  if it finds something that looks like a tag          
False Positives ARE possible
Checking for known tags:
DEBUG: Clock detect error          
demodoffset 126, clk 16          
Too many errors found, clk: 16, invert: 0, numbits: 438, errCnt: 64          
DEBUG: Error - EM4305: PSK1 Demod failed, ans: 0          
DEBUG: Bitlen from grphbuff: 6000          
DEBUG ASK WEAK: startIdx 66          
DEBUG: Too many errors found, errors:741, bits:742, clock:8          
DEBUG: Error - EM4305: ASK/Manchester Demod failed, ans: 0          
DEBUG ASK WEAK: startIdx 1          
DEBUG: no data or error found 748, clock: 8          
DEBUG: Error - EM4305: ASK/biphase Demod failed, ans: 0          
DEBUG ASK WEAK: startIdx 1          
DEBUG: no data or error found 748, clock: 8          
DEBUG: Error - EM4305: ASK/biphase Demod failed, ans: 0          
#db# Uknown frame length: 2          
DEBUG: Error - COTAG too many errors: 130          
proxmark3>

I don't have real reader to test if the clone in v3.0.1 is working

I am calling on the forum, could you run lf clone and sea against your tag, testing when you are lucky one with a real reader. Pls run 3 times consecutive and place the result here. V3.0.1 is powerful but also a monster version, help in testing and feed back, your share would make sure that all the new changes and ideas are 100% tested and working and not just on an edge

Last edited by ntk (2017-07-01 09:13:20)

marshmellow · 2017-06-24 05:18:38

Have you repeated this test yourself, and with different t5577s? Looks like the write cmds just didn't take on your card, which isn't that unusual. Depending on antenna, environment, and tag size it can easily take two or more write cmd attempts before the chip is correctly written.

ntk · 2017-06-24 09:54:58

i did repeat many times this failure is consistent, Marshmellow.

and the chip is not blocked or too small for antenna size, I tried with other write commands fdx, awid, hid, t55xx write antenna and chip is ok, I did repeat when test success too, for confirmation, fine in other case we could write but not in indala clone. And strange is: did report back write is OK!
So even the check in the command is dubious now? I don't have reader hence so I am not sure where can the fault be

marshmellow · 2017-06-24 13:28:15

There is no check in the cmd. It merely says it is done trying to write.

marshmellow · 2017-06-24 16:08:45

And you could dump the t5577 blocks and see what was written...

ntk · 2017-06-24 16:56:11

In the past, last year to early this year, I recall lf search sometimes also can not find indala tag and display UID = all 0s. but 3 from 5 times it then found the tag and displayed the UID we tried to write to it. There was a thread about taht issue to. But it never complaints about seeing perhaps only noise, no signal. when read indala tag etc.

The tag can be written after indala experiment, emulating other tag type, and lf search can immediately find those types too, so it is not the tags or antenna fault. Is it correct Marshmellow?

I have tried 5 different tags, each used to be reserved for one type of tag: one for HID, one for AWID, one for FDP, viking, gproxxII, I used all of them now for indala. all of them behaves similare, when come to write indala data, as if ... PM3 would send write sequence from the code level, but does HW tweak the voltage & send signal out over the communication interface at all? is there any ACK in that level that that has happenedd.

If I find out the version from last year where I was sure indala writing and lf search on indata tag has functioned would it be helpful? what about iceman's fork? his version was since this year very advanced it still scared me nowadays

Last edited by ntk (2017-06-25 03:30:34)

ntk · 2017-06-25 11:12:35

Iceman and Marshmellow, have you found any indication why indala is so instabile in V3.3.01? I was surprised that in indala clone writing is with no check that the tag has been written, usually in t55xx only when mixing the firmware and ACK warning already flags up. definitely we should enhance the writing process in indala with this check feature.

I have some small progress: I have found a version where indala clone/dem/altdem work very stable it was a version from end of April 2017. each time I send lf sea indala is found, that is definitively better and different then the V3.0.1 version.

I am not a GIT expert or programmer, but I like to know why and where that fault has plagued us more than 2 weeks already.

Could you help me
1/ establish which version this sw is, which performs clearly better in for indala
2/ trace the fault or source of instability in the PM3 SW, now that we have this version to compare with. I guess something with "indala"

note, when testing I run in minGW environement only so instability is not in GUI, HW, tag position etc no changed

Last edited by ntk (2017-06-25 11:38:38)

iceman · 2017-06-25 12:25:15

Sorry, no time to fiddle with indala. I don't have any real indala tags to test either.

As @marshmellow42 said before, all clone commands that clones to a T55X7 tag doesn't have any validation if the write actually went well.

ntk · 2017-06-25 13:40:46

Me too iceman, no real reader to test against. but I still feel attracted to this fault, to know this one fault's reason, because it is interesting on the theory level: What has changed on the one hand it escapes the eyes of professionals (clone procedure appears to work) but on the other hand the tiny injection strong enough to make that indala so instabile.

Usually a fault stretched slowly over several months and hard to trace back, when so many different factors modified themselves too; but here very lucky in the period of 2, 3 month this instability comes out so stark that between 2 SW suites you can compare what has affected so much, and everything else is still "quite" constant from build environment, PC, tag, PM3, PC environment HW changes etc a detective would dreams everydays something like that.

definitely this indala stabile, I did 10xwriting, and then doing a lf sea for recheck all 10 passed, after the first lf sea passed I ran lf sea 9 more times and all 9 also passed. So no coincident.

This version is not one of your recent development SW fork because I don;t see the file iceman.txt in there. it is dated 28/04/17

Last edited by ntk (2017-06-25 15:17:31)

ntk · 2017-06-25 14:32:55

in source code lfops.c

void CopyIndala64toT55x7(uint32_t hi, uint32_t lo) {
	//Program the 2 data blocks for supplied 64bit UID
	// and the Config for Indala 64 format (RF/32;PSK1 with RF/2;Maxblock=2)
	uint32_t data[] = { T55x7_BITRATE_RF_32 | T55x7_MODULATION_PSK1 | (2 << T55x7_MAXBLOCK_SHIFT), hi, lo};
	//TODO add selection of chip for Q5 or T55x7
	// data[0] = (((32-2)/2)<<T5555_BITRATE_SHIFT) | T5555_MODULATION_PSK1 | 2 << T5555_MAXBLOCK_SHIFT;

	WriteT55xx(data, 0, 3);
	//Alternative config for Indala (Extended mode;RF/32;PSK1 with RF/2;Maxblock=2;Inverse data)
	//	T5567WriteBlock(0x603E1042,0);
	DbpString("DONE!");
}
// Clone Indala 224-bit tag by UID to T55x7
void CopyIndala224toT55x7(uint32_t uid1, uint32_t uid2, uint32_t uid3, uint32_t uid4, uint32_t uid5, uint32_t uid6, uint32_t uid7) {
	//Program the 7 data blocks for supplied 224bit UID
	uint32_t data[] = {0, uid1, uid2, uid3, uid4, uid5, uid6, uid7};
	// and the block 0 for Indala224 format	
	//Config for Indala (RF/32;PSK1 with RF/2;Maxblock=7)
	data[0] = T55x7_BITRATE_RF_32 | T55x7_MODULATION_PSK1 | (7 << T55x7_MAXBLOCK_SHIFT);
	//TODO add selection of chip for Q5 or T55x7
	// data[0] = (((32-2)>>1)<<T5555_BITRATE_SHIFT) | T5555_MODULATION_PSK1 | 7 << T5555_MAXBLOCK_SHIFT;
	WriteT55xx(data, 0, 8);
	//Alternative config for Indala (Extended mode;RF/32;PSK1 with RF/2;Maxblock=7;Inverse data)
	//	T5567WriteBlock(0x603E10E2,0);
	DbpString("DONE!");

Do I understand correctly that this coding parts try to build this following datas
0x603E1042
0x603E10E2.

I hope not. Those are clearly wrong!!!!

how to see the realtime data of block 0?
Dbprintf("Config : %???", data[0]);???

or

DbpString("DONE witth following data !", data[0]..data [3]);???

Last edited by ntk (2017-06-25 14:39:04)

ntk · 2017-06-25 14:53:07

Is it correct that when write to t55x7, after sending write command sequence to lower layer I can use this to check lower layer responses to make sure the write is really applied /done to a tag

                SendCommand(&c);
		if (!WaitForResponseTimeout(CMD_ACK, &resp, 1000)){
			PrintAndLog("Error occurred, device did not respond during write operation.");
			return -1;
                     }
                return 0;

what is against argument?

iceman · 2017-06-25 14:53:32

no, those lines are commented out and as the comment states they would be alternative config blocks to test with.

These configblocks as seen in the code are used.
T55x7_BITRATE_RF_32 | T55x7_MODULATION_PSK1 | (2 << T55x7_MAXBLOCK_SHIFT)
T55x7_BITRATE_RF_32 | T55x7_MODULATION_PSK1 | (7 << T55x7_MAXBLOCK_SHIFT)

2block for short UID, 7blocks for long UID

The armside code is not the error, I belive @marshmellow tried to implement the indala with the new PSK demodulation functions. They might be the cause, look at clientside code instead.

marshmellow · 2017-06-25 19:58:03

i have used the indala demod commands dozens of times recently and can guarantee they work fine on most equipment. though there are many factors that can create problems demoding psk.

but i won't contribute to the guessing and invalid assumptions that are common in this thread. as there is nothing here to go on.

a trace would be helpful...

and as far as the block 0 configs mentioned you said:

I hope not. Those are clearly wrong!!!!

actually they work quite well... but no they are not in use as iceman pointed out.

ntk · 2017-07-01 08:52:59

I have found out what is wrong

The fault was not caused by any SW iceman or main repo pre or V3.0.1 it depends on the tag and type of clone you do to get consistent result.

I was caught out by using a tag where due to the form of some of the fobs I have, perhaps dense or thicker plastic moulding on one side, so the distance from PM3 antenna to tag's coil effectively seems to be different.

So when I clone ASK/FSK type on that tag/fob I can lay it both sides, clone result shows no different behaviour (if work on the real reader is a different matter, what I mean is I clone in theory, and I do read/search on the PM3 and it see the type of clone)

But Indala modulation is PSK1 it is very sensitive, depends on size of tags of antenna. Here in PSK experiment I see the result is consistent good on one side and intermittently failed on the "must be thicker plastic" side

I can reproduce the result, intermittent failure is tag dependent and happens only in PSK modulation, so I thnk we can close the thread now.

ntk · 2017-07-01 09:11:11

marshmellow wrote:

and as far as the block 0 configs mentioned you said:
I hope not. Those are clearly wrong!!!!
actually they work quite well... but no they are not in use as iceman pointed out.

normally I regard highly your opinion, but here I can't accept without any explanation.
regarding these 2 configuration, I have no access to many real readers so I can not test, but in theory I think it better needs clarity. In my opinion it does not conform to the ATmel t55xx data sheet

I have opened a new thread for discussion about configuration of block 0 could you help me understand the configuration block

//Alternative config for Indala (Extended mode;RF/32;PSK1 with RF/2;Maxblock=2;Inverse data)
// T5567WriteBlock(0x603E1042,0);
and

//Alternative config for Indala (Extended mode;RF/32;PSK1 with RF/2;Maxblock=7;Inverse data)
// T5567WriteBlock(0x603E10E2,0);

Last edited by ntk (2017-07-01 09:11:39)

yongmuh · 2017-10-10 16:58:58

I have one indala tag that my pm3 cannot read it (lf search) properly.

First I tried it on home PC and the card cannot be recognized at all. Then I tried it at workplace whereby the card can be read intermittently only, returning several different UIDs (includes those all 0).

I had flashed different firmware (V2.00, V2.50, V3.01) but the same problem persists. Please advise, thanks!

Last edited by yongmuh (2017-10-10 17:13:05)

Dot.Com · 2017-10-10 17:54:42

lf read,
data samples 40000,
lf indala altdemod

This works for the latest firmware from Github.

marshmellow · 2017-10-10 18:05:05

Post a trace file and we can debug.
The standard lf indala demod or lf search works well with the most current github code for all indala types I've seen.

yongmuh · 2017-10-11 11:52:33

These are the trace files:

Thank you.

yongmuh · 2017-10-12 17:58:31

Several indala cards also returned inconsistent UID. I am using the cheaper "Proxmark3 Easy" rather than "Proxmark3 Kit", wonder whether this would affect the performance.

Dot.Com · 2017-10-12 19:06:28

There are only 2 types I have seen.

-Long string (224)
Just use lf se u will work.

-And the normal one.
if not, use this.
lf read
data samples 40000
lf indala altdemod

Yes. If the voltage is not high enough for the LF antenna, you might have some problems with it. Should be intermittent issues though.

And depends on which cheaper Proxmark3 easy you are getting. If you are getting a fake pm3, the voltage is not stable.
Too many fakes out there.

yongmuh · 2017-10-13 07:26:56

My LF antenna voltage ranges 31.21-35.48V, it should be pretty good.

It prompts me "Valid Indala ID Found" (UID=all 0) despite I put no card on top of it, is this normal?

I bought my PM3 from China which costs ~45 USD. I wonder whether this could be hardware failure.

yongmuh · 2017-10-14 03:39:23

Prox/RFID mark3 RFID instrument
bootrom: master/v3.0.1-94-g77aecdd-suspect 2017-10-06 13:03:33
os: master/v3.0.1-94-g77aecdd-suspect 2017-10-06 13:03:38
LF FPGA image built for 2s30vq100 on 2015/03/06 at 07:38:04
HF FPGA image built for 2s30vq100 on 2017/07/13 at 08:44:13

uC: AT91SAM7S256 Rev D
Embedded Processor: ARM7TDMI
Nonvolatile Program Memory Size: 256K bytes. Used: 198479 bytes (76%). Free: 63665 bytes (24%).
Second Nonvolatile Program Memory Size: None
Internal SRAM Size: 64K bytes
Architecture Identifier: AT91SAM7Sxx Series
Nonvolatile Program Memory Type: Embedded Flash Memory
proxmark3> hw tune

Measuring antenna characteristics, please wait.......
# LF antenna: 34.65 V @ 125.00 kHz
# LF antenna: 31.90 V @ 134.00 kHz
# LF optimal: 35.75 V @ 127.66 kHz
# HF antenna: 28.96 V @ 13.56 MHz
Displaying LF tuning graph. Divisor 89 is 134khz, 95 is 125khz.

Indala UID was inconsistent each time. Any solution?

marshmellow · 2017-10-15 02:38:15

your traces are garbage. you are only picking up noise. no signal. so either you are sitting next to a large electro magnet or your tag or antenna are not operating at the same frequency.

yongmuh · 2017-10-15 12:11:56

It appears to have similar result with different indala tags, so this would imply hardware problem, right?

marshmellow · 2017-10-16 01:11:37

How do you know it is an indala tag? Is it marked or are you going by the false positive results you show above?

yongmuh · 2017-10-17 15:11:42

@marshmellow
I assumed it based on the false positive result. Do you have any idea what is this card?

Image:

Video: Here

Thank you very much!!

EDIT:
I was told that this is UHF 6C card, which is not supported by PM3

Last edited by yongmuh (2017-10-19 11:17:34)

Proxmark3 community

Announcement

#1 2017-06-24 04:33:38

[solved] an indala clone or a lf search issue in version 3.0.1?

#2 2017-06-24 05:18:38

Re: [solved] an indala clone or a lf search issue in version 3.0.1?

#3 2017-06-24 09:54:58

Re: [solved] an indala clone or a lf search issue in version 3.0.1?

#4 2017-06-24 13:28:15

Re: [solved] an indala clone or a lf search issue in version 3.0.1?

#5 2017-06-24 16:08:45

Re: [solved] an indala clone or a lf search issue in version 3.0.1?

#6 2017-06-24 16:56:11

Re: [solved] an indala clone or a lf search issue in version 3.0.1?

#7 2017-06-25 11:12:35

Re: [solved] an indala clone or a lf search issue in version 3.0.1?

#8 2017-06-25 12:25:15

Re: [solved] an indala clone or a lf search issue in version 3.0.1?

#9 2017-06-25 13:40:46

Re: [solved] an indala clone or a lf search issue in version 3.0.1?

#10 2017-06-25 14:32:55

Re: [solved] an indala clone or a lf search issue in version 3.0.1?

#11 2017-06-25 14:53:07

Re: [solved] an indala clone or a lf search issue in version 3.0.1?

#12 2017-06-25 14:53:32

Re: [solved] an indala clone or a lf search issue in version 3.0.1?

#13 2017-06-25 19:58:03

Re: [solved] an indala clone or a lf search issue in version 3.0.1?

#14 2017-07-01 08:52:59

Re: [solved] an indala clone or a lf search issue in version 3.0.1?

#15 2017-07-01 09:11:11

Re: [solved] an indala clone or a lf search issue in version 3.0.1?

#16 2017-10-10 16:58:58

Re: [solved] an indala clone or a lf search issue in version 3.0.1?

#17 2017-10-10 17:54:42

Re: [solved] an indala clone or a lf search issue in version 3.0.1?

#18 2017-10-10 18:05:05

Re: [solved] an indala clone or a lf search issue in version 3.0.1?

#19 2017-10-11 11:52:33

Re: [solved] an indala clone or a lf search issue in version 3.0.1?

#20 2017-10-12 17:58:31

Re: [solved] an indala clone or a lf search issue in version 3.0.1?

#21 2017-10-12 19:06:28

Re: [solved] an indala clone or a lf search issue in version 3.0.1?

#22 2017-10-13 07:26:56

Re: [solved] an indala clone or a lf search issue in version 3.0.1?

#23 2017-10-14 03:39:23

Re: [solved] an indala clone or a lf search issue in version 3.0.1?

#24 2017-10-15 02:38:15

Re: [solved] an indala clone or a lf search issue in version 3.0.1?

#25 2017-10-15 12:11:56

Re: [solved] an indala clone or a lf search issue in version 3.0.1?

#26 2017-10-16 01:11:37

Re: [solved] an indala clone or a lf search issue in version 3.0.1?

#27 2017-10-17 15:11:42

Re: [solved] an indala clone or a lf search issue in version 3.0.1?

Board footer