Some success with writeCID

[J_3]

Hello xArt, what you wrote is very interesting.
Reading the cid is a trivial thing that doesn't involve any problem at all, the really hard thing is to rewrite it.
Me too I was able to change the cid of some samsung card using evoplus_cid and I have read that someone has succeeded with a Blue Pill-ATM32 that I don't think is very different from an Arduino.
You wrote that the same process over an spi interface doesn't work so the card never enters vendor mode, ok, but can you say exactly which commands are sent for everything to work?
If you know the commands to be used I would ask you to state them.
Regardless of whether commands should be issued in sd-mode or spi, I thought they were these:

cmd62 0xEFAC62EC (enter vendor mode)
cmd62 0xEF50 (unlock the backdoor)
cmd17 0x00 (confirm Smart Report after reading Sector 1 at Address 0)
cmd26 0x00 0xFE [16bytes NEW CID] (WRITE_CID+single block write start TOKEN+16byte NEW CID)
cmd62 0x00DECCEE (exit vendor mode)

In my opinion it would be important to know the exact sequence of commands issued by evoplus_cid, so it would be useful to extract it from the source code and post it here.
That should clarify things enough.
Unfortunately I'm not able to unpack the code from myself, It's obfuscate to me.
I asked to the author of evoplus_cid but he didn't answer me.

[xArt]

Hi, I can hardly believe you could get a compiled version for Linux.
It's posted on Github here: https://github.com/raburton/evoplus_cid

I just duplicated that source using Microchip's MDDFS library (for USB keys & SD Cards).
I used the same SD card for both platforms, so can verify evoplus_cid for Linux worked ok.

I don't expect any problem with any platform ->reading<- the CID.

Evoplus_cid bails for any command leading up to CMD26 that doesn't give an expected reply.
Just like that program, I didn't push it any further.
CMD26 is never sent if the card doesn't reply properly to the vendor mode command.
Over an SPI interface, it doesn't.

[J_3]

Hello xArt.

Hi, I can hardly believe you could get a compiled version for Linux.
It's posted on Github here: https://github.com/raburton/evoplus_cid

I just duplicated that source using Microchip's MDDFS library (for USB keys & SD Cards).
I used the same SD card for both platforms, so can verify evoplus_cid for Linux worked ok.

I don't expect any problem with any platform ->reading<- the CID.

Really I don't understand exactly what you have just written above.
I have evoplus_cid working on linux and android and I'm pretty sure I'm not the only one.
What do you mean?
And surely there can be no problem reading the cid with linux, android or anything else.

Evoplus_cid bails for any command leading up to CMD26 that doesn't give an expected reply.
Just like that program, I didn't push it any further.
CMD26 is never sent if the card doesn't reply properly to the vendor mode command.
Over an SPI interface, it doesn't.

Being a backdoor it works just like you wrote, of course, but it isn't true that in SPI it doesn't work.
Executing a cmd26 directly on the card while in SPI mode, then error 0x04 (illegal command) is issued, while always in SPI mode executing cmd62 0xEFAC62EC cmd62 0xEF50 cmd26 there is no error at all.
So it works.
The sequence cmd62 0xEFAC62EC cmd62 0xEF50 cmd26 can be used to check if the card supports the back door or not.
No errors it does, some error, generally 0x04 (illegal command), it doesn't, rather easy.

[xArt]

In my opinion it would be important to know the exact sequence of commands issued by evoplus_cid, so it would be useful to extract it from the source code and post it here.

I was replying to this.
It's easy to know what evoplus_cid does because source is available,
and I don't know of any distributions available that don't include source.

If you say the card replies to the vendor command properly, I'll have to try again.
I at least know the SPI and card library work well because I've implemented other commands
and used the library for a couple of years now.