eLox

Note: Live property IDs, room numbers, and full supervisory PINs below have been masked with letters like XX, YY, or ABCD to avoid publishing working credentials for active facilities.

The hospitality industry has a quiet habit of overcharging for commodity tech. Vendors take standard access control hardware, lock it behind proprietary software, and charge massive premiums for gear you could otherwise source directly for cheap.

A good example is the ecosystem around hotel locks sold under names like eLox, eLocks, and Securelox (elocks.online). They charge around $800 for a basic desktop card encoder machine.

Underneath the plastic, these are just standard 13.56 MHz RFID readers writing fixed payloads to ordinary cards. Here is how I audited the tags, worked out the memory layout with a Proxmark3, and replaced their expensive encoder setup with a $65 USB-C card reader.

Instead of using a standard USB reader that connects to a PC using normal drivers, this system uses a bulky, battery-powered handheld terminal that looks like an oversized calculator. It has a basic LCD screen, a numeric keypad, and an internal RFID coil.

To issue cards or change settings, staff punch 8-digit supervisor PINs directly into the keypad:

• 8632XXXX – Master and emergency keys
• 3090XXXX – Building and guest keys
• 5962XXXX – Program lock and sync internal clock

These PINs are static codes built into the system rather than unique keys generated per property. Once you enter the PIN, the handheld writes fixed data blocks straight to the card.

Better Hardware Options

You do not need their expensive terminal to read or write these cards. Any standard 13.56 MHz reader will work:

• Research and testing: A Flipper Zero or Proxmark3 works fine for dumping sectors, sniffing traffic, and emulating tags.
• Front desk production: Standard USB CCID readers work out of the box on macOS, Linux, and Windows:
  • ACS ACR122U: Older USB-A model. Usually under $40, reliable, and supported by almost every library out there.
  • ACS ACR1552U: Modern USB-C version. Costs around $65, reads faster, and plugs straight into modern machines without USB adapters.

The vendor documentation (including their security page at elocks.online/security) claims the system uses MIFARE Ultralight cards.

Scanning an actual physical keycard with a Proxmark3 (hf search) shows something different:

[=] --- Tag Information ---
[+] UID: XX XX XX XX
[+] ATQA: 00 04
[+] SAK: 08 [2]
[+] Type: NXP MIFARE Classic 1K | Plus 1K (4-byte UID)
[+] Proprietary non-standard encryption: Yes (Crypto1)

The system uses standard MIFARE Classic 1K cards, not Ultralight. Security relies on default sector keys and unencrypted data blocks.

Looking at the card sectors, the lock only actually checks a single 16-byte block (Line 1) to grant access. The encoder terminal also writes a second 16-byte block (Line 2) full of filler padding (030303...), but the lock opens completely fine even if you leave Line 2 off entirely.

Comparing Guest Cards

Here is what two valid guest cards look like after dumping them (property IDs and room numbers masked):

• Dump A (Room 123, Stay: Oct 04 to Oct 06):
  AAAA 00 00 0123 01 12 02104100 01106100
• Dump B (Room 12, Stay: Mar 17 to Mar 20):
  BBBB 00 00 0012 01 14 61817150 01120150

Running this through the Proxmark3 client:

[usb] pm3 --> elox -d AAAA0000012301120210410001106100...

[=] E-LOX Credential Breakdown
[=] ----------------------------------
[+] Facility / Hotel ID... AAAA
[+] Card Function......... 0 - Guest Card
[+] Room Number........... 123
[+] Subroom............... 6
[+] Room Card Counter..... 1
[+] Check-in.............. 2024-10-04 21:20
[+] Check-out............. 2024-10-06 11:00
[+] Unknown Byte.......... 00

The Line 1 Byte Map

The 16-byte payload is just plain Binary Coded Decimal (BCD) and bitfields:

Roles (Byte 02)

Dumping a master card shows:
BBBB 07 00000000438181715001117270

Byte 02 sets the permission level:

• 0 – Guest
• 1 – Safety
• 2 – Enable
• 3 – Disable
• 4 – Section
• 5 – Zone
• 6 – Building
• 7 – Master (seen above as 07)
• 8 – Emergency
• 9 – Communication

On the Master card, bytes 03 through 05 are completely zeroed out (00 00 00). The lock does not check for a room number if Byte 02 is set to master level; it only checks that the Hotel ID matches the lock's configuration.

Because these locks are offline units with no Wi-Fi or Zigbee mesh, they cannot ping a central server to revoke access or verify active bookings. The entire access control logic relies on two checks: permission level and time validation.

If two guest cards are cut for the same room with the exact same Hotel ID, room number, and check-in timestamp, they are bit-for-bit identical clones. Both will open the door without issue.

Revocation works through the check-in timestamp:

1. When a guest loses a card and the desk cuts a replacement, the system generates a payload with a check-in time matching the current minute.
2. The moment that new card is tapped on the lock, the lock compares the card's check-in timestamp against the watermark stored in its local memory.
3. If the card's check-in time is even 1 minute newer than what the lock has on record, the lock accepts it, writes the new timestamp into internal memory, and unlocks.
4. Once that happens, the older card is instantly invalidated. If anyone attempts to tap the previous card later, the lock detects that its check-in timestamp is older than its current watermark and rejects it.

This explains why the payload does not need complex cryptographic revocation lists or remote blacklists. The lock simply uses forward-moving time as an automatic replacement trigger.

The security model here is just obscurity:

• No cryptographic verification: There are no digital signatures, HMACs, or challenge-response steps. Everything is written as plaintext BCD.
• Predictable data: Anyone who can read the card can change Byte 02 from 00 (Guest) to 07 (Master) or extend the expiration date, and the lock will accept it.
• Static credentials: The physical encoder relies on fixed PINs rather than any real authentication handshake.

Once you know the 16-byte layout, writing cards is straightforward. Instead of using their handheld calculator machine, you can run a simple script with a $65 ACR1552U USB-C reader.

The entire process—reading the card UID, authenticating to the sector, and writing the 16-byte payload—takes under 100ms. It completely bypasses the need for an $800 proprietary terminal or clunky Windows middleware.

Big thanks to @iceman and people in the Proxmark Discord for answering questions and double-checking dumps along the way.