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.
Do with all my playing with the NTAG213's, I figured I would ask if any work is going on getting the PM3 to SIM a NTAG213 or any working on adding it to the eload option????
Offline
if you look into the "Hf 14a sim" I think there is some ntag stuff there.
the eload is down to how to load a eml (ascii) formatted file. DUmps for UL/NTAG is 4bytes with, the Mifare classic uses 16bytes width..
Offline
Iceman-
Yeah the sim has some NTAG but just the 215 from what I remember seeing, no 213. I also tried the sim command for the 215 and it throws an error (The UID was just dummy test UID) :
pm3 --> hf 14a sim t 7 u 12121212
Emulating ISO/IEC 14443 type A tag with 4 byte UID (12121212)
Press pm3-button to abort simulation
#db# Error: unkown tagtype (7)
I figured the eload would need some mods, it tried to load a tag from a 213 but of course its looking for more data (as you stated). In your fork you have it, but it does say : (hf mfu) eload <not implemented> Load from file emulator dump
Was hoping the 213 might get added to the sim?
Offline
if it sends unknown tagtype then you didn't use my fullimage...
The "hf mf eload" works instead in my fork. @marshmellow who did the eload changes never got around to impl a seperate eload for mfu.
If you can compile the fork, the code to change is not that hard since the ntag215 is already inplace...
Offline
Iceman -
Ah good point ... noted and thanks - I'm going to try that later tonight
My hope was to toy with a tag and try to figure out some of the values on Lego, but of course I need a way to make a token to try the values on ....
Offline
Iceman -
Ok, I did some code changes and compiled - I can eload a NTAG213 tag now, but of course I cant hf mf sim t xxxxxx.
I did edit the code to add a type 8 (I called it just NTAG213), has the PACK added.
Looked at the c code for the firmware to accept the option of a tag 8, but I'm a little over my head at first look for that change ... I'm going to keep looking at it tonight - Anything you can point out to help with this part?
Oh yeah. and of course, you were correct, I had your previous fullimage.bin so the passing of tag type 7 wasn't there - That's all good now.....
Offline
If you don't know how to add a new type, just hijack the tagtype 7,.. its easier for you.
Offline
Yep - that was my thought last night with some small changes that I *think* were needed - going to try to run it today .....
As always, I appreciate the direction - 5 days with the proxmark and I'm feeling pretty comfortable - BUT that's just due to what you, marshmallow, and other have created ... Just riding your coat tails to get some knowledge from all of you.
Offline
standing on shoulders of giants helps a lot.
I think the 213 changes needs to take account of get_version, pack and the read/increase counter commands. The rest should work as is.
Dump a correct version (you have that in your info command) and change in the armsrc
//reverse/bigballs@disneyhq/
Last edited by iceman (2015-11-22 18:02:49)
Offline
Ah yeah - You caught the reverse naming - Always a hockey thing we used on my team .....
I'm going to do more sim testing tomorrow - I had some issues with the FW code I was doing, I knew I should have finished it last night - This morning I had a brain block and that does help....
Offline
The mighty ducks Sorry, couldn't resist.
Offline
This Change is keeping me up at night now - So close to getting it working, at least it hasn't been a complete failure so far. Works intermittently ...
Offline
you'll eventually get it and when it happens its gonna feel real good
Offline
check my hf_magic_tests fork and the hf mfu commands
Offline
marshmellow - cool, I'm heading over now ..... That's hot off the presses, commit was 3 hours ago ....
Having a compile issue :
mifarehost.c: In function 'mfCSetUID':
mifarehost.c:242: error: 'MAGIC_SINGLE' undeclared (first use in this function)
mifarehost.c:242: error: (Each undeclared identifier is reported only once
mifarehost.c:242: error: for each function it appears in.)
mifarehost.c:268: error: 'MAGIC_WIPE' undeclared (first use in this function)
mifarehost.c:269: error: 'MAGIC_UID' undeclared (first use in this function)
I'm looking at it some, but might not get to it until tomorrow....
** Ah, mifarehost.h is missing the declaration for the the MAGIC_* Variables... **
Last edited by sllabgib (2015-12-15 03:54:21)
Offline
hmmm.. looks like i forgot to push the changes to protocols.h .... fixed now
Offline
should be able to dump a tag (preferably with the password even if default) using hf mfu dump
convert the .bin file to .eml with script dumptoemul-mfu.lua
load .eml with hf mfu eload
sim with hf mfu sim
see "h" option for each command for details
Offline
i've used it for ntag 213, 203, 215...
Offline
You did change the dump format if I remember it, so new dumps are needed to make a proper simulation running.
Offline
Just finished for the day - Ill get the new update - I figures it was protocol.h but it was late and I figured you would get it fixed - Thanks for that!
**Edit**
Hey Marshmellow - One more :
obj/cmdhf14a.o: In function `CmdHF14ASim':
C:\ProxSpace-Scott\pm3\client/cmdhf14a.c:554: undefined reference to `tryMfk32'
C:\ProxSpace-Scott\pm3\client/cmdhf14a.c:555: undefined reference to `tryMfk32_moebius'
obj/cmdhfmf.o: In function `CmdHF14AMf1kSim':
C:\ProxSpace-Scott\pm3\client/cmdhfmf.c:1109: undefined reference to `tryMfk32'
C:\ProxSpace-Scott\pm3\client/cmdhfmf.c:1118: undefined reference to `tryMfk64'
collect2: ld returned 1 exit status
make[1]: *** [proxmark3] Error 1
I presume another .h missing or not in the import for the module?
Last edited by sllabgib (2015-12-15 22:47:44)
Offline
doh... forgot about my fiddling with mfk and nonce2key... sorry.. better now..
Offline
Cool - Ill try it now.... Thanks (We've all been there when coding .....)
**EDIT** - Confirmed, good Bingo now
Last edited by sllabgib (2015-12-15 23:21:12)
Offline
Cant seem to get LD to see a Sim tag - I did on some old code I wrote using the 14a sim .... When I did a new dump with the MFU from the fork it said it read 57 blocks, but I thought a 213 had only 44 Blocks? So the eload I tried both just in case the EMU memory was bad - neither worked.
The PWD seems to work in a trace, it reads block (38) but then nothing but collision data, it never tries to read 36 or 37 which is needed (and a normal read for these).....
Ill look more later ...
Offline
the extra blocks are for the extra data in the card that is normally not read by blocks but by special commands... the get version command, and get signature command are the largest 2.
57 is correct.
if you know the password you should send the dump command with the password so it can gather the pack information (if you did that i don't know why it did not work for you.) i have run a ntag 213 against most commands and the code works with standard readers.
Last edited by marshmellow (2015-12-16 02:22:12)
Offline
if you could show a hf list 14a after the sim attempt and a trace of a snoop of the real tag maybe i could identify the issue.
Offline
@marshmellow, you have a minor issue in the modified "hf mfu dump". ref: https://github.com/marshmellow42/proxma … fu.c#L1462
this needs to be changed. When I removed the check, it started working
Offline
i don't see the same issue.
Offline
try calling it with a key
Offline
i don't have the same issue. the code you identified is pre-existing and hasn't changed. and i can call it with a key with no issues.
Offline
as ref: http://pastebin.com/NbLZ2f35 but I emailed you about it with more details.
I noticed that I can only call swapendian64 only once, to always get the same output... something with static buffs
Offline
the code only ever calls it once. note the ! in front of the swapendian boolean.
however, it appears i was reformatting the key for output before the last usage of the key in the new code. this could cause an issue with keys that did not have mirrored values, which is why i did not see it at first using keys like FFFFFFFF, 00000000, or 11111111...
this should now be fixed.
Offline
more background. the key we see in memory outputs is bigendian, by default sprint_hex prints little endian. so before we print it we have to swap it (unless we used the switch `l` [swapendian] - in which case we can't swap it twice...)
Offline
I've got my pm3 up and running. I've got into the hf mfu menus. I have successfully dumped to a file a tag. I'm trying to simulate an NTAG. I can run the script to convert the bin to eml. When I try to eload the eml it tells me "file reading error".
Second issuue, anytime I try to use the hf 14a sim or hf mfu sim and try to use type 7 I get the error "unkown tag type (7)". Any advice would be great.
Last edited by greatone76 (2016-04-22 01:50:21)
Offline
I will answer your question with some questions,
did you use the right convertion script?
are you using a fork that supports "t 7"?
Offline
I used the dumptoemul-modules.lua that is in the latest full proxmark3 repository. Is there a way to check the script?
I guess I don't understand forks. I've seen mention, but don't understand. I don't want the base set of files. I need a special set of the proxmark files to do the emulation or I need additional file set on top of the base to do the emulation? Where do I find them and how do I get the right one or ones. I apologize, I'm relatively low on the coding tree.
Offline
The Proxmark3 master (branch) is the stable code-release at present. That is its purpose. It doesn't contain everything.
Since its opensource, everyone can download and modify it. Hence some other users, like myself, has a fork of the PM3 master which contains different functionality.
Like if you look at your issue with simulation and the option "T 7", that option is not in the PM3 master.
That option is found in the iceman fork... Which you need to download, compile, flash and run the client to be able to use.
Offline
Thanks for help. Will the branch fix my dumptoemul-mfu.lua problem as well or is that a seperate issue?
Offline
that fork will fix that problem aswell.
Offline
For my NTAG213 Emulation I have the tag dump working to a .bin and the script working to convert to .eml, but when I go to eload the .eml file it says "test.eml not found or locked". Where does the .eml file end up and how do I reference it correctly or move it to the correct location or unlock it.
Also, when using the "hf mfu sim t 7 u XXXXXXXX It gives me the unknown tag type (7) error.
Last edited by greatone76 (2016-05-04 03:16:22)
Offline
two questions,
usually you start inside the /client folder, and thats where it saves it default. However since I know that you are using my docker container, that a docker container is a clean environment. Or prestine, everything you do is gone when you close it down. Like the saved dump files. You need to extract and save your dumps from the docker container. A slight extra hassle.
The other question has been answered many times. The answer is the same, don't mix firmware & client from different builds.
If you are using my fork, flash the fullimage and use the client from that build.
Offline
How do I extract and save in docker?
Where do I find the correct forward and do I load the firmware through docker or Windows?
Offline
I suggest you google "docker cp" command.
And I suggest you flash thru docker then you get the last firmware & client. Remember the process "git pull && make clean && make all" first.
Offline
Sorry for more questions: Using the Proxmark3 Wiki in the Linux Ubuntu Section I only see a reference to the older version of flashing:
Use the older version of the flasher to update the proxmark:
cd client/hid-flasher
make
./flasher -b ../../bootrom/obj/bootrom.elf
./flasher ../../armsrc/obj/fullimage.elf
cd ../..
I put in the first line and then when I make I get the following error:
proxusb.h:30:3: error: unkown type 'usb_dev_handle'
usb_dev_handle *handle;
make: *** [obj/flash.o] Error1
I'm guessing I need to use the "new flash", but I'm not finding instruction on how to find it and use it. As usually any advise would be greatly appreciated.
Offline
The ubuntu section isn't complete sadly but it does inform you of how to dectect which version you are running your device on.
HID vs CDC device.
If you identify it as HID, follow instructiosn for upgrading.
as well with CDC,
If you have one of the elechouse pm3 kits, its already CDC firmware. You can follow the instructions here https://github.com/Proxmark/proxmark3/wiki/compiling
All of your problems is solved by searching this forum and reading all different parts of the Wiki.
Please do read up a bit.
[edit]
I also remembered now that its quite detailed in the README section on GitHub on my fork.
Offline
After making -- I check firmware and I'm CDC
So I used the below command:
client/flasher -b /dev/ttyACM0 bootrom/obj/bootrom.elf
It says:
Loading ELF file '/dev/ttyACM0' ...
and it just hangs there.
I'm assuming that I have some issue with my file path, but I'm clueless about the file structure of docker and what is saved in the container and where other files are ect. I know these are annoying questions but I've never used Linux and I've never used docker and there a lot of layers that don't make enough sense to me. I understand you gave me the docker cp for copying, but I can't figure out where the file should be in the first place and where I would move it. In the container to my local?
A brief understanding of why docker can't read a file created in the container and how I correct that would be greatly appreciated.
Offline
If you are on CDC, no direct need to update bootrom..
If you are using my fork? I push a minor fix yesterday where the flasher hangs. *sorry*
For you inside the docker container, this is the steps you need to have the latest source compiled.
If there is no "new code" from the git pull, then you don't need to recompile / flash. Just memorize.
git pull
make clean
make all
client/flasher /dev/ttyACM0 armsrc/obj/fullimage.elf
cd client
./proxmark3 /dev/ttyACM0
Getting files in and out from a docker container is not the topic of this thread.
Offline
I'm using the iceman fork and iceman docker.
I do the following:
git pull
make clean
make all
All above work fine.
client/flasher /dev/ttyACM0 armsrc/obj/fullimage.elf
I get the following:
Loading ELF file /armsrc/obj/fullimage.elf' . . .
Loading Usable ELF segments:
0: V 0x00102000 P 0x00102000 (0x0002fff8->0x0002fff8) [R X] @0x94
1: V 0x00200000 P 0x0013aff8 (0x0001ae8->0x0001ae8) [RW ] @0x3008c
Waiting for Proxmark to appear on dev/ttyACM0 . . . . .
And it just hangs and continues making dots.
Any Advice?
Offline
have you followed the instructions for flashing to linux? like figuring out which tty-port the pm3 got?
Offline
I believe so. tty-port checked - Once given the command - the PM lights (2) red lights, so it appears to be connected and responds to the command there is just some issue loading or refreshing (I'm guessing).
Offline
Thats sounds like its waiting for the firmware to transfer.. hm, if you are using my docker container,
please do a:
git pull
make clean
make all
before trying to flash. I pushed a minor fix for the flasher which is not in the docker container.
Offline