Fixed card save from slot

[VarChar42]

According to https://github.com/RfidResearchGroup/ChameleonUltra/blob/main/docs/protocol.md the command MF1_READ_EMU_BLOCK_DATA accepts 2 arguments: block_start and block_count

[VarChar42]

Also I noticed, the function mfClassicGetBlockCount has a parameter isEV1 which is currently not set.
So only 64 blocks get read from a 1K EV1 card with 72 blocks.

[VarChar42]

the export from the "Read Card" page seem also broke. There each sector only contains 16 bytes.

[Foxushka]

So only 64 blocks get read from a 1K EV1 card with 72 blocks.

When you load 1k EV1 save into Chameleon, it becomes Mifare Classic 2k, as firmware doesn't support signatures with 1k

[Foxushka]

I've pushed fix to write-card branch with commit (cc7e2a2). As your fix will lose speed that is critical on mobile. Can you retest it on write-card branch?

[VarChar42]

I've pushed fix to write-card branch with commit (cc7e2a2). As your fix will lose speed that is critical on mobile. Can you retest it on write-card branch?

Your implementation still has the same problem.
Can you please reopen this PR I will look into speeding it up.

[Foxushka]

Are you sure there is issue on last changes in write-card branch?

[Foxushka]

Some fixes are in next commit, so only this commit won't work

[VarChar42]

Some fixes are in next commit, so only this commit won't work

yeah including the fixes in the next commit it works.

[VarChar42]

my version now checks for block counts not power of 32 .. for example mifare mini with 20 blocks

[VarChar42]

Why do you want to copy these changes into your PR? The PR should only contain changes regarding its scope... (my opinion)

[Foxushka]

Forgot about Mifare Mini actually

[Foxushka]

Can you move down count of blocks back to 16, not 32?

[VarChar42]

Can you move down count of blocks back to 16, not 32?

sure. any specific reason for this?

[Foxushka]

I don't remember, but I had problems with that, probably unstable via BLE

[Foxushka]

Thank you for fixing this