My first quickBMS script

AnonBaiter · Post by **AnonBaiter** » Thu May 19, 2016 4:27 pm

Do you guys think I'm doing well with this script?

# My first quickBMS script.

Set VAR_TEST_01 10;
Set VAR_TEST_02 100;
Set VAR_TEST_03 200;
Set VAR_TEST_04 400;
Set VAR_TEST_05 800;
Set VAR_TEST_06 1600;
Set VAR_TEST_07 2400;
Set VAR_TEST_08 4800;
Set VAR_TEST_09 8000;
Set VAR_TEST_10 16000;

Math VAR_TEST_01 *= VAR_TEST_03;

String VAR_TEST_01 -= VAR_TEST_06;

aluigi · Post by **aluigi** » Fri May 20, 2016 3:08 pm

You don't need the final ';'.
When setting numeric values I prefer to use: math VAR = VALUE
It's better if you use quickbms for extracting data and files rather than performing string operations and similar for which there are other languages.

AnonBaiter · Post by **AnonBaiter** » Fri May 20, 2016 3:56 pm

Well, that's what I supposed to do, I guess...
But anyway, is it necessary to have reverse engineering skills in order to figuring out the format?

aluigi · Post by **aluigi** » Fri May 20, 2016 6:05 pm

File format reverse engineering, yes. So being able to figure the most important fields just by using a hex editor.
Software reverse engineering instead is necessary only in some rare cases and for encryptions and obfuscations.
The quickbms script is just the final part of the job

AnonBaiter · Post by **AnonBaiter** » Fri May 20, 2016 6:16 pm

I see... so maybe when the time comes I'll do more than just sit around and spam around samples of games I have so that anyone can figure it out for me.
Thanks for the explanation, though.

aluigi · Post by **aluigi** » Sat May 21, 2016 7:15 am

I'm happy both if you spam the forum with new requests and if you release your own scripts

AnonBaiter · Post by **AnonBaiter** » Sat May 21, 2016 10:15 am

Ah, come on. Figuring out these formats aren't that easy to begin with, so...

AnonBaiter · Post by **AnonBaiter** » Wed Jun 01, 2016 8:11 pm

So I'm trying to write a script:

Code: Select all

set SEGA_PIC_KEY binary "" # set PIC key here
putarray 10 -1 "\x6B\x7A\xDA\x61\x34\xC8\xF1\x40" # ikaruga
putarray 10 -1 ""
math SEGA_PIC_KEY_IS_SET = 0

This script's purpose is to decrypt PIC keys out of GD-ROM* media used by SEGA arcade systems. However, I'm still puzzled about it and I need some assistance as to whether or not I should do to apply this script to any encrypted GD-ROM out there.

*They're usually located at the third track according to a .cue file.

aluigi · Post by **aluigi** » Thu Jun 02, 2016 9:58 am

putarray doesn't support C notation unfortunately so you can't use it in that way (but there are alternatives to do it like performing an hex->byte conversion later)
Do you have more information about this format, algorithm and so on?

AnonBaiter · Post by **AnonBaiter** » Thu Jun 02, 2016 10:49 am

aluigi wrote:putarray doesn't support C notation unfortunately so you can't use it in that way (but there are alternatives to do it like performing an hex->byte conversion later)

Really? I didn't know putarray didn't support those. Might as well use another function...

aluigi wrote:Do you have more information about this format, algorithm and so on?

No but I`m starting to research it just now. Besides, I`ve found a few links that might be of interest:
http://segaretro.org/GD-ROM
https://en.wikipedia.org/wiki/GD-ROM
http://hwdocs.webs.com/dreamcast

aluigi · Post by **aluigi** » Thu Jun 02, 2016 11:01 am

Yeah the commands that support C notation are identified by "cstring" in the quickbms.txt manual.
The reason is that C notation wasn't supported in the original language of 1997 and causes problems to people not used to programming languages, so its usage was limited only to commands that require the ability of specifying binary data: idstring, findloc, a type of Set and String, comtype, encryption and Print (useful for the \n line-feed).

AnonBaiter · Post by **AnonBaiter** » Thu Jun 02, 2016 11:09 am

So basically it's supposed to work like this:

Code: Select all

encryption gdrom "\x6B\x7A\xDA\x61\x34\xC8\xF1\x40" # ikaruga/gdl-0010
or
findloc SEGA_PIC_KEY binary "\x6B\x7A\xDA\x61\x34\xC8\xF1\x40" # ikaruga/gdl-0010

aluigi · Post by **aluigi** » Thu Jun 02, 2016 11:19 am

"gdrom" is not an encryption algorithm

aes, blowfish, rc4 and so on are algorithms.

But yeah the syntax is correct.

AnonBaiter · Post by **AnonBaiter** » Thu Jun 02, 2016 11:44 am

I just found out that GD-ROM uses an ISO9960 format, and uses two density areas:
The Single Density Area uses at maximum of 36,000KB(4 minutes or 18,000 sectors) of data size and can be played at any CD player.
The High Density Area uses at maximum of 1,008,600KB(112 minutes and 4 seconds or 504,300 sectors) of data size and can only be played at the Sega Dreamcast system.

In a nutshell, it is basically an enhanced CD-ROM with a twist. You can check all the documentation I gathered if you see what I mean.

aluigi · Post by **aluigi** » Fri Jun 03, 2016 7:08 am

No mention to encryption in that documentation.
In my opinion trying to read an ISO with quickbms is close to be crazy because it's too complex for the language.

AnonBaiter · Post by **AnonBaiter** » Fri Jun 03, 2016 11:10 am

^ It's because the documentation I posted focuses only on the GD-ROM technology as designed by Dreamcast.
Oh yeah and the .pic file is where I found the encryption keys. If you wish, I can upload the file itself here.

aluigi wrote:In my opinion trying to read an ISO with quickbms is close to be crazy because it's too complex for the language.

Yeah I know, but as I learned that there were PIC keys stored in a corresponding MAME ROM I thought to myself "why not"?

AnonBaiter · Post by **AnonBaiter** » Sat Jun 18, 2016 10:33 pm

Okay, so my script needs to detect these file types:

Code: Select all

00000110              74 78 32 00 74 78 74 00 78 6D 6C 00      tx2.txt.xml.
00000120  6C 75 61 00 6D 69 68 00 69 64 78 00 62 6D 70 00  lua.mih.idx.bmp.
00000130  66 6E 74 00 62 6E 6B 00 70 74 68 00 69 63 6F 00  fnt.bnk.pth.ico.
00000140  68 74 6D 00 74 67 61 00 62 61 6B 00 63 6E 66 00  htm.tga.bak.cnf.

Should I do it like this:

Code: Select all

getdstring TYPE 3

AnonBaiter · Post by **AnonBaiter** » Sun Jun 19, 2016 3:31 am

Double post.

I'm trying to write a script based off Fantavision's .PKG format.

Code: Select all

comtype zlib_noerror
get FILES long
goto 0x40
for i = 0 < FILES
   get OFFSET byte
   get SIZE short
   get DUMMY byte
   getdstring NAME 0x3C
   log "" OFFSET SIZE
next i

The problem though is knowing where the offsets of these files are. Any ideas?

Acewell · Post by **Acewell** » Sun Jun 19, 2016 5:03 am

your "get TYPE long" is where the data offsets are
and your "getdstring NAME 0x3C" is pointing at folder structures with or without a file

i don't know where you getting these from though
get DUMMY long
get OFFSET long
get SIZE long

i don't know a whole lot about bms scripting i was just bored

i really need to start learning more about archive extractions too :geek:

AnonBaiter · Post by **AnonBaiter** » Sun Jun 19, 2016 5:15 am

Acewell wrote:i don't know where you getting these from though
get DUMMY long
get OFFSET long
get SIZE long

All the offsets were supposed to be in the file, right?

Code: Select all

00003300  00 00 01 00 04 00 00 00 01 00 00 00 00 00 80 3F  ..............€?
00003310  74 04 00 00 7C F9 CC EC 0F 09 00 00 7C F9 40 F2  t...|ùÌì....|ù@ò
00003320  0F 09 00 00 7C F9 A5 F1 0F 09 00 00 7C F9 CC EC  ....|ù¥ñ....|ùÌì
00003330  0F 09 00 00 00 00 00 00 00 F0 00 00 00 00 00 00  .........ð......
00003340  6E 3E 00 7F CC F1 5C E9 0F 09 00 00 CC F1 CB EF  n>..Ìñ\é....ÌñËï
00003350  0F 09 00 00 CC F1 14 EF 0F 09 00 00 CC F1 5C E9  ....Ìñ.ï....Ìñ\é
00003360  0F 09 00 00 00 00 00 00 00 F0 00 00 00 00 00 00  .........ð......
00003370  6F 3E 00 7F CE FA A3 E5 0F 09 00 00 CE FA 23 ED  o>..Îú£å....Îú#í
00003380  0F 09 00 00 CE FA 4D EC 0F 09 00 00 CE FA A3 E5  ....ÎúMì....Îú£å
00003390  0F 09 00 00 00 00 00 00 00 F0 00 00 00 00 00 00  .........ð......
000033A0  6F 3E 00 7F CE FA A3 E5 0F 09 00 00 CE FA 23 ED  o>..Îú£å....Îú#í
000033B0  0F 09 00 00 CE FA 4D EC 0F 09 00 00 CE FA A3 E5  ....ÎúMì....Îú£å
000033C0  0F 09 00 00 00 00 00 00 00 F0 00 00 00 00 00 00  .........ð......
000033D0  6F 3E 00 7F CC F1 5C E9 0F 09 00 00 CC F1 CB EF  o>..Ìñ\é....ÌñËï
000033E0  0F 09 00 00 CC F1 14 EF 0F 09 00 00 CC F1 5C E9  ....Ìñ.ï....Ìñ\é
000033F0  0F 09 00 00 00 00 00 00 00 F0 00 00 00 00 00 00  .........ð......
00003400  6F 3E 00 7F 7E F5 18 E3 0F 09 00 00 7E F5 53 EB  o>..~õ.ã....~õSë
00003410  0F 09 00 00 7E F5 69 EA 0F 09 00 00 7E F5 18 E3  ....~õiê....~õ.ã
00003420  0F 09 00 00 00 00 00 00 00 F0 00 00 00 00 00 00  .........ð......

What you're seeing here is the first bytes of a files stored in an .PKG archive. If I don't know where the offsets of these file are then in any case I'm screwed if I don't know at least a bit of reverse engineering file formats. I've already took the risk of doing so anyway, and the results weren't pretty.

I tried to make the script extract the files, but instead of seeking through an offset of a file stored in an archive file, it got beyond even the filesize(more than 1GB to be exact). Now all I'm doing is making several revisions to make sure the script works correctly with the file. And don't even get me started with detecting the filenames, which I'm currently struggling with right now.

EDIT: Now it finally got the filenames right. All I did was to move "goto 0x40" out of the "for i = 0 < FILES" section. Still, figuring out the archive will be a challenge.

ZenHAX

My first quickBMS script

My first quickBMS script

Re: My first quickBMS script

Re: My first quickBMS script

Re: My first quickBMS script

Re: My first quickBMS script

Re: My first quickBMS script

Re: My first quickBMS script

Re: My first quickBMS script

Re: My first quickBMS script

Re: My first quickBMS script

Re: My first quickBMS script

Re: My first quickBMS script

Re: My first quickBMS script

Re: My first quickBMS script

Re: My first quickBMS script

Re: My first quickBMS script

Re: My first quickBMS script

Re: My first quickBMS script

Re: My first quickBMS script

Re: My first quickBMS script