+  RHDN Forum Archive
|-+  Romhacking
| |-+  General Romhacking
| | |-+  SHA1 hash - help
Pages: [1] 2
Author Topic: SHA1 hash - help  (Read 1128 times)
Special T
Guest
« on: October 27, 2006, 11:04:37 pm »

Does anyone know what the "SHA1 hash" is on a rom?

I wanted to start a screen shot / title shot / box art archive of games for older systems
(NES / Master System / Genesis / SNES / PC Engine / 32 X / Sega CD / N64 / etc.)

I wanted to base my archive off the good tools rom sets, so I asked the best method to catalog the pictures to avoid rename mix ups (New goodset version)

I was told to use the "SHA1 hash" but I don't know what it is or where to find it.

Also would the best picture format to use be .PNG or .TIFF?
Aerdan
Guest
« Reply #1 on: October 28, 2006, 03:33:06 am »

A SHA-1 hash is similar to an MD5 sum, except produced by a different algorithm

And I don't know anyone who supports TIFF images in browsers.
creaothceann
Guest
« Reply #2 on: October 28, 2006, 03:36:02 am »

1. http://en.wikipedia.org/wiki/SHA_hash_functions

2. most probably PNG
Aerdan
Guest
« Reply #3 on: October 28, 2006, 05:17:38 am »

I forgot to add that for SNES games, please don't use GoodSNES; use NSRT instead.
Special T
Guest
« Reply #4 on: October 28, 2006, 06:57:22 am »

I've never heard of NSRT before why would that be better than goodsnes?
creaothceann
Guest
« Reply #5 on: October 28, 2006, 07:26:49 am »

Quote
NSRT, the most advanced SNES ROM tool to date, provides the ability to check, alter, retrieve info from, verify, fix, and organize SNES ROMs.

While some of NSRT's features are similar to what SNESTool, SNES Explorer, inSNESt, SMC File Checker, and GoodSNES can do, NSRT is both more accurate and up-to-date, encompassing everything into a single convenient package. NSRT also adds on many useful features not found in the aforementioned tools.

NSRT also doesn't bother with bad dumps, pirate carts, homebrewed ROMs etc. Wink
Special T
Guest
« Reply #6 on: October 28, 2006, 09:15:16 am »

I read up on some of the information for SHA1 hash and from my understanding that is a number derived from the name of the rom.

I don't understand why I should use the SHA1 hash as the numbering system for my images. If a rom gets renamed won't that change the SHA1 hash variation and then make the corresponding image not match?

Is their any other form of identifier that I can use from a rom that does not change and that I would have access to without doing allot of work?

If I'm missunderstanding what the SHA1 hash is please let me know. Thanks.

Quote
NSRT also doesn't bother with bad dumps, pirate carts, homebrewed ROMs etc.

Why are these types of roms included within the GoodSNES if they are not really necessary? Do they actually have a purpose?

I had planned on using the goodtools rom set & the GBA renamer romset to get my image catalog started, but from what I understand NSRT would be better than GoodSNES. Is their any other romset I should use for any other system than the goodset?
KaioShin
Guest
« Reply #7 on: October 28, 2006, 09:19:50 am »

Quote from: Special T on October 28, 2006, 09:15:16 am
Quote
NSRT also doesn't bother with bad dumps, pirate carts, homebrewed ROMs etc.

Why are these types of roms included within the GoodSNES if they are not really necessary? Do they actually have a purpose?

Because GoodSNES is for ROM hoarders who need every existing piece of trash labelled "SNES" regardless of real value. Besides GoodSnes is an offence to all ROMhackers since it contains prepatched ROMs against their will.
creaothceann
Guest
« Reply #8 on: October 28, 2006, 09:26:43 am »

Quote from: Special T on October 28, 2006, 09:15:16 am
I read up on some of the information for SHA1 hash and from my understanding that is a number derived from the name of the rom.

Nope, the file content.

(Copier headers on SNES ROMs are not required for SNES emulation and should not be used for identification. Btw. the ROMs have an internal header too, but you can just ignore that one.)


Quote from: Special T on October 28, 2006, 09:15:16 am
Quote
NSRT also doesn't bother with bad dumps, pirate carts, homebrewed ROMs etc.

Why are these types of roms included within the GoodSNES if they are not really necessary? Do they actually have a purpose?

Afaik Cowering doesn't want to constantly receive the same bad ROMs because people think they've found a "new one".
Special T
Guest
« Reply #9 on: October 28, 2006, 09:38:46 am »

Quote from: creaothceann on October 28, 2006, 09:26:43 am
Quote from: Special T on October 28, 2006, 09:15:16 am
I read up on some of the information for SHA1 hash and from my understanding that is a number derived from the name of the rom.

Nope, the file content.

So that means if the name changes then the SHA1 hash value will stay the same right?

Also how can I find the SHA1 hash for each individual rom?

Quote
Because GoodSNES is for ROM hoarders who need every existing piece of trash labelled "SNES" regardless of real value. Besides GoodSnes is an offence to all ROMhackers since it contains prepatched ROMs against their will.

I'm not really conserned with getting every variation of every dump out their I just want the most up to date roms/translations etc. (that work) to get images for. So it sounds like NSRT would be the most viable solution. Do they make any tools for the Gen / NES or other systems?
creaothceann
Guest
« Reply #10 on: October 28, 2006, 12:59:07 pm »

1. Google search: generating SHA1 c++ OR java

2. Nope, as can be seen on the website.


EDIT: Personally I would just use CRC32. It's safe enough for ROM tools, and probably much easier to implement. The code can be found for example in SNES emulator sources. Wink
« Last Edit: October 28, 2006, 02:01:18 pm by creaothceann »
Special T
Guest
« Reply #11 on: October 28, 2006, 10:36:41 pm »

I appreciate all the helpful feedback! Thanks
Spikeman
Guest
« Reply #12 on: October 29, 2006, 02:45:07 am »

Why don't you just use MD5? It's built into PHP so it would be much easier to implement.. or am I misunderstanding what you want it for?
Special T
Guest
« Reply #13 on: October 29, 2006, 07:56:11 am »

Quote from: Spikeman on October 29, 2006, 02:45:07 am
Why don't you just use MD5? It's built into PHP so it would be much easier to implement.. or am I misunderstanding what you want it for?

I  plan to make a title screen / screen shot archive for use with gamefront and I need a way to correspond the pictures with the roms.

http://www.ideiadupla.com/gamefront/download.htm

I was looking for a unique identifier for each individual rom. I don't want to use the name in case it gets relabeled later. That will case me to have to update the picture archive.

I would prefer to use some type of number (kinda like GBA-renamer) one that wont change even if the name does or if it gets a patch etc.

My first suggestion was to use SHA1 hash, but I was informed it would be allot easier to use CRC32 number.

I would perfer to use something that is very easy to locate (hopefully in an emulator) because I will be cataloging allot pictures and that is going to take a long time.

So out of the 3 choices what does everyone think is the most viable option.

SHA1 hash, CRC32, or MD5
creaothceann
Guest
« Reply #14 on: October 29, 2006, 08:21:32 am »

Quote from: Special T on October 29, 2006, 07:56:11 am
I was looking for a unique identifier for each individual rom. I don't want to use the name in case it gets relabeled later. That will case me to have to update the picture archive.

I would prefer to use some type of number (kinda like GBA-renamer) one that wont change even if the name does or if it gets a patch etc.

[...]

I would perfer to use something that is very easy to locate (hopefully in an emulator) because I will be cataloging allot pictures and that is going to take a long time.

Patches might change anything in the file; they could even change its size. It's very unlikely that a patched file has the same checksum number (ie. generic checksum / SHA1 / CRC32 / MD5 / ...) as the unpatched file!

The only thing that doesn't change with patching is the filename.
The only thing that doesn't change without patching is the checksum.

Either you identify only unpatched ROMs (like NSRT does), or you identify via filename.
Pages: [1] 2  


Powered by SMF 1.1.4 | SMF © 2006-2007, Simple Machines LLC