Project

General

Profile

Actions

Bug #5550

open

EF.ARR file decoding would need to be context dependent

Added by chrysn 3 months ago. Updated about 2 months ago.

Status:
New
Priority:
Normal
Assignee:
Category:
-
Target version:
-
Start date:
05/06/2022
Due date:
% Done:

0%

Spec Reference:

Description

A record in EF.ARR can only be understood properly when it is known what it is used for (the audience in certificate parlance; whether it's used by an EF or a DF). Semantics vary widely -- an AM=0x01 in a record used by an EF means "read access" (ISO/IEC 7816-4:2005(E) table 16), whereas the same value interpreted by a DF or MF means "delete child file" (ISO/IEC 7816-4:2005(E) table 17).

Currently, pysim always interprets records as if they were used for an EF.

Changing this is likely hard, as the information needed to make the decision is simply not available. (A highly devious card author might even use the same rule for different purposes, but such a polyglot use we could probably ignore).

Potential solutions, probably in increasing complexity:
1. Do nothing; document that we're always assuming an EF type (and expect the user to do the necessary adjustments).
2. Use more general terms -- "bit1" instead of "write_append" (still work for the user, but not easily confused).
3. Use more general terms in output, but accept the type specific terms in input.
4. Accept input from the user in `read_record[s]_decoded` on how to interpret the record; using "bit1"-style output in absence of such input.
5. Keep tabs on which of the previously seen files refer to which record in an EF.ARR, and use that as default decoding style. (And warn/err if the type specific terms are used on a record that is referenced by a different type).

How much effort to put into this depends on the general usage patterns which I'm not familiar with yet. I can probably apply any solution (possibly with a bit of guidance as to the intended architectural decisions), but would need guidance as to which solution make sense here.

Actions #1

Updated by laforge about 2 months ago

  • Assignee set to chrysn

chrysn wrote:

Potential solutions, probably in increasing complexity:
1. Do nothing; document that we're always assuming an EF type (and expect the user to do the necessary adjustments).

this should be done right now, to at least make the cautious user aware. The other steps below are more optional, while this one is mandatory.

3. Use more general terms in output, but accept the type specific terms in input.

One could probably also add some EF-specific commands for decoding, so the user on the shell can state which of the two decode flavors should be used for decoding of a single record, like:

decode_ef_arr_record_for_df 1
decode_ef_arr_record_for_ef 1

Still a kludge, but at least for interactive usage that would be useful

Once those two decoders exists, we can als add a shell function that would decode the EF.ARR record for the curretly selected file. So you select ADF.USIM/EF.IMSI and then form there call a decode_ef_arr without any arguments. The code then knows it is an EF, and calls the EF-specific decoder and outputs the decoded access rules.

4. Accept input from the user in `read_record[s]_decoded` on how to interpret the record; using "bit1"-style output in absence of such input.

accepting both as input would also be useful.

5. Keep tabs on which of the previously seen files refer to which record in an EF.ARR, and use that as default decoding style. (And warn/err if the type specific terms are used on a record that is referenced by a different type).

doesn't look appealing to me.

Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)