This topic was archived here:

https://web.archive.org/web/20230000000000fw_/https://www.zenhax.com/viewtopic.php?t=2478

AnonBaiter, posted Thu May 19, 2016 4:27 pm (13514)

---

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

Code:

# 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, posted Fri May 20, 2016 3:08 pm (13548)

---

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, posted Fri May 20, 2016 3:56 pm (13550)

---

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, posted Fri May 20, 2016 6:05 pm (13559)

---

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, posted Fri May 20, 2016 6:16 pm (13561)

---

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, posted Sat May 21, 2016 7:15 am (13578)

---

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

AnonBaiter, posted Sat May 21, 2016 10:15 am (13589)

---

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

AnonBaiter, posted Wed Jun 01, 2016 8:11 pm (13914)

---

So I'm trying to write a script:

Code:

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, posted Thu Jun 02, 2016 9:58 am (13926)

---

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, posted Thu Jun 02, 2016 10:49 am (13928)

---

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, posted Thu Jun 02, 2016 11:01 am (13929)

---

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, posted Thu Jun 02, 2016 11:09 am (13931)

---

So basically it's supposed to work like this:

Code:

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, posted Thu Jun 02, 2016 11:19 am (13932)

---

"gdrom" is not an encryption algorithm
aes, blowfish, rc4 and so on are algorithms.

But yeah the syntax is correct.

AnonBaiter, posted Thu Jun 02, 2016 11:44 am (13934)

---

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, posted Fri Jun 03, 2016 7:08 am (13977)

---

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, posted Fri Jun 03, 2016 11:10 am (13989)

---

^ 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, posted Sat Jun 18, 2016 10:33 pm (14591)

---

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

Code:

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:

getdstring TYPE 3

AnonBaiter, posted Sun Jun 19, 2016 3:31 am (14595)

---

Double post.

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

Code:

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, posted Sun Jun 19, 2016 5:03 am (14596)

---

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

AnonBaiter, posted Sun Jun 19, 2016 5:15 am (14598)

---

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:

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...|uIi....|u@o
00003320  0F 09 00 00 7C F9 A5 F1 0F 09 00 00 7C F9 CC EC  ....|u?n....|uIi
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>..In\e....InEi
00003350  0F 09 00 00 CC F1 14 EF 0F 09 00 00 CC F1 5C E9  ....In.i....In\e
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>..Iu?a....Iu#i
00003380  0F 09 00 00 CE FA 4D EC 0F 09 00 00 CE FA A3 E5  ....IuMi....Iu?a
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>..Iu?a....Iu#i
000033B0  0F 09 00 00 CE FA 4D EC 0F 09 00 00 CE FA A3 E5  ....IuMi....Iu?a
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>..In\e....InEi
000033E0  0F 09 00 00 CC F1 14 EF 0F 09 00 00 CC F1 5C E9  ....In.i....In\e
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>..~o.a....~oSe
00003410  0F 09 00 00 7E F5 69 EA 0F 09 00 00 7E F5 18 E3  ....~oie....~o.a
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.

Acewell, posted Sun Jun 19, 2016 5:59 am (14600)

---

i was just about to say "goto 0x40" should probably be outside your loop because you don't want to cycle that over and over

edit: also this file doesn't appear to be compressed so i don't think you need to call a compression type

aluigi, posted Sun Jun 19, 2016 10:17 am (14608)

---

Wow lot of posts
I answer in order from the one of Getaway

1)
It's unknown if those sequence of strings are forced to 4 bytes (getdstring TYPE 4) or are just NULL terminated strings (get TYPE string), I may think to the former because fixed size strings are used in other places of the archive

2)
There are situations where you don't have the OFFSET fields or where you don't have the SIZE field.
Your situation is the lack of the SIZE field so you have to collect all the OFFSETs and dumping the files retrieving the SIZE using "NEXT_OFFSET - OFFSET". Currently the solution I like to use for these archvies is: store the info in an array, store the size of the archive in the last array, sortarray (no need to use it, skip it), SIZE = NEXT_OFFSET - OFFSET. Something like this:
http://aluigi.org/bms/winning_eleven_10.bms
0x3300 is the offset of the first file fanta1.ico!
Remember to perform the log operation if SIZE != 0 because the archive stores also the folders (senseless).

AnonBaiter, posted Sun Jun 19, 2016 12:47 pm (14615)

---

Okay, so I did it like this:

Code:

get DUMMY long
get PKG_SIZE long
math BASE_OFF = 0x40
goto BASE_OFF
get FILES long
for i = 0 < FILES
#   getdstring NAME 0x3C # I don't know where are the correct information of the files so I'll just leave it like that
   get OFFSET long
   math OFFSET   BASE_OFF
   putarray 0 i OFFSET
next i
math PKG_SIZE   BASE_OFF
putarray 0 i PKG_SIZE
for i = 0 < FILES
   getarray OFFSET 0 i
   math i   1
   getarray SIZE   0 i
   math SIZE - OFFSET
   if SIZE != 0
      log "" OFFSET SIZE
   endif
next i

But when I tested the script to extract the file, it gave me this error:

Code:

. 00000000 getarr  OFFSET     0xc4840040 0:254
. 00000000 getarr  SIZE       0xc4b60040 0:255
  c4840040 3276800    00000000.dat

Error: incomplete input file 0: E:\Fantavision\FANTAVISION_JAPAN\DATA\COMMON.PKG
       Can't read 64 bytes from offset c4840040.
       Anyway don't worry, it's possible that the BMS script has been written
       to exit in this way if it's reached the end of the archive so check it
       or contact its author or verify that all the files have been extracted.
       Please check the following coverage information to know if it's ok.

  coverage file 0     2%   52236      1939296

Last script line before the error or that produced the error:
  22  log "" OFFSET SIZE

Am I doing something wrong?

aluigi, posted Sun Jun 19, 2016 2:41 pm (14618)

---

Yes, you must read the filename field.

Anyway this is the script:
http://aluigi.org/bms/fantavision.bms