---
title: ChipMan Script Language Reference
publisher: MP-Sys GmbH
language: en
version: "1.2b"
date: "2026-10-28"
status: "Public reference — derived from MP-Sys Technical Documentation 2026"
source: "ChipMan Technical Documentation 2026 (English), section 26"
---

# ChipMan Script Language Reference

**Official-source-based AI-ready reference · English · Version 1.2c**  
**Publisher:** MP-Sys GmbH · https://www.mpsys.de

This publication reorganizes the existing MP-Sys ChipMan Technical Documentation 2026 for use by customers, integrators, and AI assistants. **Command names and signature lines in the command catalog below are reproduced from the English technical documentation**, preserving placeholders and version-specific syntax. Supporting workflow guidance is editorial advice, *not* an additional ChipMan command specification.

> **Production note:** AI-generated code is a proposed script, not evidence of successful encoding. Test with the target card, reader, ChipMan version, key configuration, and downstream verification system before production. Never disclose production key values in prompts or scripts.

## 1. AI assistant instructions

When generating a ChipMan script from a card coding specification:

1. Identify the chip family and generation, starting card state, existing applications and files, reader, and required communication/authentication mode.
2. Extract exact AIDs, file IDs, access rights, offsets, lengths, encodings, key numbers and versions, expected verification behavior, and database mapping.
3. Use only documented ChipMan command names/signatures and the MP-Sys tested call patterns in section 4.5. **Derive DESFire standard fields using the encoding rules in section 4.4**, instead of treating calculable values as missing. If a ChipMan-specific argument remains `<...>` and has no worked example, do not invent its syntax.
4. Keep KeySafe aliases in scripts and actual keys exclusively in ChipMan KeySafe. Differentiate a KeySafe alias from a literal hex key.
5. Keep initial setup and recurring production coding separate. Do not include card formatting, application deletion, irreversible configuration, or key changes without an explicit requirement.
6. Choose length and encoding intentionally. Verify binary versus ASCII, hex text versus binary bytes, little-endian multi-byte fields where specified, leading zeroes, and DB field padding.
7. After writing, read back and compare when possible. A read command alone does not perform a comparison. Place output database changes **after** verified successful encoding.
8. Do not claim `UPDATE` has written a row if the target record may not exist. Verify row existence and affected row count using an appropriate database workflow.
9. If the spec omits a business choice (e.g. key alias, starting PICC key, application key versions, or how the fifth key should be used), state an explicit assumption or ask only for that essential missing requirement. **Do not ask for byte layouts already defined in section 4.4**. Distinguish a calculated encoding from a hardware-tested result.
10. Distinguish source-specified card behavior from assumptions and from a test-confirmed result.

### Suggested assistant output

- Requirement summary and known/unknown parameters
- KeySafe alias table (never key values)
- Initialisation script, if needed
- Production script
- Read-back and acceptance checks
- Warnings and test status

## 2. Script syntax and variables

```ini
; Comment
<Command>,<Parameter1>,<Parameter2>,...
```

| Notation | Meaning |
|---|---|
| `@Field` | Field from the current database row, e.g. `@Nummer`, `@ID` |
| `%UID` | UID automatically updated upon card detection; may be a random/external identifier depending on card settings |
| `%VAR1` … `%VAR8` | General script variables |
| `%EDITOR` | Hex editor/content buffer |
| `DefaultAES`, `Key01` | KeySafe aliases: values are resolved from KeySafe |
| `<source>` / `<target>` | Data source or destination as allowed by the individual command |

The published source uses mixed-case spellings for certain commands (e.g. `SQL,Refresh`); operational examples also use `SQL,refresh`. Preserve known working spelling in your deployment.

## 3. Command catalog (source syntax)

The following signatures are transcribed from *ChipMan Technical Documentation 2026*, section 26. Some entries are illustrative calls rather than general syntax. A placeholder such as `<...>` means that this edition does not specify the complete parameter sequence. For those entries, use the ChipMan script editor/assistant rather than guessing.


### 1 Contact Chip


```ini
ReadChip,<adr>,<len>,<target>
ReadChipHex,<adr>,<len>,<target>
ReadChip,CUR,<len>,<target>
WriteChip,<adr>,<source>
WriteChipHex,<adr>,<source>
WriteChip,CUR,<source>
PresentPIN,<pin>
ChangePIN,<old>,<new>
Protect,<adr>,<len>
```


### 2 MIFARE Classic


```ini
MifareAuth,<KeyA|KeyB>,<sector>,<Key>
MifareReadUIDHex,<target>
MifareReadBlock,<sector>,<block>,<target>
MifareReadBlockHex,<sector>,<block>,<target>
MifareWriteBlock,<sector>,<block>,<source>
MifareWriteBlockHex,<sector>,<block>,<source>
MifareWriteKeyAccess,<sector>,<KeyA>,<AccessBits>,<KeyB>
```


### 3 Ultralight / NTAG 21x


Mirror Option: 0=no mirror, 1=UID, 2=counter, 3=UID+counter, 4=TT, 5=TT+UID, 6=TT+counter, 7=TT+UID+counter. Password StartPage FF means no password.


```ini
UltralightReadPage,<page>,<target>
UltralightWritePage,<page>,<source>
NTAGReadPage,<page>,<target>
NTAGWritePage,<page>,<source>
WriteMultiPagesHex,<Start page>,<SOURCE>
NTAGGetURIMirrorAuth,<URI>,<URI SubString>,<add offset>,<Mirror Option>,<Password StartPageHex>,[(TT)],<target>
```


### 4 MIFARE Plus


The MIFARE Plus group includes SL0 WritePerso, SL0 CommitPerso, SL1 Authenticate AES, SL1 Switch Security Level and SL3 Authenticate AES.


```ini
MifarePlusWritePerso,<Block>,<Data>
MifarePlusCommitPerso
MifarePlusSL1Auth,<Block>,<Data>
MifarePlusSL1SwitchLevel,<Block>,<Data>
MifarePlusSL3Auth,<Block>,<Data>
```


### 5 DESFire EV1 / EV2 / EV3 / DUOX


ChipMan supports classic DESFire commands as well as EV2 Secure Messaging, AES-256, KeySets, TMAC and SDM/NDEF. Dialog assistants generate the required script lines.


```ini
DesfireAuth,<AID>,<Key>,<KeyNo>
DesfireAuthAES,<AID>,<Key>,<KeyNo>
AuthenticateEV2First,<Key>,<KeyNo>
DesfireGetUID,<target>
DesfireChangeKey,<...>
DesfireChangeKeyAES,<...>
DesfireChangeKeyExAES,<...>
DesfireChangeKeyEV2Ex,<...>
DesfireChangeKeySettings,<...>
DesfireFormatPICC
DesfireSelectApp,<AID>
DesfireCreateApp,<AID>,<KeySettings>,<NoOfKeys>
DesfireDeleteApp,<AID>
DesfireDeleteFile,<FileNo>
DesfireClearRecordFile,<FileNo>
DesfireReadDataAES,<FileNo>,<Offset>,<Length>,<target>
DesfireWriteDataAES,<FileNo>,<Offset>,<Length>,<source>
DesfireReadRecord,<...>
DesfireWriteRecord,<...>
DesfireGetValue,<...>
DesfireCredit,<...>
DesfireLimitedCredit,<...>
DesfireDebit,<...>
DesfireCommitTransaction
DesfireAbortTransaction
```


### 5.1 File Creation


```ini
DesfireCreateBackupFile,01,03,3012,200000
DesfireCreateValueFile,02,00,0000,00000000,64000000,0A000000,02
DesfireCreateLinearRecordFile,03,01,F012,200000,0A0000
DesfireCreateCyclicRecordFile,04,03,FEE2,030000,400000
DesfireCreateTMacFile,06,03,F012,<TMKey>,<TMKeyVersion>
DesfireCreateStdDataFileISO,E104,00,40,20E2,000400
DesfireChangeFile,00,00,30E2
```


### 5.2 AES-256 and KeySets


```ini
AuthenticateEV2First,DefaultAES,0
DesfireInitializeKeySet,01,02
DesfireChangeKeyEV2Ex,01,00,01,DefaultAES,AESKey1
DesfireFinalizeKeySet,01,01
DesfireRollKeySet,01
```


### 5.3 Configuration


```ini
DesfireAuthAES,000000,DefaultAES,00
DesfireSetConf,4,0003
```


### 6 NTAG 424 DNA


```ini
NTAGAuthenticateEV2First,<Key>,<KeyNo>
NTAGAuthenticateEV2NonFirst,<Key>,<KeyNo>
NTAGReadData,<FileNo>,<CommMode>,<Offset>,<Len>,<target>
NTAGWriteData,<FileNo>,<CommMode>,<Offset>,<Len>,<source>
NTAGGetUID,<target>
NTAGNDEFChangeFileSettings,<Settings>
NTAGChangeKeyEx,<KeyNo>,<OldKey>,<NewKey>,<NewKeyVersion>
NTAGChangeKey,<KeyNo>,<OldKey>,<NewKey>,<NewKeyVersion>
```


### 7 ISO7816 / iCODE


```ini
ISOSelect,<P1>,<AID|FID|DF>,<SW1SW2>
ISOReadBinary,<target>,<offset>,<len>,<SW1SW2>
ISOUpdateBinary,<source>,<offset>,<len>,<SW1SW2>
iCodeLockBlock,<Block>
```


### 8 LEGIC


RF Standard: 0=LEGIC, 1=ISO15693, 2=ISO14443A, 3=ISO14443B, 4=INSIDEContactless, 5=SONY FeliCa subset. The older LEGIC command group remains available as a legacy function for older readers.


```ini
LegicRF_STD,<RF Standard>
Legic_MODE,<Mode>
LegicStateIdle
LegicSearchTxp
LegicSelectTxp
LegicSearchSegment,<S_NUM>,<S_TYPE>,<STAMP>
Legic4xReadHex,<adr>,<Length>,<Target>
Legic4xWriteHex,<ADR>,<SOURCE>
Legic4xRead,<adr>,<Length>,<Target>
Legic4xWrite,<ADR>,<SOURCE>
Legic4xMakeCRC,<CRC_TYPE>,<CRC_ADR>,<ADR>,<DATA_LEN>
```


### 9 SAM


```ini
SAM_APDU,<cmd>,<Target>[,<SW1SW2>]
SAMAuthAES,0,00,DefaultAES,0
SAMChangeKeyEntry,<...>
SAMChangeKeyEntryAV2,<...>
SAMSwitchAV2,<AuthKey>
SAMUnlockAV2,<UnLockKey>,<KeyNo>,<KeyVer>
SAMDesfireAuthAES,<AID>,<DesfireKeyNo>,<SAMKeyEntry>,<SAMKeyVersion>,<AuthMode>,<DivInp>
SAMDesfireReadFile,<FID>,<Offset>,<Length>,<target>
SAMDesfireWriteFile,<FID>,<Offset>,<Length>,<source>
SAMDesfireChangeFileSettings,<FID>,<ComSet>,<AccessRights>
SAMDesfireChangeKey,<Case>,<DesfireKeyNo>,<KeyEntry>,<KeyEntryVer>,<KeyEntryNew>,<KeyEntryVerNew>,<P1>,<DivInp>
ProtosSAMAuth,<AuthKey>
ProtosSAMDesfireAuthDES,<AID>,<KeyNo>,<KeyIndex>
ProtosSAMDesfireAuthAES,<AID>,<KeyNo>,<KeyIndex>
ProtosSAMDesfireChangeKey,<Case>,<KeyIndexOld>,<KeyIndexNew>,<KeyNo>,<KeyVersion>
ProtosSAMDesfireChangeKeySettings,<Settings>
```


### 10 Reader-specific Commands


```ini
APDU,<cmd>,<Target>[,<SW1SW2>]
CardReset
CardColdReset
CheckForTAG
ReadFeigID,<target>
WriteFeigID,<source>
ElatecSetTagTypes,<TagTypesLF>,<TagTypesHF>
ElatecGetUID,<Target>
ElatecGetHybridUID,<TYPE_MASK_1>,<TYPE_MASK_2>,<TargetUID_1>,<TargetUID_2>
ElatecHitagReadPage,<PageNo>,<target>
ElatecHitagWritePage,<PageNo>,<source>
ElatecCommSet,<CommSet>
ElatecDesfireChangeKey,<...>
ElatecNTAGReadPage,<page>,<target>
ElatecNTAGWritePage,<page>,<target>
ElatecNTAGPwdAuth,<Password>,<PwdAck>
```


### 11 Tools / Data Processing


```ini
COPY,<source>,<target>,<start>,<len>
INSERT,<source>,<target>,<position>
WRITE,<source>,<target>,<start>,<len>
ROTATE,<source>,<target>
Replace,<target>,<from hex values>,<to hex values>
SwapNibbles,<source>,<target>
SwapNibblesBitwise,<source>,<target>
LSBTOMSB,<source>
INC,<source>,<step>
IncDay,<OldDate>,<IncValue>,<target>
IncMonth,<OldDate>,<IncValue>,<target>
IncYear,<OldDate>,<IncValue>,<target>
FILL_LEFT,<char>,<length>,<target>
FILL_RIGHT,<char>,<length>,<target>
COMPARE,%VAR1,%VAR2,<Errortext>
COMPARE_EQUAL,%VAR1,%VAR2,<Errortext>
LIST:BEGIN
LIST:END,<Target>
```


### 12 Conversion / Checksums / Cryptography


```ini
HEX,<source>
BCD,<source>
DEZ,<source>
HEXBIN,<source>
BinaryToHex,<source>,<target>
HexToBinary,<source>,<target>
DEZHEX,<source decimal>,<target hex>,<target length>
TrailingZeros,<source>,<target>
ADDMOD10,<source>
ADDLMD10,<source>
AES,<source hex>,<key hex>,<target hex>
AES_CMAC,<Key hex>,<source hex>,<target hex>
AES_DIV,<Key hex>,<DivInput hex>,<target hex>
XOR,<source hex>,<value hex>,<target hex>
ADDXOR,<source>
ADDINVXOR,<source>
CRC8,<source hex>,<polynom hex>,<init hex>,<target>
CRC,<source>,<target>
CRC16,<source hex>,<target hex>
CRC16DM,<source hex>,<target hex>
CRC32,<source hex>,FFFFFFFF,<target hex>
MD5Hash,<source>,<target>
SHA256Hash,<source>,<target>
RandomHex,<length>,<target>
CipherDLL,<P1>,<Input>,<Output>
```


### 13 SQL


```ini
SQL,select * from <table>
SQL,insert into <table> (<FIELD>,...) VALUES ('<VALUE>','...')
SQL,update <table> SET <FIELD=VALUE> WHERE <CONDITION>
SQL,Refresh
SetDBField,<FIELD>,<VALUE>
DBFIRST
DBLAST
DBNEXT
DBPRIOR
ExecSQL,<target>,<SQL statement>
NextCardID
```


### 14 Files / External Programs


```ini
SaveJob,<JobFileName>
LoadFile,<Filename>,<target>
SaveFile,<Filename>,<source>
AppendFile,<Filename>,<source>
LoadFileBin,<Filename>,<target>
SaveFileBin,<Filename>,<source>
DeleteFile,<Filename>
ReadXMLNode,<Filename>,<XPath>,<Attribute>,<target>
ExtApp,<Filename>,<parameter>
```


### 15 NDEF


VERSION:3.0


```ini
CreateNDEF,<target>,<MB-TNF>,<Type>,<ID>,<Payload>
GetURIMirrorOffset,<URI>,<URI SubString>,<add offset>,<target>
NDEFCreate
NDEFAddRecord,<RecordType>,[<Protocolbyte>],<Payload>
NDEFEncode,<Target>
VCARD:BEGIN
N:@Name;@Vorname;;@Titel;
FN:@Titel @Vorname @Name
TEL;type=WORK;VOICE:@TelFirma
TEL;type=CELL;MOBILE:@Mobil
EMAIL;type=WORK:@Email
ORG:@Firma
URL;WORK:@Url
VCARD:END,%var1
```


### 16 Flow and Error Control


```ini
Refresh
Wait,<time in ms>
CardWait,<timeout in ms>
PrintCard
ExportCard,<Filename>,<PixelResX>,<PixelResY>,<page>,<rotate>
Exit
ErrorHaltOn
ErrorHaltOff
ShowErrorMessages
AutoEjectCardOnError
try
except
```


## 4. Verified workflow patterns and database integration

### 4.1 Database UID return using the current record

The following SQL commands have been exercised in ChipMan for a joined input/output display with a separate writable output table:

```sql
SELECT I.ID, I.Nummer, O.UID
FROM [Input] AS I
LEFT JOIN [Output] AS O ON I.ID = O.ID
ORDER BY I.ID;
```

The join is for **reading**. Updating the joined ADO dataset directly can fail with insufficient key-field information. The separate SQL script command is:

```ini
; Execute only after encoding and verification have succeeded
SQL,UPDATE [Output] SET UID = '%UID' WHERE ID=@ID
SQL,refresh
```

`UPDATE` requires an existing matching `Output.ID`. UID storage should accommodate the full hex UID; for a 7-byte UID use at least 14 characters rather than `NCHAR(10)`.

### 4.2 NTAG 424 DNA NDEF / SDM workflow

The following is an **illustrative project pattern**, not a universally applicable configuration. It shows working ChipMan command names while omitting site-specific settings and private keys:

```ini
; Select NDEF application and NDEF file
ISOSelect,04,D2760000850101,9000
ISOSelect,00,E104,9000

; %VAR1 contains the prepared NDEF file bytes
ISOUpdateBinary,%VAR1,0,0,9000
ISOReadBinary,%EDITOR,0,255,9000

; Authenticate and apply *project-specific* file settings
NTAGAuthenticateEV2First,DefaultAES,00
; NTAGNDEFChangeFileSettings,<project-specific verified settings>

; Change keys only when required, with authorised KeySafe entries
; NTAGChangeKeyEx,01,DefaultAES,Key01,01
```

Use `GetURIMirrorOffset,<URI>,<URI SubString>,<add offset>,<target>` to calculate offsets when the NDEF layout is compatible; verify returned offsets against the final binary file layout. SDM file settings, key roles and key versions must match the customer's specification and verifier.

### 4.3 DESFire application and AES data file

For DESFire, follow the documented parameter forms rather than assuming a particular EV3 or EV2 secure messaging implementation:

```ini
ErrorHaltOn
CheckForTAG
; AID, keys, permissions and file size must be specified per project
DesfireAuthAES,000000,DefaultAES,00
DesfireCreateApp,123456,0B,83
DesfireAuthAES,123456,DefaultAES,00
DesfireCreateStdDataFile,00,03,2012,100000
```

**Illustrative only:** this setup applies to a card whose PICC master authentication and application state meet those assumptions. Do not run it against existing applications without checking state and authorisation.


### 4.4 DESFire EV1/EV2/EV3 parameter encoding guide (AI guidance)

**Scope and evidence labels:** The ChipMan command spellings and syntax examples come from the published MP-Sys technical documentation; the byte interpretations below are **DESFire card-format decoding rules**, not extra ChipMan commands. This section is intended to let assistants *calculate standard parameters* instead of requesting them repeatedly. Real card state, key values, and ChipMan version compatibility still require validation.

#### A. Application creation: key type and key count

```ini
DesfireCreateApp,<AID>,<KeySettings>,<KeyTypeAndCount>
```

- `AID`: three-byte application identifier written as six hex characters in the same notation as the documented ChipMan examples; e.g. `112233`. Note that the card-level byte order of an AID is protocol-dependent; use the ChipMan command convention for script values.
- `KeySettings`: one hexadecimal byte; the **upper nibble** selects the key required to change application keys, while the **lower nibble** contains additional permissions. In the key-change nibble, `0` corresponds to application key 0, `4` to key 4. Other values have special semantics; do not select them unless specified.
- `KeyTypeAndCount`: for standard AES-128 application keys, `0x80 | key_count` where the key count is in the low nibble. Thus `83` = 3 AES keys and `85` = 5 AES keys. The `80` byte alone is **not** a five-key declaration.
- Preserve unspecified lower-nibble permissions deliberately. The documented example uses `0B` for `KeySettings`. If the project explicitly wants **key 4 to authorize application-key changes** and the *other settings are intentionally the same as in the documented `0B` example*, use `4B`. Neither `0B` nor `4B` is a universal default.

| Example | Explanation |
|---|---|
| `DesfireCreateApp,123456,0B,83` | Original MP-Sys example: 3 AES-128 application keys. |
| `DesfireCreateApp,112233,4B,85` | Calculated example: 5 AES-128 keys, key 4 required for changing keys, lower settings nibble `B` retained. |

**Do not confuse** the application key-change permission in `KeySettings` with the **file Change Access Rights** nibble (below). They control different objects.

#### B. Standard Data File communication mode and access rights

```ini
DesfireCreateStdDataFile,<FileNo>,<CommMode>,<AccessRights>,<FileSizeLE3>
```

This general parameter mapping is reconstructed from the MP-Sys example `DesfireCreateStdDataFile,00,03,2012,100000` and standard DESFire file-setting layout; verify if the ChipMan GUI presents additional options for your version.

- `FileNo`: two hex digits such as `00` and `01`.
- `CommMode`: `00` = plain, `01` = MACed, `03` = fully enciphered (standard DESFire file communication settings).
- `AccessRights`: four hexadecimal nibbles in order **RW | Change | Read | Write**. A nibble `0..D` identifies the corresponding application key; `E` means free access and `F` means never/no access. For RW=3, Change=0, Read=1, Write=2 the bytes are `3012`.
- `FileSizeLE3`: file size encoded as a **three-byte little-endian** hexadecimal string, e.g. 16 decimal = `10 00 00` = `100000` in the ChipMan script. Not `000010`.
- The access-rights nibble for *Change* controls modification of file settings, not replacement of application AES keys.

| Intent | Value |
|---|---|
| File 00, 16 bytes, encrypted, RW key3 / Change key0 / Read key1 / Write key2 | `DesfireCreateStdDataFile,00,03,3012,100000` |
| File 01, same rights and size | `DesfireCreateStdDataFile,01,03,3012,100000` |

#### C. Authentication and KeySafe aliases

Documented MP-Sys examples use these **actual command shapes**:

```ini
DesfireAuthAES,000000,DefaultAES,00
DesfireAuthAES,112233,DefaultAES,04
DesfireChangeKeyAES,00,00,AESKey0
DesfireChangeKeyExAES,01,00,DefaultAES,AESKey1
```

The command catalog has a four-argument general form for `DesfireChangeKeyAES`, while MP-Sys tested examples use its three-argument form. The three-argument form shown here comes from MP-Sys example scripts (e.g. `DesfireChangeKeyExAES,01,00,DefaultAES,Key1`). **Do not generalize undocumented arguments** or replace existing alias names silently. The proven example uses the arguments `<KeyNo>,<Version>,<OldKeyAlias>,<NewKeyAlias>` for `DesfireChangeKeyExAES`, with version `00`. Use the currently valid change-authorizing authentication key; key changes depend on application KeySettings.

KeySafe aliases must exist with the exact spelling used. A typical test setup might have `DefaultAES`, `AESKey0`, `AESKey1`, `AESKey2`, `AESKey3`, `AESKey4`. New card defaults, application defaults, and any required PICC authentication are distinct from the chosen production keys. Never put actual secret material into a prompt or script example.

#### D. Worked case: AID 112233, five AES keys, two encrypted files

**Requirements:** DESFire EV2, app AID `112233`, 5 AES keys, file `00` and `01` as 16-byte encrypted standard data files; file permissions RW=3, Change=0, Read=1, Write=2; application *key changes* authorized by key 4. **Explicit assumptions:** a new card with PICC AES key `DefaultAES`; AID does not exist; application keys start at default zero AES; lower key-settings nibble intentionally `B`; KeySafe aliases for five intended new keys exist. The following is a **test-oriented initialization template**, not a proven production sequence.

```ini
; DESFire EV2 | Initialization (new card only)
; AID 112233 | 5 AES keys | file 00 + 01, 16 bytes, encrypted
; Key 4 controls application-key changes; Key 0 controls file settings
ErrorHaltOn
CheckForTAG
DesfireAuthAES,000000,DefaultAES,00
DesfireCreateApp,112233,4B,85
DesfireAuthAES,112233,DefaultAES,04
DesfireCreateStdDataFile,00,03,3012,100000
DesfireCreateStdDataFile,01,03,3012,100000
; Remaining key migration requires the correct existing-key
; state and testing of ChipMan's ChangeKeyAES/ChangeKeyExAES
; argument behavior; avoid assuming the keys are already changed.
```

**Key migration guidance (NOT a claim of completion):** Under `4B`, authenticate with the *current* key 4 to change application keys. Arrange migration so the key that authorizes changes stays usable throughout the sequence (e.g. plan changing key 4 last, if supported by the card's change-key rules). After every relevant key change, confirm the resulting key version and authentication under the correct key. The example above **creates the application and files only**; it does not switch keys 0–4, and it must not be reported as a completely personalized or secure card.

**Required checks:** Read application key settings and file settings; confirm key count/type, file numbers, file size and enciphered communication; exercise authorized/unauthorized key access; conduct an authenticated write/read/compare using supported ChipMan commands; do not format/delete an existing application on rerun. Check the handling of file-setting change permission and application-key change permission independently. Read-back and key-version tests should be run on an expendable test card.

#### E. Additional AI response rules for DESFire jobs

1. Calculate known bitfields / multi-byte encodings explicitly in a small table and give a complete `DesfireCreateApp` / `DesfireCreateStdDataFile` call whenever the inputs are sufficient.
2. If asked to produce a full key migration, use documented ChipMan call shapes and disclose any unverified key-change sequencing; **never claim that the mere creation of five key slots changes their values**. In multi-key changes, **reauthenticate with the current authorized application key immediately before every `DesfireChangeKeyExAES` call**; see the rule and tested example in section 4.5.
3. Do not imply that a dedicated authentication command is equivalent to a DESFire file's enciphered communication mode; both must be configured appropriately.
4. If the user says 'Key 4 changes keys', distinguish application key migration settings (`KeySettings` upper nibble) from file-setting changes (`AccessRights` Change nibble).
5. Keep calculated, documented and hardware-verified claims separate. A code example without real-card testing is a test draft.

**AI rule — reauthenticate before every application-key change (MP-Sys tested workflow):** When a script changes several DESFire application keys, generate a fresh `DesfireAuthAES,<AID>,<AuthorizedKeyAlias>,<AuthorizedKeyNo>` immediately before **each** `DesfireChangeKeyExAES` invocation. Use the current authorizing key from the application's `KeySettings` (for example key 0 for `0B`), not necessarily the key being changed. After changing that authorizing key itself, authenticate with its **new** KeySafe alias before changing further keys. If the application is configured with a different change authorizer (for example key 4 with `4B`), adapt the authentication and key-change order; do not blindly reuse the key-0 sequence. This repeats the successfully executed MP-Sys workflow and is recommended even if a reader/card combination might retain authentication across an individual change.

**Required generation pattern (`KeySettings=0B`):**

```ini
DesfireAuthAES,112233,EV2_Key0,00
DesfireChangeKeyExAES,01,00,DefaultAES,EV2_Key1
DesfireAuthAES,112233,EV2_Key0,00
DesfireChangeKeyExAES,02,00,DefaultAES,EV2_Key2
```

### 4.5 DESFire AES key changes — MP-Sys hardware-tested example

**Evidence level: hardware-tested by MP-Sys.** The original `DesfireCard.job` script (6 November 2023), with corrected application labels, was executed successfully on a physical DESFire card as confirmed by MP-Sys in October 2026. This confirms the command forms and the execution of that specific job; it does **not** independently certify each resulting permission, diversified-key value, or card-generation-specific behavior.

#### A. Known-working key-change commands

The tested MP-Sys script uses these exact patterns:

```ini
; Change the key used to authenticate (three-parameter form)
DesfireAuthAES,4600DD,DefaultAES,00
DesfireChangeKeyAES,00,00,App_DD0046_Key0

; Change another key, supplying previous and replacement KeySafe aliases
DesfireAuthAES,4600DD,App_DD0046_Key0,00
DesfireChangeKeyExAES,01,00,DefaultAES,App_DD0046_Key1
```

**Parameter definitions for the tested forms:**

| Command | Tested arguments | Meaning |
|---|---|---|
| `DesfireChangeKeyAES` | `<KeyNo>,<Version>,<NewKeySafeAlias>` | Change the authenticated key in this tested workflow; `00` is the key-version argument. |
| `DesfireChangeKeyExAES` | `<KeyNo>,<Version>,<OldKeySafeAlias>,<NewKeySafeAlias>` | Change another application key, supplying previous and new values through KeySafe. |
| `DesfireAuthAES` | `<AID>,<KeySafeAlias>,<KeyNo>` | Authenticate using a selected application and numbered AES key. |

**Compatibility clarification:** The pre-existing command catalog also includes the general four-argument form `DesfireChangeKeyAES,<KeyNo>,<Ver>,<Crypt>,<Key>`. Do **not** delete or silently overwrite that catalog entry. The MP-Sys script demonstrates that the *three-argument* form is also valid in the tested workflow. No claim is made here that the two forms are interchangeable in every mode or version.

#### B. Fixed AES application keys, 14-key application

This condensed excerpt uses neutral aliases and the **tested call sequence**. `4600DD` is ChipMan's byte notation for the intended application ID `0xDD0046`; the order matters. In the original job, key 0 was changed first, then the card was reauthenticated using the new key 0 to change the remaining keys.

```ini
; App 0xDD0046 has been created as:
; DesfireCreateApp,4600DD,0B,8E
DesfireAuthAES,4600DD,DefaultAES,00
DesfireChangeKeyAES,00,00,App_DD0046_Key0
DesfireAuthAES,4600DD,App_DD0046_Key0,00
DesfireChangeKeyExAES,01,00,DefaultAES,App_DD0046_Key1
DesfireAuthAES,4600DD,App_DD0046_Key0,00
DesfireChangeKeyExAES,02,00,DefaultAES,App_DD0046_Key2
; Repeat the same auth + change pattern for keys 03 through 0D.
; The original MP-Sys job changes all 14 keys (00..0D).
```

**Do not copy this rekey order into an application with `KeySettings=4B` without adapting it.** In the hardware-tested example `KeySettings=0B`, key 0 authorizes key changes. When a different application key authorizes changes, authenticate with that *current* authorizing key and plan the change order accordingly.

#### C. Complete tested application/file-creation layout

The hardware-tested MP-Sys job used two applications, `4600DD` and `4700DD`, each with 14 AES keys (`8E`), six encrypted 32-byte Standard Data Files (`03`, `200000`), and file-specific access-right encodings:

```ini
DesfireCreateApp,4600DD,0B,8E
DesfireCreateApp,4700DD,0B,8E
; Authenticate to the relevant application using its current key 0 first.
DesfireCreateStdDataFile,00,03,302F,200000
DesfireCreateStdDataFile,01,03,504F,200000
DesfireCreateStdDataFile,02,03,706F,200000
DesfireCreateStdDataFile,03,03,908F,200000
DesfireCreateStdDataFile,04,03,B0AF,200000
DesfireCreateStdDataFile,05,03,D0CF,200000
```

**Illustrative only:** The two `CreateApp` commands above cannot be run consecutively without the necessary PICC-level authentication steps, and the file commands require the application authentication shown in the original job. Treat this listing as a parameter matrix, **not** a standalone executable job. The original file creates files separately for each application and writes 32 bytes per file using the corresponding authenticated write key.

### 4.6 Card-specific AES-128 diversification — NXP AN10922

**Technical source:** NXP application note **AN10922**, *Symmetric key diversifications*, Rev. 2.2 (2 July 2019): https://www.nxp.com/docs/en/application-note/AN10922.pdf. NXP defines AES-128 key diversification from a 16-byte base key and a diversification input. The exact input construction is application-specific. Do not confuse the document number with AN10992.

**MP-Sys example input composition (project-specific):** `01 || UID || AIDbytes || ContextBytes`, where `01` is the AES-diversification domain constant, `UID` is the actual card UID, `AIDbytes` uses the ChipMan byte sequence `4700DD`, and `ContextBytes` are ASCII data converted to hex. The same input and byte order must be used in the verifier/reader system. Avoid sending any real base key or secret context in an AI prompt.

```ini
; Example only: nonsecret context;  actual base keys stay in KeySafe
copy,ProjectContext,%VAR2,1,50
HEX,%VAR2
AES_CMAC,App_DD0047_Key0,01%UID4700DD%VAR2,%VAR1
UpdateKeySafe,DivKey0,%VAR1
DesfireAuthAES,4700DD,DefaultAES,00
DesfireChangeKeyAES,00,00,DivKey0

; Following keys are diversified separately under their own base aliases
DesfireAuthAES,4700DD,DivKey0,00
AES_CMAC,App_DD0047_Key1,01%UID4700DD%VAR2,%VAR1
UpdateKeySafe,DivKey1,%VAR1
DesfireChangeKeyExAES,01,00,DefaultAES,DivKey1
```

The original tested job repeats this pattern through key `0D`, deriving `DivKey0`, `DivKey1` ... `DivKeyD` separately using the corresponding base KeySafe aliases. `UpdateKeySafe` stores the *derived* result by an alias for immediate use by later ChipMan commands.

**Cryptographic caution:** AN10922 describes a specific diversification procedure, including input padding/CMAC final-block treatment. Do not assume that an arbitrary library CMAC call over `01||M` is necessarily equivalent in every implementation. The MP-Sys script is a tested ChipMan workflow, but interoperability with an external reader must be validated against AN10922 test vectors or the intended external verifier. A successful card write alone does not establish that independently computed diversified keys match.

**AI requirements for this pattern:**

1. Distinguish raw `AES_CMAC` calculations from the application note's full diversification procedure; preserve the supplied ChipMan workflow when reproducing a verified project.
2. Do not alter the diversification data order or AID byte order. Do not change `DefaultAES` to a new alias before the card key has actually been changed.
3. For a `0B` application, authenticate with the newly set application key 0 before changing other keys. For other KeySettings, use the applicable authorizing key.
4. Never publish actual key values, customer-specific secret context strings, or derived production keys; use neutral KeySafe aliases and placeholders.
5. Treat hardware-tested call syntax as stronger evidence than a speculative extension, while retaining documented alternative signatures and their applicability caveats.

### 4.7 Worked DESFire EV2 example — five AES keys and two encrypted files

**Purpose:** Make an AI response useful when the task is to create an AID with encrypted files, without pretending that default keys have already been personalized.

```ini
; Initial setup for a NEW card only, factory/default PICC AES key
; AID 112233, five AES-128 keys, files 00 + 01, size 16 bytes
; File rights: RW=3, Change=0, Read=1, Write=2
; Application KeySettings 0B: key 0 manages app-key changes
ErrorHaltOn
ShowErrorMessages
CheckForTAG
DesfireAuthAES,000000,DefaultAES,00
DesfireCreateApp,112233,0B,85
DesfireAuthAES,112233,DefaultAES,00
DesfireCreateStdDataFile,00,03,3012,100000
DesfireCreateStdDataFile,01,03,3012,100000

; Switch authenticated key 0, then all other application keys
DesfireAuthAES,112233,DefaultAES,00
DesfireChangeKeyAES,00,00,EV2_Key0
DesfireAuthAES,112233,EV2_Key0,00
DesfireChangeKeyExAES,01,00,DefaultAES,EV2_Key1
DesfireAuthAES,112233,EV2_Key0,00
DesfireChangeKeyExAES,02,00,DefaultAES,EV2_Key2
DesfireAuthAES,112233,EV2_Key0,00
DesfireChangeKeyExAES,03,00,DefaultAES,EV2_Key3
DesfireAuthAES,112233,EV2_Key0,00
DesfireChangeKeyExAES,04,00,DefaultAES,EV2_Key4
```

**Status:** Constructed from documented parameter rules plus a *different* MP-Sys hardware-tested key-change pattern. The exact five-key combination above has **not** been separately tested by MP-Sys as one job. It is a ready-to-test example, not a certified production script. All `EV2_Key*` aliases must exist in KeySafe. `0B` means key 0 authorizes application key changes; if the customer instead requires key 4 as change authorizer, adjust `KeySettings` (e.g. `4B` with the same lower settings nibble) **and** the key-change authentication sequence. File `Change=0` is independent of that choice.

**Production checks:** Confirm AID and AES key count, file-0/1 type and 16-byte size, encrypted communication, file access rights, key versions and successful authentication with new keys. Test writing and reading under the intended authorizations, then compare 16-byte results; do not claim verification merely because the file-creation commands returned success.

## 5. KeySafe and handling of customer projects

KeySafe names in scripts are aliases, not keys. Keep actual values inside ChipMan KeySafe; avoid publishing customer-specific security values in documentation, tickets, screenshots or AI chats. Where a customer supplies a restricted coding specification, share only authorised material and obtain permission before publishing a reusable example.

## 4.8 NTAG213 — encode an HTTPS URI as an NFC Forum Type 2 NDEF message

**Status: protocol-derived, ChipMan command syntax documented, not yet hardware-verified as a complete workflow.** This example applies to an unprotected, NFC Forum Type 2-compatible NTAG213 with a valid Capability Container (CC). It does **not** apply unchanged to NTAG 424 DNA, whose file access workflow is different.

**User request:** Store `https://test.de/info` in a tag so a standard smartphone reads the URL.

### Fully prepared write example (20 bytes, pages 04–08)

```ini
; NTAG213 - HTTPS URL as NDEF URI record
; Preserves manufacturer/lock/CC pages 00-03
; Requires valid Type 2 CC and writable pages 04-08
ErrorHaltOn
ShowErrorMessages
CheckForTAG
WriteMultiPagesHex,4,0311D1010D5504746573742E64652F696E666FFE
; Read-back must be performed and checked before production approval
NTAGReadPage,4,%VAR1
NTAGReadPage,5,%VAR2
NTAGReadPage,6,%VAR3
NTAGReadPage,7,%VAR4
NTAGReadPage,8,%VAR5
```

The write payload is 20 bytes in hexadecimal: `03 11 D1 01 0D 55 04 74 65 73 74 2E 64 65 2F 69 6E 66 6F FE`.

| Field | Value | Interpretation |
| --- | --- | --- |
| `03` | NDEF Message TLV tag | NFC Forum Type 2 tag NDEF area |
| `11` | Length: 17 bytes | NDEF message length, excludes TLV header and terminator |
| `D1` | NDEF record header | MB/ME/SR flags, TNF well-known |
| `01` | Type length | One-byte type |
| `0D` | Payload length | 13 bytes: one URI prefix byte plus 12 ASCII URL bytes |
| `55` | Record type `U` | NFC Forum URI record |
| `04` | URI identifier | `https://` prefix |
| `746573742E64652F696E666F` | `test.de/info` | Remaining URI as ASCII bytes |
| `FE` | Terminator TLV | End of TLV area |

The first NDEF data page is page 4. Each NTAG213 page contains 4 bytes; therefore 20 bytes occupy five pages, 4 through 8. Do not write manufacturer, static lock, or CC pages 0–3. This example assumes the CC is already valid and the area has not been password-protected or locked.

### Dynamic URL construction with ChipMan NDEF commands

ChipMan also documents `CreateNDEF,<target>,<MB-TNF>,<Type>,<ID>,<Payload>` as well as `NDEFCreate`, `NDEFAddRecord` and `NDEFEncode`. These construct an NDEF record/message; **do not assume** that they automatically add the Type 2 TLV framing needed before `WriteMultiPagesHex`. A verified dynamic record-to-TLV example should be added separately after testing the exact output format in ChipMan.

### AI instructions for NTAG21x URI requests

- For simple URL requests on NTAG213/215/216, prefer a complete, correctly framed Type 2 NDEF example with `WriteMultiPagesHex` over a partial builder-only script.
- Calculate URI prefix, NDEF payload length, record length, TLV length, page count and end terminator explicitly. Do not confuse bytes with hexadecimal characters.
- Use the official ChipMan command syntax `WriteMultiPagesHex,<Start page>,<SOURCE>` (start page decimal/hex interpretation depends on command conventions; the sample uses page `4`).
- Do not write to page 0–3, or alter lock bits/password protection, unless separately requested.
- Include explicit read-back and smartphone testing. Do not claim the read-back was automatically compared when the example only reads pages into variables.
- For arbitrary or variable-length URLs, generate and validate an appropriate TLV byte stream; do not reuse the fixed sample bytes.
- For NTAG 424 DNA use the ISOSelect / ISOUpdateBinary path and its own access/configuration requirements, not this Type 2 page-write example.

## 4.9 NTAG21x — ChipMan CreateNDEF + WriteMultiPagesHex (MP-Sys supplied example)

**Origin:** MP-Sys GmbH supplied the following concrete ChipMan script. Its command pattern is supplied by the software developer; the example has not separately been reported as hardware-tested in this conversation. Use on writable, appropriately configured NTAG21x cards. The supplied script uses URI prefix **02 = `https://www.`**, so `test.de/info` becomes **`https://www.test.de/info`**, not `https://test.de/info`. For the latter use **04 = `https://`**.

### Original MP-Sys example: https://www.test.de/info

```ini
; CreateNDEF,<target>,<MB-TNF>,<Type>,<ID>,<Payload>
; URI prefix 02 = https://www.
CreateNDEF,%var1,D1,55,02,test.de/info
; Type 2 NDEF TLV wrapping as used by MP-Sys
copy,03%var1FE00,%var1,1,255
WriteMultiPagesHex,4,%var1
; Tag-specific formatting commands from the supplied example:
UltralightWritePageHex,2,ED480000
UltralightWritePageHex,3,E1101000
```

### Recommended example for https://test.de/info (already NDEF-formatted NTAG213)

```ini
ErrorHaltOn
ShowErrorMessages
CheckForTAG
; URI prefix 04 = https://
CreateNDEF,%VAR1,D1,55,04,test.de/info
copy,03%VAR1FE00,%VAR1,1,255
WriteMultiPagesHex,4,%VAR1
; Verify by reading pages and testing with a smartphone.
; Do not change pages 2 or 3 on an already formatted tag.
```

**Interpretation of the ChipMan-specific preparation:** `CreateNDEF` produces the URI NDEF record data expected by the supplied pattern. The subsequent `copy,03%VAR1FE00,...` prepares Type 2 TLV framing for `WriteMultiPagesHex`, and the trailing `00` provides padding. The precise byte sequence should be inspected with ChipMan before adapting the pattern to arbitrary record types or larger URLs. `CreateNDEF` is not itself a tag write command.

**Do not generalize the page-2 write.** In the supplied example `UltralightWritePageHex,2,ED480000` writes to a page containing static lock bytes and other control data. These bytes are tag-state dependent and may affect write protection irreversibly. Do **not** include this command in a generic NDEF URL script, and do not infer that it is required for ordinary NDEF encoding.

**Capability Container:** `UltralightWritePageHex,3,E1101000` is part of that supplied configuration, but it must not be blindly applied to every NTAG213. A normal NTAG213 Type 2 CC often uses `E1101200` for the 144-byte user memory size; confirm the tag type and existing CC first. Never modify the CC simply to write an NDEF record if the card is already correctly formatted.

### NFC Forum URI identifier byte examples

| Code | URI prefix |
| --- | --- |
| `01` | `http://www.` |
| `02` | `https://www.` |
| `03` | `http://` |
| `04` | `https://` |

### Rules for AI-generated NTAG21x scripts

1. **Prefer the MP-Sys `CreateNDEF` → `copy,03%VAR1FE00` → `WriteMultiPagesHex,4,%VAR1` workflow** for straightforward URI requests on a writable, properly formatted NTAG213/215/216. Do not unnecessarily stop after `NDEFCreate` / `NDEFEncode` without writing to the tag.
2. Match the URI identifier to the **exact URL**. Code `02` adds `https://www.`; code `04` adds `https://` without `www`.
3. Keep irreversible/static lock bytes (page 2) and Capability Container (page 3) **out of standard URL-writing scripts**. Document these separately as device- and state-specific formatting steps.
4. Validate that the framed NDEF message fits the available writable memory and is aligned/handled appropriately by `WriteMultiPagesHex`.
5. Read back and verify the final URL using a phone or another NDEF reader. Reading pages without an explicit byte comparison does not prove verification.
6. NTAG424 DNA is a **different workflow** (ISOSelect/ISOUpdateBinary and possibly SDM); do not apply NTAG21x page writes to it.

## 6. Production acceptance checklist

- Card/chip type, current state, key type and communication mode verified
- KeySafe aliases and key versions validated
- Input encoding, file sizes, offsets, access rights and data format verified
- Card read-back and any cryptographic MAC/server checks completed
- Production SQL row association confirmed; no false success on a zero-row update
- Logging/export excludes secret key material
- Repeated-card detection and reruns do not accidentally rekey or reformat the card
- A representative pilot card accepted before batch release

## 7. Source and editorial boundaries

**Primary reference:** MP-Sys GmbH, *ChipMan Technical Documentation 2026* (English), section 26, "Script Editor Command Reference" and section 29, "Appendix — Script Demos". The catalog is source-derived; sections 1, 2, 4–6 are AI-oriented editorial guidance and examples. See the original ChipMan command assistant for parameters not fully specified in the technical documentation.

**Status:** Version 1.2b prepared for public release after MP-Sys editorial approval. The advanced examples are supplied by MP-Sys and marked separately as tested or extrapolated. Hardware tests remain specific to each customer project.