Any chance you would consider open sourcing this?
sure, here it is: https://github.com/LedZeppelin68/dvd-shrinker
all credits for the algorithms goes to JayFoxRox
You are not logged in. Please login or register.
Redump Forum → Posts by LedZeppelin68
Any chance you would consider open sourcing this?
sure, here it is: https://github.com/LedZeppelin68/dvd-shrinker
all credits for the algorithms goes to JayFoxRox
Did you make any new research on this, Led?
I would continue to research type 2 algo, maybe some statistical analysis will help
for now, all i can offer to save space
1) for a little amount of isos with type 1 seed (maybe few hundreds) - xbox shrinker
2) for big games with regional clones, which data occupies most of the iso - use merger
Sorry, this is all i can offer
I think we must save, what can be saved, and store al possible info
I remade xbox_rnd tool, now it doesn't remove the junk from ISO, but only brutes the seed of first type
saves it to log, and it works much faster
P.S. drag all ISOS on the EXE and wait
Ok but my questions about the timestamp? Is there no way to predict the seed?
i can say - no
the seed value for second type is 128 bit, which consists of two 64 values:
1: system time and date (we can reduce this value to year, or maybe a month) +
2: and time from last reset (2^64 combos)
it is a very huge number to bruteforce
first type seed is only 32bit, 256^4 combinations
second type seed is 128bit, 256^16 combinations, impossible to bruteforce, forever
One doubt, is there any restriction when naming the iso?
Is it necessary to keep the seed in the name?
Or could it be kept separate?
since we need a bunch of information to restore the padding, seed and SS ranges
it is useless to store the seed in the name, it is a temporary workaround
we have two ways
1) store all data in a separate file
2) store data inside the iso, for example, in the first sector
but there is bad news: JayFoxRox (our member and person who discovered the algorithms) described it there
https://www.reddit.com/r/crypto/comment … eforce_on/
in two words:
isos compiled with SDK between versions 3926 - 4721 - easy to brutforce
isos compiled with SDK between versions 4831 - 5849 - will take forever
I think "UEFA Champions League 2004-2005 (Europe) (Es,It)" is a late game and uses another padding generator
http://xboxdevwiki.net/XDVDFS#Random_blocks
Version 4831 - 5849 algorithm
i didn't implement it yet, but i know which game to test
LOL, i got it, because xboxregen also needs "ss.txt" and i forgot to add the support, lame i am
one more thing we need is a security sectors ranges, they are unique for every game, and we have to specify it
since redump does have this info, this is not a problem
I included sample "ss.txt" in archive and updated xbox_dernd tool so it can support it
also i unlocked brutforce range to full range
test it!
P.S. Silent Hill 2 is 1,77 GB 7zipped
P.S.S. you should place "ss.txt" in the folder with iso
this is time taken to brute the seed value for "Silent Hill 2 - Inner Fears (Europe) (En,Ja,Fr,De,Es,It).iso"
Hello!
1) 1 seed value for entire disc, since current tool uses only one thread brutrforcing takes around 8 minutes on modern PC, I'll try to speed it up
2) I cannot tell for sure about nNASOS, if it uses the first version of NASOS, no it fills garbage blocks with zeroes and should have header block with marks which block uses garbage padding.
NASOS deux replaces garbage with "JUNK", and the image is playable in emulator
http://forum.redump.org/topic/17831/nasos-2/
3) Yes, this version supporting one game only
OK, test it on "Petit Copter (Japan).iso"
2 executables
1) xbox_dernd.exe - derandomizer
like "nasos deux", it doesn't change the structure of the file, just replaces "random data block" with block full of "JUNK", it is like zeroing but it serves as a mark
you will get a file called "Petit Copter (Japan).f401863e.iso"
f401863e is a seed for the random generator
2) xboxRegen.exe - regenerator of random data
replaces blocks full of "JUNK" with random data blocks, generated by using seed number
xbox_dernd is tweaked to be compatible with the Petit Copter for test purpose
the tweak is, that it bruteforces only 1/16 part of full range
from 0xf0000000 to 0xffffffff (f401863e)
to speed up the test process, it tooks about 8 seconds on my rig
brutforcing the full range will took about 8 minutes
P.S. 7zipped iso is 48,7 Mb
It works!
Tested it with the game from the example and known seed
Compressed size of archive 65 mb, against 6.4Gb with "garbage"
Great, Jackal, thanks for the info!
great, thanks for the link, very interesting for research
will take a look after figuring out the 3ds decryption
LedZeppelin68 wrote:Merge It!
Not the best solution for decompressing them on-the-fly on "a tiny quiet Android box".
everything is possible!
Merge It!
Hi, saw the issue http://forum.redump.org/topic/19210/an- … -database/
and made an util
it doesn't fix the last sector, only shows and logs info about it
so you can find suspicious images
usage:
NoEDChecker.exe "Image1.bin" "Image2.bin" ...
it produces noedc.log with recommendations
Results:
https://cdn.discordapp.com/attachments/ … 062411.jpg
Also, the game itself has English, Spanish, and French language support.
Thank you!
Hi, ajshell1, can you please dump this hybrid disc with UMDKiller mod?
http://forum.redump.org/post/62111/#p62111
and compare the dump
Hi, i have modded UMDKiller PRX edition and wish to explain, how it works
the main part is this code
opening UMD for reading, not the file system, the media itself
fd = sceIoOpen("umd0:", PSP_O_RDONLY, 0777);
allocating buffer in memory
umdbuffer=malloc(2097152);
reading 1024 sectors in buffer
sceIoRead(fd, umdbuffer, 1024);
opening file for writing on memorystick
redump = sceIoOpen("ms0:/ISO/REDUMP.iso", PSP_O_WRONLY| PSP_O_CREAT | PSP_O_TRUNC, 0777);
writing buffer bytes to file
sceIoWrite(redump, umdbuffer, 1024*2048);
it works with sectors, not file system
working buffer is 1 or 2 megabytes doesn't affect the perfomance, ripping time is equal, PSFiller == UMDKiller (300 Mb Tron Evolution in ~3:30 minutes)
What have been modded.
the original killer reads and saves chunks of 512 sectors at once.
this is ok when the size of UMD is a multiple of 512 (my test Tron Evolution is multiple, what a luck)
and i can't understand if original source does have the routine to handle not multiple UMDs, maybe this sceIoRead is so clever and can handle it by itself?
ok, there is a function "sceIoLseek" it can show the end sector, and if we add +1, it will be the size of the UMD
there is another place, that stores complete size in sectors, 16th sector of UMD, at the offset 0x50h
16 * 2048 + 0x50h = 0x8050h
Tron Evolution (ULES-01494)
Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
00008000 01 43 44 30 30 31 01 00 50 53 50 20 47 41 4D 45 .CD001..PSP GAME
00008010 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
00008020 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
00008030 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
00008040 20 20 20 20 20 20 20 20 00 00 00 00 00 00 00 00 ........
00008050 00 4A 02 00 00 02 4A 00 00 00 00 00 00 00 00 00 .J....J.........
00 4A 02 00 = 024A00h = 150016
I added this check, reading 16th sector and determine the full size of UMD
then I'm splitting the dumping process in two parts there it dumps chunks multiple of 1024
and the remaining non-multiple chunk
range1 = umdFullSize / 1024;
range2 = umdFullSize % 1024;
umdbuffer=malloc(2097152);
for(i=0;i<range1;i++)
{
sceIoRead(fd, umdbuffer, 1024);
sceIoWrite(redump, umdbuffer, 1024*2048);
}
free(umdbuffer);
if(range2!=0)
{
umdbuffer=malloc(range2*2048);
sceIoRead(fd, umdbuffer, range2);
sceIoWrite(redump, umdbuffer, range2*2048);
free(umdbuffer);
}
this is more simple and clear solution
to use this PRX, your should place it in "seplugins" directory on memorystick
add the line to seplugins/vsh.txt "ms0:/seplugins/UMDKiller.prx 1" without quotes
1 means enabled
don't forget to reset the handheld, place umd in drive, wait until it appears in XMB and press NOTE button
yes, you're right, and this file is compatible with Dolphin emulator, that's the main difference with the previous NASOS
the GCMs, produced with nasos 2:
1) does have compatibility with emulator;
2) doesn't have "randomly" generated junk;
3) can be packed by archivers;
4) can be reversed to its normal state
Metroid Prime (Korea).dec.iso, packed by 7zip, is 895 megabytes
How the heck did you make this into a playable format?! Is this basically a scrubbed iso that is scrubbed in a specific way so that its consistently reversible?
Awesome work.
Yes, it is scrubbed in a specific way, actually, i replaced non-compressable junk with compressable, it's lame, but effective
and utillity just swaps between this junks
Can you please post the source code so we can compile for other platforms?
Hi
I rewrote NASOS util, now it only supports gamecube images
the main difference, that it produces images that playable in emulator
Hello, jhmiller
Thanks for this notice.
Track 4 consists of 0x00h, that's why there are so many matches.
So, i modified util to stop searching after 1st succesful match
Redump Forum → Posts by LedZeppelin68
Powered by PunBB 1.4.4, supported by Informer Technologies, Inc.
Currently installed 6 official extensions. Copyright © 2003–2009 PunBB.