Research, development and trades concerning the powerful Proxmark3 device.
Remember; sharing is caring. Bring something back to the community.
"Learn the tools of the trade the hard way." +Fravia
You are not logged in.
Time changes and with it the technology
Proxmark3 @ discord
Users of this forum, please be aware that information stored on this site is not private.
Pages: 1
While doing some experiments and tests I faced some questions that I thought here I might get a good answer for them.
I`ve been trying to read some access control tags which I have, from (or compatible with) Aptus products, operating at 125kHz.
http://www.aptus.se/sv/site/aptusse/Produkter/?groupId=744484&productId=746075 #1
http://www.aptus.se/sv/site/aptusse/Produkter/?groupId=744484&productId=746078 #2 (closest match to my tag)
Apparently both are compatible with EM standard which proxmark should be able to handle. This is according to reader brand, and also very limited information about the tag I could find on manufacturer, mentioning it being "EM" compatible. I have a 3rd aptus (EM based) tag as well, but since things are straight forward with it and I can read and decode it with standard proxmark commands, I`ll skip it.
Since it was not clear which exact EM model they are based on, I tried identification based on analysing read samples via plot, and testing different modulations. I`ve attached both data samples for the record.
In case of #1 , things seems to be normal. By reading samples and ask 1 demodulation, I can decode tag ID with manchester demod command in (latest svn) proxmark. Having the information from proxmark WiKi I narrowed down to below bit streams. The wiki referred column parity and stop bits for given EM4102 sample, and I tried to follow the same practice in my case as below:
[HEADER] 0111100000000000000010010010011010001111010010001100100
[HEADER]
0111 1
0000 0
0000 0
0000 0
1001 0
0100 1
1010 0
0111 1
0100 1
0001 1
0010 0 * parity
which is:
0x700094A741
Please correct me if I`ve done it wrong, based on sample 'aptus1'.
In older firmwares, every step had to be done manually but it seems that latest version takes care of automatic detection of clock and modulation, and one can directly demodulate data from samples.
Now the tag #2 which supposed to be similar, things are totally different.
Assuming it also is based on EM, similar demodulation should work. but it does not. It can not be demodulated with Manchester, and trying with FSK demodulation results seems wrong too. My guess is that proxmark stars decoding from wrong place, which means every time I get different response. Trying autocorr command I also see that the the yellow marker is adjusted couple of bits away from the beginning. Does the it skip the header?
I`m kinda stuck with this sample. Looking at the plot, I doubt that if it`s one of EM models with password protection, since a pattern is clearly repeated, making me think of insecure ID only tags. Note that none of tags have any info printed on them, so I can not be sure if I`m decoding correctly. Also there is no snoop option for LF EM tags, so I cannot monitor a legitimate communication between tag and reader, or can I ??
Any comments on this one is appreciated If you are able to analyze it, I`d be thankful if you mention different steps or approaches you use. Maybe after figuring out where I`m mistaking, we could also include it in the firmware.
Tag samples : https://www.dropbox.com/sh/5kaxhohhf5f1c9k/AABxw62D4AJKBj5qVtUrk6_Oa
Offline
ID: 108a0aede
Apply Enio's patch from (topic post: http://www.proxmark.org/forum/viewtopic.php?pid=10569)
If you don't know how to patch (on linux/OSX), copy the patch into a text file, into the same directory as the client folder '/client'
call the file 'dirthreshold-patch' then execute
patch -p0 < dirthreshold-patch
Command sequence:
proxmark3> data load aptus2-unknown.txt
proxmark3> data dirthreshold 50 -20
Applying Up Threshold: 50, Down Threshold: -20
proxmark3> data plot
proxmark3> data askdemod 1
proxmark3> data mandemod
Last edited by midnitesnake (2014-06-09 18:40:37)
Offline
Thank you for your reply!
I applied the patch and that indeed solved the problem.
Knowing where the problem is, can you please explain how you define given threshold numbers based on graph?looking at plot, I see that non of them are close to pick of the graph and for -20 you are cutting it off too early..? In general I`d like to learn how this thershold limitation works during analysis here.
thanks again
Offline
see below
Last edited by midnitesnake (2014-06-09 21:07:21)
Offline
I used this command on OSX/Linux:
head -n 20 aptus2-unknown.txt
and noted the largest and smallest numbers and rounded to the nearest 10 (50 & -20).
Offline
Hi,
could you have a look on :
http://www.proxmark.org/forum/viewtopic.php?id=2037
I cannot identify the tag. I guess it's askmod, but mandemod fail.
I even tried to simulate directly with
lf read
data samples 40000
lf sim
But the result gives nothing.
Offline
Have you tried the patch midnitesnake referred to?
also try both 125kHZ and 134kHZ reading (lf read h)
Offline
Little late, but the new "data askmandemod" handles poor reads and weak tags much better than the older commands.
You can also just do a "lf search"
Offline
Pages: 1