You're going down the right path. I don't mean to diminish your research. These links are all great for a beginner and keeping this in one place is wonderful.
But, you're going in a slow meandering way IMO.
Read the code to the NefMoto flasher I linked you, it's all there for you. Then read about ISO 14229 UDS, which is generally speaking based on the KWP protocol the NefMoto flasher uses but over CAN-TP as the transport instead of a serial line.
J2534 is a minor aside in all this, it's a convenient way to access CAN from Windows but nothing more. You could use the ELM327 protocol (not recommended, it sucks) or SocketCAN on Linux instead of J2534 on Windows, it's all the same at the end of the day. It sounds like you've figured this part out already
Between the NefMoto flasher and the ISO 14229 documentation, you'll have a general idea of the ECU flashing process works (very broadly speaking diagnostic session -> security access -> erasememory -> request download -> transfer data (repeat) -> exit transfer -> checksum -> reset).
Now you can read "Corporate Group Requirement Specification For Programming Control Units with Keyword Protocol 2000 Transport Protocol 2.0.pdf" which documents this procedure for VW ECUs specifically, including the SecurityAccess Seed/Key calculation which is a simple bytecode script transformation.
Next, you need to understand how the ECU software verifies its own integrity. This varies from ECU to ECU. For example, in ME7 (which the NefMoto flasher handles) this is basic sum/CRC checksums applied to various blocks. ME7Sum at
https://github.com/nyetwurk/ME7Sum can calculate these for you and "fix" an ME7 file so it will pass its own integrity checks. Later in the ME7 days, an RSA integrity check was added to the application running on the ECU, but it's performed by the software itself after it's running rather than when it's written, so it can either be removed in the ECU code or self-signed (the public key replaced and the file signed with a valid, matching key). ME7Sum can self-sign RSA ME7 files as well.
For newer ECUs, there is usually a real integrity check (RSA, etc.) and sometimes the flash payload is encrypted with AES, too. For these ECUs, you need to reverse engineer the integrity checking and find the AES keys as well as an exploit in the chain of trust, just as you would with any other protected hardware. Unfortunately these exploits are usually fought over and protected as there's $$$ to be made in this industry. Learning to use Ghidra or IDA and how to map ECU files at the correct memory addresses to follow the disassembly is what will let you eventually figure this stuff out.
Also, you mention reading. On most modern ECUs, you simply can't read the ECU back when the application software is running as the ability to do so was intentionally left out of the software. You'll have to add the ability back by breaking the chain of trust somewhere and adding your own flash read-out/transfer code, or rely on decrypted factory update files (FRFs), also known as "virtual reads" to help you on your path.
