[YU-RIS] SDK編譯器調用

YU-RIS的官方是提供SDK下載的，而且他們2023年還更新了提供下載的引擎版本到0.490

這個SDK里包含了一個完整的demo工程文件，還有未編譯的腳本，并附帶了一些工具，比如腳本的編譯器和封包工具，音頻視頻轉換工具之類的。

最近為了研究YU-RIS引擎的腳本反編譯，發(fā)現(xiàn)官方的SDK腳本文件雖然是明文，但是運行的時候是要調用編譯器編譯的，所以這里可以自己修改腳本來觀察編譯后的文件，這樣研究反編譯也方便很多，還可以對官方編譯器進行逆向之類的。

不過正當想著怎么使用官方這個編譯器的時候，發(fā)現(xiàn)，壓根沒有文檔啊！也沒控制臺或GUI界面！雙擊啟動直接沒反應，真是煩人吶，唯一能觀察到的就是啟動官方的demo程序（需要轉區(qū)不然編譯器無法正常編譯）會出現(xiàn)編譯腳本的dialog，等它編譯完成就進入demo了，但是檢查目錄下并沒有任何編譯后的文件。推測應該是主程序去調用了編譯器程序并把編譯的文件直接放在了主程序的堆里。

真是太傻X了！一個編譯器還搞這樣！

觀察目錄結構

SDK下載后解壓到 “システム”文件夾里就是demo的項目目錄了，

官方還有一份這個目錄的結構說明

/システム/yu-ris.exe          :起動ファイル
         /エンジン設定.exe    :エンジン動作設定ファイル
         /yscfg.dat           :エンジン動作設定データ
         /system/forE-mote/   :E-mote動作用DLLファイル
                /forWin98/    :Win98以降版用EXEファイル
                /YSCom/       :コンパイルツール
                /YSConv/      :畫像形式変換ツール
                /YSEnv/       :環(huán)境情報取得ツール
                /YSIcon/      :EXEアイコン書換ツール
                /YSOgg/       :OGGファイル変換ツール
                /YSOne/       :1ファイルEXE作成ツール
                /YSPac/       :ファイルパックツール
                /YSScr/       :スクリーンセーバー作成ツール
                /YSSelf/      :自己解凍EXE作成ツール
                /YSYmv/       :YMVムービー作成ツール
                /ysconfig.txt :システム設定ファイル
         /data/               :ERISサンプルプロジェクト

/マニュアル/                  :β4暫定マニュアル

/はじめに.txt                 :簡易説明テキスト(このテキスト)

data里就是項目文件了，包含了腳本代碼和資源文件，system里則是一些工具，編譯器就是YSCom

轉區(qū)啟動可以看到這個界面，編譯完成后這個程序就退出了，demo正常運行啟動，可見是在運行的時候進行了腳本的編譯，不過目錄下并沒有編譯后的文件就是了

找到編譯器的主程序看看，可以看到YSCom.exe就是了，還有個YSCom.ycd的文件，這個Com應該是command的縮寫，里面的結構和編譯后ysbin里的ysc.ybn文件很像，那些字符串其實是按順序的Opcode的名稱和參數(shù)的名稱，這個有機會再說吧。雙擊YScom.exe也沒任何反應，控制臺運行也沒有任何輸出。

方法論

這個問題的核心就是通過 CreateFileMapping 通過內核對象來共享數(shù)據(jù)

主程序編譯器調用分析

這里只講解關鍵部位的作用，具體的函數(shù)調用流程可以到YurisTools里下載IDA的文件自行查看。

yu-ris.exe就是主程序了，既然要調用YSCom.exe進行編譯，肯定有個CreateProcess這樣的創(chuàng)建進程的操作，對該API下斷點是一個不錯的選擇。而且既然要創(chuàng)建進程，當然會有進程名稱這個參數(shù)，所以搜索字符串YSCom.exe也是一個思路。

還有就是可能涉及到進程之間的數(shù)據(jù)傳遞問題，也就是編譯器如何把編譯后的腳本數(shù)據(jù)傳遞給主程序的問題。

隨便思索一下，現(xiàn)在把yu-ris.exe拽進IDA先。進來后搜一下字符串，YSCom果然是有的，而且還是相對路徑

查看一下引用，發(fā)現(xiàn)都來自同一個函數(shù)內部，這里函數(shù)名和變量名我稍微處理了一下，并添加了結構體偏移的信息

一看到CreateFileMapping差不多結構就出來了，這是通過內核對象來在不同進程之間傳遞數(shù)據(jù)啊，不懂也沒關系稍后介紹吧。

先在x64dbg里斷下這個函數(shù)，發(fā)現(xiàn)確實走了這里，并且這個函數(shù)執(zhí)行過程中就出現(xiàn)了編譯的dailog窗口，差不多就可以確定，這個函數(shù)就是調用編譯器的函數(shù)了，那么我們就仔細來分析這個函數(shù)。

這里還有一點需要注意，因為編譯器并不能在中文系統(tǒng)下正確編譯，所以需要轉區(qū)運行，那么轉區(qū)運行怎么調試呢？Locale Emulator可以為每個程序創(chuàng)建配置文件，在配置文件里把 Create process with CREATE_SUSPENDED勾上就可以了，這時候進程創(chuàng)建后里面的線程都是掛起的，x64dbg附加后再resume thread就可以轉區(qū)調試了。而且該進程就算后續(xù)再創(chuàng)建子進程也是可以被LE轉區(qū)的，這也就是為什么這樣編譯器進程就可以正常編譯了。

其實不轉區(qū)也是可以打開程序的，只不過會在編譯階段報錯，這個原因和路徑有關，只要路徑全為英文就可以打開，具體原因參見[無法直接運行的解決方法](https://github.com/Dir-A/Dir-A_Essays_MD/blob/main/引擎逆向/YU-RIS/[YU-RIS] 無法直接運行的解決方法.md)

一進來就是fopen，可以看到fopen成功后就fclose了，可見這個僅僅只是判斷YSCom.exe這個文件是否存在而已

緊接著就是CreateFileMapping了，這個函數(shù)其實就是映射文件，當然具體的專業(yè)說法就自己去查吧，這里就簡單說一下，CreateFileMapping創(chuàng)建一個內核對象，我們都知道內核對象不同于在本進程的那些對象，內核對象是可以在不同進程之間共享的，CreateFileMapping可以理解為創(chuàng)建了一個buffer，但是這個buffer是可以在不同進程之間來訪問的，要訪問這個buffer就得把這個buffer映射進當前進程的地址空間，相當于我們要得到一個buffer得new一樣，不過這個是用MapViewOfFile而且buffer的內容是確定的，返回值就是指向這個buffer在當前進程的地址了，你可以修改buffer里的內容，然后別的進程就可以OpenFileMapping然后MapViewOfFile來取得里面的內容。

好了繼續(xù)看代碼，第一步CreateFileMappingA了一個0x200的空間，并命名為YU-RISCompilerFileMapObject，緊接著MapViewOfFile來映射到進程地址空間得到指針hdr_ptr，這個空間大小其實就512字節(jié)了，具體結構如下

struct YSCOM_Compiler_HDR
{
	uint32_t uiCompileState0;          // State For Compiler Open YSCOM_Compiler_HDR            1 = Successfully
	uint32_t uiCompileState1;          // State For Engine Create YU-RISCompilerFileMapObject2  1 = Successfully
	uint32_t uiCompileState2;          // State For Compiler Compiled All Script                1 = Successfully
	uint32_t uiCompileState3;          // State For Compiler Compiled All Script                1 = Successfully
	uint32_t uiCompiledScriptCount;
	uint32_t uiCompiledScriptsSize;
	uint32_t uiUnknow1[0x1A];
	uint32_t uiEngineVersion;          // 486
	uint8_t  ucProjectPath[0x17C];
};

接著可以看到這里對版本號uiEngineVersion和項目目錄進行了賦值，前頭還有一個sg_fnInitBufferToZero(hdr_ptr, 0x400);其實這是一個全局的函數(shù)指針，具體指向的函數(shù)由cpu的指令集和配置文件決定，在0x00403588的函數(shù)會對這些全局的函數(shù)指針進行初始化。

緊接著就調用了CreateProcessA來運行編譯器進程，值得注意的是它沒給CreateProcessA的第一個參數(shù)傳遞編譯器的程序名，而且在commandline參數(shù)里寫system\\YSCom\\YSCom.exe ys來調用編譯器，并且?guī)в幸粋€arg，就是ys。

由此可見，編譯器進程應該會捕獲arg，在YSCom的WinMain有如下代碼

先是判斷了args的數(shù)目，顯然是兩個，如果直接雙擊運行編譯器的exe顯然是一個arg，那么start_compile_flag就會變成0從而無法進入StartCompile函數(shù)來執(zhí)行編譯，也就是退出了程序。如果正確的添加了arg，那么會對比第二個arg是不是ys，是的話給start_compile_flag賦值true，也就可以進入StartCompile函數(shù)來進行編譯了。通過對arg的觀察，發(fā)現(xiàn)這個ys除了在這里進行驗證，也沒別的作用了，我們完全可以強制跳轉到StartCompile函數(shù)。

回到我們的主程序，然后是一個while死循環(huán)，里面在判斷這個編譯器進程是否在運行，并且等待uiCompileState0，被修改為1，顯然是等待編譯器的進程去修改，也就說明編譯器會去OpenFileMapping，然后MapViewOfFile，并修改。如果編譯器進程在運行，并且修改為1，則退出循環(huán)。

那么我們可以通過搜索YU-RISCompilerFileMapObject這個內核對象的名稱來在YSCom.exe里定位到這部分的代碼

搜索結果有兩處，第一處可以看到檢查了版本號，并且把主程序當前的目錄路徑字符串復制了一份。但是這里并沒有去修改uiCompileState0。

第二處如下

可以看到這里打開了YU-RISCompilerFileMapObject并且映射進地址空間，修改了uiCompileState0為1，這樣主程序的死循環(huán)就可以退出來了。同時還傳遞了腳本數(shù)量和編譯后buffer的總大小信息，然后對ProjectPath拷貝了一些東西，并死循環(huán)來等待uiCompileState1被修改成1

回到我們的主程序，死循環(huán)退出后獲取了編譯腳本的總數(shù)和總大小，并開始創(chuàng)建名為YU-RISCompilerFileMapObject2的新內核對象，該內核對象的大小正是剛剛傳遞過來的編譯文件總大小。

創(chuàng)建完成新的內核對象，就對uiCompileState1修改成1，此時一個死循環(huán)，等待編譯進程退出。

來到編譯器這邊

可以看到打開了新的內核對象，并有一個以腳本數(shù)量為范圍的循環(huán)處理，猜測就是編譯部分的代碼了，不過這里好多都是函數(shù)指針數(shù)組的調用，看起來有點麻煩，需要先回去函數(shù)指針數(shù)組初始化的地方看數(shù)組對應的真正函數(shù)地址。

處理完成后給uiCompileState2和uiCompileState3都給設置成1，接著就是清理工作了，并退出程序了。

回到主程序，當檢測到編譯器退出后，就會malloc一個空間，并把數(shù)據(jù)都拷貝過來，然后生成一個包含描述腳本大小和腳本名稱，腳本數(shù)據(jù)地址的結構，用于等下的腳本讀取，也就是sg_ysbin_file_list了。

解析編譯器返回的數(shù)據(jù)

當編譯器進程退出后，map_file內buffer里的數(shù)據(jù)如下

結構也可以很簡單，腳本路徑字符串長度，腳本路徑字符串，腳本數(shù)據(jù)大小，腳本數(shù)據(jù)，按照這個結構解析就可以得到全部編譯后的文件了，值得注意的是這些編譯后的文件都是加密的，也就是xor啦，用的是默認的密鑰，0x96AC6FD3，也可以猜密鑰，方法很多。

struct YSCOM_Compiled_Script_Entry
{
	uint32_t uiScriptNameSize;         // With End 0x00, With Path
	uint32_t uiScriptFileSize;
	// file data
};

// Mapping OBJ Name YU-RISCompilerFileMapObject2 : YSCom.exe : 0x0040168C
struct YSCOM_Compiled_Script
{
	YSCOM_Compiled_Script_Entry[YSCOM_Compiler_HDR.uiCompiledScriptCount];
};

再談YU-RIS的文件讀取模式

如果你看到我之前的文章就知道，yu-ris讀取文件有不同的模式，通過一個讀取優(yōu)先順序的數(shù)組來控制。

可以看到有三種模式

可見GetFileViaList這個分支就是讀取剛剛編譯器生成的文件數(shù)據(jù)。而下面兩個則是從封包和目錄下讀取文件。

sg_ysbin_file_list結構如下

實現(xiàn)編譯器的啟動器

觀察完了上述調用過程，心里應該也有個大概的流程了，我們先可以自己寫一個程序來調用編譯器編譯文件并且把編譯的文件保存起來。

https://github.com/Dir-A/YurisTools/blob/main/lib/YurisStaticLibrary/YSCOM.cpp#L21C7-L21C7

當然現(xiàn)在編譯階段的大概位置也可以確定了，對編譯過程的分析也可以找到入手點了。

還有不太明白的，沒看懂的，建議自己手動調試一下。

總結

實際上這就是兩個進程之間通過內核對象進行數(shù)據(jù)交換罷了。

主程序通過創(chuàng)建內核對象 YU-RISCompilerFileMapObject 來和編譯器交換所需要的信息

編譯器把編譯后的數(shù)據(jù)通過 YU-RISCompilerFileMapObject2 來傳遞給主程序

接著主程序解析編譯后的數(shù)據(jù)，生成一個描述文件的結構（文件名，大小，地址）的數(shù)組

引擎通過切換不同的文件讀取模式，來在該數(shù)組中查找需要的文件

這也就是為什么編譯后目錄下沒有任何編譯文件的原因了，因為它全部編譯的文件都存在主程序的堆里。