Feature #6069
openport hello-stk to ant-based build like mrlnc/HelloSTK2
90%
Description
It's rather hard to build the old hello-stk using java8 sdk and the sim-tools makefiles etc. on a current distribution today.
Instead, @merlinchlosta came up with a modern, ant-based build using ant-javacard by Martin Paljak
I've started to migrate our hello-stk.git (with both the HelloSTK and the ImsiChange applet) over to this build system. See my laforge/ant branch.
Please take this over by doing some more testing and updating documentation (README, wiki, possibly other places like sysmoUSIM/ISIM user manual, ...). Ideally we'd have the documentation in one place, and other locations just point to it.
Checklist
- test the generated applets from laforge/ant branch
- update README[s] with new build instructions
- update wiki with new build instructions
- update README with installation instructions (preferably using GlobalPlatformPro, if that works)
- merge everything to master
Updated by dexter 3 months ago
- Status changed from New to In Progress
Building the laforge/ant branch seems to work fine. Unfortunately the current ant-javacard.jar seems not to work, but when I use the previous version everything is fine. I will try to contact the maintainer of ant-javacard.jar so that the problem can be fixed.
I didn't test the resulting cap files yet. I will do this next.
As far as I am aware this is the only wiki page that needs updating:
https://osmocom.org/projects/sim-toolkit/wiki
Updated by dexter 3 months ago
- % Done changed from 0 to 20
The problems with ant-javacard.jar are now fixed by the maintainer. So, everything now builds as expected. I have tested the two applets now. The HelloSTK Applet works fine but the IMSIChange has a problem. It loads fine onto the card, but when I try to use it it does not do anything.
Updated by dexter 3 months ago
In any case I think we should move along even if we can not get the IMSIChange applet to work. With the old build system, which relies on ancient JAVA SDKs we probably barely stand a chance to go anywhere.
Still I wonder what we could try to get IMSIChange to work. In oracle_javacard_sdks we have a good selection of different JAVA SDKs we could try a different SDK.
Updated by dexter 3 months ago
- % Done changed from 20 to 80
The laforge/ant branch is no merged to master and all the readme files and wiki pages are updated with the new build instructions.
Unfortunately installing the applets via GlobalPlatformPro does not work for some reason. The error I get is always the same:
java -jar ./gp.jar --key-enc 4999F15B6530E911A4A94AE8B4B8701A --key-mac 10B7BB63702FED7C1C15859DAA422C19 --key-dek 7025744D65A4EA13869AC2793293600D --install /home/owner/work/simcard_applet_loading/HelloSTK2_14062023.cap CAP loaded Error: INSTALL [for install and make selectable] failed: 0x6A80 (Wrong data/incorrect values in data)
Surprisingly it works when I remove the following line from the applet code:
helloMenuItem = reg.initMenuEntry(menuItemText, (short)0, (short)menuItemText.length, PRO_CMD_SELECT_ITEM, false, (byte)0, (short)0);
With when I use shadysim_isim, the applet loads fine on an sysmo-isim-sja2. We have additional parameters in shadysim_isim.py that relate to menu text length and memory sizes. With gp.jar we do not have those parameters. I wonder if the problem is somehow related to that. I also wonder from where those parameters come from when gp.jar is used.
Updated by laforge 3 months ago
On Wed, Sep 06, 2023 at 10:38:18AM +0000, dexter wrote:
With when I use shadysim_isim, the applet loads fine on an sysmo-isim-sja2. We have additional parameters in shadysim_isim.py that relate to menu text length and memory sizes. With gp.jar we do not have those parameters. I wonder if the problem is somehow related to that. I also wonder from where those parameters come from when gp.jar is used.
you might want to raise this question as a github issue in the GlobalPlatformPro repo. I would suspect
there's some spec on how to pass them along in the INSTALL FOR ... APDU?
I've never been very strong about those kind of questions at the border of JavaCard / GlobalPlatform and
UICC/USIM :/
Updated by merlinchlosta 3 months ago
dexter wrote in #note-7:
With when I use shadysim_isim, the applet loads fine on an sysmo-isim-sja2. We have additional parameters in shadysim_isim.py that relate to menu text length and memory sizes. With gp.jar we do not have those parameters. I wonder if the problem is somehow related to that. I also wonder from where those parameters come from when gp.jar is used.
There's a related GPPro issue, essentially it seems to go beyond the GPPro scope to build the required parameters for SimToolkit:
https://github.com/martinpaljak/GlobalPlatformPro/issues/293
shadysim_isim builds the 'CA' parameter ("SIM File Access and Toolkit Application Specific Parameters Tag") here:
https://github.com/herlesupreeth/sim-tools/commit/c7110a85344f9688591cf5a5853bfc962f9a63eb#diff-452bd0611db696dcab13ba04799853ea337b506f8761d03b847ddf3702cdc1d1R386
Updated by merlinchlosta 3 months ago
dexter wrote in #note-4:
Still I wonder what we could try to get IMSIChange to work.
The IMSI Change applet requires setting `--access-domain=00` during installation to enable file system access (00 = full access, ff = no access, the default in shadysim_isim).
See here: https://osmocom.org/issues/4412#note-4 and 102.226 clause 8.2.1.3.2.5.1.
Both applets build and work for me.
Updated by dexter 2 months ago
- % Done changed from 80 to 90
@merlinchlosta, thanks for trying it out. I have checked it also on my side and now the applet loads fine using shadysim_isim. I wonder if it is possible to use the --params parameter to pass the parameter string generated by shadysim_isim (line 393) to gp.jar. I have tried that but had no success. I also tried other variations too but unfortunately I had no success so far.
(I think getting gp.jar to load the HelloSTK and ImsiChange would be a huge step forward.)
Updated by merlinchlosta 2 months ago
dexter wrote in #note-11:
I wonder if it is possible to use the --params parameter to pass the parameter string generated by shadysim_isim (line 393) to gp.jar. I have tried that but had no success. I also tried other variations too but unfortunately I had no success so far.
(I think getting gp.jar to load the HelloSTK and ImsiChange would be a huge step forward.)
I think it actually worked for me now. In this case, GPPro is the offender :-) It assumes that within the params TLV the tag 0xc9 (Application Specific Parameters) always comes first (see GPSession.java). Shadysim however puts the element 0xEF first, then 0xC9. (link to code). In that case, GPPro prepends another 0xC9 tag, invalidating the whole TLV.
So just swap the elements in this line and print parameters:
- parameters = 'ef' + ('%02x' % (len(parameters) / 2)) + parameters + 'c9' + ('%02x' % (len(args.app_parameters) / 2)) + args.app_parameters
+ parameters = 'c9' + ('%02x' % (len(args.app_parameters) / 2)) + args.app_parameters + 'ef' + ('%02x' % (len(parameters) / 2)) + parameters
Params for ImsiChange that seemed to work:
$ java -jar ./gp.jar --key-enc XXX --key-mac XXX --key-dek XXX --install ../hello-stk/build/ImsiChange.cap --params c900ef2ac80201FFc70201FFca20010001000f0c0000000000000000000000000000000000000000000000000000 CAP loaded
When thinking how documentation could be improved, my main impulse was that the shadysim script could be a bit more helpful by itself. So before realizing that GPPro (arguably the better technical base) might be a realistic replacement, I tried to revamp the script a little bit: https://github.com/mrlnc/pysim/blob/install-applets/stk_applet_manager.py
- Python3
- read AIDs from CAP
- check if applet is already present before loading
- clearly separate load and install to allow separate trouble-shooting
I'm not suggesting this as a replacement or anything. My hope is simply that next time I return to SIM applets - in a year or two - I will not spend that much time reading about Status Words :)
Updated by laforge about 2 months ago
merlinchlosta wrote in #note-12:
When thinking how documentation could be improved, my main impulse was that the shadysim script could be a bit more helpful by itself. So before realizing that GPPro (arguably the better technical base) might be a realistic replacement, I tried to revamp the script a little bit: https://github.com/mrlnc/pysim/blob/install-applets/stk_applet_manager.py
Thanks for pointing this out. I was about to suggest to submit it upstream when I sawa that it (like shadysim) manually fiddles with hard-coded DES rather than working with the hopefully generic enough pySim.ota library code (supporting DES and AES with varying key lentghs), see
https://gitea.osmocom.org/sim-card/pysim/src/branch/master/pySim/ota.py
So maybe one could use that and implement app loading/installation on top of that to avoid further replication of hand-coded 03.48?
Updated by merlinchlosta about 1 month ago
pySim.ota works so far, at least for the SJA2+DES (updated my branch). But honestly, there are so many other components involved that I'm not familiar with, I'm not sure if this is an actual improvement over the original script (or using GPPro).
Updated by laforge about 1 month ago
On Thu, Nov 02, 2023 at 12:14:23PM +0000, merlinchlosta wrote:
pySim.ota works so far, at least for the SJA2+DES (updated my branch).
thanks.
But honestly, there are so many other components involved that I'm not familiar with, I'm not sure if this is an actual improvement over the original script (or using GPPro).
I think any step in the reduction of code duplication and towards having
more proper/general/clean implementation of the required parts is one
step in the right direction.
I think some more parts of send_wrapped_apdu_internal() can be replaced
by our existing library classes:
- adding the user data header using pySim.sms.UserDataHeader
- creating the SMS-DELIVER TPDU by using pysim.sms.SMS_DELIVER
- adding device identities by using pySim.cat.DeviceIdentities
- wrappping int SMS-PP-Download using pySim.cat.SMSPPDownload
For the first step (UserDataHeader), I'm actually momentarily suprirsed
that OtaDialectSms.encode_cmd doesn't automatically add it, given that
OtaDialectSms.decode_resp is assuming it is present? Maybe it's not
needed in the SMPP case? I don't recall the details, but maybe it is an
oversight...
I guess somehing like this should do the trick:
udh = UserDataHeader(ies=[{'iei': 0x70, 'length': 0, 'value':b''}]) foo = udh.toBytes()
How to use the last three parts can be seen in the do_envelope_sms() function of pySim-shell.AddlShellcommands
tpdu_ie = SMS_TPDU() tpdu_ie.from_bytes(h2b(opts.TPDU)) dev_ids = DeviceIdentities(decoded={'source_dev_id': 'network', 'dest_dev_id': 'uicc'}) sms_dl = SMSPPDownload(children=[dev_ids, tpdu_ie]) # you can get the resulting output via sms_dl.to_tlv() and convert to hex, as needed # as in the arguments below # (data, sw) = self._cmd.lchan.scc.envelope(b2h(sms_dl.to_tlv()))
It might not be much less lines of code in your script, but it will be a more generic and maintainable
implementation.
As for actually exchanging the ENVELOPE APDUs with the card: I've done
a lot of preparatory work recently to make sure we can more easily use
the pySim library classes from code != the pySim-shell "main" program.
I'll soon plan to add some examples for that (something like a
sysmo-isim-tool replacement, for example). Once that exists, that could
be used as basis to also use all that magic from your applet manager
If you want to join in, you could also start factoring out some of your
code into a pySim library module. Like the LoadFile class.