Help With Making a Patch?

What game is it?

It's not really making a patch that's the hard part. It's the hacking process.

I'm not sure how to hack PC games, but I do hack DS games and the difficulty changes from game to game.

So if you're just learning how to hack, you may want to choose an easy game to start with.

 

Visual Novels are usually pretty hard. Or at least on the DS

EDIT: You will probably need a programmer, as well. Not sure how PC games work, so don't take my word for it.

 

The basic principles of translating a PC game and translating a console game are the same (find the text, find how it is encoded, find out how any markup and/or pointers for it works and go nuts) but PC games can and do frequently use lots of compression (Japanese programmers favour some odd methods there but Japanese computing in general seems to favour odd methods), encryption (usually something very basic like a weak XOR and unlikely to stand up to any real attack but still encryption) and can still store all their text as images in the game rather than just use a font instead (nice as you can never be sure what a system will have). On top of this the visual novel format lends itself to being part of a complete scripting engine quite well (or at the very least something in the linked list family) and with them tending not to make it outside Japan the programmers of them quite often do not make translation (either ones where people might have source code or unofficial like this hence they the can be difficult comment).

If you say "the files" do I understand that as all the files because if so that is probably an archive format and will probably contain all sorts of things. If you mean just the text it could still be an archive but there are different approaches (as in you head straight to text hacking methods rather than archive reverse engineering).

Bonus is though debugging a PC game there are many high end hacking tools that allow you to fiddle with it the likes of which we are only just getting for the likes of the NES and SNES now with a bonus that people can usually assume a PC has unlimited power and have no need to go right down to hardware level formats as they do with the consoles (I have seen a few of these written in python and pretty much able to be decompiled on the spot).
Alas the number of sentences with "could be" or an equivalent is indicative of the wide range of options available to a programmer on the PC and especially of a less demanding style of game like this: for a 3d whizz bang game you are pretty much compelled to use one of a couple of programming methods and languages (and maybe just buy in the unreal or source engines) for much of the game but here you could have some veteran programmer knock it out in C (especially if they have an older game/game engine they can adapt) or someone that appreciates the niceties of modern languages and uses something like python or c# or indeed someone that prefers old school languages and you have something written in older VB all with the added possibility that someone made a scripting language novels in any one of those (this goes very far back- SCUMM quite literally stands for Script Creation Utility for Maniac Mansion and that was 1987 and far from the first game to attempt such a thing). Console games up until the late PS2 era were pretty much all down the bare metal and could be approached from that perspective which you could still do for PC but really long winded and good luck finding someone with those skills that can and is willing to do such a thing (it is the metaphorical equivalent of buying, killing and butchering a cow when you could just buy a steak instead).
This brings me to the second possibility though- if you have the translation and can get the assets it might be easier to port those to a new engine similar to how someone might port/remake a fighting game in MUGEN or remake an old FPS as a mod of another one and in many cases the visual novels I have seen are almost identical in mechanics (although there many that have little minigames that might be harder to replicate and I have not played the game not to mention my youtube searches fell short of things other than trailers so I could not glean anything from there).

 

Minigames would only really apply if you were porting across but if you are sticking with the original ignore that and I certainly understand wanting to stick with the original game.

Now comes the time I spit drink over my keyboard- multiple files over 50 megs with a total size of those getting on for 2 gigs in a fairly simple looking visual novel. That it is distributed somewhat also causes a raised eyebrow (large is one thing but that they are different sizes sets bells off). Extensions do not mean that much and developers have been known to choose random ones for reasons including attempting to stifle hacking attempts and right now the names mean very little to me (the might however mean more to someone versed in the game and/or versed in Japanese more than I- I quite often see the Romanised Japanese names for terms when pulling things apart but I do not know Japanese well enough to think in abbreviations and acronyms).
First instincts here are
Massive padding of the files (seen it a few times and if you have to fill a DVD who cares)
The game is 500 hours long with a cast of hundreds (probably not)
The game uses a series of uncompressed high res TIFF images or something similar (far from unheard of but not common by any means)
The game uses a lot of uncompressed/barely compressed/lossless video (assuming that MPG is there as an intro or something unlikely but still not unheard of).
The game uses a lot of uncompressed/lossless audio (far more likely and for reasons unknown uncompressed is in fashion even if lossy is available and takes a good chunk of size and most people do not know enough to know when they are hearing lossy, this being said audio patents are a pain and I do not know what goes with Japanese IP law right now)
The game (ab)uses a full 3d format for 2d. Given the large number of DS games that do this on ostensibly 2d platformers (the PC is no different) I can see it but I would not head there without additional info.
I can not see animation by itself getting that large (combined with the massive images maybe).

Diff files and updates are nice if they come with an appropriate changelog (I also hope that scp file is not to do with scp the file transfer protocol as that might not be ideal) as you can run them and see what has changed- if it is typos fixed you now have text, if it is pixels corrected you now have graphics, if it is levels fixed/tweaked you now have levels......... Along with high end debugging tools this is what I envy most from PC hacking (consoles have minor updates these days and there have long been v1.1 versions but it is not the same).
After this we are back (at first at least) to corrupting files and seeing what happens and also maybe running something like ofview ( http://www.nirsoft.net/utils/opened_files_view.html ) and similar tools (also available from that site) to see what is open when depending what is happening in the game.

The trouble is I am still talking at a high concept level (assuming I want to stay relevant I have no real choice otherwise at this stage- through no fault of your own you have effectively asked to be taught everything about nearly everything and that could take a while) and other than being shocked at file size nothing new is really known. Certainly though I have not heard of the extension and neither has a quick search of the internet. http://gbatemp.net/topic/326547-basic-fileprogram-hacking-information/ has some more on the subject and as mentioned a lot of stuff carries across from consoles and once things start to get nailed down both in terms of what does what and how it operates you can be directed a bit more for right now I have no idea if this will head towards low level hacking including dealing with compression, encryption and obfuscation, pointing you are a decompiler for something and a guide to the language being decompiled or even giving you a tool/method to parse the archives and pointing you at a text editor with the most exotic thing being it is encoded in shiftJIS- I have seen all three in games (and although it looks like I drew lines they can get blurred in an instant) regardless of genre and expect I will continue to do so for some time to come.

 

Idunno' about padding, the only times I've seen that are in systems with a constant rotational speed for the optical drive (like in the DC), where data on the edge of the disc is read faster so the game is padded to push the data there, or some crap like that.
Ikaruga, IIRC

Looking at the sizes perhaps images are being used for things that it's oftentimes better to use other forms for... for example keeping text as an image removes dependencies on fonts and it's much easier to code a few lines to display an image in a set place than it is to code text parsing with word wrapping), so maybe something along those lines (not specifically text, just inefficient storage because of lazy coding) is going on?

 

Can you tell if the audio sounds mixed properly (like an MP3 or some other soundwave format, something recorded with actual instruments) or like a tracker tune (MIDI/S3M/MOD/etc.)? The main difference will be that tracker formats use samples for the instruments so in most cases each instance of a certain note of a certain instrument will sound exactly the same (opposed to the slight variations occurred with real instruments). This affects things like timings as well, the exact length of the note and whether the note is exactly on cue or not (though this can be fiddled with in a tracker format, most of the time composers don't bother with doing this for realism).

Of course it's always possible that they did a tracker format and then output it as a soundwave format for easier use...

 

If the file is compressed, it will look like a bunch of gibberish until you decompress it. Even then, the file will have some gibberish until you find the text. DS romhackers use hex editors to look at the files, perhaps it's the same for PC. It's not really as easy as popping it in a text editor most of the time, so you may want to learn a bit more about hacking or show the file to a romhacker/hacker so they can check for compression

 

One approach has been overlooked in this thread so far: instead of hex editing/messing with the game files in any way the English text could simply be drawn on screen. This could be achieved in a variety of ways, here are some:

Create a launcher.exe which injects a DLL into the game hooking a function to which the Japanese text to be drawn on screen is passed. The hooked function retrieves your English translation for a given Japanese string, for example by means of a hashmap, and returns it so the game so that now the English translation is what the game will draw.

Another option if the above ends up being unsuitable for one reason or another would be to simply draw the English text through an own function (using GDI or something more fancy) at suitable points rather than using the game's internal text drawing function. Which English text to draw could be decided either by reading memory for the Japanese string or using some kind of character recognition for images on the screen.

Granted, the above approaches do require some skill in reverse engineering and programming, but depending on how the game is coded it could be trivial enough that even a novice could do it.

 

Things like that, even at the notice level, are relatively difficult compared to static resource replacement. I'm not nearly as good as you at that stuff, I wouldn't even attempt that if static resource replacement was possible.

 

Well, optimally some recon would be done to see which approach would be most suitable. If the static resources of a program turn out to be encrypted, of a non-standard format or otherwise messy you could potentially get away with a lot less work by not messing with the static resources at all (given that you have knowledge of what to do and/or the googling skills/forum help to obtain it).

 

The "no readable memory" error seems odd, the only time I've run into that is when trying to scan a process that's no longer open.

As for the way the text is kept in RAM it could vary, so even though you do look to be searching for it the right way the way they actually have it exist in the program's memory can vary.

Again I can't really offer specific help here.