Hi there! As many of You know, among the several retrofits I’m doing on my Karoq, there’s the screen update, from Amundsen (8 inches) to Columbus (9,2).

While the rectangular connector fits perfectly (audio works and buttons turn on), the screen remains black due (according to mechanic) to the different Fakra connectors, blue on Amundsen and Black on Columbus) as they have a small tooth in a different position (top on one, bottom on the other).

According to You/Your experience, replacing the cable can solve the problem?

Take a Cutter and cut until it will Plug 😉

You mean the small tooth? And are the inner wires in the correct order?

Did You get my DM about the datasets?

This morning I brought car to Skoda Dealer to replace the factory Amundsen screen with the Columbus one (part n. 565919606D) and factory Amundsen navigation in the glove box with the Columbus one (part n. 3V0035816K); I also replaced the cable what connect the two units.

Of course I brought with me the purchases invoices to witness the parts were regularly purchased from a wreckage shop in order to remove legally the component protection.

One hour ago Skoda contacted me saying they gave up as the screen doesn't turn on: can anybody help me saying me what else can I do?

Why 3V0035816K?

This is kamiq/Scala Not for 9,2" Screen

Edited 20 August20 Aug by Cairus

In Skoda they told me I can get the K or the P, and I found a good deal on the K

On 20/08/2026 at 12:20, Benja77 said:

In Skoda they told me I can get the K or the P, and I found a good deal on the K

If the K unit is really meant for the Kamiq/Scala, that could explain the black screen. I’d double-check the exact compatibility before replacing or modifying anything else.

Now I need only to ask Skoda to remove the old component protection and apply to the new mib

What have you Pay for the sreen?

MIB3? Preh Manufactur? Simple to patch CP Off via USB, but Software dont Higher then 332

15 hours ago, Cairus said:

What have you Pay for the sreen?

I was lucky: got it for 130€ from a totalled car in a wreckage shop with regular invoice

15 hours ago, Cairus said:

MIB3? Preh Manufactur? Simple to patch CP Off via USB, but Software dont Higher then 332

Yes it’s a MIB3; i prefer not to patch as I want to keep all the services connected

3 hours ago, Benja77 said:

I was lucky: got it for 130€ from a totalled car in a wreckage shop with regular invoice

My 9,2" Display Display, the same in the kodiaq, 50€ 😂

Edited 13 September13 Sep by Cairus

Luckier than me, indeed

Component protection removed and retrofit done but navigation, smartlink and vocal commands don’t work. But online services via app are on

Looks like the FECs didn’t migrate yet!

Any idea how solve this without patching the unit?

Edited 6 hours ago6 hr by Benja77

😂

Sorry. Nobody read What i say:

Did you perform the function activation? It probably won't work with ODIS Online, though, because different data is stored on the server.

If IT works, only the Fec's from Factory out are activ.

In my opinion, the online services are completely useless. The MIB3 runs much more stably and reliably without them. So, disable them via coding, patch the unit, and you're done.

But in this case, since the CP has been officially removed, the online service might actually work despite the FEC patch.

Edited 6 hours ago6 hr by Cairus

But point I’d like to keep on using at least smart link to connect my iPhone as GPS and vocal commands.

However I didn’t patch unit at all; only thing I can do right now will be upgrading the MIB’s firmware to version 324 or 330 (actually is 320)

Edited 5 hours ago5 hr by Benja77

Personally, I would update to 0330 and then apply the patch; that way, you have 332 as a backup.

Talking with a friend of mine, who know coding quite well, we realized mechanic just replaced the unit a screen without doing the replacement procedure first! That’s why the licenses/FEXs were NOT transferred from old unit to the new one

Once again, FECs cannot be transferred from the old unit to the new one. The FECs must be activated online via ODIS using a function activation procedure.

Every control unit has a unique identifier known as the VCRN. At the factory, this is paired with the EEPROM, the eMMC Key ID, the CPU Key ID, and the VIN. As soon as the unit is installed in a different vehicle, the software detects a discrepancy and—as shown in your picture—marks all FECs as "temporarily rejected." When you then perform the function activation, the FECs that were valid from the factory (or officially purchased later) are activated; essentially, the routine performs a fresh reconciliation and re-signs the eMMC and EEPROM.

In principle, the patch does the same thing as the MIB2 Toolbox—it bypasses the verification check—but with MIB3, the trade-off is that online services no longer work; unlike the MIB2, the software immediately detects the discrepancy in the EEPROM and switches to a "tamper mode." The FeCs appear as rejected in the software, yet they still function despite the tampering.

Edited 56 minutes ago56 min by Cairus

Even the component protection is implemented quite effectively. It is linked to the CPU Key ID, the eMMC Key ID, and the EEPROM, and is further encrypted using a cryptographic key stored on the VW server. If you were to clone the data via the EEPROM, the system would immediately detect that the cryptographic signature is invalid because the new unit—where the EEPROM data was loaded—has different Key IDs for the CPU and eMMC. In other words, the software instantly recognizes the tampering. I spent hours, days, and weeks trying to bypass this on the MIB2; I succeeded, but the problem is that the solution isn't firmware-stable—a single update wipes everything out. Plus, you need the dump from the unit that was officially paired with the vehicle. The effort involved just isn't worth it for the MIB2. With the MIB3, I am currently in the process of creating a full system backup—meaning the eMMC, including Boot 1, Boot 2, User, and Config partitions. The EEPROM part is simple enough, but the eMMC in the Preh MIB3 unit has 64GB of flash storage. Since I don't use a "chip-off" method, performing a 1-bit ISP backup takes anywhere from 5 to 24 hours, depending on the clock frequency and the bench setup.

The advantage of this would be that, for instance, you could virtually mount the user partition in Linux and extract the `system.ifs` file from it. This means you could theoretically patch the system directly; no discrepancy would be detected, and the system would boot up and function perfectly.

I hope the explanation is detailed enough now. Perhaps this is of interest:

@travs @JR RS @Binx1310 @Bap33 abd Others

Edited 28 minutes ago28 min by Cairus

Thanks