Can anyone help out on Little Busters!'s script?

Well, a lot of folks might suggest RLdev, but in this case it doesn't work.
In the trial version of Little Busters!, there was already a file in Seen.txt that cannot be disassembled by RLdev. It was okay because other than that RLdev works fine with the trial version. But the full version is somehow different.
Is it possible that Little Busters! used the same encryption as Bonbee!'s Scramble Heart? And if so, is there any solution for me to get all the script from Seen.txt disassembled, or at least, extracted? Thanks in advance

I tried to run Little Busters! (1.4.8.8) with Scramble Heart's RealLive.exe (1.4.6.2), and failed. SH's .exe didn't recongnize LB's Seen.txt correctly, even though the list of SEENs seem to be right, the execution failed.

Seen9010(00027)
ｾｰﾌﾞﾎﾟｲﾝﾄ
*Qｹ[Q・ｶﾔ$ﾏﾓﾑ{.ｮ[EQ・・&ﾚ
ﾏ2#

Seen9010(00027)
■ＥＲＲ：代入演算

Seen9010(00027)
選択から（Seen0513 #Z00）
※フラグ情報やコール情報が不確定なので、正常に動作しません。

Seen9010(00027)
システム開放

CALLｽﾀｯｸ 初期化

GRPｽﾀｯｸ 初期化

システム初期化

↑ part of the debug message

And that LB's own .exe won't enter its debug mode (I'm not using the AlphaRom modified LB,RealLive.exe) when #MEMORY=1 is added to Gameexe.ini. That's bad because a lot of tricks can't be used anymore. I really need help on this, if there's anyone here who's also interedted in working something out of LB, please help :-)

[Sieg]

So you're just trying to extract the script? How do CGs fare? Also unable to be removed?

As far as my 2 minute research can tell, the script pack in LB just have their "signature" changed, nothing more.

When I removed the signature check (@ offset 4) from my program, I am able to extract the individual script. I think if you do the same thing in RLDev, it should be able to get something for you to start with.

If for some reason it aborts, you can always try "just decompress" (without disassembling), and then try do "blind extract" (extract by JIS character encoding range).

To Sieg:
CG's are okay, vaconv can handle it with no problem.

To Misha:
Thanks, man, that's great news. I'll check it out later and see if I can get it right to extract the scripts. But there are still 2 problems that's annoying:
1. They've had new functions built into RealLive that the current version of RLdev cannot recognize. The bad thing is I can't debug LB's executable, and that's giving me a hard time doing any reverse engineering at all.
2. If it's only the signature that changed, why would the previous versions of RealLive interpreter misinterpret the script, as you can see from the log above?

I'm working on LB to try to update RLdev so that it gets up-to-date (at least to some degree). As I would like to see any progress here would in turn do good for the RLVM project that I'm interested in. :-)

[Sieg]

I'm wondering how you can even extract all of this stuff like CGs with RLDev...and nice to know you've got it under control now, or so I'd hope.

Originally Posted by UnregisteredLB

To Misha:
Thanks, man, that's great news. I'll check it out later and see if I can get it right to extract the scripts. But there are still 2 problems that's annoying:
1. They've had new functions built into RealLive that the current version of RLdev cannot recognize. The bad thing is I can't debug LB's executable, and that's giving me a hard time doing any reverse engineering at all.
2. If it's only the signature that changed, why would the previous versions of RealLive interpreter misinterpret the script, as you can see from the log above?

Sorry, by "nothing more", I mean the script packing algorithm, not the instructions inside the script.

Thanks to your hint that eariler version of Reallive can actually execute the new script, I knew that unpacking the script must be an easy fix - since old engine can actually unpack and execute into the script, the encoding/encryption algorithm must haven't changed.

So, just remove the 0x2712 check at offset 4, the old unpacking algorithm should work.

BTW, if RLDev can provide more information whenever it encounters error, such as, the offset of the problem, the bytecode that caused the problem, or even just print out the next 100 bytes in ASCII, and adding new instructions support should also be very easy.

Becuase AVG2K script is very structural and verbose, one can actually "eyebal" a lot of information just by using a hex editor and a notepad. :P

To Sieg:
All CGs are located in the g00 folder in LB's game folder. They're in g00 format, and if you're using RLdev, use the "vaconv" part of it to convert these *.g00 files to *.png files.
The usage goes as simple as:
vaconv filenameToConvert

To Misha:
Older version of the interpreter doesn't execute LB's script correctly, but yes, they do get the TOC (table of contents) right, which is worth digging into. Now my concern turns to how to debug LB's RealLive.exe. OllyDbg keeps on complaining that it's not a valid Win32 application. Any clue on that?

Originally Posted by UnregisteredLB

To Misha:
Older version of the interpreter doesn't execute LB's script correctly, but yes, they do get the TOC (table of contents) right, which is worth digging into. Now my concern turns to how to debug LB's RealLive.exe. OllyDbg keeps on complaining that it's not a valid Win32 application. Any clue on that?

To my knowledge, there are actually three versions of Reallive.exe floating around.

Version 1 (the original) has a built in icon, and when it runs, it generates Reallive.000 in the current folder.

Version 2 is the so called no cd version (not so nocd comparing to the following), it is about 500KB smaller than the original, and is about the same size as the Reallive.000.

Version 3 is actually Version 1 patched by a 20K program that completely removes media checking.

My intuitive guess is, the originalled (version 1) reallive.exe is "packed" or "shelled" by a protection program which of course should try its best to stop you from debugging. Version 2, however is the "unpacked" or "de-shelled", barebone reallive program. (V3, of course, is still packed and protected)

So, to debug the program, your best hope is to use the "Version 2" reallive program.

--------------
BTW, I still think the easiest way is to let RLdev point out the place it has trouble handling, and then you go ahead and "eyeball" out the structure of the new instruction. Given existing argument formats, it shouldn't be very hard.

To Misha:
That's interesting. I haven't seen that second version of RealLive.exe you mentioned above. I'm using the original one (probably, 2,994,176 bytes), and I have seen the third version (2,457,600 bytes). Does the second version have anything to do with "LB,RealLive.exe", one that is patched by some AlphaRom avoiding program?

Originally Posted by UnregisteredLB

To Misha:
That's interesting. I haven't seen that second version of RealLive.exe you mentioned above. I'm using the original one (probably, 2,994,176 bytes), and I have seen the third version (2,457,600 bytes). Does the second version have anything to do with "LB,RealLive.exe", one that is patched by some AlphaRom avoiding program?

I think the 2.4MB one that does not have built-in icon, and requires you to copy some dummy files to avoid media checking is the "unpacked" reallive.

However, since I have no experience in ICE like debugging, I could be wrong - the anti-debugging code could also exist in the unpacked file.

[jyuichi]

umm... can someone explain in plain English how to extract the script? I have rldev and it doesn't work obviously but how do you "remove the 0x2712 check at offset 4" ?

I suppose it would be a bit much to ask someone to post an patched seen.txt or the extracted files? (I do have a legal copy if thats a concern, if you want me prove it I can tell you the number of pages in the user manual or box dimensions or something...)

Sorry this hacking stuff confuses me. I've read through the rldev manual as much as I could understand but I'm no programmer, ^^; gomen.

[Haeleth]

You adjust the is_bytecode function in src/common/bytecode.ml so that it allows 110002 as well as 10002 for the TPC32 version. Or just change the value in the extracted bytecode file by hand. :)

Prz's 2-minute investigation didn't go deep enough, because there is also a change to the bytecode: there's an additional layer of trivial encryption underneath the compression that wasn't there in earlier games. To be specific, a 257-byte block starting 256 bytes into the uncompressed bytecode is XORed against the key a828fd66a0237769f945f82c7c00adf4. Quite why they bothered adding such a weak feature is unclear...

Originally Posted by Haeleth

You adjust the is_bytecode function in src/common/bytecode.ml so that it allows 110002 as well as 10002 for the TPC32 version. Or just change the value in the extracted bytecode file by hand. :)

Prz's 2-minute investigation didn't go deep enough, because there is also a change to the bytecode: there's an additional layer of trivial encryption underneath the compression that wasn't there in earlier games. To be specific, a 257-byte block starting 256 bytes into the uncompressed bytecode is XORed against the key a828fd66a0237769f945f82c7c00adf4. Quite why they bothered adding such a weak feature is unclear...

That might just be because they don't want everyone to fool around their game with your rldev ;-p
Good job, boss!