In this case asterisk sybmols are to be completely omitted.
Submit the ring code as 0028.
You are not logged in. Please login or register.
Redump Forum → Posts by Bigmanjapan
Pages 1
In this case asterisk sybmols are to be completely omitted.
Submit the ring code as 0028.
http://lukasz.dk/mirror/forums.ps2dev.o … tml?t=3743
http://brokensword.narod.ru/ps2bios_unpacker.zip
This unpacker will output individual executable files off a PS2 BIOS file. Including that PS1DRV executable in particular.
Load PS1DRV executable in ps2dis, click Analyzer -> Invoke Analyzer, then go to Edit -> Jump to Labeled. Scroll the list and you will see some PS1 serial numbers.
They are located in Metadata section of redump entries for PS3 submissions.
To create an IRD file using Redump2IRD program you would need:
1. PS3 disc image (ISO) in encrypted state;
2. Corresponding Disc Key from Metadata section of a redump entry for the disc;
3. Corresponding Disc ID from Metadata section of a redump entry for the disc;
4. Corresponding Permanent Information & Control (PIC) from Metadata section of a redump entry for the disc;
What to do:
1. Launch Redump2IRD program;
2. Make sure Redump Mode is ticked (at the bottom);
3. Put Disc Key into Encrypted D1 (Key) field;
4. Put Disc ID into Decrypted D2 (ID) field;
5. Put Permanent Information & Control (PIC) into Permanent Information & Control (PIC) Data (in Hex) field;
6. Press Create IRD button;
7. Select encrypted image (ISO file);
8. After 10-20 seconds pause, input filename for IRD file.
The result is an IRD file for >decrypted< image of the game.
Allow for automatic dumping process termination upon encountering read errors and I'll switch to it. And if FTP connection is added at some point, then I'll drop multiMAN entirely (haven't tried webMAN-MOD yet).
Dumping process terminates automatically upon exceeding allowed amount of re-tries now.
For the software to display log entries for each individual read error during dumping process (starts at 5:04 in the video above), the Show Logs option has to be enabled in Settings. It is disabled by default.
Looks like get 3Dump.bin issue got fixed?
Correct.
I haven't looked into Evilnat yet but ManaGunZ reached a point where it can replace MultiMAN + GetKey combination.
I've tried using the 1.41 test build with the same scratched LittleBigPlanet disc.
1. At 05:30 you can see that the log stating read errors appears which is nice.
2. At 06:33 you can see that 30/30 re-tries are reached on the first bad sector, no termination of dumping process or any prompt appearing happens. The log itself is already a pretty nice development but I would like to see a setting (that could be switched on and off in the global settings of the program, for example) that would make dumping process actually be terminated upon any bad sector reaching 30/30 re-tries. My reasoning is that, with multiMAN after I start dumping process, I go and do something else. I don't need to constantly monitor the screen since multiMAN will outright terminate the dumping process by itself. With ManaGunZ in its current state I need to monitor screen in order to know if read errors happened or not.
Also, I'm not sure why multiMAN and ManaGunZ make optical drive behave differently when read errors are encountered. Again, as I've described in my previous post multiMAN would stop and spin the disc again which is very audible while ManaGunZ doesn't do this, even in the 1.41 test version. It wouldn't matter much if the output dumps are correct, I guess. Just a thought.
3. At 07:43 you can see that Cancelled notification pops-up at the upper right corner. That's me trying to terminate the dumping process by pressing Circle button. For some reason, termination doesn't happen if the log is actively shown on screen. When I pressed Hide logs button at 08:14, the dumping process was allowed to be terminated.
I also tried using the newly implemented "Get files for redump.org" function seen at 0:23 in the above video. Works perfectly. And more than that, it outputs files with the custom filenames which include timestamps like this:
BCES01663_20210722_071038.getkey.log
BCES01663_20210722_071038.disc.pic
This is a nice improvement in comparison to GetKey since when keys are dumped via GetKey the output files' filenames would remain the same, meaning that GetKey would overwrite them. This forces dumpers to transfer the files to PC after each dump which wastes time. ManaGunZ improves on this, especially since it uses timestamps a dumper can dump multiple copies of the same game in one session and the files won't be overwritten.
So, ManaGunZ is approaching to be the dumping tool for me. Allow for automatic dumping process termination upon encountering read errors and I'll switch to it. And if FTP connection is added at some point, then I'll drop multiMAN entirely (haven't tried webMAN-MOD yet).
I don't know what key/hash does Dump Disc Hash Key function in Hybrid Firmware Tools dump. Usually nothing else is needed for submission apart from decryption key and hashes. If key generated by Dump Disc Hash Key function doesn't match key generated by GetKey, then it's not needed (I guess).
You can submit dumps without providing decryption keys if your dumped ISOs have hashes matching the redump entries.
You probably know this but I will remind that while HEN can be installed on any PS3, only certain PS3 models can be modded with proper CFW: https://youtu.be/Eckd06nFReY?t=95
Hello.
From what I understand HEN doesn't provide enough access to the system's inner workings. In particular it's not possible to dump eid_root_key and without it you wouldn't be able to use Getkey.
You need to have a proper CFW installed.
I've tested 1.40 version of this program by dumping two discs:
1. After Hours Athletes BCES-01335 (perfect condition, dumps fine via multiMAN and matches existing redump entry);
2. LittleBigPlanet 3 BCES-01663/RSC (data side is heavily scratched, cannot be dumped via multiMAN due to read errors).
1. Dumping.
ManaGunZ 1.40 dumped After Hours Athletes game correctly. The hashes match redump entry.
Dumping LittleBigPlanet raised some questions. When multiMAN dumps a disc with read errors it does 30 retries on each error. If data cannot be read in 30 retries, then dumping process is terminated. This happens with my damaged LittleBigPlanet disc too. ManaGunZ on the other hand, continues to dump the disc without terminating dumping process. The read rate dips to 0 MiB/s in problematic areas as expected but dumping is not terminated. I transferred the output dump to my PC, calculated the hashes and they didn't match the redump entry. Now I'm not sure what ManaGunZ does exactly (forcefully fills error segments with zeros or something else) but it clearly is an issue when it comes to accurate dumping. I've had multiple PS3 discs which visually had perfect data surface but rendered read errors upon trying to dump them via multiMAN. With ManaGunZ there is simply no way to tell if such discs were dumped correctly. Moreover, as an additional indicator of dumping process status multiMAN features an active log which shows errors and retry attempts; ManaGunZ has no log and therefore no way to see if any errors were ever encountered during dumping.
Another thing I've noticed is that when multiMAN encounters read errors, discs would slow down and speed up again. In other words, one can hear how optical drive does something with the discs. In ManaGunZ nothing like this happens, just a steady humming of a dumping process despite the errors.
Dumping process of damaged LBP disc via ManaGunZ 1.40:
https://www.youtube.com/watch?v=E2Qr5mHiBwo
Dumping process of damaged LBP disc via multiMAN 04.85.01:
https://www.youtube.com/watch?v=Df6uDcv8uqk
2. Transferring the dumps.
My Slim PS3 has only two USB ports. One is occupied with the controller since its battery is dead. Dumping keys via GetKey requires FAT32 formatted storage. Dumping discs via ManaGunZ requires NTSC formatted storage (as a proposed method in the guide posted above). You can see how this becomes an absolute circus of constantly inserting/removing devices to keep the dumping process going.
ManaGunZ can dump discs to internal HDD just like multiMAN does but at the same time there is no FTP connection support. Therefore even if I dump a disc to internal HDD via ManaGunZ, I would still need to use multiMAN to transfer the dump to my PC since I use cable connection which is the fastest method.
3. Images' filenames.
One interesting detail of ManaGunZ is how it forces its own filename format on the dumps.
For example, multiMAN would name the above-mentioned After Hours Athletes like this:
After Hours Athletes.ISO
While ManaGunZ would render this filename:
BCES01335_20210710_063641.iso
This could actually be a solution for those users who encounter an outright termination of dumping process in multiMAN when certain Japanese discs are attempted to be dumped. They have either Japanese characters or nothing at all in their file/volume names and that, I guess, confuses multiMAN. ManaGunZ might be able to bypass this.
My resume would be that using ManaGunZ for dumping in its current state is not warranted. The way it handles read errors alone is reason enough. At the same time it might help dumpers who have issues with Japanese discs but imagine that those Japanese discs would have read errors as well, then it's a guessing game of was such disc dumped correctly or not all over again.
Pages 1
Redump Forum → Posts by Bigmanjapan
Powered by PunBB 1.4.4, supported by Informer Technologies, Inc.
Currently installed 6 official extensions. Copyright © 2003–2009 PunBB.