[solved] Unknown LF card: relation between written number and content.

hexa3e8 · 2016-07-02 19:37:34

Getting more and more familiar with rfid and the proxmark3 and thought lets get one step further now with lf.
I have 2 identical looking thin lf-cards from a alarm systemcompagny modhex (hlhbhdhrhvifidhvhu) where you can use the rfid cards to switch on/off you home alarm.
on both cards is written a number like 1410-00-0010-1630. strange thing is that both cards give a different result with lf search u. one card says Nedap found and the other says checking for unknown tags. At least one card give a probably easy result. So I take it from there.

Checking for known tags:

NEDAP ID Found - Card: 20092 - Raw: ffbfa73e4c0003ffffbfa73e4c0003ff
BIN: 1111111110111111101001110011111001001100000000000000001111111111

Is there somewhere in that code a relation with the number written (1410-00-etc).
I have read all the pages on the forum about Nedap (5 results in search) but I cannot seem to figure out how to use this data to clone it on the TX5777
I read that the encryption and checksums are not available yet but I thought I could use the lf nedap sim command. I tried that but I need the 24 bit value.

Usage: lf nedap sim Card-Number
Options :
<Card Number> : 24-bit value card number
Sample : lf nedap sim 112233

Can someone point me into a direction where to start and where to look for that 24bit value? Or explain a bit what that raw data means. I assume it is data from block 0,1,2?!? Hopefully It is not to much of a silly question.
Maybe this info is useful to update the proxmark firmware so that's why I posted the real data of this card.
thanks so far for reading this post.

some extra info:
pm3 --> lf read
LF Sampling config:
q divisor: 95
b bps: 8
d decimation: 1
a averaging: 1
t trigger threshold: 0
Done, saved 40000 out of 40000 seen samples at 8 bits/sample
buffer samples: bd b7 b3 ae a9 a5 a2 9e ...

Last edited by hexa3e8 (2016-07-22 21:33:19)

hexa3e8 · 2016-07-03 10:14:50

I see in this post http://www.proxmark.org/forum/viewtopic.php?id=2364&p=2
that the first 64 bits are the badgenumber in which the first half is encrypted and the second half (32 bits) are the unencrypted version of the batch number, So can I conclude that the Raw data ( ffbfa73e4c0003ffffbfa73e4c0003ff ) is the unique badge number?

iceman · 2016-07-03 12:08:33

You have the cardnumber 20092,

However, I'm not sure if the "lf nedap sim" works. But give it a try and report back!

iceman · 2016-07-03 12:09:37

If you have access to a valid reader, then you could gather the different output from the reader when simulating uids

hexa3e8 · 2016-07-05 22:28:19

I know a person who installs systems like that so I have access to a test system and and a valid reader,without setting off an alarm system during testing (lol)Those cards are programmed (probably the UID is enabled) to do some actions with the system. I am not sure yet. It could also be possible that some data (user code,which you normally type in) is written inside a block. I will ask the installator to show me who he "programms"/connects the cards to the system. I am not able to test right away since I am depending on the agenda of the installator.
So stay tuned for some updates to come. (hopefully some succesful)

I will figure out how to gather the different output from the reader. I haven't used the sniffing methode yet (listen between the card and reader with the proxmark) but I guess it's probably on the forum. I will search for that. (-edit-> snoop function)
Iceman, thanks for stearing me in the right direction.

Last edited by hexa3e8 (2016-07-05 23:03:10)

suixo · 2016-07-06 15:57:21

@iceman: the code given by your code doesn't correspond to the Nedap XS tag IDs I had on my side... I didn't have time to properly investigate and report a bug / submit a PR but I'll try to do it rather quickly.

@hexa3e8: the Nedap XS encoding is 128 bits long, in your case you have two exactly identical blocks of 64 bits which is quite surprising. How do you know this tag is a Nedap one? In case this is not a Nedap XS one I cannot help you (and I guess the code written by iceman in the fork doesn't neither).

If I feed it into my analyzer, I get the following tag ID:
Tag ID:
A 00111001 39
B 11111110 FE
C 11111111 FF
=> 39 FE FF

If this is written somewhere on the tag (it should be written in the back at the bottom left, just near the "Nedap XS" mark) then you are good

Last edited by suixo (2016-07-06 15:59:32)

suixo · 2016-07-06 16:02:59

After re-reading your message, it looks like the cards may not be from Nedap. Can you try to dump the result given by "lf search u" for both cards, and look for a repetitive pattern (a 64-bit-long pattern, actually) ?

Once you managed to get the pattern sent by the tag, and you have the encoding used (Manchester? ASK Biphase inverted?), you can give it to the T5577 for emulation

iceman · 2016-07-06 18:18:37

Well, no, the nedap code isn't fully mapped yet as mentioned in the forum before.
What I've see is that NEDAP XS has 128bits,
first 64bits is encrypted, where the used encryption is not known.
second half of 64bits, is unencrypted, but with Wiegand. Thats where the suggested cardnumber comes from, a 16bit number.

The detection code, looks for 128bits, preamble and parity check on first64bits.
if doesnt look for the checksum or parity check for second64bits, so many false positives is still possible.

Whats most lacking is the understanding of encryption/scrambleing of first64bits, and the parity calcs.

If you have a working detection code, do please share and I'll put it in good use.

iceman · 2016-07-06 18:28:04

But in short, yes the code is unfinished.

hexa3e8 · 2016-07-06 18:42:40

Thanks suixo for your input. I have no idea what sort of cards are being used. I know for sure thats LF at 125kHz. thats written on the website. The only thing written on the card is the number mentioned above (card1: 1410-00-0010-1630)(card2: 1410-00-0011-3949). the tag id => 39 FE FF remains a question for me. even with a hexa-decimal converter I cannot link 39 FE FF tot the 1401-... number.

card 1:

pm3 --> lf search u
Reading 30000 bytes from device memory
          
Data fetched          
Samples @ 8 bits/smpl, decimation 1:1           
NOTE: some demods output possible binary
  if it finds something that looks like a tag          
False Positives ARE possible
          

Checking for known tags:
          
NEDAP ID Found - Card: 20092 - Raw: ffbfa73e4c0003ffffbfa73e4c0003ff          
BIN: 1111111110111111101001110011111001001100000000000000001111111111          

Valid NEDAP ID Found!          
pm3 -->

card 2 has a different result:

pm3 --> lf search u
Reading 30000 bytes from device memory
          
Data fetched          
Samples @ 8 bits/smpl, decimation 1:1           
NOTE: some demods output possible binary
  if it finds something that looks like a tag          
False Positives ARE possible
          
Checking for known tags:
No Known Tags Found!
          
Checking for Unknown tags:
          
Possible Auto Correlation of 1 repeating samples          

Using Clock:64, Invert:0, Bits Found:466          
ASK/Manchester - Clock: 64 - Decoded bitstream:          
7111111111111111
1111100001110100
0110001110110011
1010101010101010
1000000000000000
0000011110001011
1001110001001100
0101010101010101
0111111111111111
1111100001110100
0110001110110011
1010101010101010
1000000000000000
0000011110001011
1001110001001100
0101010101010101
0111111111111111
1111100001110100
0110001110110011
1010101010101010
1000000000000000
0000011110001011
1001110001001100
0101010101010101
0111111111111111
1111100001110100
0110001110110011
1010101010101010
1000000000000000
0          

Unknown ASK Modulated and Manchester encoded Tag Found!          

if it does not look right it could instead be ASK/Biphase - try 'data rawdemod ab'

To be honest, I am not that experienced yet to know what it all means. But as you can see the second card which has the exact looks, spits out totally different data and because the first one says quite clear NEDAP I take it from there.Maybe the decoded bitstream is helpful for you?

hexa3e8 · 2016-07-06 18:50:31

I will try If I can get more of these cards to read and see if they also say NEDAP.

iceman · 2016-07-06 19:35:37

You wouldn't mind making a table with written data, uid, raw bytes

I can make the detection a bit better, I also noticed that the cardnumber as it is now is useless. The UID should be 3bytes.
Its not implemented.

iceman · 2016-07-06 20:51:55

Making a clone out of @hexa3e8 raw data, using:

lf t55xx wr b 1 d ffbfa73e
lf t55xx wr b 2 d 4c0003ff
lf t55xx wr b 3 d ffbfa73e
lf t55xx wr b 4 d 4c0003ff
lf t55xx wr b 0 d 00170082

Modifying the Nedap printing:

pm3 --> lf se
Reading 30000 bytes from device memory

Data fetched
Samples @ 8 bits/smpl, decimation 1:1
NOTE: some demods output possible binary
  if it finds something that looks like a tag
False Positives ARE possible


Checking for known tags:

NEDAP ID Found - Raw: ffbfa73e4c0003ffffbfa73e4c0003ff
Cardnum: 20092 ,  UID: FF FE 39
BIN:
1111111110111111101001110011111001001100000000000000001111111111
1111111110111111101001110011111001001100000000000000001111111111

Valid NEDAP ID Found!

Gives @suixo UID bytes of 0xFF 0xFE 0x39, so the raw bytes is correct.

iceman · 2016-07-06 21:25:38

And with some details to the unencrypted bytes.

NEDAP ID Found - Raw: ffbfa73e4c0003ffffbfa73e4c0003ff
 - UID: 39FEFF
 - I: 80E4
 - Checksum2 FF00

Where according to other users, I is identical

iceman · 2016-07-07 09:21:18

After some testing of some users has posted here on the forum, the "I" is not identical.

I pushed these fixes to my fork. Next step would be fixing the rest of the "lf nedap" commands.

hexa3e8 · 2016-07-07 19:44:22

First of all, I really,really appreciate the time and effort you all put into this. A big thumbs up!
I flashed the proxmark3 and your modifications are nice. Even the second card which didn't report a NEDAP card works fine now with just some remarks.

1st 64bit parity check failed: 1|0
2st 64bit parity check failed: 1|0
NEDAP ID Found - Raw: ffbb1ad9580003ffffbb1ad9580003ff
- UID: D6ECFF
- i: 0095
- Checksum2 FF00

Valid NEDAP ID Found!

This weekend I can finally use the entire test-system. I will try the tx55xx clone with the test-system. So far the proxmark3 reads the same info as the original card so that looks promising.(of course)

I think I have found out that the number 1410-00-0011-3949 printed on the card means nothing. Unfortunately. It is just a number like a serial number. I saw more of those ' 14 digits format' on the motherboard of the system and on the motherboard of the reader itself. So that’s why I think it is just some sort of serial number of a device. So unfortunately nothing to copy with the naked eye. So officially I fear that the title of this topic has been solved but I would like to continue to put all the further testing in this post so we have all the NEDAP card info for this alarm-system here.Of course not a problem if you disagree.

suixo · 2016-07-08 10:21:09

Well done iceman!

hexa3e8 · 2016-07-10 08:27:41

Great news, It seems that in my previous post my assumption was wrong.Let me explain.
Making a clone out of the raw data as prescribed by iceman worked great.the cloned card produced the exact same result as the original. But to my surprise I saw the number 1410-00-0010-1630 in my screen after using the card.
I guess that the reader somehow decodes the raw data into that number. of course cloning a card with the raw data works fine. it doesn't matter how the reader exactly calculates that number but it would be fun if we knew how.
the reader is a usb reader and it is possible to connect it directly to windows pc. In a dos box appears the exact same number 1410-... after placing the card/cloned card. Thats why I think the reader does the calculations.

So I tried to clone the other card. I have the raw data, so I was able to write to block 1 - 4 on the t55xx card.Then I got a bit frustrated. How does that magic mind of iceman work? how do I calculated block 0. I tried the same code as the first card but that didn't work. ( lf t55xx wr b 0 d 00170082 ).
So here the blocks.
Card 1: ok    Card2: ?
ffbfa73e    ffbb1ad9
4c0003ff    580003ff
ffbfa73e    ffbb1ad9
4c0003ff    580003ff
---------------------------
00170082    ?
How to calculate the questionmark? I tried figuring it out from the t55xx info chart but it remains a puzzle for me.
I hope you can explain that.

Second I tried to simulate with different cardnumbers/UID (and hopelessly even raw data )but the reader did not react.
Anything else I can do to test or to make it work?
(So the topic continues)

Last edited by hexa3e8 (2016-07-10 10:01:51)

iceman · 2016-07-10 09:18:50

You don't need to change the block 0 anymore, you read on the forum about t55x7 cards and how they work. Google "datasheet atmel t55x7" and you will have a deeper understanding what block0 does and how to calc it.
There are some spreadsheet and also program which calcs the needed config block for different setups.

However back to the NEDAP XS,
I'm still stuggeling with the paritybit calc, out of those samples I've available I get unconsistent results.

1410-00-0010-1630

1410- sounds like definition of what type of number-encoding is used if its hardcoded in the dos-box.

00-0010-1630 - this part

hexa3e8 · 2016-07-10 09:50:55

Thanks,I found the pdf with the datasheet. still some difficult terms but now I can puzzle.
Can I perform some tests to help? I have two cards now, maybe there is a different command to use to obtain more info from the cards. The raw data is on this forumpost,but if you need other data from the card maybe I can perform some tests.

marshmellow · 2016-07-12 16:15:46

i don't think hexa3e8 cards are nedap. or at least not the same nedap as the previous posters.

hexa3e8 has 64 bits repeating not 128. and it doesn't match the format definitions.

(the clone will work because it is the right RAW read...)

hexa3e8 · 2016-07-12 20:21:48

@marshmellow, you could be right. I have one card which I can duplicate because of the Raw data (and the help from you guys). but I am not successful in duplicating the other with the presented raw data. (tried different t55xx cards) Maybe, somehow the raw data isn't correct for that card.Is that possible? Also when I perform a: 'lf search u' I get an error. But as iceman said:the code is still unfinished and there are parity problems. I have searched the internet where I could buy such cards,but the the information is really limited, only 125khz and that every card had a unique code.So no info there.

this is the trouble maker:

pm3 --> lf search u
Reading 30000 bytes from device memory
Data fetched          
Samples @ 8 bits/smpl, decimation 1:1           
NOTE: some demods output possible binary
  if it finds something that looks like a tag          
False Positives ARE possible
 Checking for known tags:
 1st 64bit parity check failed:  1|0           
2st 64bit parity check failed:  1|0           
NEDAP ID Found - Raw: ffbb1ad9580003ffffbb1ad9580003ff          
 - UID: D6ECFF          
 - i: 0095          
 - Checksum2 FF00          

Valid NEDAP ID Found!

any idea's what to do next? get some more cards to analyse?

iceman · 2016-07-12 22:03:18

Yup, as usual @marshmellow is right. The repeating pattern of 64bits, is not nedap xs.
Another user from this forum has the details on the checksum and paritiybits. If you are good at decompiling firmware you could find the needed details Since I don't have this info, I can't verify stuff. The amount of available raw bytes/data read for valid tags is limited.
I think I have 4 samples to play with, so yes, the code is not verified or correct. I would love to get the stuff correct but as of now we all don't have enough info to play with to make this good.

I can just plea for the community to share more, if you all want the proxmark3 to become up-to-date and the best god damn rfid tool there is.

For you, who want to share, use ghostbin or pastebin if you feel you want to share but are reluctant.

jump · 2016-07-12 22:43:15

I can confirm that this doesn't match a Nedap encoding.

BTW Nedap is not always 128 bits long. Sometimes they transmit only 64 bits which then corresponds to the "encrypted" (encoded would better match what they actually do) format only.

hexa3e8 · 2016-07-13 21:42:23

update: The Raw data presented by the proxmark3 for my cards is totally correct. I can use the raw data correctly to clone BOTH the cards.Whether it is a NEDAP card or not, it is now easily clonable. I found out that when writing to the t55xx chip sometimes a block doesn't write correctly or not at all. of course after analysing the new raw data presented by the clone it was quite clear that there was the problem. (a newbie control mistake). But that's called learning by doing.... I also tried for the first time the sim function: 'lf se u' and then 'lf sim' and that worked fine, the proxmark could make the reader respond with the exact same output as the card.
I then tried to use the Raw data to do a simulation but I haven't figured that out yet. I would like to save the raw data and then use it to perform a simulation, so I do not need the card anymore.
I tried 'lf sim d ffbb1ad9580003ffffbb1ad9580003ff' and all the other simfsk/simpsk/simask but I do not know how to do that. I guess I have to give more settings with the command, while using the 'lf se' command all those settings are already loaded into the buffer.

Any tips to get that working?

Next I wrote down the difference in binary between the 2 card numbers presented by the reader and changed some different bytes to see if I could make a new card but without success. the reader wouldn't respond.
1111 1111 1011 1111 1010 0111 0011 1110 0100 1100 0000 0000 0000 0011 1111 1111
1111 1111 1011 1011 0001 1010 1101 1001 0101 1000 0000 0000 0000 0011 1111 1111
x x xx xx x xxx xxx x x (unsuccessful to align correctly here)

x = difference.
A fun project but so far after changing many bytes (one at a time at different positions) it remains a secret for me. But cloning works so big thumbs up for the proxmark3 and the iceman fork and this community!

Last edited by hexa3e8 (2016-07-13 22:03:47)

marshmellow · 2016-07-14 16:15:10

@hexa3e8 can you post a trace for one or both of your tags? i'd like to identify your tag. (trace = `data save xxxx.xxx`)

also the simask command is what you would need, and you will need to know the encoding (ask or biphase or biphase inverted) and you will need to know the clock (data rate) and specify them in the command along with the data.

(or save a trace and load the trace later do a `lf search 1 u` then `lf sim`)

it might be best though if you start a new thread as your cards are not NEDAP related.

Last edited by marshmellow (2016-07-14 16:15:43)

hexa3e8 · 2016-07-15 19:32:53

@marshmellow, Thanks for the tips and advice, I will start a new topic for the unknown lf-tags.

see topic:
http://www.proxmark.org/forum/viewtopic.php?id=3387

Last edited by hexa3e8 (2016-07-15 19:46:07)

hexa3e8 · 2016-07-17 14:43:13

The lf seach and then the lf sim works perfectly. but that sounds the easy way, I would like to do it the more profi way like with simask.(mentioned above)

lf simask c 128 i r d ffbfa73e4c0003ffffbfa73e4c0003ff
I have tried I think every combination now but cannot get it to work,the reader stays silent.frustrating
(c64,c32, with i, without i, r (even m and b) and al variations.)
So unfortunately I am guessing the clockspeed probably is not correct, what else to test, can anyone give me a hint how to find out about the clockspeed (hopefully not a too dumb question...) or another trick to find out the right command? It would be fun to have a result after a few hours of testing and reading many posts.

Usage: lf simask [c <clock>] i b|m|r s [d <raw hex to sim>]
Options:
h This help
c <clock> Manually set clock - can autodetect if using DemodBuffer
i invert data
b sim ask/biphase
m sim ask/manchester - Default
r sim ask/raw
s add t55xx Sequence Terminator gap - default: no gaps (only manchester)
d <hexdata> Data to sim as hex - omit to sim from DemodBuffer

iceman · 2016-07-17 15:13:41

I don't think your clock is 128.
and wasn't your tag "ask/biphase"

hexa3e8 · 2016-07-17 15:41:54

@iceman, you rock! thanks. I tested ask/biphase and tried the command below.
lf simask c 64 b d ffbb1ad9580003ffffbb1ad9580003ff

no more frustration both raw data from the cards are now well simulated.(once it works it seems always so easy...) This way I can try to test some more raw data manipulations much easier to get the reader to hopefully respond with a number (see: title of this topic).
@iceman, @marshmellow and others Thanks for all of your patience and a little piece of your knowledge.

Last edited by hexa3e8 (2016-07-17 15:43:52)

marshmellow · 2016-07-18 18:54:40

btw you can cut the data in half as the tag automatically repeats. so ffbb1ad9580003ff would be sufficient.

(just adjust the t55xx config block for 2 mem blocks instead of 4 for cloning)

marshmellow · 2016-07-18 19:08:56

to summarize what is known for this JA-190J tag:

ASK/Biphase, RF/64, 64 bit repeating pattern

card1: 1410-00-0010-1630 (printed) | ffbfa73e4c0003ff (raw) (proper start position unknown)
card2: 1410-00-0011-3949 (printed) | ffbb1ad9580003ff (raw) (proper start position unknown)

entire printed card number is read by valid reader from the raw data somehow
how is unknown.

it is not manchester encoding but it could be inverted biphase aka differential biphase aka di-phase

suggested tests:
run `lf t55xx resetread` on both tags and compare the plots or post traces to attempt to ascertain exact starting point of the repeating binary.
simulate against the reader to see if single bit changes work and what combinations don't or how it changes the read number.
get/identify more valid raw to printed ID samples for more analysis.
attempt `lf t55xx detect` to see if the original tag is a t55xx and if it is unlocked

Last edited by marshmellow (2016-07-20 14:45:11)

hexa3e8 · 2016-07-19 19:20:30

results lf t55xx resetread : for the card with 1630 http://pastebin.com/Zuvkydfp
for the card with 3949 http://pastebin.com/L7sfTjHS
Hopefully this works.

pm3 --> lf t55xx detect
Could not detect modulation automatically. Try setting it manually with 'lf t55xx config'

I will try to get more valid printed id's. I know some people who have those cards (all in the name of science. )

>simulate against the reader to see if single bit changes work and what combinations don't or how it changes the read number.

I tried a lot of combinations with bit changes so far without any result... unbelievable. I assumed faster result since only few bits were different between the two cards. but after changing so far the reader didn't respond.maybe a checksum somewhere. but now since I can sim the cards the speed increases. If I have an update I will post it.
So I think now that going for more cards gives better insight in the bits.

marshmellow · 2016-07-20 14:44:05

the correct start position demodulation for the JA-190J tag is:

Differential Biphase / di-phase (inverted biphase)
1410-00-0010-1630
FFFF00001016306C  (note the card number 101630) and the checksum 6C

1410-00-0011-3949
FFFF0000113949A9 (note the card number 113949) and the checksum A9

the preamble is FFFF0?

Thanks for sharing the traces.
next step is to identify the checksum

Last edited by marshmellow (2016-07-20 14:45:35)

marshmellow · 2016-07-20 14:58:06

checksum is most likely a crc8 as follows:
width=8 poly=0xa3 init=0xb0 refin=true refout=true xorout=0x00 check=0x28 name=(none)

iceman · 2016-07-20 15:59:26

reveng -w 8 -s 113949a9 1016306c ?

--
reveng -c -w 8 -p 0xa3 -i 0xb0 -l 101630 == 0x6C
reveng -c -w 8 -p 0xa3 -i 0xb0 -l 113949 == 0xA9

marshmellow · 2016-07-20 21:34:12

that is how i got the info yes

iceman · 2016-07-21 09:38:31

One of these days, I'm going to need to make a documentation in how to analys unknown LF and the figuring out of checksum etc.

PLötz et al wrote a paper on CRC reversal in which I read that you can validate a CRC very easy.
Data + crc == 0x00. Verfiy the above data is below.

ie:
reveng -c -w 8 -p 0xa3 -i 0xb0 -l 1016306c == 0x00
reveng -c -w 8 -p 0xa3 -i 0xb0 -l 113949a9 == 0x00

--
Now back to OP's tests.

Lets try to validate this CRC, with some new data on OP's reader.

Generate testdata by changing 113949 with one bit into 123949.
this gives a CRC of 15.

OP, would you mind simulating:
FFFF000012394915

marshmellow · 2016-07-21 11:38:22

Only one note: He needs to simulate di-phase instead of biphase with that hex.

iceman · 2016-07-21 15:45:52

indeed, and we should have this conversation in the other thread OP started...

marshmellow · 2016-07-21 16:18:09

lol, yeah about that... i guess i didn't realize THIS thread was started by hexa3e8. i should have just asked him to re-title this and remove the nedap from it instead of starting a new thread... sorry. my bad. i have to look closer when reading from my phone...

iceman · 2016-07-21 16:29:46

well, OP could still do all of that.

But I'm more curious about the testing of the crc than forum formalities. Lets hope OP can try it out soon.

hexa3e8 · 2016-07-22 12:18:22

wow, great progress you two made!! I was/am out for 2 days,I can test it this evening when I am home. Really mindblowing about the 'tricks' you perform with CRC. Fortenately you guys know how to operate with that. Can't wait till this evening to test.
(what or who is OP?) me?

Last edited by hexa3e8 (2016-07-22 12:19:05)

marshmellow · 2016-07-22 13:07:22

I do like the 'lf t5 resetread' cmd

And yes op = original poster = you

hexa3e8 · 2016-07-22 19:10:16

So ready to test, reader in place, test original card: check, test sim with original data: check, test posted data: brain-error.

I am having trouble finding out how to di-phase a simulation. I found 2 posts with the word di-phase. but I didn't get wiser.
So I tried a lot of commands, with lf sim and with lf simask, checked the config. I see only bi-phase to sim. I am afraid it is probably something simple but I am out of brain-options.
Is di-phase already implemented to use? I see only (invert data,ask/biphase/manchester/raw)

some example no result:
> lf simask c 64 i d FFFF000012394915
> lf simask c 64 b d FFFF000012394915
> lf simask c 64 b d FFFF000012394915FFFF000012394915

result: original raw data = ok
> lf simask c 64 b d ffbb1ad9580003ff
now want result to be

another thing:I don't think I have the rights to change the title of the topic, so feel free to change it.

Last edited by hexa3e8 (2016-07-22 20:37:20)

marshmellow · 2016-07-22 21:00:12

Di-phase is inverted biphase. (Inverted binary) (so use the i to invert before the b for biphase)

To edit the title just edit the first post

Last edited by marshmellow (2016-07-22 21:16:13)

iceman · 2016-07-22 21:30:35

Just like Marshmellow said,

lf simask c 64 i b d FFFF000012394915

hexa3e8 · 2016-07-22 21:48:46

thanks for clearing that out!
unfortunately no response or reaction from reader.
pm3 --> lf simask c 64 i b d FFFF000012394915

reader responds ok with the other data,so the command is correct.
pm3 --> lf simask c 64 i b d FFFF00001016306c
pm3 --> lf simask c 64 i b d FFFF0000113949a9
I tried to install /use reveng to calculate another bitchange to test it directly. maybe there is a maximum for some number.(cards start only with 10 or 11, so 12 does not work?) can you calculate for example 9 or a bit before that.
I guess: reveng -c -w 8 -p 0xa3 -i 0xb0 -l 093949?? == 0x00 or maybe change the last 49 to 50?
If I have some more data I can directly test it. I cannot produce it.

marshmellow · 2016-07-22 21:52:02

You could test all 256 possible checksums.

hexa3e8 · 2016-07-22 21:56:06

almost finished

Proxmark3 community

Announcement

#1 2016-07-02 19:37:34

[solved] Unknown LF card: relation between written number and content.

#2 2016-07-03 10:14:50

Re: [solved] Unknown LF card: relation between written number and content.

#3 2016-07-03 12:08:33

Re: [solved] Unknown LF card: relation between written number and content.

#4 2016-07-03 12:09:37

Re: [solved] Unknown LF card: relation between written number and content.

#5 2016-07-05 22:28:19

Re: [solved] Unknown LF card: relation between written number and content.

#6 2016-07-06 15:57:21

Re: [solved] Unknown LF card: relation between written number and content.

#7 2016-07-06 16:02:59

Re: [solved] Unknown LF card: relation between written number and content.

#8 2016-07-06 18:18:37

Re: [solved] Unknown LF card: relation between written number and content.

#9 2016-07-06 18:28:04

Re: [solved] Unknown LF card: relation between written number and content.

#10 2016-07-06 18:42:40

Re: [solved] Unknown LF card: relation between written number and content.

#11 2016-07-06 18:50:31

Re: [solved] Unknown LF card: relation between written number and content.

#12 2016-07-06 19:35:37

Re: [solved] Unknown LF card: relation between written number and content.

#13 2016-07-06 20:51:55

Re: [solved] Unknown LF card: relation between written number and content.

#14 2016-07-06 21:25:38

Re: [solved] Unknown LF card: relation between written number and content.

#15 2016-07-07 09:21:18

Re: [solved] Unknown LF card: relation between written number and content.

#16 2016-07-07 19:44:22

Re: [solved] Unknown LF card: relation between written number and content.

#17 2016-07-08 10:21:09

Re: [solved] Unknown LF card: relation between written number and content.

#18 2016-07-10 08:27:41

Re: [solved] Unknown LF card: relation between written number and content.

#19 2016-07-10 09:18:50

Re: [solved] Unknown LF card: relation between written number and content.

#20 2016-07-10 09:50:55

Re: [solved] Unknown LF card: relation between written number and content.

#21 2016-07-12 16:15:46

Re: [solved] Unknown LF card: relation between written number and content.

#22 2016-07-12 20:21:48

Re: [solved] Unknown LF card: relation between written number and content.

#23 2016-07-12 22:03:18

Re: [solved] Unknown LF card: relation between written number and content.

#24 2016-07-12 22:43:15

Re: [solved] Unknown LF card: relation between written number and content.

#25 2016-07-13 21:42:23

Re: [solved] Unknown LF card: relation between written number and content.

#26 2016-07-14 16:15:10

Re: [solved] Unknown LF card: relation between written number and content.

#27 2016-07-15 19:32:53

Re: [solved] Unknown LF card: relation between written number and content.

#28 2016-07-17 14:43:13

Re: [solved] Unknown LF card: relation between written number and content.

#29 2016-07-17 15:13:41

Re: [solved] Unknown LF card: relation between written number and content.

#30 2016-07-17 15:41:54

Re: [solved] Unknown LF card: relation between written number and content.

#31 2016-07-18 18:54:40

Re: [solved] Unknown LF card: relation between written number and content.

#32 2016-07-18 19:08:56

Re: [solved] Unknown LF card: relation between written number and content.

#33 2016-07-19 19:20:30

Re: [solved] Unknown LF card: relation between written number and content.

#34 2016-07-20 14:44:05

Re: [solved] Unknown LF card: relation between written number and content.

#35 2016-07-20 14:58:06

Re: [solved] Unknown LF card: relation between written number and content.

#36 2016-07-20 15:59:26

Re: [solved] Unknown LF card: relation between written number and content.

#37 2016-07-20 21:34:12

Re: [solved] Unknown LF card: relation between written number and content.

#38 2016-07-21 09:38:31

Re: [solved] Unknown LF card: relation between written number and content.

#39 2016-07-21 11:38:22

Re: [solved] Unknown LF card: relation between written number and content.