All Simos versions dervatives (12.x/14.x/16.x/18.x etc) use different AES key/iv pairs.
Even subversions (for example 12.1, 12.2, 12.9) use various encrypt keys.      
Compress/decompres algo is the same in all cases.

Decrypt example for your frf in attach.

Looks a lot like Simos18.

There is a CRC checksum block at 0x300 in CBOOT/ASW1/CAL (block0/block1/block4) and 0x0 in ASW2/ASW3 (block2/block3).

The checksum looks like: 4 bytes of checksum data, 1 byte telling how many regions were summed, and then n 4-byte region_start:region_end specifiers for the region that is checksummed.

Checksum tool here: https://github.com/bri3d/VW_Flash/blob/master/checksumsimos18.py

Please note that these CRC regions for CBOOT are hardcoded in SBOOT - that is, even if you get clever and alter the region specifiers in the checksum header, the same areas in CBOOT are still checksummed. There is no reason to do this anyway as the correct checksum is trivial to calculate (see tool above).

Then there is an RSA signed SHA256 hash at the end of each block. This is not altered but is instead bypassed in all tools I am aware of by turning RSA off. This is done by patching a development mode ECU check. Unlike ME7 or older ECUs with RSA, the public keys are in OTP and can't be overwritten, so it's easier to turn it off than to try to do it "right" like ME7Sum does for ME7.

Maybe my Simos18 documentation can help you: https://github.com/bri3d/VW_Flash/blob/master/docs.md .

I am working on a write-up targeted at this forum and audience to be released soon, along with some more detail about SBOOT and how to find the AES keys.

I will quickly drop some hints here, sorry if they are scattered as I am in a bit of a rush:

SBOOT comes in two halves, the actual SBOOT and what I'll call the "OTP part". The "OTP part" of SBOOT starts at 80014000 and seems to be written in the end-of-line manufacturing of the ECU. It is flagged with OTP by Tricore, so it cannot be written ever again.

The OTP part of SBOOT starts with an export table at 80014000. References to anything in 80014000-80014090 from other parts of software are calling into the cryptography library in SBOOT. The export at 80014088 in Simos18 is essentially "AES_SetKeyMaterial" and thus by finding XRef to this export from CBOOT (the XRef will be in the UDS 0x34 TransferData handler itself in all cases I have seen), you can find the location of the TransferData AES keys in a flash dump.

The OTP part next has some blank space followed by the Tricore device identifier right at 80014200 (to marry the OTP with this specific ECU), followed by the Tricore flash memory unlocking passwords or "boot passwords" (specific to the device) at 8001420C.

After the passwords, there's a cryptography library containing CRC, AES, SHA256, and PKCS #1 RSA used to sign the SHA256, as well as the public key material used to verify the RSA signatures. The library starts off with obvious constants tables for CRC, AES, SHA256, and a PKCS#1-SHA256-RSA header which is injected into the RSA signature to pass into a standard PKCS verification library (I guess they thought storing the PKCS header in the flash would be too obvious).

I am assuming Simos12 is the same based on what I have seen in your files so far, maybe I am wrong, but I hope this helps.

Oh, that's an amazing amount of work, thanks!

Both in the 8R2907115C (Simos 18) and 8K0906264B (Simos 12.1) I can only find external function calls to
d000a0a4 .. d001b034 and d001ed80, with base address of the 1st out of 5 data chunks set to 0x8001C000.
I'm new to Ghidra, so I might just be pushing wrong buttons. I'll post an update here if I'm getting further.

Ah, after setting up the memory maps as you described (including one for the SBOOT area),
I indeed found the expected key/iv as input arguments for the AES call on the Simos18 dump I have (FL_8R2907115C).

On the Simos18 file, the first 4 bytes of CBOOT (80 01 CA E8) are a jump to a function.
On the FL_8K0906264B, the first 4 bytes (80 03 0d 60) seems to jump to an empty area.
Should I consider that the memory map for the Simos12 file is different?

The CBOOT code copied to the d0008000 region has references to d0004000, that also doesn't seem quite right.

I'll fiddle with things, see if I can make sense of it.

Spent a few minutes with your file. The CAN handlers in S12 aren't xreferenced to RAM the way they are in S18 but rather into PMEM, it looks like CBOOT works a little differently in S12.

Furthermore the AES is done right there in CBOOT, not in an library in OTP.

Anyway I think I have found the AES keys at 80030027, the 0x34 RequestDownload handler can be found in the CAN table at 8002f9dc, and the handler itself is at 8002acec.

IV: 30 6e 37 42 6b 6b 53 6f 31 6d 4a 69 74 36 6d 34
Key: 31 4d 75 36 41 6e 30 47 39 6a 41 32 52 35 6f 45

I don't have an encrypted ODX for this ECU handy to verify, so if you could check by modifying my script that would be amazing. I may have inadvertently switched the key and IV also...

You just beat me to it, you have the right addresses.
What I have so far:

| Description | Simos 12 | Simos 18 |
|---------|----------|----------|
| CBOOT   | 80020000 | 8001c000 |
| DecryptFirmware    | 8002acec | 8002f79c |
| CallAesSetKey | 8002c654 | 80030cb2|
| AES Key | 80030037 | d00080c0 |
| AES IV  | 80030027 | d00080b0 |

With this, I can decrypt FL_8K0906264B__0003.frf successfully.
Thanks a lot for all the help!

I addressed the so-called "4MB gap" (aka the reserved area between PMEM0 and PMEM1) already: "It looks as though Simos12 only utilizes the first flash area on the processor"

Thanks for the pointer though, the processor not having a PMEM1 to start with does help to explain why it is not used