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.
I did the above and get the same result.
Any advice?
I'm under the impression I don't need to install the Linux driver just the windows one. It is either not needed or already in the container. Also per your above list I don't need to load the bootrom. Please let me know if I'm wrong on either of those and that is my problem.
Offline
You should start another post to ask about firmware flashing problems, this thread is about NTAG213 Simulation
Offline
I'm using the iceman fork in the docker container. I have successfully gotten the hf mfu dump to get me a file ..... test.bin. I successfully got the dumptoemul-mfu script to work to convert my test.bin to test.eml. I figured out how to copy that file from the client folder to just the proxmark3 folder.
I then use the hf mfu eload u test.eml and it gives me the following:
.............................................File reading error
And advice? Is there any way to check the file?
Offline
The issue I ran into was that the .eml file had a extra line it. I opened a text editor and removed the line and resaved and then it would load into memory.
Offline
hm, Didn't I fixed that one in the converting script? Have to look into it.
Offline
Did you run a lua-script to convert it to eml? Which one?
Offline
I used dumptoeml-mfu.lua
Offline
from my fork?
Offline
From your fork inside the docker container if that matters.
Offline
I thought I fixed that last new-line in output file in the dumptoemul* scripts,
Offline
Funny, I went through the exact same issue yesterday but I was surprised to see that the dump produced by mfu dump on the official repository ("Dumped 20 pages, wrote 80 bytes") and iceman's fork ("Dumped 32 pages, wrote 128 bytes")
The card is a MIFARE Ultralight EV1 48bytes (MF0UL1101), and I was not able to emulate it successfully.
The second dump contains additional "special block data", placed at the beginning of the file.
I don't precisely know how the emul format works (ASCII representation of the plain memory ?).
There is a default password on the Ultralight card (FF FF FF FF).
Why did the emul format change, and do the emulator needs these "special block data"?
Offline
Thats because the icemanfork is special
Naw, that is only part of story, full story goes like this, @marshmellow did some changes in one of his branches on his fork when we were working on MFU commands. Where we wanted to make a "complete" emulation of a UL-EV1 tag, i.e. even GetVersion, GetSign commands is all written in to the dumpfile. Hence it became bigger. So as I took everthing and fixed some other stuff, into my fork.
So @marshmellow never merged his changes into the PM3, so thats why PM3 master is kind of old and has less functionality.
[Obvious selfish brag here]
As is with icemanfork you can make funnier stuff and more stuff and it is make stabil with all code fixes from the Coverity scans. Never mind, just read the changelog and you'll see how much more it can do.
Offline
Ahah, I knew it
(and BTW you guys did a really great job! I hope I could be as helpful and useful as you)
More seriously, the existing script dump2emul-mfu.lua doesn't seem to work properly with these new binary dumps, cf for instance the UID doesn't get dumped in the script (https://github.com/iceman1001/proxmark3/blob/master/client/scripts/dumptoemul-mfu.lua#L94). I will investigate when I find time to see what is going wrong (where are the data placed in the file).
Do you confirm we are able to emulate an Ultralight EV1 (48 bits) as mine?
The process being mfu dump > dumptoemul-u2f > mfu eload u > mfu sim ?
Offline
The original though was like that, to make "perfect" emulation, not just data part.
At that time I made some toy-token-readers belive that the PM3 was an exact copy and they were UL-ev1
But that was over a year ago, or it feels like that, so there may be bugs in it still. If you find them, do raise an issue or fix them and make a PR. I usually merge it quite fast.
Offline
And since we "broke" the original dump format, I'm guessing, and didn't have a proper discussion about it here on the PM3 master, is the reason for @marshmellow not to make a PR.
Personally, I would like to a json format style, but thats a complete different matter and topic and should not be discussed here.
Offline
Yeah, the script, dump file format and sim changes were a quick hack. So i never pushed it to the main. Iceman cleaned it up a little for his fork. I think my original ntag fork still exists and was working at the time. I'll look around.
Offline
Just want to say a quick thanks to everyone involved in making this emulation happen. I successfully emulated an NTAG213 off the PM3 with a machine that provides a unique key, verifies a unique pack from the tag, then both reads and writes to the protected area of the tag. And all of this worked perfectly to let the machine do its thing without knowing I was emulating.
Offline