hf 15 rdbl flag issue

[ikarus23]

Hi!

To my understanding the read block command hf 15 rdbl will always set the ISO15693 "custom flag" in its request.
I think it does this, because some tag manufacturers will include the lock bit, if you define this flag.

For example, this is a hf 15 rdbl of a ICODE SLI:

Reader: 62  20  11  22  33  44  55  66  77  88  08  49  81
        ^   ^   ^                               ^   ^
        |   |   |                               |   |
        |   |   UID                             |   CRC
        |   CMD                                 Block Nr.
        Flags

Tag:    00  00  ff  ff  ff  ff  ee  3c
        ^   ^   ^               ^
        |   |   |               |
        |   |   Block content   CRC
        |   Lock bit
        Flags

If you do not set the "custom flag" the 0x62 will become 0x22. The same read does then look like this:

Reader: 22  20  11  22  33  44  55  66  77  88  08  49  81
        ^   ^   ^                               ^   ^
        |   |   |                               |   |
        |   |   UID                             |   CRC
        |   CMD                                 Block Nr.
        Flags

Tag:    00  ff  ff  ff  ff  ee  3c
        ^   ^               ^
        |   |               |
        |   Block content   CRC 
        Flags

Notice that the lock bit is missing in the response.

Although this is a convenient way to get the lock bit while reading a block, this is not a specified behavior according to ISO 15693-3. I have a tag that does not use the "custom flag". Therefore, the hf 15 rdbl command will display wrong results because it assumes that there is a lock bit information in the response.

It would be great if there would be a option to hf 15 rdbl which does disable setting the custom flag and in return just shows the block data (and no information about the lock bit).

Thanks!

[ikarus23]

The "custom flag" is also enabled on hf 15 wrbl. Not sure why.

[ikarus23]

For context:

[iceman1001]

We have a param for it:
at[5] = arg_lit0("o", "opt", "set OPTION Flag (needed for TI)");

We just override it for the rdbl/wrbl like this:

    // enforcing add_option in order to get lock-info
    if (add_option == false) {
        if (verbose) {
            PrintAndLogEx(INFO, "Overriding OPTION param in order to get lock-info response (ENFORCE)");
        }
        add_option = true;
    }

If you don't want to, then you need to handle two different responses on client side and the longer wait for the write on device side.
Remember that wrbl / restore is more or less the same,
and rdmulti, rdbl, dump is too.

So if you want to change it, don't forget to handle them too properly.

Not to mention I guess you as a consequence sooner or later also might want to handle the simulation code to mimic it.

[ikarus23]

Thanks for the input. As always: very valuable! For some reason I did not think of OPTION = "Custom Flag" in ISO15693. Like always, I should have looked into the code. :)

I see the challenges with handling two different responses (with and without lock information). But not sure if it will affect other commands. hf 15 dump does not use the option flag, does not store the lock information and therefore it should not affect hf 15 restore. Same for hf 15 wrbl. The command just sets the data, not the lock bit. Therefore I'm not sure if enforcing the option flag is needed.

Different responses should only affect rdbl and rdmulti if issued with or without the option flag.

Any thoughts? Maybe one day I will find the time to implement the different handling for these two commands...

[iceman1001]

hf 15 dump should honor the options flag
https://github.com/RfidResearchGroup/proxmark3/blob/master/client/src/cmdhf15.c#L1776

It doesn't store the information right now doesn't mean it is correct. The JSON format should include it.

The writeblock wants it on TI tags and my other tags is ok with it. So easier to make that the default behavior.
Otherwise I can see end user run write first, doesn't work, even with a hint, has to try a second time,
most likely by then , going to forum/discord here and complain.

We really don't want that.

[ikarus23]

hf 15 dump should honor the options flag

Oh yes, it does! I guess what tripped me was that rdbl, wrbl, rdmulti do not honor the flag. Or even more confusing: set the flag all the time.

The writeblock wants it on TI tags and my other tags is ok with it. So easier to make that the default behavior.
Otherwise I can see end user run write first, doesn't work, even with a hint, has to try a second time,
most likely by then , going to forum/discord here and complain.

You are absolutely right on this! Just set the flag by default! But what I would really like is not to be forced to (without knowing). Maybe the easiest way out is to always set the flag for all commands and make it an option to not set it (which is not enforced). If I'm not mistaken, only the rdbl and rdmulti command have to be updated to handle different data output. The dump command already does this!

[iceman1001]

If you find time, feel free to improve it.

I am swamped with other parts now.

[ikarus23]

Yeah, I feel you. Lots of things to do :)

Thanks for sticking with me through this discussion. I'm pretty new to ISO15693 and the way the PM3 interacts with those tags.

Let's keep this issue open for at least some time. Hopefully I can find some time to implement changes to make it more intuitive/consistent.

[iceman1001]

of course,
You been in the zone since 37c3. Just keep at it. You are correct that 15 commands isn't quite there but its an improvement.
try the -z for view :) you don't need to see all long repeating blocks.

[iceman1001]

What is the status on this one?

[ikarus23]

The flag is still all over the place.

1. rdbl shows the flag but ignores (enforces) it.
2. rdblmulti shows the flag but ignores (enforces) it.
3. dump shows the flag but only uses it on the systeminfo command. It is enforced on the read block (without any hint to the user).

There is no easy fix. The -o argument is part of a default cli argument selection. Even if the option would be respected correctly in all commands the output (and dump) would be differently (with and without lock bit). I feel like the root cause of the issue is using the flag to get lock bits. This not the way the ISO15693 standard specifies it.

The best way in my opinion would be:

1. Provide the -o option, if it is really needed (e.g. for some TI tags).
2. Never get the lock bits by assuming they will be there when the flag is set. The flag is just for manufacturer specific stuff.
3. If the lock bits should be part of read commands (rdbl, rdblmulti, dump) then get the bits with the "Get multiple block security status" (0x2C) command. This will respect the ISO15693.
4. If the lock bits should be part of a write command (wrbl, restore) then set the lock bits with the "Lock block" (0x22) command. This will respect the ISO15693
5. Provide a simple lock command (e.g. lkbl) to lock blocks individually.
6. Provide an option to not rely on the systeminfo command when using dump. Some tags may not implement it. A user should be able to specify the size of the tag (page count).

Now to the important part: Will I have the time and motivation to implement all this? No.
But now it is documented with this issue. Maybe someday someone will have the skill, time and motivation for this.

Regardless, with the latest reworks the hf 15 commands are better then ever before and I'm very grateful for this.