Unless you know the format of the file contents there is not really any way to do it. You can try some guesswork and logical tests (I have done similar in the past) but it is really down to looking at the content, and figuring out what each byte or set of bytes is supposed to represent.
One of these days I'm going to think of a really clever signature.
What do you mean with getting the format? If it's a binary file and you don't know how to interpret its contents, I don't think you can get a format.
Regarding the reversion, thats quite easy, although I don't see the point in doing it. You could use the functions fread(), frwite() and the like to read it into a large enough char array, loop through it from back to front and write it byte by byte into a new file (assuming is is small enough to fit into memory).
My next plan is to try and work with a few friends to translate the rest of the tool. Basically, it revolves around changing the text in the dialog boxes. The problem I'm facing is how to manage such a team effort.
Does anyone know a way (or utility) to extract the resources from a windows executable, split it into different files and then merge it all back together?
As useful as Resource Hacker is, its essentially a one-man tool. I'm looking for something that would let me work with a version control system for this.
On the legal side of things, I've been led to understand that the original developer has granted permission for translation efforts (admittedly, hearsay from others). The way I see things, since its a free tool and because I'm only translating it, there shouldn't be any trouble.
There's a bunch of commercially availble tools for the job, you could check out Deja Vu, SDL Passolo or Idiom. If you google around for Flexytrans, you may find that one (it should be for free if you manage to find it).
The more elaborate tools have loads of functions for working in teams. For the simpler ones, use the Clipboard to export the strings to text files.
I suppose you are compiling with VS. What differs is a timestamp added by compiler (more precisely, by linker). I don't remember where, but I think is somewhere in IAT. You can patch those bytes (I think is a __int64, most likely a FILETIME) either by patching the binary or by setting system time (not sure since you don't know when exactly the linking occurs).