search

iceman1001 / proxmark3

[Deprecated] Iceman Fork, the most totally wicked fork around if you are into proxmark3
http://www.icedev.se/pm3.aspx
GNU General Public License v2.0
465 stars 116 forks source link

hf mfdes read block and write block commands - commented out? #152

Closed aaronmaxlevy closed 6 years ago

aaronmaxlevy commented 6 years ago

Hi @iceman1001 ,

I was wondering about why the read and write block commands are commented out for hf mfdes .

Does that code theoretically work? If not, were you ever able to determine the issue?

I'm trying to figure out how to read a file from a Desfire 1K card.

Thanks!

iceman1001 commented 6 years ago

yeah, that part of the code is desperate need for some love. Basically that need for crypto needed to support desfire wasn't available then, when I started those commands.

Today, ppl like @merlokk and @pwpiwi has added lots of open-source based cryptolibs. The idea of keeping it on the client side instead since there is no space on the device.

Des, 3des, aes, and mac calculations is needed for supporting reading a desfire tag. Not too hard, given that the device now supports big frames again. Look at the new apdu-command. or emv.

aaronmaxlevy commented 6 years ago

Thanks @iceman1001 . To clarify, are you saying that in theory, all of the work to be able to read Desfire can be done using client-side code, without making additional firmware modifications?

Also, does the commented out code actually work? Or is that code essentially not even worth looking at?

Thanks! -Aaron

iceman1001 commented 6 years ago

Yes, not only in theory. The pm3 device will not have any problem getting full desfire support, based on a client-side implementation. Just like hf 14a apdu or hf emv now is being implemented.

You should not need to modify the firmware, you can implement this on so many ways. like using the hf 14a apdu as a base for sending your desfire commands. The biggest issue is crypto/mac signing, all of which needs to be implemented on client side.