Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ISO15693 NXP SLIX-L features #930

Open
wants to merge 7 commits into
base: master
Choose a base branch
from

Conversation

g3gg0
Copy link

@g3gg0 g3gg0 commented Apr 13, 2020

This PR adds advanced ISO15693 emulation features to the proxmark3.
The chosen tag to emulate was a NXP SLIX-L. The emulation code does not
implement all functionalities the tag has, it merely focuses on privacy mode
and the password feature.
This blocking simulator code now exits whenever there is some USB communication.

It also adds some advanced features for SLIX-L tags, like locking or changing the password,
revealing the tag from privacy mode and a ISO15693 command scanner.

Porting these features to the latest commits caused some trouble, but it looks like
i got everything working again.

The simulator was tested with a closed source children audio system of a german manufacturer
which uses the SLIX-L tags in privacy mode in their system.

@pwpiwi
Copy link
Contributor

pwpiwi commented Apr 15, 2020

Thank you very much for your contribution. Good work!

However, this adds a lot of code at the ARM side (appmain.c, iso15693.c) which should be avoided because space is very limited there. Specifically:

  • why did you implement a standalone mode for card only functions?
  • why did you implement specific commands CMD_ISO_15693_SLIX_L_DISABLE_PRIVACY, CMD_ISO_15693_SLIX_L_CHANGE_PASS, CMD_ISO_15693_SLIX_L_LOCK_PASS, CMD_ISO_15693_BRUTE_FORCE instead of using the generic CMD_ISO_15693_COMMAND?
  • what is the purpose of StressSlixLIso15693()?

I would think that most of the functionality can be implemented in cmdhf15.c instead?

@g3gg0
Copy link
Author

g3gg0 commented Apr 15, 2020

Thanks for your feedback.

When implementing this, I didn't have resources as primary goal.
Goal was to emulate SLIX-L tags for experiments with a closed ecosystem for children to play audio files from the cloud.

  • The standalone mode is an optional thing to execute certain functions with a button press only
    i agree that this might be "too much" for most of the users, but it is not enabled by default.
    can remove this - or keep as a reference (like the other standalone modes were for me)

  • the SLIX-L tags must not get powered off between the commands "get random" and other password related commands.
    disabling the field causes the random value in the tag to get dropped and authentication wont work
    i see these functions as "atomic" functions for NXP SLIX-L and would like to keep them.
    also the somewhat modular function design is smth i like personally. If resources are too low,
    having them static will even improve the flash usage compared to "hand-implement" those manually

  • this is quite helpful to debunk the cheap chinese "yes yes its original NXP!" clones.
    had one of those which fail immediately when running a stress test.
    this is also something very optional and does not have to go into mainline

Thanks again for checking and your feedback on this.

g3gg0 added 2 commits May 19, 2020 01:11
moved internal commands to only build in standalone mode
send NACK if DisablePrivacySlixLIso15693 fails
@pwpiwi
Copy link
Contributor

pwpiwi commented May 20, 2020

I am currently quite busy and cannot spend time on code reviews. If anybode else wants to step in...

At a first glance I see

  • some hard coded passwords
  • not using emulator memory
  • functions implemented on device instead on client
  • standalone mode for card only function. I am questioning standalone modes in general, but for card only functions (i.e. you don't need to approach a reader) they are definitely not required.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants