1

(35 replies, posted in General discussion)

user7 wrote:

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

2

(35 replies, posted in General discussion)

diego-rbb-93 wrote:

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

3

(35 replies, posted in General discussion)

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

4

(35 replies, posted in General discussion)

Jackal wrote:

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

5

(35 replies, posted in General discussion)

first type seed is only 32bit, 256^4 combinations

second type seed is 128bit, 256^16 combinations, impossible to bruteforce, forever

6

(35 replies, posted in General discussion)

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

7

(35 replies, posted in General discussion)

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 smile

8

(35 replies, posted in General discussion)

LOL, i got it, because xboxregen also needs "ss.txt" and i forgot to add the support, lame i am

9

(35 replies, posted in General discussion)

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 smile

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! smile

P.S. Silent Hill 2 is 1,77 GB 7zipped
P.S.S. you should place "ss.txt" in the folder with iso

10

(35 replies, posted in General discussion)

https://i.imgur.com/7bA0cki.png

this is time taken to brute the seed value for "Silent Hill 2 - Inner Fears (Europe) (En,Ja,Fr,De,Es,It).iso"

11

(35 replies, posted in General discussion)

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

12

(35 replies, posted in General discussion)

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

13

(35 replies, posted in General discussion)

It works!

https://pastebin.com/vfC9GSLX

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!

14

(35 replies, posted in General discussion)

great, thanks for the link, very interesting for research
will take a look after figuring out the 3ds decryption

15

(13 replies, posted in General discussion)

F1ReB4LL wrote:
LedZeppelin68 wrote:

Merge It!

Not the best solution for decompressing them on-the-fly on "a tiny quiet Android box".

everything is possible! smile

16

(13 replies, posted in General discussion)

Merge It!

http://forum.redump.org/post/63916/

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

19

(53 replies, posted in General discussion)

ajshell1 wrote:

Results:

https://cdn.discordapp.com/attachments/ … 062411.jpg

Also, the game itself has English, Spanish, and French language support.

Thank you!

20

(53 replies, posted in General discussion)

Hi, ajshell1, can you please dump this hybrid disc with UMDKiller mod?
http://forum.redump.org/post/62111/#p62111
and compare the dump

21

(75 replies, posted in General discussion)

Hi, i have modded UMDKiller PRX edition and wish to explain, how it works

https://pastebin.com/iJsTSgST

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

22

(6 replies, posted in General discussion)

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

23

(6 replies, posted in General discussion)

johnsanc wrote:

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?

sure
https://github.com/LedZeppelin68/gcm-nasos-deux

24

(6 replies, posted in General discussion)

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

https://i.imgur.com/wsgGnG0.png