-
Notifications
You must be signed in to change notification settings - Fork 30
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
Showing
15 changed files
with
3,643 additions
and
3,643 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,41 +1,41 @@ | ||
| FriiDump came to existance thanks to the work by a lot of people, most of which | ||
| are probably not aware of this fact ;). So here is proper credit: | ||
| The DVD seed bruteforcing algorithm and code were taken from unscrambler 0.4 | ||
| by Victor Mu�oz ([email protected], | ||
| http://www.ingenieria-inversa.cl/?lp_lang_pref=en). | ||
| The theoritical basis of the dumping methods were suggested in several comments | ||
| to Victor's post. The most important comments came from Victor himself (xt5), | ||
| FuzzyLogic and svpe. | ||
| The code to actually perform the dumping was derived from the work of Kevin | ||
| East, AKA SeventhSon ([email protected], http://www.kev.nu/360/), which, in turn, | ||
| derives from work by a lot of other people. See his page for full details. | ||
| Many hints were taken from RawDump, whose author is unknown. | ||
| A program that helped me a lot to understand the drive cache behaviour is | ||
| PLScsi by Pat LaVarre (http://members.aol.com/plscsi/). | ||
| Nintendo disc structure information was taken from: | ||
| - http://www.gc-linux.org/docs/yagcd.html | ||
| - http://www.wiili.org/index.php/GameCube_Optical_Disc | ||
| Code to tell whether a Wii disc contains an update or was inspired by a program | ||
| by [email protected]. Sorry but I cannot find the URL anymore :(. | ||
| Other minor pieces of code were taken from tcpdump (www.tcpdump.org), Python | ||
| (www.python.org) and the glibc printf manpage. | ||
| GDR8163B and Windows testing was performed by tasso85. | ||
| Thanks also go out to the ConsoleTribe staff for giving me the possibility to | ||
| use their forum for the program support. | ||
| Glue, endless hours spent understanding drive cache behaviour and rest of the | ||
| code are by me, Arep <[email protected]>. | ||
| Finally, obvious thanks go out to Nintendo for making all of their great | ||
| consoles, who constantly help me to waste the rest of my spare time I do not | ||
| spend coding ;). | ||
| FriiDump came to existance thanks to the work by a lot of people, most of which | ||
| are probably not aware of this fact ;). So here is proper credit: | ||
|
|
||
| The DVD seed bruteforcing algorithm and code were taken from unscrambler 0.4 | ||
| by Victor Mu�oz ([email protected], | ||
| http://www.ingenieria-inversa.cl/?lp_lang_pref=en). | ||
|
|
||
| The theoritical basis of the dumping methods were suggested in several comments | ||
| to Victor's post. The most important comments came from Victor himself (xt5), | ||
| FuzzyLogic and svpe. | ||
|
|
||
| The code to actually perform the dumping was derived from the work of Kevin | ||
| East, AKA SeventhSon ([email protected], http://www.kev.nu/360/), which, in turn, | ||
| derives from work by a lot of other people. See his page for full details. | ||
|
|
||
| Many hints were taken from RawDump, whose author is unknown. | ||
|
|
||
| A program that helped me a lot to understand the drive cache behaviour is | ||
| PLScsi by Pat LaVarre (http://members.aol.com/plscsi/). | ||
|
|
||
| Nintendo disc structure information was taken from: | ||
| - http://www.gc-linux.org/docs/yagcd.html | ||
| - http://www.wiili.org/index.php/GameCube_Optical_Disc | ||
|
|
||
| Code to tell whether a Wii disc contains an update or was inspired by a program | ||
| by [email protected]. Sorry but I cannot find the URL anymore :(. | ||
|
|
||
| Other minor pieces of code were taken from tcpdump (www.tcpdump.org), Python | ||
| (www.python.org) and the glibc printf manpage. | ||
|
|
||
| GDR8163B and Windows testing was performed by tasso85. | ||
|
|
||
| Thanks also go out to the ConsoleTribe staff for giving me the possibility to | ||
| use their forum for the program support. | ||
|
|
||
| Glue, endless hours spent understanding drive cache behaviour and rest of the | ||
| code are by me, Arep <[email protected]>. | ||
|
|
||
| Finally, obvious thanks go out to Nintendo for making all of their great | ||
| consoles, who constantly help me to waste the rest of my spare time I do not | ||
| spend coding ;). |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,53 +1,53 @@ | ||
| Since last official version original method 1 have been renamed to method 0 | ||
| and it undergone certain changes. Methods 2, 3, 4 have been renamed to 7, 8 | ||
| and 9 respectively. Method 0 should work with all drives as long as they | ||
| are supported by one of memory dump commands, so if drive is unrecognized it | ||
| is preferable to keep method at 0, and try all commands. If one of such | ||
| combinations turns out to work, you can proceed then testing other methods | ||
| with this commad. In case none of commands work, you could try to determine | ||
| drive's Read Buffer command's parameters with supplied 'BruteForce3C.exe'. | ||
| Generally program's overall bahaviour regarding commandline haven't changed | ||
| and you should be able to use same options as with official versions, though | ||
| in case you were using unrecognized drive, which would nevertheless work with | ||
| Hitachi command, you'll need to set command to 2 now (e.g. --command 2) and | ||
| method to 7, 8 or 9. | ||
| Performance have increased since official release and should be now about the | ||
| same as with 'RawDump'. | ||
| Regarding supported drives: | ||
| 1. Hitachi-LG GDR8161B, GDR8162B, GDR8163B, GDR8164B, GDR8082N | ||
| Those drives can read GC/Wii media without swapping. Expected performance is | ||
| 1600..1900 MB/h for *4B, *3B and 2100..2600 MB/h for *2B, *1B. Custom memory | ||
| dump command is used, which returns 2064 bytes of data. It was reproted that | ||
| they can not read other (e.g. PC) discs this way though, this needs | ||
| confirmation. | ||
| 2. Lite-On LH-18A1H, DVDRW LH-18A1P, DVDRW LH-20A1H, DVDRW LH-20A1P | ||
| Reading performance for PC DVDs can go up to 5000 MB/h, which means program's | ||
| core as well as new methods are capable to output data at least at this rate. | ||
| Reading performance for GC was about 1600..1700 MB/h so likely this slowdown is | ||
| caused by drive logic itself. Though I only had one GC game to test with, so | ||
| possibly better results can be achieved depending on media. Best results were | ||
| obtained, when using method 5 with parameter 16,27 (--method5=16,27). This | ||
| combination isn't set as default because it can cause noticable delays | ||
| depending on medium quality and to make methods more general for use with other | ||
| devices. Lite-On won't read GC/Wii DVDs at all without swapping. Lite-On | ||
| returns 2384 bytes of data (2064 + ECC) by means of vendor specific READ BUFFER | ||
| command. Tested with models LH-18A1H, LH-18A1P and LH-20A1H. | ||
| 3. Plextor | ||
| Plextor would return 2064 bytes of already unscrambled data with READ BUFFER | ||
| command. It works good with ordinary DVDs but due the lack of streamed reading | ||
| support is practically useless for GC/Wii dumping because of very low | ||
| performance. Works nevertheless and could be used for some experiments and | ||
| testing. Results from PX-760A. | ||
| 4. Toshiba Samsung SH-D162A, SH-D162B, SH-D162C, SH-D162D | ||
| Returns 2384 data bytes per sector like Lite-On does. Appears to support | ||
| streamed reading but performance with tested model (SH-D162D) was somewhat low | ||
| and unstable even with ordinary DVDs. Looks promising, if only good-working | ||
| method could be determined. Latest drives added, definitely need more testing | ||
| at this point. | ||
| Since last official version original method 1 have been renamed to method 0 | ||
| and it undergone certain changes. Methods 2, 3, 4 have been renamed to 7, 8 | ||
| and 9 respectively. Method 0 should work with all drives as long as they | ||
| are supported by one of memory dump commands, so if drive is unrecognized it | ||
| is preferable to keep method at 0, and try all commands. If one of such | ||
| combinations turns out to work, you can proceed then testing other methods | ||
| with this commad. In case none of commands work, you could try to determine | ||
| drive's Read Buffer command's parameters with supplied 'BruteForce3C.exe'. | ||
|
|
||
| Generally program's overall bahaviour regarding commandline haven't changed | ||
| and you should be able to use same options as with official versions, though | ||
| in case you were using unrecognized drive, which would nevertheless work with | ||
| Hitachi command, you'll need to set command to 2 now (e.g. --command 2) and | ||
| method to 7, 8 or 9. | ||
|
|
||
| Performance have increased since official release and should be now about the | ||
| same as with 'RawDump'. | ||
|
|
||
| Regarding supported drives: | ||
|
|
||
| 1. Hitachi-LG GDR8161B, GDR8162B, GDR8163B, GDR8164B, GDR8082N | ||
| Those drives can read GC/Wii media without swapping. Expected performance is | ||
| 1600..1900 MB/h for *4B, *3B and 2100..2600 MB/h for *2B, *1B. Custom memory | ||
| dump command is used, which returns 2064 bytes of data. It was reproted that | ||
| they can not read other (e.g. PC) discs this way though, this needs | ||
| confirmation. | ||
|
|
||
| 2. Lite-On LH-18A1H, DVDRW LH-18A1P, DVDRW LH-20A1H, DVDRW LH-20A1P | ||
| Reading performance for PC DVDs can go up to 5000 MB/h, which means program's | ||
| core as well as new methods are capable to output data at least at this rate. | ||
| Reading performance for GC was about 1600..1700 MB/h so likely this slowdown is | ||
| caused by drive logic itself. Though I only had one GC game to test with, so | ||
| possibly better results can be achieved depending on media. Best results were | ||
| obtained, when using method 5 with parameter 16,27 (--method5=16,27). This | ||
| combination isn't set as default because it can cause noticable delays | ||
| depending on medium quality and to make methods more general for use with other | ||
| devices. Lite-On won't read GC/Wii DVDs at all without swapping. Lite-On | ||
| returns 2384 bytes of data (2064 + ECC) by means of vendor specific READ BUFFER | ||
| command. Tested with models LH-18A1H, LH-18A1P and LH-20A1H. | ||
|
|
||
| 3. Plextor | ||
| Plextor would return 2064 bytes of already unscrambled data with READ BUFFER | ||
| command. It works good with ordinary DVDs but due the lack of streamed reading | ||
| support is practically useless for GC/Wii dumping because of very low | ||
| performance. Works nevertheless and could be used for some experiments and | ||
| testing. Results from PX-760A. | ||
|
|
||
| 4. Toshiba Samsung SH-D162A, SH-D162B, SH-D162C, SH-D162D | ||
| Returns 2384 data bytes per sector like Lite-On does. Appears to support | ||
| streamed reading but performance with tested model (SH-D162D) was somewhat low | ||
| and unstable even with ordinary DVDs. Looks promising, if only good-working | ||
| method could be determined. Latest drives added, definitely need more testing | ||
| at this point. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,64 +1,64 @@ | ||
| FriiDump 0.5.3 - Copyright (C) 2007 Arep | ||
| This software comes with ABSOLUTELY NO WARRANTY. | ||
| This is free software, and you are welcome to redistribute it | ||
| under certain conditions; see COPYING for details. | ||
| Official support forum: http://wii.console-tribe.com | ||
| Forum for this UNOFFICIAL VERSION: http://forum.redump.org | ||
| Available command line options: | ||
| -h, --help Show this help | ||
| -a, --autodump Dump the disc to an ISO file with an | ||
| automatically-generated name, resuming the dump | ||
| if possible | ||
| -g, --gui Use more verbose output that can be easily | ||
| parsed by a GUI frontend | ||
| -d, --device <device> Dump disc from device <device> | ||
| -p, --stop Instruct device to stop disc rotation | ||
| -c, --command <nr> Force memory dump command: | ||
| 0 - vanilla 2064 | ||
| 1 - vanilla 2384 | ||
| 2 - Hitachi | ||
| 3 - Lite-On | ||
| 4 - Renesas | ||
| -x, --speed <x> Set streaming speed (1, 24, 32, 64, etc., | ||
| where 1 = 150 KiB/s and so on) | ||
| -T, --type <nr> Force disc type: | ||
| 0 - GameCube | ||
| 1 - Wii | ||
| 2 - Wii_DL | ||
| 3 - DVD | ||
| -S, --size <sectors> Force disc size | ||
| -r, --raw <file> Output to file <file> in raw format (2064-byte | ||
| sectors) | ||
| -i, --iso <file> Output to file <file> in ISO format (2048-byte | ||
| sectors) | ||
| -u, --unscramble <file> Convert (unscramble) raw image contained in | ||
| <file> to ISO format | ||
| -H, --nohash Do not compute CRC32/MD5/SHA-1 hashes | ||
| for generated files | ||
| -s, --resume Resume partial dump | ||
| - General ----------------------------------- | ||
| -0, --method0[=<req>,<exp>] Use dumping method 0 (Optional argument | ||
| specifies how many sectors to request from disc | ||
| and read from cache at a time. Values should be | ||
| separated with a comma. Default 16,16) | ||
| - Non-Streaming ----------------------------- | ||
| -1, --method1[=<req>,<exp>] Use dumping method 1 (Default 16,16) | ||
| -2, --method2[=<req>,<exp>] Use dumping method 2 (Default 16,16) | ||
| -3, --method3[=<req>,<exp>] Use dumping method 3 (Default 16,16) | ||
| - Streaming --------------------------------- | ||
| -4, --method4[=<req>,<exp>] Use dumping method 4 (Default 27,27) | ||
| -5, --method5[=<req>,<exp>] Use dumping method 5 (Default 27,27) | ||
| -6, --method6[=<req>,<exp>] Use dumping method 6 (Default 27,27) | ||
| - Hitachi ----------------------------------- | ||
| -7, --method7 Use dumping method 7 (Read and dump 5 blocks | ||
| at a time, using streaming read) | ||
| -8, --method8 Use dumping method 8 (Read and dump 5 blocks | ||
| at a time, using streaming read, using DMA) | ||
| -9, --method9 Use dumping method 9 (Read and dump 5 blocks | ||
| at a time, using streaming read, using DMA and | ||
| some speed tricks) | ||
| FriiDump 0.5.3 - Copyright (C) 2007 Arep | ||
| This software comes with ABSOLUTELY NO WARRANTY. | ||
| This is free software, and you are welcome to redistribute it | ||
| under certain conditions; see COPYING for details. | ||
|
|
||
| Official support forum: http://wii.console-tribe.com | ||
|
|
||
| Forum for this UNOFFICIAL VERSION: http://forum.redump.org | ||
|
|
||
|
|
||
| Available command line options: | ||
|
|
||
| -h, --help Show this help | ||
| -a, --autodump Dump the disc to an ISO file with an | ||
| automatically-generated name, resuming the dump | ||
| if possible | ||
| -g, --gui Use more verbose output that can be easily | ||
| parsed by a GUI frontend | ||
| -d, --device <device> Dump disc from device <device> | ||
| -p, --stop Instruct device to stop disc rotation | ||
| -c, --command <nr> Force memory dump command: | ||
| 0 - vanilla 2064 | ||
| 1 - vanilla 2384 | ||
| 2 - Hitachi | ||
| 3 - Lite-On | ||
| 4 - Renesas | ||
| -x, --speed <x> Set streaming speed (1, 24, 32, 64, etc., | ||
| where 1 = 150 KiB/s and so on) | ||
| -T, --type <nr> Force disc type: | ||
| 0 - GameCube | ||
| 1 - Wii | ||
| 2 - Wii_DL | ||
| 3 - DVD | ||
| -S, --size <sectors> Force disc size | ||
| -r, --raw <file> Output to file <file> in raw format (2064-byte | ||
| sectors) | ||
| -i, --iso <file> Output to file <file> in ISO format (2048-byte | ||
| sectors) | ||
| -u, --unscramble <file> Convert (unscramble) raw image contained in | ||
| <file> to ISO format | ||
| -H, --nohash Do not compute CRC32/MD5/SHA-1 hashes | ||
| for generated files | ||
| -s, --resume Resume partial dump | ||
| - General ----------------------------------- | ||
| -0, --method0[=<req>,<exp>] Use dumping method 0 (Optional argument | ||
| specifies how many sectors to request from disc | ||
| and read from cache at a time. Values should be | ||
| separated with a comma. Default 16,16) | ||
| - Non-Streaming ----------------------------- | ||
| -1, --method1[=<req>,<exp>] Use dumping method 1 (Default 16,16) | ||
| -2, --method2[=<req>,<exp>] Use dumping method 2 (Default 16,16) | ||
| -3, --method3[=<req>,<exp>] Use dumping method 3 (Default 16,16) | ||
| - Streaming --------------------------------- | ||
| -4, --method4[=<req>,<exp>] Use dumping method 4 (Default 27,27) | ||
| -5, --method5[=<req>,<exp>] Use dumping method 5 (Default 27,27) | ||
| -6, --method6[=<req>,<exp>] Use dumping method 6 (Default 27,27) | ||
| - Hitachi ----------------------------------- | ||
| -7, --method7 Use dumping method 7 (Read and dump 5 blocks | ||
| at a time, using streaming read) | ||
| -8, --method8 Use dumping method 8 (Read and dump 5 blocks | ||
| at a time, using streaming read, using DMA) | ||
| -9, --method9 Use dumping method 9 (Read and dump 5 blocks | ||
| at a time, using streaming read, using DMA and | ||
| some speed tricks) |
Oops, something went wrong.