破解Korg Kronos 電子琴加密

小時候拆解Roland ,Korg,Yamaha生產的電子合成器.發現PCB主控最右上Intel C8095-90 ,DAC是最左邊中間的PCM54, 看到幾個Roland字樣的IC
心裡覺得 挖靠 量這樣小好了不起 ,音樂公司自己Tape out 一堆特製ASIC.
後來才知道 以Roland MT-32為例子,原創 ASIC 為R15229896 LA32(LA合成IC ),其他長條的Roland IC只是Hitachi  27C256 EPROM

這幾年來x86性能舉崛起,沒想到我才發現這類音樂客製化合成算法IC很多早已不見.而是以X86模擬….

之前閱讀到這篇文章 因為實在太有意思了 因此先簡單翻譯一下.

翻譯與修改自：https://marcan.st/2016/06/hacking-and-upgrading-the-korg-kronos/

原作者Marcan
Korg 電子合成器Korones是一個有趣的東西。Korg的旗艦電子合成器，實際上他是一台x86主機板和一個鍵盤跟定制I / O板。有趣的是它運行Linux。

kronoshacker匿名黑客blog ，一直在記錄有關Kronos軟件的各種細節，從安全到混淆到性能。他更換主板和CPU DRAM 升級Kronos電子合成器
（原來是一個過時的Atom），用Skylake的CPU來替代，並大幅提高了性能。我決定嘗試做同樣的事情，並記錄過程。

Kronos 硬體底層

Kronos基本上由兩個主要組件組成：x86和NKS4。x86是一款bog標準的Intel D510MO 主板，主頻為1.66GHz的雙核Atom D510。它運行Linux，所有的合成音樂訊號處理都在這裡。但是，它的I / O大部分是未使用的; 它真的只是設備的“大腦”。合成器的軟體，音色樣本和用戶數據存儲在內置SATA 30G SSD。主板配備2GB內存，但可以正式升級到3GB。由於CPU和軟件僅為32位，因此使用超過4GB的RAM是不可能的。系統外設保留了一些地址空間，但可以安裝4GB的RAM，並且合成器可以識別超過3GB單元的數百兆的額外內存。

大部分I / O都通過NKS4發生。NKS4是基於TI AM1806處理器的定制板。它處理觸摸屏（幀緩沖和輸入），所有按鈕和LED以及音頻I / O。它運行一個相當簡單的固件，並通過USB端口連接到x86。固件是可升級的，但不會在內部升級。相反，要升級它，在打開設備時按住ENTER + PAUSE鍵，將其置入引導加載程序模式。然後，您將USB設備端口連接到PC，並運行Korg提供的用於更新固件的實用程序（顯然是通過USB MIDI接口）。這看起來很愚蠢，因為在Kronos的固件更新過程中，NKS4內部更新會更有意義，但是很好。

鍵盤通過RS232端口分別連接到x86。 它由一個單獨的微控制器控制。也許他們決定使用RS232端口來減少一些延遲，而不是通過NKS4和USB發送鍵控數據。

軟體架構

Kronos運行一個標準的BIOS，並正常啟動，使用一般舊版的GRUB引導。但內核有點特別：它包括實時補丁（RTAI）和一些Korg自定義修改。

先不討論Korg違反GPL。可以這麼說，他們在很多地方完成了這個任務，從未公開的內核補丁到一個將GPL-only符號重新導出為非GPL的Shim模塊傳輸到帶補丁和無源代碼的GPL用戶空間應用。他們花費精力將內核源碼和不完整的補丁分發到隨設備附帶的DVD中。

內核引導到一個精簡的Linux發行版，只有最小的用戶空間和init。然後它執行一些基本的初始化，然後開始加載內核模塊並啟動用戶空間守護進程。Kronos運行時有兩個主要組件：OA.ko是主要的合成器內核模塊，並且執行內核空間中的所有實際音頻處理（使用RTAI提供的實時服務）。Eva是用戶界面，並在用戶空間中運行。用戶界面通過NKS4 over USB導出的幀緩衝區顯示，可用/dev/fb1

其他用戶空間進程處理其他事情，例如vsftpd內置FTP服務器， avahi/mDNS/ifplugd處理網絡接口。fanctrld據我所知，還有一種有趣的事情，除了守護進程和sleep(1)循環運行之外別無他法。我猜它過去曾經是一個風扇控制守護進程，並且在某個時候被替換為一個沒有運行的守護進程…

合成器模塊，用戶空間軟件和一些樣品實際上存儲在加密文件系統映像中 – 這是Kronos安全系統的一部分。這些密鑰存儲在 /.pairFact3文件中，並自己加密。解開的密鑰是通過與Atmel AT88SC0204CACryptoMemory芯片進行密鑰交換獲得的，該 芯片已連接並通過NKS4提供。該loadmod.ko內核模塊負責這樣做的，而且還包含其他位和混淆和片安全特別，它執行文件系統完整性檢查，並拒絕如果它檢測到篡改的工作。

Kronos使用cryptoloop 加密文件系統映像，AES-256-CBC加密……儘管它們實際上使用124位密鑰轉換為ASCII十六進制格式作為256位AES密鑰。是的，124位，而不是128位，因為它們有一個bug，它會佔用最初的128位密鑰的最後一個。這三個映像檔及其各自的掛載點是

/korg/ro/Eva.img → /korg/Eva
/korg/ro/Mod.img → /korg/Mod
/korg/ro/WaveMotion.img → /korg/rw/PCM/WaveMotion

整個安全機制相對毫無意義，因為獲得root shell並不困難（正如我們將會看到的那樣），一旦擁有root用戶，您可以很好地請求loadmod.ko加載加密的文件系統並將其內容複製出來。獲取加密密鑰（對每台Kronos來說都是一樣的）也很容易，可以通過幾種方式完成（甚至可以將它們中的一個放在推文中，兩次），但我將把它作為讀者的練習。只要說鍵是31個字符的十六進製字符串就足夠了。kronoshacker更新了他的博客，並發布 了密鑰和一種方法，以便在我發布此帖時幾乎同時獲得這些密鑰，所以如果您想要密鑰只需遵循該鏈接。他使用了一個內核補丁，但是我的兩個簡單的方法是簡單地使用LOOP_GET_STATUS64用戶空間的ioctl（它很高興為您提供密鑰），或者，如果您希望您的keydumper適合tweet，請執行以下操作（安裝文件系統後）：

# busybox mknod /dev/mem c 1 1
#busybox strings /dev/mem | grep -E '^[0-9a-f]{31}$' | busybox tail -n 3

引文

kronoshacker涵蓋了不少主題，所以如果你想了解詳細信息，你現在應該前往該博客：

• 安全芯片
• 內核shenanigans和混淆
• / sbin / loadoa
• 固件更新
• 文件系統完整性檢查
• 編譯一個新的內核
• loadmod.ko（大部分安全/模糊處理在這裡）

 

我假設您至少知道內核是什麼，如何使用標準的Linux命令行工具，以及什麼是busybox以及如何使用它來替換丟失的系統工具。

入門：開啟Kronos

kronoshacker已經為我們提供了一個 根源於Kronos 的現成 更新文件並安裝了一個SSH守護進程。但是，他沒有解釋它是如何工作的，所以我會:-)。

loadmod.ko執行文件系統完整性檢查，其中意味著如果您嘗試更改文件（例如，/etc/passwd或/etc/inittab停止對引導過程的微小修改），它將拒絕工作 。但是，它僅檢查其現有預期文件列表的完整性; 它不知道或關心任何其他文件。它也沒有檢查任何東西/boot，因為這通常沒有安裝。

kronoshacker的方法非常簡單：不是修改現有的init系統，而是安裝並行init系統。更新包安裝busybox並將其鏈接到/bin/init（與原始版本相比/sbin/init）。Busybox被修補以/etc/inittab.busybox代替使用/etc/inittab。由於GRUB配置沒有被選中，內核可以被告知使用init=/bin/init，而啟動並行init系統。由於原始文件未觸及，loadmod.ko因此沒有更明智的做法。SSH守護進程是dropbear，修補為使用Kronos的FTP憑證而不是/etc/passwd登錄，因此您可以方便地從UI更改根SSH密碼。

Defroning Kronos安全：loadmod.ko和加密

loadmod.ko主要工作是進行密碼交換，計算加密過的音色，並安裝它們。因此，通過複製內容，我們應該能夠擺脫它，避免文件系統完整性檢查並加速啟動。

但是，擺脫loadmod.ko會破壞音頻合成OA.ko。這也是混淆的一部分。loadmod.ko向魔術核心狀態（未發布的Korg內核補丁的一部分）通過檢查而觸發魔法值OA.ko。如果OA.ko沒有找到合適的值，它會故意削弱音頻合成器。這是以一種有趣的方式完成的：該模塊包含兩個硬編碼的128位SSE浮點常量，{1., 1., 1., 1.}並且被 {-1., -1., -1., -1.}適當地調用allPlusOne並且allMinusOne （是的，它們將模塊分配滿符號…），它們在整個合成器中被用作常量值。如果魔法值校驗失敗，這些被改寫{0.7, 0.7, 0.7, 0.7}，並{-0.2, -0.2, -0.2, -0.2} 分別說這不必要確實非常糟糕的事情音頻。

kronoshacker已經通過構建一個自定義的內核來處理這個問題，該內核已經在正確的位置合併了魔法值來滿足OA.ko。你會發現他的預構建的內核，補丁集，並解釋 在這裡。

安裝這個內核只需要掛載/boot，在那裡拷貝，然後更新GRUB config（/boot/grub/grub.conf）來使用它：

default=0
timeout=3

title kronos-bzImage-20160505 + busybox
        root (hd0,0)
        kernel /kronos-bzImage-20160505 root=/dev/sda2 max_loop=16 fbcon=map:0 memmap=384m vga=0x0303 loglevel=0 fastboot Single raid=noautodetect elevator=noop init=/bin/init

title Linux (2.6.32.11)-320m STG 8x6 + busybox
        root (hd0,0)
        kernel /bzImage root=/dev/sda2 max_loop=16 fbcon=map:0 memmap=384m vga=0x0303 loglevel=0 fastboot Single raid=noautodetect elevator=noop init=/bin/init

title Linux (2.6.32.11)-320m STG 8x6
        root (hd0,0)
        kernel /bzImage root=/dev/sda2 max_loop=16 fbcon=map:0 memmap=384m vga=0x0303 loglevel=8 fastboot Single raid=noautodetect elevator=noop

這樣做後，我們可以安全地擺脫loadmod.ko。為此，我們將首先複製加密的圖像。從引導的Kronos：

# mount /korg/Mod
# mount -o remount,rw /korg/ro
# cp -vr /korg/Mod /korg/Eva /korg/ro/
# cp -vr /korg/rw/PCM/WaveMotion /korg/rw/PCM/WaveMotion2

/korg/ro默認情況下沒有足夠的可用空間，因此我決定將WaveMotion數據放入，/korg/rw而不是放在安裝的位置。

請注意，/korg/Eva只能安裝一次（loadmod.ko第一次安裝後擦除加密密鑰），但其他圖像可以重複安裝/卸下。相反，/korg/Mod在它所包含的內核模塊被加載後被卸載，但可以自由重新安裝，同時/korg/Eva必須保持安裝，以便用戶空間軟件可以運行。有人想知道Korg是否意味著將單一安裝保護添加到/korg/Mod相反的位置，但是卻把它弄糟了……

接下來，我們需要替換/sbin/loadoa，它實際上只是一個試圖成為shell腳本的C程序（嚴重地說，它充滿了popen對shell管道等的調用），並且將其修改為不加載loadmod.ko，但是替代只需將綁定的數據複製到最終的掛載點上即可。我把/sbin/loadoa.sh 這個做了。將它複製到Kronos中，確保 chmod 775 /sbin/loadoa.sh，然後編輯/etc/OA.clonos.rc（/etc/OA.rc由kronoshacker的根包安裝的備用版本）來調用它，而不是/sbin/loadoa。

計劃

隨著這些令人討厭的位，現在是計劃硬件升級的時候了。kronoshacker記錄 了他選擇的硬件，我用它作為基準。這就是我想到的：

• 主板：華碩H110I-PLUS
• CPU：Core i3-6320（Skylake）
• 內存：Crucial 8GB DDR4（2×4GB）
• SSD：Crucial MX200 250GB

這個CPU與kronoshacker使用的一樣（他還 為它準備了一個現成的CostProfile，它告訴OA.koCPU的性能，以便它可以正確執行音色合成）

我對串口硬體冒了一點賭注。正如kronoshacker所解釋的那樣，它 OA.ko直接與串行硬件（超級I / O芯片）進行通信，並期望使用特定類型的芯片，超越標準的16550寄存器。kronoshacker 確認 與Winbond W83627（原裝Kronos），Nuvoton NCT6627UD（Kronos 2）和Nuvoton NCT6776（替換主板）的兼容性。我的主板也有一個Nuvoton芯片，但是有一個不同的芯片（NCT5539D），我不確定它是否可以兼容開箱即用，或者如果我需要補丁支持OA.ko。謝天謝地，它確實只是工作。

8GB的RAM是過度使用 32位操作系統通常幾乎不能使用3GB以上。但是，我想嘗試使用高內存（運行Kronos虛擬化，任何人？）構建PAE內核或其他實驗，此外，購買少於8GB的RAM現在感覺很愚蠢。

把它拆開

此時我意識到Kronos中的PSU沒有ATX12V連接器。但是，PSU側的連接器有一個未插入的引腳，恰好是另一條12V線路，所以我決定使用它。我用老式PSU對一個ATX12V連接器和電纜進行了拆解，並且將所需的引腳拆分為適合來自舊式PSU的AUX連接器（恰好具有適當類型的引腳）的Kronos連接器。沒有沒有人口聚集的地方，我也不想過分碾壓原來的線路，所以我決定使用一個螺絲端子並將接地線連接到PSU的一個螺絲（它們接地）。

我還決定添加外部HDMI和以太網連接，所以我可以用蓋子控制啟動過程。Kronos通常使用外部USB以太網適配器作為（可選）網絡，但內部端口（通常未連接）也可以使用，並且將DHCP關閉網絡。

原始內核在新硬件上啟動。但是，該內核沒有USB xHCI功能支持，因此無法在新硬件上運行該合成器。儘管如此，如果使用PS / 2鍵盤，它確實會為您提供可用的終端。kronoshacker的內核包含一個很好的backported xHCI驅動程序。華碩主板擁有與原裝Atom主板相似的r8169級別以太網芯片，因此無需任何額外模塊即可正常工作。

一個BIOS設置非常重要：必須關閉C2以上的CPU C狀態，否則在加載RTAI模塊時會導致隨機掛起。我也有機會將BIOS升級到最新版本。

有了新的硬件，Kronos比原來強大了幾倍，同時發聲數更強大了。

然而，有一個令人失望的是：在新硬件的情況下，Kronos的樣本內存可用性略低於舊的。這是怎麼回事？

※TOLUD: Top of Lower Usable DRAM 
※TOUUD: Top of Upper Usable DRAM 

為什麼新的硬件會進一步限制內存？那麼，在32位系統上，內核只能使用低於4GB的內存。但系統i/o和其他特殊地址範圍也需要映射到4GB以下。為了達到這個目的，BIOS將從地址空間頂部取出一塊內存，並禁用它或將其重新映射到4GB以上（取決於BIOS配置），然後為外設和其他系統範圍使用相應的空間。這是由TOLUD芯片組配置中的寄存器控制的，並且在它之後變得已知。

我的主板TOLUD默認配置為3 GiB，並且在一些ACPI開銷後，最大可用RAM地址為2974 MiB：

BIOS-provided physical RAM map:
 BIOS-e820: 0000000000000000 - 000000000009c800 (usable)
 BIOS-e820: 000000000009c800 - 00000000000a0000 (reserved)
 BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved)
 BIOS-e820: 0000000000100000 - 00000000b9ea6000 (usable)
 BIOS-e820: 00000000b9ea6000 - 00000000b9ea7000 (ACPI NVS)
 [...]
 BIOS-e820: 00000000bffff000 - 00000000c0000000 (usable)

不幸的是，雖然kronoshacker的主板有一個用戶可配置的TOLUD 設置，但華碩不支持這個設置，而且它的默認設置會保留比原來主板更多的內存。這似乎需要一個BIOS修補程序來解決，但幸運的是，有一個更簡單的方法。要看看發生了什麼，我們將不得不查看BIOS映像。

UEFI BIOS相當複雜，包含許多模塊和嵌套的數據結構。有些工具如UEFITool可以讓UEFI BIOS映像變得更加簡單。

將ASUS BIOS加載到UEFITool後，我們可以提取Setup模塊PEI圖像。UEFI設置屏幕使用一種字節碼語言進行描述。值得慶幸的是，還有一些工具可以自動反編譯。我使用 通用IFR提取器。

TOLUD在反編譯的設置IFR中搜索我們發現，實際上，設置在那裡：

Suppress If: {0A 82}
    True {46 02}
    Setting: Max TOLUD, Variable: 0x483 {05 91 FC 04 FD 04 20 06 01 00 83 04 10 10 00 0B 00}
        Default: 8 Bit, Value: 0x0 {5B 06 00 00 00 00}
        Option: Dynamic, Value: 0x0 {09 07 FE 04 00 00 00}
        Option: 1 GB, Value: 0x1 {09 07 09 05 00 00 01}
        Option: 1.25 GB, Value: 0x2 {09 07 08 05 00 00 02}
        Option: 1.5 GB, Value: 0x3 {09 07 07 05 00 00 03}
        Option: 1.75 GB, Value: 0x4 {09 07 06 05 00 00 04}
        Option: 2 GB, Value: 0x5 {09 07 05 05 00 00 05}
        Option: 2.25 GB, Value: 0x6 {09 07 04 05 00 00 06}
        Option: 2.5 GB, Value: 0x7 {09 07 03 05 00 00 07}
        Option: 2.75 GB, Value: 0x8 {09 07 02 05 00 00 08}
        Option: 3 GB, Value: 0x9 {09 07 01 05 00 00 09}
        Option: 3.25 GB, Value: 0xA {09 07 00 05 00 00 0A}
        Option: 3.5 GB, Value: 0xB {09 07 FF 04 00 00 0B}
    End of Options {29 02}

但它被永久抑制（即隱藏）Suppress If: True。

雖然我們無法訪問設置選項來更改TOLUD設置，但該選項及其相應的配置變量確實存在。因此，我們可以手動更改選項的值，而無需使用Setup Utility。這些值存儲在SetupUEFI變量中：

    Default Store:  0x1 {5C 06 02 00 01 00}
    Var Store: 0x1[3597] (Setup) {24 1C 43 D6 87 EC A4 EB B5 4B A1 E5 3F 3E 36 B2 0D A9 01 00 0D 0E 53 65 74 75 70 00}

更改UEFI變量的一種簡單方法是啟動到啟用UEFI的Linux內核（在UEFI模式下）並使用efivarfs。我用我可靠的SystemRescueCD USB棒（它支持UEFI模式）。啟動到兼容的內核後，我們可以看到Setup變量：

% cd /sys/firmware/efi/efivars
% ls -al Setup-*
-rw-r--r-- 1 root root  3601 May 31 21:16 Setup-ec87d643-eba4-4bb5-a1e5-3f3e36b20da9

一些手動的完整性檢查表明，IFR數據中指定的可變偏移量不直接對應於變量中的字節偏移量，而是從偏移量4開始的字節偏移量。因此，我們的變量位於偏移量0x483 + 4處。我們想寫的值是0xb（3.5 GiB）：

% cp Setup-ec87d643-eba4-4bb5-a1e5-3f3e36b20da9 ~/Setup
% cd
% cp Setup Setup.bak
% echo -ne '\x0b' | dd of=Setup bs=1 seek=$((0x483 + 4)) conv=notrunc
% cat Setup >/sys/firmware/efi/efivars/Setup-ec87d643-eba4-4bb5-a1e5-3f3e36b20da9

重新啟動進入Kronos系統確認修復工作正常：

BIOS-provided physical RAM map:
 BIOS-e820: 0000000000000000 - 000000000009c800 (usable)
 BIOS-e820: 000000000009c800 - 00000000000a0000 (reserved)
 BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved)
 BIOS-e820: 0000000000100000 - 00000000d0d53000 (usable)
 BIOS-e820: 00000000d0d53000 - 00000000d0d54000 (ACPI NVS)
 [...]
 BIOS-e820: 00000000d7fff000 - 00000000d8000000 (usable)

這實際上是3.375 GiB而不是3.5 GiB的TOLUD配置，但總比沒有好。這應該給Kronos 3341 MiB的記憶。然而……可用內存略有增加，但不如預期的那麼多。事實上，我們預計大約2957 MiB的可用堆（3341 MiB – 384 MiB），但OA.ko報告獲得大約2619 MiB的內存：

5b000000..feb53000 is ioremapped memory, 2746560512 bytes, physicalBankStart @ 0x18800000

OA.ko內存管理

為了理解如何優化可用的合成器內存，我們需要看看Kronos如何進行內存管理。與其使用標準Linux內核機制管理大部分RAM，Kronos設置為僅啟用RAM的低384 MiB（如memmap=384M命令行選項所指定的）。然後，OA.ko獲取剩餘的可用內存，將其作為一個巨大的物理連續塊映射到內核空間，並對其執行自己的內存管理。

為了實現這一點，內核使用一些非標準的1G / 3G用戶/內核內存拆分來構建。這意味著，在32位系統上可用的4 GiB地址空間中，前1 GiB分配給用戶空間，最後3 GiB分配給內核空間。這使它可以將近3GiB的合成堆映射到內核空間。

我不知道他們為什麼要這樣做：通常情況下，不支持scatter-gather DMA的啞硬件需要物理連續的內存，但在這種情況下，內存只能由x86本身使用。使用物理上連續的內存在標準分頁內存上幾乎沒有任何好處（它仍然通過頁表來映射）。我唯一的猜測是，OA合成器是其他Korg合成器產品的後代，它們直接在沒有MMU的裸機上運行，並且設計為直接與物理內存一起工作，而Korg只是將此架構延伸到Kronos。

無論哪種方式，最終結果都是內核虛擬地址空間跨越了3 GiB範圍0x40000000–0xffffffff。但是，默認情況下，內核映射其地址空間底部的所有可用RAM。由於Kronos告訴內核使用384MiB的RAM，因此可用內核地址空間的3 GiB-384 MiB = 2688 MiB來映射合成器堆。這是我們記憶力受限的原因。

內核並不需要在所有時間映射所有的物理內存。事實上，在更典型的3G / 1G分割（內核為1GiB）和超過1GiB的RAM的系統中，這是不可能的。所以內核支持 不直接映射的高內存概念。可以指示使用vmalloc命令行選項為高內存映射保留更多空間。我們只給內核提供直接映射物理內存的64MB。這意味著3072 MiB-64 MiB = 3008 MiB的vmalloc空間。開銷減去另外16 MiB，剩下2992 MiB。

添加vmalloc=2992M到內核命令行產生：

320MB HIGHMEM available.
63MB LOWMEM available.
[...]
found a suitable region at 0x18800000 of size 0xb8553000 (3092590592).  Our size request is 0xcd000000 (3439329280)
sPhysicalBankStart = 0x18800000, physMemSize = 0xb7b53000 (3082104832), sIORemapBase = 0x47000000
47000000..feb53000 is ioremapped memory, 3082104832 bytes, physicalBankStart @ 0x18800000

2972 MiB內核虛擬地址空間的29B MiB用於合成器堆，UI現在報告可用的大量2277 MiB的用戶採樣內存（減去其他合成器內存使用量之後）。

這是我們所能做到的。低內核直接映射可能會起作用，但這會帶來收益遞減（最多64 MiB），而且我們已經將BIOS的3.26 GiB作為低內存運行（請記住，用戶空間佔用了384 MiB ）。要獲得多達512Mb的樣本內存，我們需要一個具有非標準0.5G / 3.5G虛擬地址空間拆分的自定義內核，啟用PAE以便為用戶空間使用高內存，並且需要多個補丁OA.ko來處理 – 但所需的修補可能可行也可能不可行，因為PAE可能會導致二進制模塊兼容性問題。可以做一些小的改進（現在內核在重疊的PCI地址空間中浪費了8Mb的內存），但是它們不值得修復。就目前而言，這和它將要獲得的一樣好。

還剩下要做的事情

升級後的Kronos工作得很好，但我想看一些問題。

至少有一個Combi有問題：如果復調音高度過高，I-A010 Phantasies會崩潰整個Kronos（即使在正常播放時也很容易，無需混合鍵）。原始CostProfile數據不會發生這種情況，這會限制複音以避免CPU過載。我的猜測是，這是一個合成器錯誤，在原始硬件上根本不會觸發，因為語音竊取者會在更早的時候發出聲音並降低聲音。至少恢復CostProfile文件可以解決這個問題（儘管它將合成器的性能限制在原始硬件的性能範圍內），並且切換文件很容易，所以不會丟失任何重要的東西。

我懷疑新硬件上的CPU鎖定可能是錯誤的。舊CPU和新CPU都是雙核心超線程CPU，但CPU的順序不同：在Atom上，CPU 0,1和2,3是線程對，Skylake上則是0,2和1 ，3。這可能意味著單個內核最終會在兩個線程上有效地承載合成和效果加載。再次，新的CPU更加強大，這可能無關緊要…

到目前為止，我一直在使用kronoshacker的預編譯內核，因為它似乎運行良好，但我打算編譯自己的代碼，並在github上建立自己的補丁集分支。