ChipMan Script Language Reference

Official-source-based AI-ready reference · English · Version 1.2
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

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

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

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

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.

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.

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.

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

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

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

5.3 Configuration

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

6 NTAG 424 DNA

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

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.

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

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

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

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

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

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

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

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

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:

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:

; 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:

; 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:

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

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.

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

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.

C. Authentication and KeySafe aliases

Documented MP-Sys examples use these actual command shapes:

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.

; 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 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 uses 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.

Required generation pattern (KeySettings=0B):

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:

; 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:

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.

; 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:

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.

; 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.

; 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.

; 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

CreateNDEF,%var1,D1,55,02,test.de/info
copy,03%var1FE00,%var1,1,255
WriteMultiPagesHex,4,%var1
; Formatting commands from the supplied example, NOT generic defaults:
UltralightWritePageHex,2,ED480000
UltralightWritePageHex,3,E1101000

ErrorHaltOn
ShowErrorMessages
CheckForTAG
CreateNDEF,%VAR1,D1,55,04,test.de/info
copy,03%VAR1FE00,%VAR1,1,255
WriteMultiPagesHex,4,%VAR1

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.2c 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.