| |
AlexC
Registered: Jan 2008
Posts: 293 |
retro replay file format
Since rr files aren't in CRT format could somebody please point me to (hopefully existing) document describing its file format? |
|
... 6 posts hidden. Click here to view all posts....
|
| |
Frantic
Registered: Mar 2003
Posts: 1627 |
Dunno. What I *do* know is that I generated 64kb cart images from my code at one point and that worked fine. |
| |
AlexC
Registered: Jan 2008
Posts: 293 |
The original RR specs define 128kb ROM so I guess this would be the limit but I'd like to have confirmation from someone who knows this topic better than I do. The RR file is 64kb long so your experience is right. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11100 |
it will accept 32k, 64k and 128k binaries. however, that is not a good way to detect valid RR images :) |
| |
AlexC
Registered: Jan 2008
Posts: 293 |
So could you please share better approach with us... |
| |
Frantic
Registered: Mar 2003
Posts: 1627 |
I think he just meant that there are zillions of files (especially cartridge images) that have these file sizes.
As for the contents of the ROM image files.. I'm not sure if there is anything that *must* be positively present or that must be absent in a RR image. I guess in principle it *could* have any contents (such as being filled with data, rather than code). Therefore any attempts to identify RR images based on contents would be heuristic rather than absolute, I think. I may be wrong of course. Anyway, my guess is that the absence of easy ways of identifying RR rom images is precisely the reason for the "less sophisticated" approach to validating RR ROM images, based on file size rather than bothering about contents.
Do you need to distinguish RR ROMS from other type of cart ROMs (or other files in general), or are you just generally curious? |
| |
Count Zero
Registered: Jan 2003
Posts: 1820 |
RR Roms have their version string at offset $80 of the file usually. However, as there are plenty of hacks you will be much better off using checksums to detect "known" vs "unknown" binaries. I recently fiddled with custom detection files for clamAV to detect some demomakers and such.
Throwing in a file with all rr.c64.org carts and available commie ROMs seems no problem there. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11100 |
AlexC: there simply is no way to detect whether some binary works on the RR or not. you could check for the CBM80 signature in bank0, but thats pretty much all about it.
what are you trying to do anyway? |
| |
AlexC
Registered: Jan 2008
Posts: 293 |
I'm writing a small program for detecting file types inside my c64 collection. Since there are number of valid RR rom files around I wanted to add additional check for those but not limit the detection to already known files (like I did for crt files which I detect by checking for CRT and CHIP header data). Seems like it is not entirely possible, but anyway I do appreciate all the input. Thanks guys!
@CZ: As for ClamAV you may consider Yara for your needs as well. |
| |
Count Zero
Registered: Jan 2003
Posts: 1820 |
Yara looks interesting. Even led me to http://x64dbg.com/ which I havent seen before.
For clam and easy going its just one line to add to some detection file. Really should put up a public database for such things and get some contributors. Since there already is all that info in e.g. unpack64 and other tools it shouldnt be too hard to create some fingerprinting db for c64 files. Does splunk support file detection on file basis?
Anybody being into alike things pls msg me :) |
| |
AlexC
Registered: Jan 2008
Posts: 293 |
Count me in :) You're right, we have all the required bits all around.
As for the debugger I don't use since all the tools I have right now are in Python and are integrated with IDA but if you are used to OllyDBG than this is a choice worth considering. I'd like to write that is has better GUI than WinDBG but on the other hand basically everything else does too ;) |
| Previous - 1 | 2 - Next |
