Custom cards and tags with Intratone

Ola Thoresen
7 min readFeb 25, 2022


Intratone is a french company that provides a range of entrance systems for apartment-buildings etc. Their solution is pretty nice for two reasons. When someone rings the doorbell, you will either get a regular phone call directly to any phone number you register, or you can use their app and you will get a video call in the app so you can actually see who is on the door. Then you can talk to the person at the door on your phone, and just open the door by pressing “*” if it is a regular phone call, or a button in the app if you use that. So this means that it will also work with old phones that do not have the option to run the app. And you do not need to be at home to open the door. Especially nice when there are deliveries while you are at work, or if you need to remotely open for someone who has forgotten their keys…

The other nice thing is that you can add a range of different “keys”. You can simply register your phone number, and when you make a call FROM that number, TO the lock, it will open. You can enter a personal code on the keypad, and you can use one of their Key Fobs or Tags to open the door.

There are some limitations though. First of all, we have had quite a few issues with the app. Some users never receives any calls in the app, for others it works sometimes, but not consistantly.

Another issue is that their official Tags or Fobs are quite expensive.You can probably get a 100-pack of cheap NFC-tags for less than the price of one of their official tags. But they offer no official support for 3. party tags, so they won’t help you setting them up.

After som experimenting, I have found out that they do work with almost any NFC enabled card or tag and with both 4 Byte and 7 Byte serial numbers. I have tested a range of tags and cards, from my NFC enabled credit cards, the keycard for Teslas and my access card at my job. They all work fine with Intratone, when you find out how to add them.

4 Byte serial numbers

Old Mifare Classic cards have a 4 byte serial number. If you read it with a card reader or just use a phone with an app such as NFC Tools you will get a Serial Number that looks someting like 12:34:ab:cd . This is a hex-representation of the 4 bytes in the serial number.

Test card with Serial Number 08:01:02:03

However, you can not enter this serial number directly into the system. If you use their mobile app to manage the system (which is a different app than the one used to receive calls and open the door), you can not even enter letters into the field for the Serial Number of the tag you want to add. It only accepts numbers. In the web gui for management, you can add both numbers and letters, so you can at least enter hex, but there is a twist. Their card reader reads the serial number as little endian, so you need to switch it around.

12:34:ab:cd must be reversed, to cd:ab:34:12 . Notice that it is only the order of the bytes that are reversed, not the entire string. THIS can be entered into the web gui as “CDAB3412”, and the keycard should work.

In the mobile app, you still can’t use the letters a, b, c and d, so you need to calculate the decimal value of this. You can either use a calculator with the options to input hex, and just insert CDAB3412 and convert it to decimal, or you can use any of a million online tools to convert it, or you can do it manually or by a script or whatever you feel like.

Any way you do it, you will then end up with a number, in this case “3450549266”, and that can be entered into the mobile app.

7 Byte serial numbers

More modern cards have longer, 7 Byte, serial numbers. These are seeemingly more problematic. Neither the app, nor the web gui allows you to enter 7 Byte strings into the fields. And the maximum decimal representation of a 7 Byte number is 70 110 209 207 109 375, which far exceeds what you can enter in the app or web gui. And even if you bypass the length-checks in the web gui by blocking some java scripts, they will only save a 10 charcater long string, so you basically can not enter such long serial numbers anywhere.

But there is a way around this. Fortunately, the card reader on the doors are able to read these 7 Byte serial numbers, but they only read the first 4 Bytes!

So let’s dig a little bit into the Mifare UID-specification.

Comparison of 7 Byte and 4 Byte serial numbers. BCC is a checksum.

As you can see, the 7 Byte UID is divided into 2 x 5 Byte blocks, where the last byte of each block is a checksum, and first byte of the first block is denoted as “CT”. This is a “Cascade Tag” and always has the value “88” (in hex) if it is a 7 Byte Serial Number (or UID).

Let’s say you have a card with the 7 Byte serial number 12:34:ab:cd:56:78:90

In reality this is encoded on the card as

88:12:34:ab:CHECKSUM cd:56:78:90:CHECKSUM

So “88” in the first byte, according to the spec, denotes that this is a 7 Byte UID, but the card reader does not care, and just reads the first 4 bytes no matter what they are, so you end up with the card reader seeing the serial number as 88:12:34:ab .

Now THIS serial number can be used just like any 4 Byte serial number, described above.

So what you do to get the correct string from a 7 Byte card:

Use a card-reader or app to read the serial number.

Reverse the 3 first bytes you can see in the app. E.g. 12:34:ab:.... becomes ab:34:12 and then add 88 at the end so you end up with ab:34:12:88. Then you can either add this directly in the web gui as “AB341288”, or you can do the same hex to decimal conversion as mentioned before and enter e.g. “2871202440” into the management app.

A small trick at the end.

If you have not figured it out already, a very easy (but time consuming and less fun) way to avoid all of this, is to just use the card reader on the door.

If you present a NFC card and it flashes red, that means that the card reader was able to read the card, but did not find it in the database. If there is no light, the card reader was unable to read it and you are out of luck.

So after a card has been tested, and the reader flashed a red light, log into the web gui of the management platform. From there you go to “Properties”, select the correct property and then the correct entry under “Blocks, halls, estates, buildings”. At the top, you will see “Secondary entrances

Click the big “View” button under “Events list”. You will then get a list of (probably really old) events. This list is not updated automatically, so you need to click on the button “Download events” in the upper right corner. Wait a few minutes, and then click “Refresh” and the list should be updated with the latest events.

You should then be able to see the failed accesses with the unregistered cards as “Fobs or Transmitters”

Two failed entries, with their serial numbers. Bonus question: Are these 4 Byte or 7 Byte cards?

Here you can see the card readers view of what the serial numbers are in the column “Who?”, and these can then be inserted directly into the web gui as new fobs.

Notice that due to GDPR, you can NOT see the serial numbers of successfull unlocks. Only of unsuccessful ones.

So this is a simple way to find the right serial number. But if you need to add more than a couple of cards/tags/fobs at a time, and you want them to be mapped to the correct resident you really need to take your time and ensure you remember the order you scanned each tag, so you get the correct association between resident and serial number.



Ola Thoresen

Noe over gjennomsnittlig interessert. Kjentmann i IP- og nettverksjungelen, og jobber i nLogic AS.