RfidResearchGroup / ChameleonUltra

The new generation chameleon based on NRF52840 makes the performance of card emulation more stable. And gave the chameleon the ability to read, write, and decrypt cards.
https://chameleonultra.com
GNU General Public License v3.0
873 stars 147 forks source link

Get device capabilities #104

Closed Foxushka closed 1 year ago

Foxushka commented 1 year ago

Implement hw raw to send raw commands to chameleon (for easier development) Implement hf mf info to get UID/SAK/ATQA from current slot

Implement DATA_CMD_GET_DEVICE to fetch all available commands from chameleon Implement DATA_CMD_GET_DEVICE_CAPABILITIES to get current chameleon type (ultra or lite) Implement DATA_CMD_GET_SETTINGS to get all chameleon settings in one command

github-actions[bot] commented 1 year ago

You are welcome to add an entry to the CHANGELOG.md as well

github-actions[bot] commented 1 year ago

Built artifacts for commit 902deed36237f5a4a2229d410c72cbfdc0a84b4e

Firmware

Client

doegox commented 1 year ago

ok if I push a fix to GET_DEVICE on your PR ? (wrong (uint8_t*)1 makes fw crashing) and I'll also augment max-line-size of autopep8 to 120 else all your style changes to avoid carriage return will be reverted by the next make_style call.

Generally speaking, please avoid massive style changes mixed with functional changes, it makes hard to review your changes.

doegox commented 1 year ago

For endianness we should use systematically everywhere functions to convert to/from "Network byte order" and not make any assumption on host byte order. In C: htonl, htons, ntohl, ntohs In Python: '!H' and '!L' with struct.pack/unpack Probably existing functions to be fixed but you can start with this good habit on GET_DEVICE_CAPABILITIES :)

Foxushka commented 1 year ago

In C: htonl, htons, ntohl, ntohs

I've tried to search for them, but they exists only in newer nRF Connect SDK (or I searched incorrectly) https://github.com/nrfconnect/sdk-nrf/blob/main/ext/iperf3/portable_endian.h

doegox commented 1 year ago

Hmm it seems they were available as macros (HTONL) in previous nRF SDKs, from nRF IoT SDK, e.g. https://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.sdk5.v15.0.0%2Fgroup__iot__defines.html but I don't know why it's gone in latest... Maybe reintegrate the defs e.g. from https://github.com/mwaylabs/fruitymesh/blob/bb0a16a2d5750c96978adcb4307ebee5b4931a6b/sdk/sdk15/components/iot/common/iot_defines.h#L64

doegox commented 1 year ago

They are in SDK 17.1.0 in external/lwip/src/include/lwip/def.h as PP_HTONS etc but external/lwip/src/include/lwip/def.h was not committed in this repo. Still probably it's better just to add the macros ourselves

Foxushka commented 1 year ago

@doegox I'm still waiting for your fix and correct hto* porting

doegox commented 1 year ago

ha sorry you never replied so I thought you did on your side. done.

doegox commented 1 year ago

i'd say it's good enough for merge now, even if I would avoid reusing existing structs with weird things like non-typed enums, and hardcoding sizes because struct is not declared for Lite. Yes I'm looking at cmd_processor_get_mf1_anti_coll_data() . But as all previous commands should be screened for that as well, let's do it in a future step.