Compare commits
| Author | SHA1 | Date | |
|---|---|---|---|
|
|
61cc4f5891 | ||
|
|
b6d2badab4 | ||
|
|
4927e0166c | ||
|
|
9106dea953 | ||
|
|
75e368da62 | ||
|
|
a2121de79e | ||
|
|
336ec82e49 | ||
|
|
2d3538f4c2 | ||
|
|
8080c9b259 | ||
|
|
2f4d84ed2c | ||
|
|
deb6684c0d | ||
|
|
dd5ff244d3 | ||
|
|
8fc45a67a4 | ||
|
|
831c401b5d | ||
|
|
dcebc89654 | ||
|
|
1da470b8fe | ||
|
|
45deb30d4a | ||
|
|
efd7405bd8 | ||
|
|
a47e9b8b03 | ||
|
|
cd51061bb0 | ||
|
|
d127f0a641 | ||
|
|
47742d5984 | ||
|
|
18a1770c80 | ||
|
|
0f730affa7 | ||
|
|
6cad966e7a | ||
|
|
3aa73a2def | ||
|
|
0c6abbea9d | ||
|
|
3022e0550c | ||
|
|
1ce506a5ad | ||
|
|
7ae3820913 | ||
|
|
465ada3544 | ||
|
|
bb0ad66a78 | ||
|
|
be7fad4906 | ||
|
|
707b0c6d4a | ||
|
|
702dba0d93 | ||
|
|
0d2c3fae89 | ||
|
|
eac1b31b3c | ||
|
|
5ea6519577 | ||
|
|
8f552773f1 | ||
|
|
42b715575c | ||
|
|
606ec02e30 | ||
|
|
226efbc3d5 | ||
|
|
7efe23edb2 | ||
|
|
48bf852465 | ||
|
|
5519715c10 | ||
|
|
4a94db10bf | ||
|
|
6915ee19a4 | ||
|
|
43cadeb84d | ||
|
|
55b4053acb | ||
|
|
4347cd9048 | ||
|
|
e757c58a20 | ||
|
|
4e1dec06ad | ||
|
|
ef1ccb40d8 | ||
|
|
db3f8ce1d7 | ||
|
|
ac1f518f0a | ||
|
|
3fc985973c | ||
|
|
e52b0302bf |
@@ -19,32 +19,47 @@ jobs:
|
||||
pre_command: |
|
||||
? .
|
||||
bundle_command: |
|
||||
Compress-Archive -Path software\* -DestinationPath client-windows.zip
|
||||
Compress-Archive -Path software\dist\* -DestinationPath client-windows.zip
|
||||
- name: linux
|
||||
os: ubuntu-latest
|
||||
pre_command: |
|
||||
true
|
||||
bundle_command: |
|
||||
(cd software && zip -r "$OLDPWD/client-linux.zip" .)
|
||||
(cd software/dist && zip -r "$OLDPWD/client-linux.zip" .)
|
||||
- name: macos
|
||||
os: macos-latest
|
||||
pre_command: |
|
||||
true
|
||||
bundle_command: |
|
||||
(cd software && zip -r "$OLDPWD/client-macos.zip" .)
|
||||
(cd software/dist && zip -r "$OLDPWD/client-macos.zip" .)
|
||||
runs-on: ${{ matrix.os }}
|
||||
steps:
|
||||
- name: Check out the repo
|
||||
uses: actions/checkout@v3
|
||||
with:
|
||||
ref: ${{ inputs.checkout-sha == null && github.sha || inputs.checkout-sha }}
|
||||
- name: Install PyInstaller and client dependencies
|
||||
run: |
|
||||
pip3 install pyinstaller
|
||||
pip3 install -r software/script/requirements.txt
|
||||
- name: Run OS specific setup
|
||||
run: ${{ matrix.pre_command }}
|
||||
- name: Compile native code
|
||||
run: |
|
||||
cd software/src
|
||||
mkdir out
|
||||
cd out
|
||||
cmake ..
|
||||
cmake --build . --config Release
|
||||
- name: Run PyInstaller
|
||||
run: |
|
||||
cd software
|
||||
pyinstaller pyinstaller.spec
|
||||
- name: Upload built client
|
||||
uses: actions/upload-artifact@v3
|
||||
with:
|
||||
name: client-${{ matrix.name }}
|
||||
path: software/*
|
||||
path: software/dist/*
|
||||
- name: Zip up client for release
|
||||
run: ${{ matrix.bundle_command }}
|
||||
- name: Upload release artifacts
|
||||
|
||||
@@ -3,8 +3,18 @@ All notable changes to this project will be documented in this file.
|
||||
This project uses the changelog in accordance with [keepchangelog](http://keepachangelog.com/). Please use this to write notable changes, which is not the same as git commit log...
|
||||
|
||||
## [unreleased][unreleased]
|
||||
- Added colors to CLI help (@doegox)
|
||||
- Changed massively CLI, cf https://github.com/RfidResearchGroup/ChameleonUltra/issues/164#issue-1930580576 (@doegox)
|
||||
- Changed CLI help: lists display and now all commands support `-h` (@doegox)
|
||||
- Added button action to show battery level (@doegox)
|
||||
- Added GUI Page docs (@GameTec-live)
|
||||
- Changed CLI threads polling into blocking reads, to reduce CPU usage (@doegox)
|
||||
- Added support for timestamped comments in CLI via `rem`, `;`, `%` or `#` (@doegox)
|
||||
- Fixed watchdog trigger during `hw factory_reset` (@doegox)
|
||||
- Added PyInstaller support for CLI client (@augustozanellato)
|
||||
|
||||
## [v2.0.0][2023-09-26]
|
||||
- Added `hw slot nick delete` and DELETE_SLOT_TAG_NICK (@doegox)
|
||||
- Changed APP_FW_VER now deduced from git tag vx.y.z (@doegox)
|
||||
- Changed initial button wakeup from 4 to 8 seconds (@aramova)
|
||||
- Added MIFARE Ultralight reading features (@FlUxIuS & @doegox)
|
||||
|
||||
@@ -14,6 +14,28 @@ Anywhere else: [Sneaktechnology](https://sneaktechnology.com) / [Aliexpress by R
|
||||
|
||||
Read the [available documentation](docs/README.md).
|
||||
|
||||
# Public Roadmap with reference to [Here](https://github.com/RfidResearchGroup/ChameleonUltra/wiki/Public-Roadmap)
|
||||
|
||||
Table for future functionality progress
|
||||
---------------------------------
|
||||
|
||||
|No.|Functionality to achieve| Date | In Progress / Achieved ? | Contributors | RRG will reward |
|
||||
|:--------------:|:--------------:|:--------:|:------------:|:------------:|:------------:|
|
||||
|1| Adding DESfire Support|28/09/2023|:--------------:|:--------------:|:------------:|
|
||||
|2| Adding Indala Emulation|28/09/2023|:--------------:|:--------------:|:------------:|
|
||||
|3| Adding HID Prox 26 bit Emulation|28/09/2023|:--------------:|:--------------:|:------------:|
|
||||
|4| Adding custom keys for t5577 read|28/09/2023|:------------:|:------------:|:------------:|
|
||||
|5|:--------------:|:--------------:|:------------:|:------------:|:------------:|
|
||||
|6|:--------------:|:--------------:|:------------:|:------------:|:------------:|
|
||||
|7|:--------------:|:--------------:|:------------:|:------------:|:------------:|
|
||||
|8|:--------------:|:--------------:|:------------:|:------------:|:------------:|
|
||||
|9|:--------------:|:--------------:|:------------:|:------------:|:------------:|
|
||||
|10|:--------------:|:--------------:|:------------:|:------------:|:------------:|
|
||||
|11|:--------------:|:--------------:|:------------:|:------------:|:------------:|
|
||||
|12|:--------------:|:--------------:|:------------:|:------------:|:------------:|
|
||||
|13|:--------------:|:--------------:|:------------:|:------------:|:------------:|
|
||||
|14|:--------------:|:--------------:|:------------:|:------------:|:------------:|
|
||||
|
||||
# Compatible applications
|
||||
|
||||
* [ChameleonUltraGUI](https://github.com/GameTec-live/ChameleonUltraGUI)
|
||||
|
||||
@@ -1,15 +1,144 @@
|
||||
## Get ChameleonUltraGUI
|
||||
|
||||
- [on Google Play](https://play.google.com/store/apps/details?id=io.chameleon.ultra) / [APK](https://nightly.link/GameTec-live/ChameleonUltraGUI/workflows/buildapp/main/apk.zip)
|
||||
- [on Google Play](https://play.google.com/store/apps/details?id=io.chameleon.ultra) / [APK](https://nightly.link/GameTec-live/ChameleonUltraGUI/workflows/build-app/main/apk.zip)
|
||||
- [on iOS](https://apps.apple.com/dk/app/chameleon-ultra-gui/id6462919364)
|
||||
- [on Windows](https://nightly.link/GameTec-live/ChameleonUltraGUI/workflows/buildapp/main/windows-installer.zip) ([or without installer](https://nightly.link/GameTec-live/ChameleonUltraGUI/workflows/buildapp/main/windows.zip))
|
||||
- [on Linux](https://nightly.link/GameTec-live/ChameleonUltraGUI/workflows/buildapp/main/linux.zip)
|
||||
- [on Windows](https://nightly.link/GameTec-live/ChameleonUltraGUI/workflows/build-app/main/windows-installer.zip) ([or without installer](https://nightly.link/GameTec-live/ChameleonUltraGUI/workflows/build-app/main/windows.zip))
|
||||
- [on Linux](https://nightly.link/GameTec-live/ChameleonUltraGUI/workflows/build-app/main/linux.zip)
|
||||
- [on macOS](https://apps.apple.com/app/chameleon-ultra-gui/id6462919364)
|
||||
|
||||
## Page Breakdown
|
||||
|
||||
### Homepage
|
||||

|
||||
|
||||
Starting from the top left, you find
|
||||
|
||||
- the *Device Name*: `Chameleon Ultra` or `Chameleon Lite` depending on the device connected ;
|
||||
- the *Disconnect* button: pressing this icon cleanly disconnects the Chameleon. It is recommended to use this button whenever possible ;
|
||||
- the *Connected Port*: it tells you where and how the chameleon is connected, followed by how it is connected (*Connection Method*), which displays a USB or Bluetooth icon. Last in that row is the *Battery Charge* display ;
|
||||
- the *Used Slots*: it displays how many out of the 8 slots are used ;
|
||||
- the *Slot Changer*: the currently selected slot is highlighted with a red circle, while enabled slots are filled in. Everything else is a hollow circle. The arrows left and right allow you to change the currently selected slot ;
|
||||
- the *Firmware version*: the version is pulled from the device displayed, as well as git commit information ;
|
||||
- the *Check for updates* button: it compares the firmware with the one available on GitHub and then updates if a newer version is available ;
|
||||
- the *Switch mode* button: use it to switch between reader and emulator modes. The icon will update accordingly ;
|
||||
- the *Device Setting* button: it allows you to change settings concerning the device, like changing the animation mode.
|
||||
|
||||
### Device settings
|
||||

|
||||

|
||||
|
||||
Top to bottom:
|
||||
- *Enter DFU mode*: to enter the device DFU mode. Allows the user to take over ;
|
||||
- *Flash latest FW via DFU*: download the newest firmware from GitHub, disregarding if the device is already up to date, and flash it ;
|
||||
- *Flash .zip FW via DFU*: it allows the user to select a zip they would like to flash to the device ;
|
||||
- *Animations*: choose if the device should play the boot-up animation when woken up by an external RFID field ;
|
||||
- *Button config*: it allows you to define both short-press and long-press actions
|
||||
- *BLE pairing* toggle: you can decide whether pairing with a BLE PIN is required or not. Enabling PIN increases security at the loss of convenience. You can define a *BLE PIN* once pairing is enabled and you can force forgetting about existing pairings with the *Clear bounded devices* option.
|
||||
- *Reset settings*: it resets all device settings but does not wipe user data.
|
||||
- *Factory reset*: **IT WIPES ALL USER DATA** and resets the device to factory settings.
|
||||
|
||||
### Slot Manager
|
||||

|
||||
|
||||
The *Slot Manager* consists of 8 cards representing the 8 slots on the device.
|
||||
|
||||
The *RFID icon* in the top left corner can either be green or red, meaning the slot is enabled and disabled respectively.
|
||||
|
||||
The *Credit Card icon* displays the name and card type of the HF card in the slot.
|
||||
The *Wi-Fi icon*, on the other hand, displays the name and card type of the LF card in the slot.
|
||||
|
||||
The *Gear icon* opens the slot settings. These settings can be changed per slot.
|
||||
|
||||
The entire card is also one big button, pressing anywhere on the card opens the select dialog for loading a card.
|
||||
|
||||
### Slot Settings
|
||||

|
||||

|
||||
|
||||
The two rows at the top, labeled HF and LF respectively, display the names of the currently loaded cards. Next to them, the *X* clears them out of the slot. If both are empty, the slot will automatically be disabled.
|
||||
|
||||
Under *Slot Status* you can set if the slot is enabled or disabled.
|
||||
|
||||
The *Mifare Classic emulator settings* section allows you to toggle various behaviors:
|
||||
- *Gen1A Magic Mode*: behaves like a gen1a magic card and allows writing to it using magic commands like the Proxmark3 `cload` ;
|
||||
- *Gen2 Magic Mode*: behaves like a gen2 magic card, makes Block 0 writable ;
|
||||
- *Use UID/SAK/ATQA from 0 block*: the Chameleon Ultra stores the UID and other anti-collision data independently of the card content. Enabling this setting tells the Chameleon to derive them from card content block 0. Only for MFC with 4-byte UID ;
|
||||
- *Collect nonces (Mfkey32)*: it toggles nonce collection for mfkey32. When enabled you will be prompted to present the Chameleon to a reader. After you have collected nonces the *Present Chameleon to reader* message will change into a *Recover Keys from x nonces* button. Pressing this will start the recovery process ;
|
||||
- *Write mode*: Please refer to the [firmware docs](./firmware.md).
|
||||
|
||||
### Search dialog
|
||||

|
||||
|
||||
When using the GUI you may encounter a *Search* dialog. The dialog is structured as follows:
|
||||
|
||||
Top left you find the *Back* button, this will abort the selection and bring you back.
|
||||
|
||||
Near the end of the row, if it is a card search dialog, a filter option will show. This allows you to filter between *HF*, *LF* and *All* cards.
|
||||
|
||||
At the end you find a *X*, this X will clear the query.
|
||||
|
||||
You enter the query into the *textbox* on the top with the placeholder text "Search"
|
||||
|
||||
The search results get listed below. The Card or Wi-Fi symbol indicates if it is LF/HF. The color of the Icon is the user-defined color.
|
||||
|
||||
Listed also are the name and type.
|
||||
|
||||
Selecting the entry automatically closes the search.
|
||||
|
||||
### Saved Cards
|
||||

|
||||
|
||||
The *Saved Cards* page allows you to manage your cards and dictionaries.
|
||||
|
||||
You import a card or dictionary by clicking the *+* button in their respective half. This opens a select dialog. You may then either select a CUGUI Json file or a Bin file. A Json file gets imported immediately while a Bin file asks if the supplied data is correct before saving.
|
||||
|
||||
Once again, we got a card per card or dictionary. At the left you find the Icon for HF/LF with the user-defined color. To the left of that the card name, type and quick actions for edit, export and delete.
|
||||
|
||||
The Card is again one Big button, pressing it brings up the Slot info. It displays info about the selected item and also has the quick actions present at the bottom.
|
||||
|
||||

|
||||
|
||||
### Card Edit Menu
|
||||

|
||||

|
||||
|
||||
Depending on the selected card type the menu only displays options applicable to it.
|
||||
At the top of the menu is the name and icon. Pressing on the icon allows you to change the color.
|
||||
|
||||
Right below is the drop-down for the type. You may switch between any type at will.
|
||||
|
||||
A bit lower again you find the UID, SAK, ATQA, ATS and all other options for the selected type. This form auto-validates, so you should not be able to save a invalid config.
|
||||
|
||||
And finally at the bottom are the save and cancel options, to save the changes and exits, or to cancel the operation with no changes.
|
||||
|
||||
### Settings
|
||||

|
||||
|
||||
The App settings have their own page and consist of a few simple settings:
|
||||
- *Sidebar Expansion*: Whether or not the sidebar shall be expanded or if the windows size should decide that
|
||||
- *Theme*: Light/Dark or get it from the System
|
||||
- *Color Scheme*: Allows you to choose a color you like for the app
|
||||
- *Language*: Choose any of the languages available. Translating is done via our Crowding project.
|
||||
- *About*: Displays simple info about the app, such as build number, contributors and people who have donated on Opencollective
|
||||
- *Activate debug mode*: Don't, just Don't
|
||||
|
||||
## How to use MFKEY32
|
||||
|
||||
- set slot to mifare classic (by uploading an empty dump)
|
||||
- set slot to MIFARE Classic (by uploading an empty dump)
|
||||
- enable mfkey32 for that slot (toggle in slot settings)
|
||||
- select slot and present ultra repeatedly to the reader in order to collect nonces
|
||||
- after collecting some nonces, go back into slot settings and click recover keys
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
### Font scaling issues on HiDPI screens
|
||||
|
||||
If you have font scaling issues (tiny fonts) with the Linux desktop app and a HiDPI screen, you can solve it by running the app as
|
||||
```
|
||||
GDK_SCALE=2 GDK_DPI_SCALE=0.5 /usr/local/lib/chameleonultragui/chameleonultragui
|
||||
```
|
||||
|
||||
### Key recovery from this card is not yet supported
|
||||
This error may occur when the card you are trying to recovery keys from is requiring a not yet supported recovery technology. You cannot tell the required recovery method from the outside.
|
||||
|
||||
You may be able to solve this issue by dumping the card with a Proxmark3 or Mifare Classic Tool (Mobile App) and then importing a bin file.
|
||||
|
After Width: | Height: | Size: 42 KiB |
|
After Width: | Height: | Size: 10 KiB |
|
After Width: | Height: | Size: 15 KiB |
|
After Width: | Height: | Size: 11 KiB |
|
After Width: | Height: | Size: 176 KiB |
|
After Width: | Height: | Size: 14 KiB |
|
After Width: | Height: | Size: 23 KiB |
|
After Width: | Height: | Size: 22 KiB |
|
After Width: | Height: | Size: 25 KiB |
|
After Width: | Height: | Size: 57 KiB |
|
After Width: | Height: | Size: 44 KiB |
|
After Width: | Height: | Size: 5.6 KiB |
@@ -1,7 +1,26 @@
|
||||
# Protocol description
|
||||
|
||||
**WIP**
|
||||
## Versioning
|
||||
|
||||
Global firmware+CLI versions are following the [semantic versioning](https://semver.org/) logic mostly regarding the protocol version, so third party clients (GUIs, mobile apps, SDKs) can rely on firmware version to know their level of compatibility.
|
||||
|
||||
Given a version number MAJOR.MINOR.PATCH, we will increment the:
|
||||
* MAJOR version when we are breaking the existing protocol format
|
||||
* MINOR version when we are extending the protocol format in a backward compatible manner (new commands,...)
|
||||
* PATCH version when we are releasing bugfixes not affecting the protocol description
|
||||
|
||||
Besides compatibility with a given firmware version, third party clients may choose to offer to the users the possibility to follow a stable release channel (installing only tagged releases) or the development channel (installing latest commits).
|
||||
|
||||
For the stable channel, a client compatible with versions X.y.z can accept any version > X.y'.z' but should refuse to work with a version X'>X.
|
||||
|
||||
For the development channel, a client compatible with versions X.y.z can accept any latest commit unless a tag X'.0.0 with X'>X is present in the repo, indicating that the corresponding commit and all the commits above are incompatible with the client version. There is still a non negligible risk that breaking changes are pushed while forgetting about putting a new tag, or artefacts being built before the tag being pushed. Here be dragons... It's always a good practice for the client to validate whatever data is transmitted by the firmware, and fail gracefully in case of hiccups.
|
||||
|
||||
Cf [GET_APP_VERSION](#1000-get_app_version) and [GET_GIT_VERSION](#1017-get_git_version).
|
||||
|
||||
When `GET_GIT_VERSION` returns only a tag and no commit hash info (on a release tag), one can query the corresponding hash with the GitHub API, e.g.
|
||||
```
|
||||
"4747d3884d21e0df8549e3029a920ea390e0b00a"
|
||||
```
|
||||
## Frame format
|
||||
|
||||
The communication between the firmware and the client is made of frames structured as follows:
|
||||
@@ -34,9 +53,6 @@ Each command and response have their own payload formats.
|
||||
Standard response status is `STATUS_DEVICE_SUCCESS` for general commands, `HF_TAG_OK` for HF commands and `LF_TAG_OK` for LF commands.
|
||||
See [Guidelines](#new-data-payloads-guidelines-for-developers) for more info.
|
||||
|
||||
* **TODO:** num_to_bytes bytes_to_num
|
||||
* **FIXME:** mf1_get_emulator_config with bits -> bytes (5) with 4 bools <> mf1_get_detection_log with bitfield (2)...
|
||||
|
||||
Beware, slots in protocol count from 0 to 7 (and from 1 to 8 in the CLI...).
|
||||
|
||||
In the following list, "CLI" refers to one typical CLI command using the described protocol command. But it's not a 1:1 match, there can be other protocol commands used by the CLI command and there can be other CLI commands using the same protocol command...
|
||||
@@ -113,6 +129,11 @@ In the following list, "CLI" refers to one typical CLI command using the describ
|
||||
* Command: no data
|
||||
* Response: n bytes, a UTF-8 encoded string, no null terminator.
|
||||
* CLI: cf `hw version`
|
||||
|
||||
Notes: the returned string is the output of `git describe --abbrev=7 --dirty --always --tags` so, depending on the status of the repo it can be
|
||||
* a short tag, e.g. `v2.0.0` if the firmware is built from the tagged commit
|
||||
* a longer tag indicating how far it is from the latest tag and 7 nibbles of its commit hash, prepended with `g`, e.g. 5 commits away from v2.0.0: `v2.0.0-5-g617d6d0`
|
||||
* a long tag finishing with `-dirty` if the local repo contains changes not yet committed, e.g. `v2.0.0-5-g617d6d0-dirty`
|
||||
### 1018: GET_ACTIVE_SLOT
|
||||
* Command: no data
|
||||
* Response: 1 byte
|
||||
@@ -125,6 +146,10 @@ In the following list, "CLI" refers to one typical CLI command using the describ
|
||||
* Command: no data
|
||||
* Response: no data. Status is `STATUS_DEVICE_SUCCESS` or `STATUS_FLASH_WRITE_FAIL`. The device will reboot shortly after this command.
|
||||
* CLI: cf `hw factory_reset`
|
||||
### 1021: DELETE_SLOT_TAG_NICK
|
||||
* Command: 2 bytes. `slot_number|sense_type` with `slot_number` between 0 and 7 and `sense_type` according to `tag_sense_type_t` enum.
|
||||
* Response: no data
|
||||
* CLI: cf `hw slot nick delete`
|
||||
### 1023: GET_ENABLED_SLOTS
|
||||
* Command: no data
|
||||
* Response: 16 bytes, 8*2 bool = `0x00` or `0x01`, 2 bytes for each slot from 0 to 7, as `enabled_hf|enabled_lf`
|
||||
@@ -136,6 +161,8 @@ In the following list, "CLI" refers to one typical CLI command using the describ
|
||||
* Command: no data
|
||||
* Response: 3 bytes, `voltage[2]|percentage`. Voltage: U16 in Network byte order.
|
||||
* CLI: cf `hw battery`
|
||||
|
||||
Notes: wait about 5 seconds after wake-up, before querying the battery status, else the device won't be able to give a proper measure and will return zeroes.
|
||||
### 1026: GET_BUTTON_PRESS_CONFIG
|
||||
* Command: 1 byte. Char `A` or `B` (`a`/`b` tolerated too)
|
||||
* Response: 1 byte, `button_function` according to `settings_button_function_t` enum.
|
||||
@@ -214,7 +241,7 @@ Notes:
|
||||
* Response: 4+N*8 bytes: `uid[4]` followed by N tuples of `nt[4]|nt_enc[4]`. All values as U32.
|
||||
* CLI: cf `hf mf nested` on static nonce tag
|
||||
### 2004: MF1_DARKSIDE_ACQUIRE
|
||||
* Command: 4 bytes: `type_target|block_target|first_recover|sync_max`
|
||||
* Command: 4 bytes: `type_target|block_target|first_recover|sync_max`. Type=0x60 for key A, 0x61 for key B.
|
||||
* Response: 1 byte if Darkside failed, according to `mf1_darkside_status_t` enum,
|
||||
else 33 bytes `darkside_status|uid[4]|nt1[4]|par[8]|ks1[8]|nr[4]|ar[4]`
|
||||
* `darkside_status`
|
||||
@@ -226,29 +253,29 @@ Notes:
|
||||
* `ar[4]` U32
|
||||
* CLI: cf `hf mf darkside`
|
||||
### 2005: MF1_DETECT_NT_DIST
|
||||
* Command: 8 bytes: `type_known|block_known|key_known[6]`. Key as 6 bytes.
|
||||
* Command: 8 bytes: `type_known|block_known|key_known[6]`. Key as 6 bytes. Type=0x60 for key A, 0x61 for key B.
|
||||
* Response: 8 bytes: `uid[4]|dist[4]`
|
||||
* `uid[4]` U32 (format expected by `nested` tool)
|
||||
* `dist[4]` U32
|
||||
* CLI: cf `hf mf nested`
|
||||
### 2006: MF1_NESTED_ACQUIRE
|
||||
* Command: 10 bytes: `type_known|block_known|key_known[6]|type_target|block_target`. Key as 6 bytes.
|
||||
* Command: 10 bytes: `type_known|block_known|key_known[6]|type_target|block_target`. Key as 6 bytes. Type=0x60 for key A, 0x61 for key B.
|
||||
* Response: N*9 bytes: N tuples of `nt[4]|nt_enc[4]|par`
|
||||
* `nt[4]` U32
|
||||
* `nt_enc[4]` U32
|
||||
* `par`
|
||||
* CLI: cf `hf mf nested`
|
||||
### 2007: MF1_AUTH_ONE_KEY_BLOCK
|
||||
* Command: 8 bytes: `type|block|key[6]`. Key as 6 bytes.
|
||||
* Command: 8 bytes: `type|block|key[6]`. Key as 6 bytes. Type=0x60 for key A, 0x61 for key B.
|
||||
* Response: no data
|
||||
* Status will be `HF_TAG_OK` if auth succeeded, else `MF_ERR_AUTH`
|
||||
* CLI: cf `hf mf nested`
|
||||
### 2008: MF1_READ_ONE_BLOCK
|
||||
* Command: 8 bytes: `type|block|key[6]`. Key as 6 bytes.
|
||||
* Command: 8 bytes: `type|block|key[6]`. Key as 6 bytes. Type=0x60 for key A, 0x61 for key B.
|
||||
* Response: 16 bytes: `block_data[16]`
|
||||
* CLI: cf `hf mf rdbl`
|
||||
### 2009: MF1_WRITE_ONE_BLOCK
|
||||
* Command: 24 bytes: `type|block|key[6]|block_data[16]`. Key as 6 bytes.
|
||||
* Command: 24 bytes: `type|block|key[6]|block_data[16]`. Key as 6 bytes. Type=0x60 for key A, 0x61 for key B.
|
||||
* Response: no data
|
||||
* CLI: cf `hf mf wrbl`
|
||||
### 2010: HF14A_RAW
|
||||
@@ -386,3 +413,9 @@ If single byte of data to return, still use a 1-byte `data`, not `status`. Stand
|
||||
### Guideline: Validate status and data
|
||||
- Validate response status in client before parsing data.
|
||||
- Validate data before using it.
|
||||
|
||||
## Room for improvement
|
||||
|
||||
* some `num_to_bytes` `bytes_to_num` could use `hton*`, `ntoh*` instead, to make endianess explicit
|
||||
* some commands are using bitfields (e.g. mf1_get_detection_log (sending directly the flash stored format) and hf14a_raw) while some commands are spreading bits into 0x00/0x01 bytes (e.g. mf1_get_emulator_config)
|
||||
* describe flash storage formats
|
||||
|
||||
@@ -4,10 +4,10 @@ Quickly get up and running with your Chameleon and no technical skill
|
||||
|
||||
1. Download any of those applications. Note that in spite of what their name may suggest, all GUIs support both the Ultra and the Lite.
|
||||
|
||||
- [ChameleonUltraGUI on Google Play](https://play.google.com/store/apps/details?id=io.chameleon.ultra) / [APK](https://nightly.link/GameTec-live/ChameleonUltraGUI/workflows/buildapp/main/apk.zip)
|
||||
- [ChameleonUltraGUI on Google Play](https://play.google.com/store/apps/details?id=io.chameleon.ultra) / [APK](https://nightly.link/GameTec-live/ChameleonUltraGUI/workflows/build-app/main/apk.zip)
|
||||
- [ChameleonUltraGUI on iOS](https://apps.apple.com/dk/app/chameleon-ultra-gui/id6462919364)
|
||||
- [ChameleonUltraGUI on Windows](https://nightly.link/GameTec-live/ChameleonUltraGUI/workflows/buildapp/main/windows-installer.zip) ([or without installer](https://nightly.link/GameTec-live/ChameleonUltraGUI/workflows/buildapp/main/windows.zip))
|
||||
- [ChameleonUltraGUI on Linux](https://nightly.link/GameTec-live/ChameleonUltraGUI/workflows/buildapp/main/linux.zip)
|
||||
- [ChameleonUltraGUI on Windows](https://nightly.link/GameTec-live/ChameleonUltraGUI/workflows/build-app/main/windows-installer.zip) ([or without installer](https://nightly.link/GameTec-live/ChameleonUltraGUI/workflows/build-app/main/windows.zip))
|
||||
- [ChameleonUltraGUI on Linux](https://nightly.link/GameTec-live/ChameleonUltraGUI/workflows/build-app/main/linux.zip)
|
||||
- [ChameleonUltraGUI on macOS](https://apps.apple.com/app/chameleon-ultra-gui/id6462919364)
|
||||
- [MTools Lite on iOS](https://apps.apple.com/app/mtools-ble-rfid-reader/id1531345398)
|
||||
- [MTools Lite on Google Play](https://play.google.com/store/apps/details?id=com.mtoolstec.mtoolsLite)
|
||||
|
||||
@@ -187,3 +187,13 @@ testing a variety of common low-power reading heads, they can open the door perf
|
||||
# Hardware frame diagram
|
||||
|
||||

|
||||
|
||||
# Birth of the project
|
||||
|
||||
When the project got open-sourced, DXL shared a few notes in [issue #1](https://github.com/RfidResearchGroup/ChameleonUltra/issues/1#issuecomment-1455016381).
|
||||
|
||||
**Hardware:** ChameleonUltra and ChameleonLite hardware were carefully designed by Proxgrind team. They inherit the style of ChameleonTiny, which is very consistent with Olaf's style. Yes, whether it is Proxmark3 RDV4 or Chameleon Tiny, Olaf likes to reduce the size as much as possible under the extreme performance, making it easy to carry, unique in appearance and full of technology. At the same time, it is a pity that the volume of Chameleon Ultra brings inconvenience to most people for PCBA manufacturing and firmware development and testing. Therefore, we feel that we need to provide a development board based on ChameleonUltra with a larger volume. The components of this development board is packaged with common volume to make it easy to weld, and we also reserved GPIO interface and SWD interface. And this development board is also open source. If enthusiasts are interested, they can build a Chameleon Ultra from scratch. Of course, if there is no welding tool, we also provide formed development boards for sale (moderate price).
|
||||
|
||||
**Firmware:** Chameleon Ultra is a very powerful platform. We can develop various 14A protocol card simulations based on this platform. In terms of high-frequency card simulation, DXL has completed the development of high-performance MifareClassic Mini ->S50 ->S70 card. However, the development of cards for other technologies has not been completed, such as UL, UL-C, NTAG, etc. In terms of low-frequency card simulation, DXL has completed the development of EM410x, but the development of other technology cards has not been completed, such as FSK and PSK-related technology cards. For card reader, DXL has completed the reading, writing and decryption of M1 card, reading EM410x and writing to T5577. Others, such as the reading and writing of UL card and NTAG card, are not completed yet.
|
||||
|
||||
**Client:** At present, ChameleonUltra uses python to develop the CLI, cooperate with independent exe to perform the decryption task, and complete the decoupling of the business logic of the CLI and the decryption algorithm logic. Due to time reasons, DXL only completes commands such as device connection, M1 card data upload, M1 card detection log download and decryption, M1 card read and write block, and so on. The complete nested, rdsc, and autopwn instructions like PM3 have not yet been implemented, which may require our joint efforts. Finally, I believe that Chameleon Ultra is definitely not limited to CLI as a way of device interaction. Perhaps we can further develop PC-side GUI, and develop IOS and Android APP. USB+BLE support makes everything possible.
|
||||
@@ -32,7 +32,7 @@ APP_FW_VER_MAJOR := $(word 1,$(subst ., ,$(APP_FW_SEMVER)))
|
||||
APP_FW_VER_MINOR := $(word 2,$(subst ., ,$(APP_FW_SEMVER)))
|
||||
|
||||
# Enable NRF_LOG on SWO pin as UART TX
|
||||
NRF_LOG_UART_ON_SWO_ENABLED := 0
|
||||
NRF_LOG_UART_ON_SWO_ENABLED := 1
|
||||
|
||||
# Enable SDK validation checks
|
||||
SDK_VALIDATION := 0
|
||||
|
||||