But the stuff we write ourselves is another matter completely.
If it explains how to avoid/circumvent a security system (or worst it does the "hack" automatically) I can ensure you that this is not legal at least in lot of countries. Also modchips are illegal in lot of countries; we can argue about this is correct or not but actually they are illegal so you can be prosecuted if you produce/resell them.
I substantially agree with the rest of your statement, in particular with your last sentence.
I am sorry holiman but rules are rules and not knowing (ignorance) or not listening (arbitrary exercise of the will) to them cannot be considered a freedom of speech. A simple example: if I discover a way to break into a security system and I arbitrarily decide to tell it to the community I can/must be legally prosecuted and this is correct because the diclosure must be "wise" that is to say I need to inform the security system administrator before releasing the "exploit" to the public; if he is not doing anything to solve the problem in a reasonable time I can inform the masses to protect them from the exploit. This is what I think is the best way to behave (and I think your one too). In this specific case the "exploit" was already widely known so i think that in this specific case you are not in the wrong way.
I agree with you holiman but before stating that what you are doing is not "shadowy or suspicious" you should consider that things that are legal in a country may be not in another. I suggest you to ask a lawyer before publishing stuff; this is a general consideration, not specific to this subject thread.
If you want to use your phone you need to buy a version supported by the phone. Actually there are 2 "versions" of those changeable UID chips (probably manufactured by different people):
- 1 kind of tag (the oldest ones), also known as "backdoored", that means they need some special commands (backdoor) to be sent before you will be able to freely write any block; this one is NOT USABLE with ANY mobile phone
- a second kind of tag (newer) in which you can send normal mifare commands to freely write any bloc; this one can be used with mobile phones compatible with NFC and mifare (not all mobile phones support mifare).
It is IMPOSSIBLE to say which one are sold on internet, you need to ask the seller and even if it say you "yes, it is the newer one" you will not be able to know if this is the true until you test it.
If you do not have a proxmark3 or other specific hardware+software you will not be able to write the UID on the 1st kind of tags.
Ok i understand now, thank you for the clarification.
My findings also work:
00 - 195225786 = 1011101000101110100010111010
01 - 195225787 = 1011101000101110100010111011
02 - 195225784 = 1011101000101110100010111000
03 - 195225785 = 1011101000101110100010111001
04 - 195225790 = 1011101000101110100010111110
05 - 195225791 = 1011101000101110100010111111
06 - 195225788 = 1011101000101110100010111100
07 - 195225789 = 1011101000101110100010111101
08 - 195225778 = 1011101000101110100010110010
09 - 195225779 = 1011101000101110100010110011
10 - 195225776 = 1011101000101110100010110000
11 - 195225777 = 1011101000101110100010110001
12 - 195225782 = 1011101000101110100010110110
13 - 195225783 = 1011101000101110100010110111
14 - 195225780 = 1011101000101110100010110100
15 - 195225781 = 1011101000101110100010110101
16 - 195225770 = 1011101000101110100010101010
17 - 195225771 = 1011101000101110100010101011
You can see that there is a sort of "base4" coding; consider last 6 bits only:
and so on with higher bits so in my opinion there is a base4 coding of the decimal short value.
00 - 195225786
01 - 195225787
02 - 195225784
03 - 195225785
04 - 195225790
05 - 195225791
06 - 195225788
07 - 195225789
08 - 195225778
09 - 195225779
10 - 195225776
11 - 195225777
12 - 195225782
13 - 195225783
14 - 195225780
15 - 195225781
16 - 195225770
17 - 195225771
I recently came accross a new algo (not exactly rfid related) and I think I find it out; on the left is the shown value, on the right the real written value (find the relation was not easy but I am almost sure it is correct); my "progression" seems to be correct, can someone explain it mathematically ? It should be "base4-something" but I am not able to implement it in excel...
I've been diving into sdr, as a pet project I am writing gnuradio-modules to interpret DCS (digitally coded squelch) from a handheld radio (they use DCS / CTCSS to have 'private' channels, by transmitting a sub-audible signal which signals that the squelch should be opened). It's nice to extract that, because then you can jump on any such transmission with the same dcs-key and join the party (I can use my computer to tell the kids it's dinner time).
Anyway, @asper wrote
- 8-bit quadrature samples (8-bit I and 8-bit Q): I don't know what it is, if someone can explain it I will be grateful !
Michael Ossman has been talking about that in videos 6 and 7. Particularly 7: http://greatscottgadgets.com/sdr/7/. I'm now starting to understand the benefits of using quadrature sampling, and can't help thinking about if that's something we could do in proxmark. We wouldn't have to start anew from scratch, I think, but maybe have a separate mode for quadrature sampling. It seems a lot simpler to accurately determine PSK / ASK / whatever modulation scheme using that method instead of our current implementations which are not very robust.
Is there anyone else interested in exploring this?
@asper, on another note, how did you do the mifare reading? I would roughly go through these things...
* set the baseband frequency to 12.56 MHZ
* Shift the signal 1 MHz so 13.56 in centered
* Low-pass filter the signal. Check the waterfall graph to see how much bandwitdh is needed.
* Decimate heavily, you definitely don't need 20MHz channel width.
* Have the antenna *really* close to the signal source. Or, try to use an inductive antenna (coil) - e.g. a proper pm3 antenna. I used a pm3-antenna on my oscilloscope when doing the iclass-debugging.
* Do a recording to a file-sink. Then do the experimentation on the recorded file using a file sink.
Thank you man for your answer. Unfortunately Gnuradio is still not working with HackRF under Windows so I cannot use it to manipulate the signal. I tested the ham it up converter but the signal is really worse (almost not visible) than without the ham it up converter so I think something is wrong with my ham it up or my antenna... also recordings done with SdrSharp are not so good so I am not able to "read" the waveform...
I will do more tests with your suggestions !
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.
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).
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
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.
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.
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.