In order for you to access the current slot and copy the private key, you need to unseal the current slot. During an unseal, the card changes its memory, namely flagging that the current slot had been unsealed and the new user can easily check that with cktap or Nunchuk. So yes, like what you said, changing the flash memory which shows the new user that a slot was unsealed.
If you want to understand the inner workings, you should check out the Coinkite tap protocol GitHub. Start with the README.md file and I suggest you give the Tap Cards Protocol doc a thorough read.
But in an attempt to shed some light your question, I'll quickly point you to look at the Satscard only commands, namely the unseal command and the dump command.
When you use your card reader (on phone or computer) to send the unseal command to the card, the card changes its own memory and marks the current slot as unsealed, and also returns the spending information back to the reader.
You can check any slot in the card by using the dump command. If a slot had been unsealed by accident or any other means, the card will let you know via the tampered return field.
The tampered field is only present (and True) if the slot was unsealed due to confusion or uncertainty about its status. In other words, if the card unsealed itself rather than via a successful unseal command.
There's an emulator if you want to play around with it without having to unseal a real card slot.
Pointing you again to the FAQ, you can use cktap command-line software and a USB NFC card reader connected to your computer to check and see if the card had been tapered with. Or if you trust their partners, Nunchuk supposedly checks the card's validity.
How do I know I'm seeing a real SATSCARD?
There are a number of ways to verify the card:
Tap on it and view the verification page.
Use cktap command-line software.
Use it with a SATSCARD-ready mobile wallet.
And more FAQ sections that I think are quite relevant to your question.
How do I know the manufacturer doesn't know the private key?
When creating a new slot, you have the option of providing a 32-byte chain code. That chain code, plus a private key picked by the SATSCARD, are combined using the BIP-32 standard to derive the payment address (m/0).
You can use the chain code you provided and the public part of the SATSCARD's key (shared even when sealed) to derive the payment address. Matching this address with the one given by the card means you can be sure the SATSCARD used your entropy (the chain code). Even if the SATSCARD was using a fixed private key, access to the funds is not possible since the chain code is unknown to anyone else.
Couldn't SATSCARD be generating private keys that look random but are all from the same HD (BIP-32) tree they control?
No. Each customer provides their own chain code for entropy. Before making a deposit, a customer can verify SATSCARD incorporated the chain code entropy when generating the keys. At the factory, we use the Bitcoin block hash of a recent block as the chain code; this is also unpredictable since it's a product of the Bitcoin mining process.
In contrast, the original OPENDIME required you to unseal before verification. You also had to track all 256 bytes of entropy during ownership.
If I get a SATSCARD initialized by someone else, they will know the chain code (32 bytes) used, so maybe they know the private key?
No. The SATSCARD itself always provides 256 bits of high-quality entropy into the same process as BIP-32. The device carefully picks its contribution to the private key, using a TRNG certified by the card maker. The chip's hardware is certified to Common Criteria evaluation assurance level 6 (EAL6). That process covers the TRNG's operation and most of the crypto math we use.
What if I make a malicious SATSCARD?
Each SATSCARD made by Coinkite carries a certificate, signed by our factory. Like the X.509 certificate chain for OPENDIME®, it can be traced back and verified in the field.
The Python code in cktap will always verify the certificate chain when speaking to a SATSCARD.
Verification does not require Internet access.
What about an active MiTM attack or relay attack over NFC?
A man-in-the-middle can't change what you're doing with the card. ECDH (Elliptic-curve Diffie-Hellman) is used to encrypt key values like the card verification code (CVC) required to modify the card or view keys. Similarly, when being read from the card, the private key is encrypted with ECDH.
How do I know the manufacturer doesn't know the private key?
Couldn't SATSCARD be generating private keys that look random but are all from the same HD (BIP-32) tree they control?
If I get a SATSCARD initialized by someone else, they will know the chain code (32 bytes) used, so maybe they know the private key?
What if I make a malicious SATSCARD?
What about an active MiTM attack or relay attack over NFC?