Hello,
i am interested in several asian rpgs, unfortunately there are some very good ones only available in japanese. Therefore i am interested in creating translation patches, for e.g. into English, to make those games available to people, who cant understand japanese, korean etc.
I tried several games to analyse, but i couldnt find any good ways to detect where all the text is stored or how to change it.
Is there maybe somewhere a site available covering this kind of topic or has anyone ideas, how to get this on?

For example i would be interested in translating the newer YS rpgs (although there are several more games i would like to work on). Any ideads or hints, where and how to start there?

People at forums.novelnews.net should be able to help you.

Thank you very much reverser for the link, i will read through some posts there; At first glance it looks interesting and will give me some more information.
Thanks!

maybe it help...

"Executable's strings lister and replacer 0.2 (exestringz) .image.
this tool has the main purpose of finding any ASCII and unicode string inside PE and ELF executables with the possibility of modifying these strings with an external text editor and re-injecting them in the original executable.
technically the finding of the strings works in the following way: it disassembles all the executable sections of the input file (like .text, only x86 32 bit supported) and visualizes any string or any array of strings, so any instruction like push "string" or mov eax, "string" or mov eax, "[4*edx+array]" and so on is handled perfectly.
while the injecting of the modified strings back in the executable (ELF not supported) is performed through the adding of a new "stringz" section which contains all the new strings and the substituiting of all the pointers to those strings collected in the "finding" operation with the new ones.
the tool can be also used as a quick and advanted strings program (the one available on *nix) with the difference that the strings found by exestringz are not casuals but are found and confirmed by the disassembled code avoiding false positives.
there is also an option specific for the asian unicode which was also the reason of the initial creation of this tool for the translating of a japanese game.
note that for obvious technical reasons is not possible to export and reimport ever all the strings for any executable because in some cases (usually with big programs) could be generated false positives, anyway the output file generated by the tool is very easy to edit so it's not a problem."

http://aluigi.altervista.org/mytoolz.htm#exestringz

Most of the time the asians put the texts in a file and then they decrypt it in memory. So put breakpoints at CreateFileA or CreateFileW then put a breakpoint on ReadFile, note down lpBuffer offset. lpBuffer will hold your encrypted data, follow the code till you find the decryption routine (you can put a memory breakpoint on read at lpBuffer), dump decrypted data to file and translate...
After that you will have some options, either reverse the decryption routine (most of the time is just simple xor with a defined key) so you can encrypt your translated text or make the executable skip the decryption routine and read the decrypted data instead

Thanks mambox and blurcode. I am still trying to analyzing the game, however, havent made much progress so far. But wont give up..

If you're really into it, try loading it in IDA. If it complains about a missing import section, you know it is protected. If it loads fine, look for references in the "strings' section. Now for the fun.

Load it in your favourite debugger and stop it at the first byte of execution code. Even if it is protected, there will always be a first byte, which should show up in IDA as a confirmation. Start single-stepping the first few bytes to see if it behaves. If the code starts changing as you type, you need to look up a tute on obfuscation. You could do it yourself, but there are principles involved in knowing which bytes can be jumped over and those which can't. Sometimes protections are checking for single-stepping.

If the code is clean, you'll be in an initialization phase in which you can pretty will jump over functions. The init section sets up memory, parses command lines, etc., for the app. No windows work is done here. Using IDA, find where the jump off point is to winproc. That's the function called where the actual windows work is done. If it's not obvious in IDA, you can trace through the init section by jumping over functions till you see a call to exitprocess, or similar, is called. winproc is usually the last function call before that, or close to it.

If the app is protected, there will be a wrapper around this init code but the start of code will now be the wrapper's SOC. The difficulty in tracing through it will depend on which wrapper it is and how recent it is. In any case, you are trying to get through this wrapper to the apps OEP (original entry point) which is the start of code I mentioned before. When you reach that, start over where my mini sermon started. To get there, you will probably have to identify the protection and get some help to reach the OEP. Since your object is to modify text, you may want to bypass the protection, if you can, using a previously worked out method.

It's important to keep notes. Before you jump a function, take down it's address. That way, if something goes wrong during the call and you get lost, when you restart and go to start of code, you can simply set a BPX on that address and go straight there. Or, if you're even smarter, you'll take down addresses on the other side of the call and jump to that. Also, look for proper function names along the way that you can set a bpx on. If a protection is looking for single-stepping alone, and you bypass that section with a bpx, it wont detect that unless it's looking for a bpx as well.

If you make it to winproc, you are normally in a loop from which all the rest of the app operates. The windows are built here and calls to any protection usually reside here. This loop only exits for program termination.

Since you're dealing with a game, there may be directx involved, and that's another kettle of fish. Check in the RCE search engine for some of Silver's stuff on DX or try to find my explanation of a directx crackme of his. The call to directx will come from within winproc, and in my experience, it came after ShowWindow, after the last window was registered. Reversing directx is not rocket science but it requires a different way of thinking.

If DX is involved, you will reach a point where it takes control and shuts out your debugger. You have to learn how to put it in a window rather than letting it take fullscreen, then your debugger will work again. You may need a debugger like softice, however, since in my experience, I needed to access ring 0 so I could break on functions in ring 0. Worry about that when you get there, if you do.

Although this is painstaking, slow work, it will teach you a lot about how apps work. The better you get at it, the better you get at knowing where to jump to avoid situations, and the better you get at recognizing how the app is implementing its resources. If you have to eventually modify the text, you are most likely going to need a detailed layout of the app's structure anyway. If there are CRC checks, you are going to have to deal with them, and the process I have described may be your only alternative.

Thanks for your reply WaxfordSqueers, I already made a little progress since my last post.

If you post an outline of what you've done, or how you're attacking the problem, maybe someone could offer more advice.

Sometimes, problems like yours are not unique to the app. The people who write software for games are not usually all that creative. You can bet a lot of them have copied someone else's software or used a template. In fact, what I have seen in adventure games is a lot of frustrated graphic artists who know little or nothing about programming.

A lot of us learned doing +Orc tutorials and he was big on never over-estimating the intelligence of a protectionist. There are a lot of times with reversing when you have to remind yourself that no one is trying to trick you. Sometimes the solution is dead easy and right in front of you. If you share what you've done, somebody will likely spot it and save you a lot of grief.