[Vegetaman]

Here's a sentence that uses the same characters consecutively.

''Goodbye, Takuya.''

Code: [Select]

00000170                               54 4E 28 4E 1C 07 11            TN(N...
00000180   10 14 59 43 27 13 10 07  0F 12 51 50 50            ..YC'.....QPP

As you can see, it uses ['] twice at the beginning, and twice and the end. And surprisingly, they have the same hex value $50,  I tried changing the last two bytes to $51 and it caused the game to show [&] instead of [']

As I understand it, it breaks up like this, then?

Code: [Select]

STRING:    '  '  G  o  o  d  b  y  e  ,     T  a  k  u  y  a  .  '  '
GAME HEX:  54 4E 28 4E 1C 07 11 10 14 59 43 27 13 10 07 0F 12 51 50 50

STRING:    '  '  G  o  o  d  b  y  e  ,     T  a  k  u  y  a  .  '  '
ASCII HEX: 27 27 47 6F 6F 64 62 79 65 2C 20 54 61 6B 75 79 61 2E 27 27

What is telling is that you have a 0x4E meaning a " ' " in one spot, and a 0x4E meaning an " o " in another, in the same string... As well as having 0x54, 0x4E, and 0x50 all meaning " ' " at different points, apparently... At least, IMO...

The ASCII hex assumes what the string would be if the game would have been using an ASCII character table (which depending on how the XOR encoding is done, may or may not be a truism). That part was added to see if any patterns emerge... Which, for me, is going to have to wait until tomorrow...

[Ryusui]

Try this. Replace an entire string with the same byte. Then you can clearly see any patterns that emerge.

[Klarth]

I've isolated the code in question.  It's not too large (the file i/o code is half of it and can be trimmed from the top).  I'll post some of the tips and techniques I used probably tomorrow.  I know for certain that the start/end points are true because I verified with memory dumps.  There may be a bit of fluff in between.  The routine decrypts a file in its entirety.

Here's the routine:
http://pastebin.com/4YaJdxXk

1. Routine opens the encrypted file.  The routine is built for normal files and win32 LZ lib.  I hit the breakpoint for the LZRead version instead of the win32api ReadFile version of the routine.
2. Read 0xC0 bytes (the header length).  0xA0 bytes into the header is the size for the rest of the file.  So it creates a buffer and reads the rest of the file.
3. The data in memory at this point is unreadable.  It's also verbatim according to a several large searches against the source data.  (My free hex editor apparently doesn't support file compare for free...)
4. Start at loc_403401 and figure out the scheme!  I have a funny suspicion some magic may be in sub_402E70 though, included at the bottom.

I haven't given the actual routine a good look yet but will tomorrow.  Unless somebody else figures it out.  I tried pretty hard to do it without the source and failed so I'm interested in what obfuscation it uses.

[Ryusui]

(My free hex editor apparently doesn't support file compare for free...)

WindHex.

[Nightcrawler]

(My free hex editor apparently doesn't support file compare for free...)

HxD is a great general purpose freeware hex editor that does file compare and many other things.

[Jorpho]

I've used FrHed in the past when I've needed to compare files.  It is surprising that the feature is so often lacking from other quality editors.

Oh, an H-game.  H-games almost universally use some variant of XOR encryption.

I wonder why?

I've isolated the code in question.  It's not too large (the file i/o code is half of it and can be trimmed from the top).  I'll post some of the tips and techniques I used probably tomorrow.

Oh yes, I'd love to know how you did something like that.

[KaioShin]

Oh, an H-game.  H-games almost universally use some variant of XOR encryption.

I wonder why?

The CG graphics are the selling point of h-games for a lot of people. There is a thriving scene in Japan that rips the CGs from newly released games and puts them online. So the developers encrypt their materials to make sure that not every day-1 buyer can just take them and send them to his friends. Of course there are people who also work on keeping up decryption tools with new releases, it's just like western games and copy protections. They know they'll get cracked anyway, but they try anyway each time.

By the way, there is a very good chance that a decryption tool already exists because of this. But don't count on repacking, and don't bother asking the authors of such decryption tools, they aren't interested. I tried

[Jorpho]

The CG graphics are the selling point of h-games for a lot of people. There is a thriving scene in Japan that rips the CGs from newly released games and puts them online. So the developers encrypt their materials to make sure that not every day-1 buyer can just take them and send them to his friends. Of course there are people who also work on keeping up decryption tools with new releases, it's just like western games and copy protections. They know they'll get cracked anyway, but they try anyway each time.

That sort of makes sense, but if it's the CGs that get ripped, why encrypt the text?  And wouldn't even the most stringent encryption not block someone with a proper screen-capture program from nabbing the CGs?

[KaioShin]

why encrypt the text?

Mostly it's "why not?". They just pack everything, sounds and music too. It's not like it increases the loading times or anything by a siginificant amount, other than loading and displaying texts and pictures, those engines have nothing to do after all. As for screen capturing, of course that works. But it's annoying work, requires someone to play through the game in all routes (eroge has multiple in 9 out of 10 cases) etc. It's a deterent more than it's really effective. If they keep the CG pack from being available at day 0 on 2chan, I think the devs are already happy. This is just a guess on my part, but I also believe there is generally a legal component involved, most copyright laws related to digital things make circumventing copy protections illegal, not making copies itself, so they are obligated to have some form of protection, no matter how effective it is.

[Klarth]

Well, I'm stuck on this code at the moment.  The data flow just isn't making sense to me (x86 isn't my strong suit).

So as far as how I isolated the code:
1. I searched the .exe to see if there was a reference to xc2.sce (the file in question) and there was.  Which made things much easier.
2. I loaded the .exe into IDA Pro to find that string and checked the cross reference.
3. I found the routine that used the string and a LZ* file functions along with CreateFile, so I knew I was on the right track.
4. I saw the reference to operator new and compared the allocation size against the file's length value and got a match.
5. I narrowed the routine down a bit into some loops and put a breakpoint just before it started and just after.
6. Debug the exe with IDA Pro and at each breakpoint, go into task manager, right click the exe, and dump memory with Create Dump File.  (Can do this in Vista/Win7)
7. Opened both dumps and got lucky enough to find the entire script in the post dump and the encoded version in the pre dump.

I've been trying to use the trace feature with minimal results.  The data is there, I'm just not matching my head up with it yet.  IDA has features to better inspect memory than a memory dump, but I'm not familiar with how to use them.

[golden]

I'm pretty sure I've read that someone managed to extract X-Change's resources with AnimED. If not, there are also various tools that might be useful: http://tlwiki.tsukuru.info/index.php?title=Tools.