Closed aveao closed 4 years ago
There isn't any real chance of writing 0xFFFF bytes from command line ever,
Even if the DESfire protocol allows for sizes, the Pm3 client isn't. If the command line isn't resized and taken care for the best you can hope for is about 255bytes in one go. Which fits into the other limits. However I doubt even that will work since readline on the different platforms this repo is used with might also have an smaller limit. And I am no sure how the parameter read hex string from command line string deals with these sizes.
With that said, the client should be able to input and correctly parse 255 bytes of data without smashing stacks.
I see, that does indeed make sense.
I think simply changing the help text from saying that the limit is 0xFFFF to 132 bytes would be a good enough fix, or if you have any ideas on how to get it working with 255 bytes, doing that and updating the help text accordingly.
Of course I have :)
The steps
That should sort out the client side problems,
As I mentioned on discord I did pretty much that (except this uses CLIParamHexToBuf
instead of param_gethex
), and it seems to work fine. Thanks a lot for the pointers, will PR shortly.
Excellent!
Describe the bug\ Writing large amounts of data (in this example, 132 bytes) using mfdes (but smaller than the documented limit of 0xFFFF bytes) causes a buffer overflow, which in turn results in stack smashing detection to terminate the client.
To Reproduce Steps to reproduce the behavior:
hf mfdes createfile -f 0001 -n 01 -c 0 -r EEEE -s 000085 -a 123456
)hf mfdes writedata -n 01 -t 0 -a 123456 -o 000000 -d AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
)Expected behavior I expected the write to file to succeed as it does for shorter input.
Screenshots
Desktop (please complete the following information):
OS: Arch Linux, latest as of 2020-09-27
Additional context
In my specific case writes with byte counts above 47 seems to fail too, but I deployed a temporary fix where I changed the following lines to be 47, which fixed that issue for me (I am trying to figure out why it fails, and this is a mere workaround):
https://github.com/RfidResearchGroup/proxmark3/blob/42eb98cdda13f54658556fd96766939901228895/client/src/cmdhfmfdes.c#L1712-L1713
If this is not just a quirk of this particular card, it may be needed to apply a workaround/fix such as this while testing this bug.