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.
Hi all,
regarding my post where I asked help in identifying a tag, I identified the tag, but a problem came out. I said I tried all standards supported by the PM3 but I get no answers. The reason is not that tag was not supported, but its standard did not work on the PM3!
It is a SRIX4K. I identified it accidentally with a chineese reader similar to the SL500F (not the same). With it I can read every block.
My problem is I cannot read it with the proxmark3 (with both the PM3 I have, I tried with every antenna, original, dual band home made, single band home made). My PM3s are both working well and read a mifare from 5 cm but cannot read a srix4k.
The mifare I refer to is a credit card size, the srix4k has the same format.
It seems to be a RF power issue, but I'm no so expert and I cannot confirm it.
I launch the command a lot of times before getting something different than "#db# No response from tag"...
This is the message I receive:
proxmark3> hf 14b srix4kread
#db# No response from tag
proxmark3> hf 14b srix4kread
#db# No response from tag
proxmark3> hf 14b srix4kread
#db# Randomly generated UID from tag (+ 2 byte CRC): fe ff 0
#db# Now SELECT tag:
#db# Expected 3 bytes from tag, got 0
here is my hardware configuration.
Somebody can help me?
Thank you all!
Last edited by MilkThief (2014-11-21 22:54:40)
Offline
hw version?
Try to up/downgrade the firmware
Offline
the hw version is at the link i posted... :-)
btw, I copy here:
proxmark3> hw version
#db# Prox/RFID mark3 RFID instrument
#db# bootrom: /-suspect 2014-10-14 14:41:16
#db# os: /-suspect 2014-10-14 14:41:18
#db# HF FPGA image built on 2014/ 6/19 at 21:26: 2
uC: AT91SAM7S256 Rev B
Embedded Processor: ARM7TDMI
Nonvolatile Program Memory Size: 256K bytes
Second Nonvolatile Program Memory Size: None
Internal SRAM Size: 64K bytes
Architecture Identifier: AT91SAM7Sxx Series
Nonvolatile Program Memory Type: Embedded Flash Memory
proxmark3>
The sw is the latest, the hardware is the one from proxmark.com and xfpga. I'll try older versions. Thank you.
Offline
Hi, I tried
- r852
- r846
- r739
but I obtain always something like
proxmark3> hf 14b srix4kread
#db# No response from tag
proxmark3> hf 14b srix4kread
#db# No response from tag
proxmark3> hf 14b srix4kread
#db# Randomly generated UID from tag (+ 2 byte CRC): fe ff 44
#db# Now SELECT tag:
#db# Expected 3 bytes from tag, got 0
proxmark3> hf 14b srix4kread
#db# Randomly generated UID from tag (+ 2 byte CRC): fe 44 44
#db# Now SELECT tag:
#db# Expected 3 bytes from tag, got 1
Are you sure the srix4kread is working? Do you suggest other versions of the code?
Tahnk you!
Offline
Looking at this, I would recommend to try flashing r259.
Also you will need old building environment I think.
Have you tried sending raw commands to your tag?
Offline
Hi,
I'm back with the new FW and after a "pause" period, I'm coming back on the old issues.
I'm trying to use the new srix4k commands (read and write), but the command seems to be broken.
I've tried on both my PM3 with 3 cards that I can read with no problems on a commercial reader.
With the "hf tune" command I see that the tag is perfectly coupled because the nominal value without tag "#db# 13045 mV " falls to "#db# 5317 mV" with the tag placed on the antenna.
With worse values ("#db# 9525 mV") I can still work well with mifare cards.
Both PM3 seems to work perfectly and the 3 tags are working perfectly for sure.
[== HW VERSION ==]
#db# Prox/RFID mark3 RFID instrument
#db# bootrom: master/v2.0.0-rc2-42-g29a7954-suspect 2015-03-19 15:44:49
#db# os: master/v2.0.0-rc2-42-g29a7954-suspect 2015-03-19 15:44:50
#db# HF FPGA image built on 2015/03/09 at 08:41:42
uC: AT91SAM7S256 Rev B
Embedded Processor: ARM7TDMI
Nonvolatile Program Memory Size: 256K bytes
Second Nonvolatile Program Memory Size: None
Internal SRAM Size: 64K bytes
Architecture Identifier: AT91SAM7Sxx Series
Nonvolatile Program Memory Type: Embedded Flash Memory
Trying to work with srix4k I get
[== PM3 ==]
proxmark3> hf 14b srix4kread
#db# No response from tag
then I tried with raw command
[== PM3 ==]
proxmark3> hf 14b raw -c -p 0B
received 0 octets
Does somebody have an idea about that issue.
Do you suggest to me to put it on the issue tracker on github?
Thank you!
Offline
Did you see this: http://proxmark.org/forum/viewtopic.php?id=1624 about the antenna size? Sometimes distance makes a difference too. About 1/2 inch away works usually pretty well with most HF tags. (I do not have any of your specific tags tho.)
Offline
I'd exclude an antenna issue, because the mifare tags (same size, thickness and working frequency) work perfectly...
Last edited by MilkThief (2015-05-07 08:18:19)
Offline
The actual code seems to have problems with ISO14443B; when sending commands [ex. hf 14b raw -c -p 06 00] to tags the pm3 hangs (solid red led) and resets itself after some seconds (10-15 seconds). Can someone look into this ?
Anyway the srix antenna is smaller than the mifare you are referring to so you always need a small antenna.
Last edited by asper (2015-05-07 09:21:52)
Offline
The actual code seems to have problems with ISO14443B; when sending commands [ex. hf 14b raw -c -p 06 00] to tags the pm3 hangs (solid red led) and resets itself after some seconds (10-15 seconds). Can someone look into this ?
Yes, I confirm that.
Anyway the srix antenna is smaller than the mifare you are referring to so you always need a small antenna.
No, asper, it depends about what kind of tag you are speaking.
As I wrote here, my tags are standard ISO/IEC 7810 ID01: 85,60 × 53,98
If I use a torch for looking trough the tag, I see the same antenna of a mifare tag (obviously a tag placed inside an ISO/IEC 7810 ID01container).
Because the mifare tag works in a wonderful way with my HF antenna, and the voltage of the "hf tune" has a good fall (8V), the same as the mifare, I assume it is absolutely not an antenna problem but a fw problem.
Offline
Did the code ever function for either of you? Can you find a version it worked and when it then got broken?
Offline
Did the code ever function for either of you? Can you find a version it worked and when it then got broken?
It is a good question, I realize only now that my testing flow is ambiguos. I try to clarify it.
At the time I started this 3d, I had only one srix4k tag and I was not sure if it had some problem (i.e. low range).
Now I've bought 3 more new tags, blank, for testing.
- All my 4 srix4k tags (ISO/IEC 7810 ID01 format) are readable on the "black chinese" reader, but none on both my PM3.
- All my mifare tags (ISO/IEC 7810 ID01 format) are readable on "black chinese" and both my PM3.
I never tried my 3 new srix4k tags on a PM3 with old FW, but I tried the first srix4k on both PM3 with old firmware and never worked.
I need that someone to indicate a fw that is sure working on srix4k and know if that PM3 has the same HW configuration.
Or... that once the actual problem is fixed, someone confirm it is working and I'll try with a new sure working firmware...
Offline
If I well remember I did my previous working tests with srix using pm3-bin-0.0.7 compiled version so, to answer you marsh, yes, the srix functions were perfectly working.
@Milk: if you have a srix tag in card-size format you are correct but I don't think srix was ever released in such size, only sri512.
Last edited by asper (2015-05-07 15:08:09)
Offline
I have a sri4k.
I remeber to read it without problem in all old versions.
I have to try with new version.
Offline
If I well remember I did my previous working tests with srix using pm3-bin-0.0.7 compiled version so, to answer you marsh, yes, the srix functions were perfectly working.
@Milk: if you have a srix tag in card-size format you are correct but I don't think srix was ever released in such size, only sri512.
No, no, no, trust in me: I work well with that tags and the black chinese commercial reader. No doubt, they are 4k, bought direct from a producer as 4k... Btw I tried, of course, the 512 command, too.
Same results: nothing.
I'll try the 0.0.7, I hope it is on the Google repo.
@thefkboss, thank you in advance, let me know.
Offline
Github has the newest code but I would guess whatever broke the code hasn't been fixed yet as this is the first I've heard of it. It would significantly help if you could flash a few versions and see where it stopped working.
Offline
Ok, the first night I have free, I'll try to make some work...
Do you know where I can find old FWs?
Offline
http://www.proxmark.org/forum/viewtopic.php?id=1562 is a good place for compiled versions for testing. They don't go really far back but it probably is enough in this case.
Offline
http://www.proxmark.org/forum/viewtopic.php?id=1562 is a good place for compiled versions for testing.
Uhm... It seems to be windows binary... Unfortunately I have'nt a windows machine.
I'll try to find old src somewhere.
Offline
Github and googlecode each keep history of changes. Github for most recent
Last edited by marshmellow (2015-05-08 16:51:29)
Offline
I have tried with one's month ago version.
You were right, it doesn't work but is not only sri is all 14443b commands..
I have tried to read one 14443b card and one red light stay on, all time.
I have to try with new versions
Last edited by thefkboss (2015-05-08 21:35:31)
Offline
Try older.
Offline
Hi everyone!
I'm having exactly the same issues, and I was going to try some old versions... It would be nice trying to maintain a list of currently tested ones in this thread in order to avoid repetitions and find when it stopped working.
Offline
If I were you, I'd start testing from mid january 2015 versions, and go backwards...
Offline
I've been trying a lot of verisions from git without result:
22 jan 7242efa07c18a92c4139c26ad7009f2d8866fc89
16 jan b689b842b68c061340f18ff595ffdabf34bdc4f0
9 jan 473124be92f5108df63146ef8b6be2a1db30b87a
29 dec 6bfa18eab4750123d0e24090597b0d4c7bd58daf
1 jul 1604d0a2909a6ae1a5b615d280671d867c1028a4
And then started trying some older versions between 2012 and 2010 with the same luck, so I'm start thinking that maybe the problem it is mine... :\
I'm able to read the tags with ACR122U and libnfc.
PM3 seems to be coupling fine (according to "hf tune"), but when sending both "hf 14b raw -c 06 00" or "hf srix4kread" I don't get any response from tag.
What else coud I try?
Offline
There was a change, mid january 2015, where the 14B commands got involved. So releases of the firmware / client from before that time, should be fine. Or that is my guess.
Offline
I'm sure that a couple of firmwares before mid january 2015 were not working on both my PM3. I'm sure because when I've discovered the wonderful work made by my 3 new heroes, I said "wow, now we'll have the LF SIM working and the SRIX4K working", so it was the first test I made.
My PM3s are standard but 2 different producers (xfpga e proxmark.com), well working on other standards (i.e. 14A) but not with 14B.
I've tried to check at https://code.google.com/p/proxmark3/ but I can't understand where the old code is located...
Offline
I've tried to check at https://code.google.com/p/proxmark3/ but I can't understand where the old code is located...
you need a SVN client like TortoiseSVN (or linux equivalent) and connect to the link you have above to download and test old versions of code. (at least AFAIK as it worked for me)
but i do think the 14b issue dates back a while early 2014 maybe?
someday i'll get some time to test this a little. but if someone has time to isolate the commit that broke it it would greatly speed up the fix.
Offline
When the command 14b raw was implemented all was working fine.
Offline
As I said I've been building several versions from git until 2013 with the same problems (as i understand, it has the same sources than google code's svn). The process has been basically this:
[== Undefined ==]
git checkout <hash_commit>
git clean -fd
make clean
make
./flash # both bootloader and fullimage (or fpga+osimage for older versions)
./proxmark3 #test if 14b works
and so on for each revision... In some cases it is necessary to modify the "common/Makefile.common" by removing "-Werror" flag from CFLAGS.
For older versions (like r259), when changing "arm-elf" to "arm-none-eabi", I've started having errors due to offset overlaps. I'll try to figure out how to solve it tomorrow :\
Offline
When the command 14b raw was implemented all was working fine.
that would have been https://github.com/Proxmark/proxmark3/c … 080f0d8fd9 on 2013/09/01
my guess is maybe one of the FPGA adjustments or possibly a shared component with 14a that got modified when fixing the 14a sniff.
early 2014? needs testing.
Offline
I suspect the BigBuf change,..
Offline
Added a new issue on github.
Offline
The "14b raw" seems to up and running again. If you are eager, go and download @pwpiwi's branch.
ISSUE #103 https://github.com/Proxmark/proxmark3/issues/103
I will test myself when I get home tonight.
Offline
I can confirm RAW commands are working:
proxmark3> hf 14b raw -c -p 06 00
received 3 octets
B8 BB C9
CRC OK
proxmark3>
proxmark3> hf 14b raw -c -p 0E b8
received 3 octets
B8 BB C9
CRC OK
proxmark3>
proxmark3> hf 14b raw -c -p 0B
received 10 octets
F9 ** ** ** ** ** ** ** ** E6
CRC OK
proxmark3>
Also "hf 14b srix4kread" works (tested with a 512-only tag):
proxmark3> hf 14b srix4kread
proxmark3>
proxmark3> #db# Randomly generated UID from tag (+ 2 byte CRC): 4a 26 1d
proxmark3> #db# Now SELECT tag:
proxmark3> #db# Tag UID (64 bits): d0021824 78917429
proxmark3> #db# Tag memory dump, block 0 to 127
proxmark3> #db# Address=0, Contents=ffffffff, CRC=470f
proxmark3> #db# Address=1, Contents=ffffffff, CRC=470f
proxmark3> #db# Address=2, Contents=ffffffff, CRC=470f
proxmark3> #db# Address=3, Contents=ffffffff, CRC=470f
proxmark3> #db# Address=4, Contents=ffffffff, CRC=470f
proxmark3> #db# Address=5, Contents=1b808c01, CRC=b46b
proxmark3> #db# Address=6, Contents=ffffffff, CRC=470f
proxmark3> #db# Address=7, Contents=3420001, CRC=28a7
proxmark3> #db# Address=8, Contents=5a5e0a09, CRC=ffc2
proxmark3> #db# Address=9, Contents=15, CRC=2851
proxmark3> #db# Address=a, Contents=46bff00, CRC=f4fd
proxmark3> #db# Address=b, Contents=605c5e, CRC=9fc4
proxmark3> #db# Address=c, Contents=0, CRC=defc
proxmark3> #db# Address=d, Contents=c9c8d901, CRC=d3ac
proxmark3> #db# Address=e, Contents=0, CRC=defc
proxmark3> #db# Address=f, Contents=0, CRC=defc
proxmark3> #db# Expected 6 bytes from tag, got less... rk3> #db# Address=ff, Contents=feffffff, CRC=ce1e
It works correctly with a 4k tag.
This is the 512 specific command:
proxmark3> hf 14b sri512read
proxmark3>
proxmark3> #db# No response from tag
proxmark3> hf 14b sri512read
proxmark3>
proxmark3> #db# Randomly generated UID from tag (+ 2 byte CRC): 39 3a 5c
proxmark3> #db# Now SELECT tag:
proxmark3> #db# Tag UID (64 bits): d0021824 78917429
proxmark3> #db# Tag memory dump, block 0 to 15
proxmark3> #db# Address=0, Contents=ffffffff, CRC=470f
proxmark3> #db# Address=1, Contents=ffffffff, CRC=470f
proxmark3> #db# Address=2, Contents=ffffffff, CRC=470f
proxmark3> #db# Address=3, Contents=ffffffff, CRC=470f
proxmark3> #db# Address=4, Contents=ffffffff, CRC=470f
proxmark3> #db# Address=5, Contents=1b808c01, CRC=b46b
proxmark3> #db# Address=6, Contents=ffffffff, CRC=470f
proxmark3> #db# Address=7, Contents=3420001, CRC=28a7
proxmark3> #db# Address=8, Contents=5a5e0a09, CRC=ffc2
proxmark3> #db# Address=9, Contents=15, CRC=2851
proxmark3> #db# Address=a, Contents=46bff00, CRC=f4fd
proxmark3> #db# Address=b, Contents=605c5e, CRC=9fc4
proxmark3> #db# Address=c, Contents=0, CRC=defc
proxmark3> #db# Address=d, Contents=c9c8d901, CRC=d3ac
proxmark3> #db# Address=e, Contents=0, CRC=defc
proxmark3> #db# Address=f, Contents=0, CRC=defc
proxmark3> #db# System area block (0xff):
proxmark3> #db# Address=ff, Contents=ffff7fff, CRC=ab03
BUG?: When using srix4k read with a 512 tag the client seems to hangs.
NOTES:
- "Randomly generated UID from tag"; this sentence is not correct because the UID is fixed; only the byte answered to the initiate command is randomly generated and it is called Chip_ID (not UID) and it is the byte referred in that sentence
- Block FF, containing System Area Block can be decoded in an hypotetical ISO14443B info as follows (drectly from the official datasheets):
OTP_Lock_Reg
SRIX4K:
The 8 bits, b31 to b24, of the System Area (block address FF) are used as OTP_Lock_Reg in the SRIX4K:
They control the Write access to the 9 EEPROM blocks with addresses 7 to 15 as follows:
– When b24 is at 0, blocks 7 and 8 are Write-protected
– When b25 is at 0, block 9 is Write-protected
– When b26 is at 0, block 10 is Write-protected
– When b27 is at 0, block 11 is Write-protected
– When b28 is at 0, block 12 is Write-protected
– When b29 is at 0, block 13 is Write-protected
– When b30 is at 0, block 14 is Write-protected
– When b31 is at 0, block 15 is Write-protected.
The OTP_Lock_Reg bits cannot be erased. Once Write-protected, EEPROM blocks behave
like ROM blocks and cannot be unprotected.
SRIX512:
The 16 bits, b31 to b16, of the System area (block address 255) are used as OTP_Lock_Reg bits in the SRI512.
They control the write access to the 16 blocks 0 to 15 as follows:
● When b16 is at 0, block 0 is write-protected
● When b17 is at 0, block 1 is write-protected
● When b18 is at 0, block 2 is write-protected
● When b19 is at 0, block 3 is write-protected
● When b20 is at 0, block 4 is write-protected
● When b21 is at 0, block 5 is write-protected
● When b22 is at 0, block 6 is write-protected
● When b23 is at 0, block 7 is write-protected
● When b24 is at 0, block 8 is write-protected
● When b25 is at 0, block 9 is write-protected
● When b26 is at 0, block 10 is write-protected
● When b27 is at 0, block 11 is write-protected
● When b28 is at 0, block 12 is write-protected
● When b29 is at 0, block 13 is write-protected
● When b30 is at 0, block 14 is write-protected
● When b31 is at 0, block 15 is write-protected.
The OTP_Lock_Reg bits cannot be erased. Once write-protected, the blocks behave like
ROM blocks and cannot be unprotected. After any modification of the OTP_Lock_Reg bits, it
is necessary to send a Select command with a valid Chip_ID to the SRI512 in order to load
the block write protection into the logic.
Last edited by asper (2015-06-03 15:18:29)
Offline
Are there any other tests to do with ISO14443B ?
Last edited by asper (2015-06-03 15:52:20)
Offline
Confirmed too, I could read SRIX4k tags with the last pwpiwi's pull request.
Very nice work, thanks
Offline
Yep, thx to piwi. when piwi gets some time we will continue fixing the snoop and Sim cmds...
Offline
@marshmellow, are you working on a "INFO" command for 14B?
Offline
I'm waiting to get piwi s final changes before I play with the ui. I might get it started if I get bored...
I have been gathering info and reading a few data sheets.
Offline
I'm bored.
Offline
Things are proceeding ! Piwi and marshmellow are working on it !
Offline
it was a reference to @marshmellows earlier post, not that I think @marshmellow and @piwi is doing a slow progress.
Offline