This repository was archived by the owner on Feb 24, 2021. It is now read-only.
Added DES AUTH command support#1
Merged
iceman1001 merged 16 commits intoiceman1001:masterfrom Jan 1, 2015
Merged
Conversation
…after challenge response
Owner
|
Sweet bforbort! |
Author
|
If you privately email me a mailing address, I can send you a couple blank DESFire cards. They will have to the Master Key '00 00 00 00 00 00 00 00' Referring to page 15 of the DESFire MF3 IC D40 data sheet, you will find that both DES and 3DES keys are stored in strings consisting of 16 bits on the DESFire card. If the 2nd half of the key string is equal to the 1st half, the key is handled as a single DES key by the PICC. In my code, I've used the example code '00 11 22 33 44 55 66 77 00 11 22 33 44 55 66 77.' This would be the 16 bit representation of the 8 bit single DES key '00 11 22 33 44 55 66 77.' |
Owner
|
You are right, I remember to have read about DES/3DES before. I got confused by you mention bits, instead of bytes. It was a while since I did something with desfire and when I did it was most AES. |
iceman1001
added a commit
that referenced
this pull request
Jan 1, 2015
Added DES AUTH command support
Owner
|
Btw, I can't find your email address. |
Author
iceman1001
pushed a commit
that referenced
this pull request
Jan 6, 2015
iceman1001
pushed a commit
that referenced
this pull request
Feb 10, 2015
micolous
added a commit
to micolous/proxmark3
that referenced
this pull request
May 24, 2018
Internally, the `uart_*` implementations treat their parameter as a pointer. While the C technically doesn't have a way to enforce that you're not modifying memory referred to by a `const` pointer, there's not a good reason to prohibit an implementation of `uart` from doing so, if it makes sense for that platform or environment. PM3 also fairly consistently casts the value to a non-const pointer anyway. This also explicitly sets `sp` to NULL, which should cause an uninitialized use of `sp` to dereference a null pointer (generally crashing with a segfault, as the program tries to reference unmapped memory), rather than reading some nearby program memory (and have undefined behaviour). That will make it very obvious in a debugger, when something has gone wrong. For example: ``` * thread iceman1001#1: tid = 32727, 0x0000555555556e1b flasher`uart_send(sp=0x0000000000000000, pbtTx="", szTxLen=544) + 123 at uart_posix.c:204, name = 'flasher', stop reason = signal SIGSEGV: invalid address (fault address: 0x0) frame #0: 0x0000555555556e1b flasher`uart_send(sp=0x0000000000000000, pbtTx="", szTxLen=544) + 123 at uart_posix.c:204 ``` This should address a number of compiler warnings on uart files.
micolous
added a commit
to micolous/proxmark3
that referenced
this pull request
May 24, 2018
Internally, the `uart_*` implementations treat their parameter as a pointer. While the C compiler technically doesn't have a way to enforce that you're not modifying memory referred to by a `const` pointer, there's not a good reason to prohibit an implementation of `uart` from doing so, if it makes sense for that platform or environment. PM3 also fairly consistently casts the value to a non-const pointer anyway. This also explicitly sets `sp` to NULL, which should cause an uninitialized use of `sp` to dereference a null pointer (generally crashing with a segfault, as the program tries to reference unmapped memory), rather than reading some nearby program memory (and have undefined behaviour). That will make it very obvious in a debugger, when something has gone wrong. For example: ``` * thread iceman1001#1: tid = 32727, 0x0000555555556e1b flasher`uart_send(sp=0x0000000000000000, pbtTx="", szTxLen=544) + 123 at uart_posix.c:204, name = 'flasher', stop reason = signal SIGSEGV: invalid address (fault address: 0x0) frame #0: 0x0000555555556e1b flasher`uart_send(sp=0x0000000000000000, pbtTx="", szTxLen=544) + 123 at uart_posix.c:204 ``` This should address a number of compiler warnings on uart files.
iceman1001
pushed a commit
that referenced
this pull request
Aug 5, 2018
cross-merging fork to branch from Iceman's repository
drandreas
pushed a commit
to drandreas/proxmark3
that referenced
this pull request
Sep 5, 2018
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
I've developed this code using a blank DESFire v1.4 card, and was able to test it by changing the PICC master key to a new value. I was drunk when I wrote this so it works but it might not be pretty. This code only adds single DES support to the auth command, so remember to make the last 8 bits of a new key the same as the first 8 bits, otherwise the command will fail when you try to auth with the new key. I have yet to test this command on a card that has been set to 3DES operation. I assume it will fail but I do not know or care where it will fail right now, I'm just way to drunk to add anything more.