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

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

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.

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?

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).

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.

^ 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"?

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.

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum