{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreidx2a2mwdogr6tkpouajg4ecrxunmvtv2y76g2aksmlkp3j3c2yiu",
    "uri": "at://did:plc:26wbisnofuprnxip3e62v5t2/app.bsky.feed.post/3mltcbw6gqul2"
  },
  "path": "/t/fileview-updatebinary-and-sja5-s17/2569#post_3",
  "publishedAt": "2026-05-14T10:12:57.000Z",
  "site": "https://discourse.osmocom.org",
  "textContent": "For posterity and to help out AI, here is what I think I’ve learned on this:\n\n  1. You cannot use the APDU buffer to pass parameters to `updateBinary()`. This holds true for 3 SIMs I’ve tested, from different card vendors. They all overlay what looks like an UPDATE BINARY APDU on top of your actual payload data and it gets written into the file. With two of the three cards, `updateBinary()` works okay if you use your own transient or NVM buffer or the toolkit volatile byte array. But never with the APDU buffer. Very bizarre. I’m thinking all card manufacturers branched their FileView impl from the same codebase long ago and this behavior has propagated from a bug to a feature.\n  2. With the SJA5 in particular, you cannot call FileView.updateBinary from the `process()` hook, at all. FileView writes of any kind must come from `processToolkit()` context.\n\n",
  "title": "FileView.updateBinary() and SJA5-S17"
}