隨便說說，我也參與過某組某遊戲的破解，知道壹些，就隨便說說。其中引用了壹部分資料
壹般來說，就分幾步：1、破解遊戲 2、文本導出 3、圖片導出 4、翻譯 5、潤色 6、測試
破解遊戲例如哪裏是字庫，哪裏是圖片（分別對應那些圖片），哪裏是文本區，哪裏是聲效區……如果文件系統比較復雜的ROM，不同文件分別是什麽內容也要進行判明。另外有的遊戲不同文本對應不同字庫，這些都是需要認真確認的內容。有的ROM可能有壓縮過的內容，如果這些內容涉及漢化的需要，這時還需要進行解壓和壓縮的測試。壹般這個階段我是會準備幾張大紙進行詳細記錄的，這樣為以後的工作將帶來很大方便。2 字庫導出 這個是關系到漢化可能性的最關鍵部分。壹般遊戲的字庫有分完整字庫和精簡字庫。完整字庫裏面包含了7000多個字符（其中6000多個漢字），而精簡字庫壹般只有1000－2000個遊戲裏面實際運用到的字符。無論那個字庫，由於日語漢字缺乏不少中文常用字，都必須修改，而精簡字庫更需要大改造，甚至擴容。後面會專門針對字庫HACK進行講解，此處暫時打住。3 文本試驗漢化，就是用中文替換原來的日本語內容，所以需要對這個替換的可能性進行試驗。當然，初步破解不壹定要很正經的進行文本導出導入，或翻譯修改，只需看看有沒有修改的可能性就行。前面提到的不少教程都有涉及這方面的操作，可以仔細研究。4 圖片HACK的主要就是圖片拼組，色版處理等。另外壹些需要漢化的關鍵圖片（圖片裏面有需要漢化內容的）必須找出來。另外還可能需要做好色版導出，圖片導出等準備工作。也可以進行壹些圖片修改的試驗。如果上面的部分準備完成，並測試成功，那麽恭喜，這個漢化項目已經成為可能。可以推進下壹步工作了。
下壹步就是學CT了
CT全稱CrystalTile，是由天使組的Crystal在過去的tile工具的基礎上不斷改進的成果。可以說是漢化GBA/NDS遊戲非常好用的工具。另外它還綜合了差值搜索，LZ77解壓，等不少有用的功能，而且還特意為漢化NDS遊戲進行了優化。另外這個工具的版本還不斷修正更新，我用的是5月中的版本，寫本文的時候又更新了幾個版本了。其實以前的TILE工具的壹些操作在CT上面是通用的，那些工具都有壹些網上的教程，但對於沒有接觸過的朋友，也作為CT這個新工具的介紹，所以我這裏就專門簡單介紹壹下。下面就是CT的界面：①的區域是導航欄的主部分，最主要的是偏址，即偏移地址，另外還有顏色格式，顏色格式關系到能否正確查看ROM的圖形部分的內容，漢化NDS遊戲常用的是1bpp單色，GBA 4bpp，GBA 8bpp這幾種（1bpp單色主要針對的是字庫的內容）②的區域就是顯示色版，關系到能否正確顯示圖形裏面所對應顏色。可以在調色版菜單裏面進行調整或回復默認。直接點擊裏面的顏色，可以進行直接修改。如果是非256色的色板，上部的橫拉桿還可以讀取總色版（256色）的不同部分來進行匹配。③的區域是TILE工具，可以進行簡單的TILE修改，同時CT在這裏還集成了通過碼表生成字庫的強大功能。(如果平時用不上TILE功能，可以隱去這個窗口騰出工作空間)中部的就是打開的ROM的內容了。現在ROM是以TILE模式打開的，也就是可以直接觀察裏面的TILE內容（字模，圖形……）菜單欄下面是快捷工具欄分別是①導出按鈕，這個按鈕可以讓CT導出選定的內容到壹定格式的文件，常用的是將選定的圖形區域內容導出為BMP文件，但CT的導出功能可不僅限於導出圖片哦。具體的內容在圖片H教程會進壹步講解。本篇只需有個大體概念就行了。②導入按鈕，對修改好的圖片，例如BMP圖片，導入回ROM裏面的指定區域。③16進制編輯器快速切換按鈕，可以快速切換到16進制模式④LZ77解壓按鈕，對選定的LZ77內容解壓⑤LZ77壓縮按鈕，將選定的內容進行LZ77壓縮⑥將色版轉換為16/32數據導入⑦將16進制方式存放的色版導出為PAL色版文件⑧對編碼染色⑨應用碼表開關其中④⑥⑦⑧⑨只能在16進制視圖模式才可以使用。打開視圖菜單，可以把工作ROM的視圖轉換到其他模式。下面我們切換到16進制模式，看看CT的16進制編輯功能。CT跟壹般的16進制編輯器很像（雖然不及UE強大），但卻結合漢化進行了優化。例如進行了編碼染色。非常方便查看，有經驗的美工，甚至可以直接通過被染色的編碼馬上就能找到色版數據的開頭，進行色版導出（後面的美工教程會有進壹步介紹）。另外在文本區域中間，也能很容易找到特殊控制符的內容（例如下面的例子中的F1FF等控制符就被染色為淺藍色，與壹般文字區別開來了）。另外壹個很有用的功能就是直接套入碼表來顯示文本區的大體內容：壹般NDS遊戲對應的碼表有兩種分別是8140＝空格的標準Shift-JIS碼表和0000＝空格的連續碼表（碼表的相關內容在後面的教程會進行介紹）。可以大膽地套壹下來看看能不能找到文本區。例如超執刀就是用0000=空格那種碼表，套入後，應用碼表，就可以在CT的16進制模式大概看到文本區的內容。這對於解讀ROM是非常必要的。另外CT還有壹個很有用的功能就是NDS文件系統。通過這個系統能直觀地看到NDS的文件結構，有的ROM甚至會把不同類型和用途的文件以更細致的方式存放，對於了解ROM的結構非常有用。此外在文件系統欄裏面還可以分別對不同部分的文件進行導出和導入，分別分析和修改。CT還有不少強大的功能，待各位在運用中慢慢挖掘吧。總之我覺得開放這個工具的人，只要不是進行過非常規壓縮和加密的ROM，大概能破解99％的GBA/NDS遊戲了……二 面用壹個簡單的例子來說壹下CT的TILE操作。壹般在CT裏面發現大概圖片後，通過調整窗口大小（快捷鍵SHIFT+方向，但最新版本修改了這個功能的快捷鍵，用新版本的用戶請閱讀新版本的說明），另外，縮放的數值建議用200左右進行作業（舊版本用1位數值顯示縮放比例）。這樣就可以調整至比較工整的情況。（下圖已經進行了調整）但這時看到的顏色是不正確的，因為默認的色版不適配所有圖形（正確來說壹般都不會適配，但相對的，也比較醒目）。如果想比較好地觀察，我建議自己準備壹個黑至白的色版（具體色版建立方法留在美工教程說吧），這樣圖形就能排除顏色的幹擾更容易發現，對於未能確定色版的時候是非常方便的。當然，要準備的分別是8bpp（256色）和4bpp（16色）兩種，以適應不同格式的圖片。好，回到上面，只要套入了正確的色版，那麽圖片就可以正常顯示了。（當然對於ROM解讀階段，沒有必要給每個圖片套上正確的色版）但發現貌似有點瑕疵，那是因為地址偏移還未準確。用快捷鍵：CTRL+方向鍵左右可以微調地址偏移，這個操作非常重要。調整後，隱藏掉礙眼網格就能看到這個效果了。用上述的方法就可以大概了解ROM的壹下大概構造了。結合NDS文件系統大概了解壹下各個文件分別包含的是什麽內容，關鍵是這個內容在ROM的那個地址。另外也得進壹步分析各個內容的具體位置，準備幾張大白紙，仔細記錄好ROM的各個區域分別是什麽內容，例如按地址位置順序列出：XXXXXXXX-XXXXXXXX是大標題圖，8bppXXXXXXXX-XXXXXXXX是小標題圖，4bppXXXXXXXX-XXXXXXXX是人物全身像，8bppXXXXXXXX-XXXXXXXX是字庫，1bppXXXXXXXX-XXXXXXXX是文本區XXXXXXXX-XXXXXXXX是音效…………這個記錄非常重要，壹方面可以方便妳隨時查找需要註意的部分，另壹個很重要的作用是：對於未確定地址的內容，可以通過歸類和排除法，快速找到其可能的位置。對於本文的內容，可以參看第壹話介紹過的教程的相關部分，並進而學習壹些文本，碼表的相關知識。終於進入了有點技術含量的部分了………
GBA/NDS遊戲壹般是怎麽顯示文字的呢 上裏面提到了用CT套入正確的碼表，在16進制模式，文本區就可以看見文本內容了。原理就是，ROM的文本區是用16進制代碼來寫的，例如上圖中：“2年前の檢查”對應的16進制就是000706f0行的CD00 CE0B 9B09 4701 3E06 1307這5組16進制編碼。而碼表就是表示CD00＝2CE0B＝年9B09＝前4701＝の3E06＝檢1307＝查這樣的轉換關系的列表。遊戲裏面也是通過這樣的轉換關系，從字庫挑取字符顯示到屏幕上面的。如果把上面文本區編碼改成CD00 CE0B CE0B 4701 3E06 1307遊戲也相應會顯示成：2年年の檢查，這個也是漢化對文本修改的基礎原理。（原文的“檢”字不是簡體的“檢”字，為了說明方便我做了簡化處理。）壹般日文版遊戲用的是Shift-JIS碼表，壹個完整的Shift-JIS碼表從空格開始，標點，特殊符號，英文字母，平假名，片假名，日語漢字……例如8140= 8141=、8142=。8143=，8144=．8145=·8146=：8147=；8148=？8149=！814a=゛814b=゜814c=′814d=‘814e=¨……像上面這樣的壹個對應關系存放的TBL文件（可以用WINDOWS的記事本打開和編輯）而之前也說過，壹般完整的Shift-JIS有2種主要的表示方式，如下圖，分別是從8140＝空格和0000＝空格開始的兩種（0000＝空格嚴格來說不是Shift-JIS，而是在Shift-JIS的基礎上重新進行自定義的編碼）。壹般完整的Shift-JIS碼表漢字部分是以“亜”開頭，以“熙”字作為結束（最完整的是以“黑”字結束，也就是“熙”後面還有壹段，但壹般情況下因為不是常用字，不少遊戲就去掉“熙”字後面的部分了）。下面是這兩種碼表的分析：這樣對比不難發現壹個問題，8140＝空格開始的那種碼表，並不是連續的，而是跳過了XX00-XX3F、XX7F、XXFD、XXFE、XXFF（觀察第壹個碼表中間框住有空行的部分）。而第二個碼表是完全連續的。為什麽呢？相信只要多觀察幾個文本區編碼就會發現問題了。對於第壹個碼表的文本，跳過這些區域可以有效防止錯位搞混的現象，另外也可以留出編碼供半角字符，控制符等使用。而第二種碼表的控制符則多數以FF00之後的編碼作為控制符。上面說的是導出文本用的碼表。只要能套上壹個正確的碼表就能把文本部分導出來了。但因為翻譯後，不壹定會（應該是“壹定不會”）用上或只用上原來的字，因為漢化翻譯後會用上很多原來字庫沒有的漢字（例如很多擬聲詞的字日語是沒有的，例如嗎，啦，嗯……），而且日語漢字多數是繁體字，要做簡體版基本要把字庫裏面的字改成簡體。那麽翻譯後要用新的字怎麽辦呢？最簡單就是在原字庫裏面添加新字，但是如果只是添加就太浪費空間了，因為翻譯後很多原來的字根本用不上，例如完整的Shift-JIS字庫裏面有6000多個漢字字模，而壹般正常翻譯之後，實際使用的漢字字模約2000－3000而已，漢化後因為內容跟原來不同，可以在原字庫的基礎上全部替換成需要用上的字模就行了。但是問題又來了，這些新的字模寫進去後，怎麽把它跟文本區的編碼掛鉤呢？這就需要用新的碼表方式，把字庫字模和文本區的編碼重新對用上，這就需要重新編輯壹個新碼表。簡單舉個例子。例如上面的“2年前の檢查”，漢化後變成“2年前的檢查”，“的”字的字模我必須找壹個位置放它，例如原來碼表是4E03=亜，翻譯後用不上這個繁體的“亜”字了，我就在字庫原來“亜”的位置把它改成“的”字，然後把碼表的對應關系改成4E03=的，跟著導入文本的時候，把原來的編碼行“2年前の檢查”的CD00 CE0B 9B09 4701 3E06 1307改成“2年前的檢查”：CD00 CE0B 9B09 4E03 3E06 1307。那麽遊戲就會從原來4E03=“亜”的地方提取出現在修改後的“的”字。而這個新的碼表和字庫對應關系就是導入文本用的碼表，也就是修改後的碼表。這就需要重新編輯壹個碼表了。以上就是對碼表的簡單介紹，有個大概概念後下面轉入字庫部分，先簡單了解壹下字庫和碼表的關系。上壹話講了最基礎的ROM解讀，那麽字庫壹般在ROM裏面是什麽樣子的呢？下面就是壹個例子：這個是超執刀的小字模字庫庫，看右邊信息就可以看到字模是8X8以下的，用的是1bpp（2色），在遊戲中的作用主要是用以標註某些專用名詞的上標。而正文的字庫是16X16的1bpp（2色）。小技巧：壹般判斷字庫字模用的模式1bpp（2色），2bpp（4色），4bpp（16色），8bpp（256色），可以在遊戲裏面觀察字體，如果是帶陰影或邊緣模糊（抗鋸齒）的，壹般就是4色以上的了。另外，如果字庫附近有色版信息，從色版的結構（例如是2色，4色還是16色的色版）也能大概判斷出字模的顯示模式。
圖片方面的話，以應援團為例說明下：這個少數遊戲的會比較艱難
應援團裏的圖片文件壹般被分成了3部分:
TILE文件:也就是主要的圖形文件
MAP文件:控制TILE擺放的,類似圖片中的文本
PALETTE文件:調色板文件
以上3個文件都是壓縮後的.對應的文件擴展名分別是:
NCGR_ NSCR_ NCLR_
圖片導出:
首先,如果有調色板壓縮文件.NCLR_,就先把這東西處理成可用的PAL文件.
方法是,用CrystalTile打開此壓縮文件,在十六進制編輯器(視圖)狀態下,選擇LZ77數據搜索(工具),點全文搜索,可能找到很多個,然後點解壓-->全部解壓,應該只能解出壹個文件,再用CT打開解壓後的文件,點壹下0x28的地方,選則GBA 8BPP,在調色板選項裏選轉換成調色板,然後再點導出軟件調色板(調色板),就可以轉換成PAL格式了,不過此種方法和下壹種方法轉換的PAL文件的第0x10和0x11兩位不同,不過這兩個字節和顏色數據無關,所以兩種方法都可行.
另壹種煩瑣的方法是,用CrystalTile(CT)打開此壓縮文件,在十六進制編輯器(視圖)狀態下,選擇LZ77數據搜索(工具),點全文搜索,可能找到很多個,然後點解壓-->全部解壓,應該只能解出壹個文件,將解壓的文件改成 p.dmp(擴展名是這個方便,文件名隨意),之後用VBA隨便打開壹個gba文件(其實隨便,我就自己生成了1個空文件,把擴展名改成了gba),打開內存查看器,點讀取,把剛才那個p.dmp選上,然後地址填4FFFFD8(解壓後的文件是從0x28處開始是顏色信息),關閉內存查看器,打開色盤查看器,點保存BG,這樣就把 NCLR_ 文件變成了我們常用的 PAL 文件.
接下來,把 NCGR_ 文件解壓,比如起名 1.bin ,然後把 NSCR_ 文件解壓,比如起名 2.bin,然後自己寫個批處理文件(用記事本寫壹個內容為 copy *.bin /b out.bin,然後把 txt 改成 bat 就可以了).運行,這兩個解壓後的文件就合並到壹起了.用UE或其他十六進制編輯器打開這個合並後的 out.bin ,找到RGCN,其中記錄R的地址+0x30為TILE地址,找到RCSN,其中R記錄R的地址+0x24為MAP地址.
最後打開CrystalMap,在TILE地址和MAP地址相應填好,BG寬度壹般是256,高度壹般是192(實際是256,從MAP數據文件的大小可以算出來MAP數據部分為2048字節,也就代表1024個TILE,橫是32,縱也是32,所以高和寬都應該是256,但是DS的屏幕只有256x192,其余的顯示不出來,這是在寫導入部分時候發現的,汗),這兩個數據不同的圖可能不同.顏色裏加載剛才轉成的PAL文件,顏色是16色模式還是256色模式要根據具體圖片而定,最後選上MAP拼圖(編輯),OK,最後壹步,導出(編輯)圖片.
某些圖片沒有NSCR_文件,那樣壹般是16色的,沒有MAP數據,就需要慢慢手動拼了(感覺是OAM拼圖,不過沒有研究過OAM數據).
DS圖片的導出方法大致都是這樣.
---------------------------------------------------------------------------------------------------------
改後導入:
壹般來說,圖片的導入就是導出的逆過程,還是像導出的時候將圖片用CM顯示出來,然後選導入(編輯),之後把文件再拆成兩個文件,按TILE數據和MAP數據文件的文件頭拆就可以,然後分別壓縮,改成原來的文件名,替換掉原文件.
不過這個導入過程和上面的導出過程的關系就像求積分和求微分壹樣,導出是簡單的,導入就要相對困難壹些.所以最好是分析文件裏的數據信息:
發現解壓後的TILE文件的文件頭的那48字節為:
52 47 43 4E FF FE 00 01 XX XX XX XX 10 00 01 00
52 41 48 43 YY YY YY YY ZZ ZZ ZZ ZZ ZZ ZZ ZZ ZZ
00 00 00 00 00 00 00 00 MM MM MM MM 18 00 00 00
其中XX部分為從地址0h開始算,下面的字節數,也就是文件大小,高位在後,YY部分為從地址10h開始算,下面的字節數,也就是文件的大小-10h,即YYYYYYYY = XXXXXXXX - 10h,ZZ部分未研究明白,汗,MM部分為從地址30h開始算,下面的字節數,也就是文件的大小-30h,即MMMMMMMM = XXXXXXXX - 30h,這樣就可以重新自己寫壹個TILE文件.
如果圖片是256x192大小的256色圖片,那麽TILE文件的大小應該為256x192+48=49200(C030),我們可以寫壹個這麽大的空文件,然後把文件頭改為
52 47 43 4E FF FE 00 01 30 C0 00 00 10 00 01 00
52 41 48 43 20 C0 00 00 ZZ ZZ ZZ ZZ ZZ ZZ ZZ ZZ
00 00 00 00 00 00 00 00 00 C0 00 00 18 00 00 00
ZZ部分和原TILE文件壹致,然後用CT打開這個只有文件頭的文件,把窗口改為256x192的大小,偏址設為30(此處是十六進制),然後直接導入修改後的BMP文件,保存,未壓縮的TILE文件就制作完畢了.
然後再來看MAP文件裏的文件頭數據:
52 43 53 4E FF FE 00 01 XX XX XX XX 10 00 01 00
4E 52 43 53 YY YY YY YY NN NN PP PP ZZ ZZ ZZ ZZ
MM MM MM MM
這裏的XX部分,YY部分,MM部分的意思和TILE裏的是壹樣的,NN NN 為圖象的寬,PP PP 為圖象的高,ZZ部分也是未弄清的,理論上MAP文件的大小應該為(256/8)x(192/8)x2+36=1572,但發現原ROM裏的是2084,原來ROM裏的MAP數據是256x256的,也就是說把圖片按256大小的方型處理了,在遊戲顯示的時候只顯示最上面高192的部分,這樣寫壹個2084(0824)大小的文件,文件頭直接把原來的COPY過來就可以了,然後從24h開始寫00 00 01 00 02 00 03 00...壹直寫到617h就可以了,這樣新的MAP文件就做成了.
最後說壹下壓縮問題,DS不是有個Wi-Fi嗎,那我的辦法就是Wi-LZ77(偽壓,這回是真成的偽壓縮,采用壓縮格式,但是沒有起到實質性的壓縮,反而是文件變成了原來的1.125倍再多4字節,再汗).
具體方法就是新建壹個空文件,先向該文件寫入10(LZ77壓縮的標誌),然後再向其中寫入待壓縮文件的大小(3字節,高位在後),然後向文件裏寫壹個00,從待壓縮文件裏讀取8字節,寫入此文件中.循環寫00再寫8字節的過程,直到把待壓縮文件都讀完,這時生成的文件就是偽壓縮後的文件.改完名稱,放回原位置,應該就可以用了.
原理:
先說調色板,正常256色PAL格式的調色板,顏色數據是從0x18開始,每四字節代表壹個顏色,最後壹字節為00,前3字節分別代表R(RED),G(GREEN),B(BLUE),每個字節的範圍是0x00-0xff,但是GBA和DS的調色板是用兩字節來表示顏色,算法是分別將[B/8],[G/8],[R/8]轉換成二進制,取後5位,連成壹個15位的數,然後在前補壹位0,最後轉換成十六進制,高位在後.
註:[]是取整函數,所以GBA和DS上兩個最相近的顏色的RGB值最小差8,做成漸變效果非常不理想,大多都可以看出顏色的層次.
例:正常256色PAL格式的調色板裏的顏色數據為 00 18 28 00, 其中第壹個 00 代表 R:0, 18 代表 G:24, 28 代表 B:40, bin([B/8])=bin(5)=00101, bin([G/8])=bin(3)=00011, bin([R/8])=bin(0)=00000,然後連成壹個16位數是: 0001010001100000, 轉成十六進制是 0x1460, 高位在後就是 60 14, 這就是在GBA或DS ROM裏看到的數據.
DS ROM裏的NCLR文件是從0x28開始是顏色數據.
再說說TILE數據和MAP數據,這裏的TILE是只8x8的,每個TILE就像壹個字模,而這些TILE的生成原理也是像生成碼表壹樣,壹般在圖片裏先出先的在前面,依次排下去,有和之前TILE相同,就跳過,這樣壹幅圖就用了較少的TILE記錄下來,同時生成他們的排放順序,也就是MAP數據,壹般MAP數據是雙字節(有的是單字節),壹般高位在後,有時高位代表特效(比如水平翻轉,垂直翻轉等,有興趣的朋友可以自己研究壹下,不過貌似GBA系統參考裏有),特效CM都能正常顯示出來,不過改完了,導入時CM只會處理雙字節的低位,有些特效代碼就要自己手動清00了.
其實我壹直把TILE數據和MAP數據按字和文本的關系來理解,這樣很易懂,就像我記定理時總愛往幾何上靠,這樣記得深刻壹樣
那麽，到這裏，破解就完成了。
下面就到翻譯了，這個沒什麽好說的。個人漢化的話，基本是邊翻譯邊潤色。直接把文字擴容或縮減到對應的部分。
上面那些都沒問題了的話，導入更是小問題了。
另外，推薦LZ個入門漢化壹些容量小破解簡單的遊戲，可以試試太空侵略者
就是破解簡單，文本量也不大。
LZ先學習性的漢化壹個，再考慮難的：
偶自問有壹些基礎，但是在嘗試破解諸如魔界戰記之類的，還是遇到很多麻煩。個人實在沒有能力精力。
我學漢化時在 A9VG學的，妳也可以去多看看，有很多具體的漢化實例。
另外，ACG和星組都是技術實力很強的組。LZ這樣說的話，感覺HH遊戲很簡單壹樣。不喜歡就玩日文版本去，沒人勉強妳
修改圖片文字同樣需要破解，同樣需要導出文本圖片，和漢化壹個遊戲是壹樣的道理，OK？