You are not logged in. Please login or register.
Redump Forum → General discussion → FriiDump 0.5.3 Source Code [Update: Linux build!]
Does it even exist anymore? I've been looking everywhere and it seems every site/search result just points to the 7zip file. I'd like to compile/run it for Linux, as 0.4.0 doesn't seem to work (GDR8082N on Fedora 14 x86_64 by the way) and I'd rather not think about trying to Wine it...
Thanks in advance.
The version that you'll find here is completely unofficial and themabus only released it in binary form..
i've mailed it to that other Linux guy and that was the last time i've heard from him
and he was sole person within a year interested in this
so i didn't think anyone else would be
well, it's a mess
*nix part was neglected and, what is, is hackish
it probably won't even compile on those machines
so you'd have to compare 0.5.3 with 0.4.0 and update nix platform specific functions
http://www.mediafire.com/?3h11a0gxrjf0mx0
but two requests in a month it's like superpopular
i guess i better add link to main topic then
Awesome, thanks!
I did eventually get 0.4.0 working, but 0.5.3 was a lot faster between the two Windows builds anyway, so I'll see if I can figure it out for Linux. I'll let you guys know if I get *NIX up to speed. 
np
that would be really great
good luck, flibitijibibo!
Bump to let you guys know that I got it compiling and I'm running it now to make sure nothing explodes.
It's being hosted here if you want to try it: http://www.flibitijibibo.com/files/flib … ump.tar.gz
Changes:
libfriidump/dumper.c:
- #include <inttypes.h>, using int64_t instead of __int64
libfriidump/CMakeLists.txt:
- Include the new files (new as in 0.5.3 anyway)
Let me know if it works on other systems!
Edit: It's functional as far as I can see, but good lord is it slow (400MB/h slower than 0.4.0). I'll test a few more games once this one is done and see what happens, but this first test is going to take like another 5 hours.
Edit 2: Nevermind, forgot the whole crash at 55% for SL thing. The output of the two dumps differ, but they both appear to be functional. As far as I can tell, the Linux build of 0.5.3 now works.
thank you very much, flibitijibibo
so, as far as i understand, it's slower on Linux and results are inconsistent, is this correct?
It's slower for sure [EDIT: No it isn't, see below]; I'll give it one more go to check for inconsistency.
hmm
could you please test raw output unscrambling (-u) performance, is there difference between 0.4/0.5 or win/nix?
*Edited like 300 times to articulate what I'm seeing with these tests*
First, readdressing speed: For some reason this next set of tests I did went at the same speed as 0.4.0 now. Seems the speed of the first test was a fluke.
As for inconsistencies, I'm now pretty sure that it's just where the dumping stops. All versions of 0.5.3 for some reason treat every game as a dual-layer disc. When you use a single-layer disc, 0.5.3 crashes at 55% every time. 0.4.0 will complete the dump as a proper single-layer disc.
Despite the crashing in 0.5.3, the dump size is consistent every time as far as I can tell. My guess is fixing the single-layer/dual-layer thing will fix the size difference between the two (which is likely the only real difference, I'd be shocked if there was any difference in actual data).
Going to try to force -T 1 and see how that compares to 0.4.0's result.
but on Windows it works, right?
i guess this is the part that has to updated for Linux.
Someone else will have to test it on Windows. If someone wants to try building/running it, use that tarball I linked to above. The only concern would be if it compiles or not though, since the only thing I changed was an int type. Even before I updated it functioned the same way (the SL/DL thing that is).
Also, the -T 1 test was successful. There are no inconsistencies, it was just 0.5.3 trying to read SL discs as DL. This leaves us with 2 issues left:
1. Whether or not it compiles/runs on Windows
2. Bug: 0.5.3 (all builds) interprets all Wii discs as Wii_DL (tested on GDR8082N), but this is a bug with 0.5.3, not the Linux update
If #1 works, then the Linux fix I did is complete. #2 is just something to be addressed for FriiDump in general, not the update I did.
no, no, we tested it on Windows quite a lot, it should be alright
i don't have Wii discs myself though, but it read PC DVDs and GC discs fine
but on Linux nobody did
i thought maybe it's something specific to your system
but still it's strange it crashes
if it was for size difference, drive would just request sectors that can not be read and program would abort
it sound very much like something has to be fixed for Linux
Er, yeah... it was an abort. Guess I should use the same words as the program, hm? It didn't actually explode or anything, the abort just read like one (specifically the part where it stops at a certain sector).
Assuming the fix above works, the two builds should work identically to the way they worked in the source before I fixed it, rather than it only functioning on Windows.
If GC discs work fine, then it must only be an issue between Wii SL and DL discs. This can be fixed with -T, but I guess it wouldn't hurt to figure out what's causing it to read as DL every time. My guess is it's something in disc.c, but I'm kind of skimming the code since I don't know a whole lot about the ins and outs of disc dumping.
Edit: Just to reiterate, the program functions identically to the version already released. It works fine with no problem, the only thing that was changed was an int type. This should be compatible with Windows, so as long as it compiles there is no problem (and basically no change) and the program will function exactly the same as before, since the int type is essentially the same, just under a name GCC recognizes.
I'm just reporting a bug that Wii SL and DL discs both read as DL discs, and this applies to ALL builds of 0.5.3.
yes, type is determined with disc_detect_type by simply requesting some sectors ahead of standard GC disc size
and then, if it pass, ahead of Wii size
i guess maybe your drive just doesn't return expected sense code
there was other method left in source, relying on content of DVD, but it was not used for some reason
so i left it alone
maybe you could check what sense your drive returns
on Windows IsoBuster could do this but i don't know about Linux tools
edit:
oh, right, i guess you could just compile it to print sense it returns
edit:
i've rechecked 0.5.3 (that precompiled version from year back) on my Lite-On with DVD+R and DVD+R DL
and it gets first one as Wii and 2nd as Wii_DL
so, i would say, on Windows generally it's fine
Ah, so it's likely just my drive then. That settles that. It'll be a long while before I have the time to look at it again though, so I'll just -T if I need to.
So as far as multiplatform goes, my work is as done as it can be. Thanks again for the source!
ok
thank you flibitijibibo
i'll add link to this thread in main topic, for other Linux users
no, it's name, that should have been changed
it's pretty messy like that
this Reed–Solomon unit is there for Lite-On, since those drives erase two bytes from each raw sector
this data has to be regenerated
they would not work at all, would there be something wrong
i made that unit atop of Morelos-Zaragoza & Thirumoorthy code
(3. 'Reed-Solomon errors-and-erasures decoder' @The Error Correcting Codes (ECC) Page)
i don't know, maybe i'll clean it up someday
not anytime soon though, i'm pretty done with this for now
edit:
ah, right, you mean, it shifts all data out now?
probably can just remove this bracket then
result is correct as it is now, probably just an unnecessary remainder is what it is
there should be quite a lot of commented out code parts and such
i didn't really invest time in aesthetics
but you could test this unit with raw DVD or CD sectors if you want to be certain
Hello all, new guy here.
I'm interested in Friidump, which is why I'm in this thread.
I have downloaded the source to Friidump 5.3, and have it running on windows under VS2010. I'm learning!
But I am unsure of two things, and any help would be appreciated.
1. There is a program called BruteForce3C included with Friidump. According to the text file, when I run it, it will interrogate the target drive to determine if it has READ BUFFER capabilities. The text says that "all returned data different from $00 will be logged to files." Has anyone done this? When I run it, I don't get any files created, at least not in the same directory from which I launch it. However, I DO get a set of numbers, like 141.712. If I run it again, I get 135.985. What do these numbers mean? Do they have any significance, or should I only be concentrating on the fact that there is no file created?
2. The target drive data is
a) H-L Data Storage
b) V/M: HLGDR-816B
c) DVD-ROM Drive
d) Model GDR-8161B
e) Type HDCO
f) Drive Rev A2
g) FW 0045
h) In the "MFC" section:
DVD-ROM DRIVE
(GDR-8161B)
E-H023-02-2782 (B)
2003. 05
I have seen some listings of drives that are known to work, but they all list the result of a successful Friidump, displaying something like "HL-DT-ST/DVD-ROM GDR8164B/0L06". Obviously, that actual text does not appear on the drive itself. Given that items "a", "c", and "d" match, should I expect the drive to work? Or do I need to see "0L06" someplace, also?
Note that Friidump shows this drive as not supported.
Also note, I have the target drive connected via a USB to IDE adapter. Should I try for a direct connect to the IDE cable?
Again, any help here would be appreciated.
Thanks
Charlie
Hi,
Is anyone else having trouble building friidump on 64-bit x86/Linux? For both the original 0.3.0 release and 0.5.3, it seems to build okay, but the program writes the first sector data (2048 or 2064 bytes depending on ISO/raw setting), then gives a segmentation fault like this:
...
Disc type..........: GameCube
Game ID............: M8
Region.............: Europe/PAL
Maker..............: 01 (Nintendo)
Version............: 1.00
Game title.........: Metroid Prime
Writing to file "test.raw" in raw format
Writing to file "test.iso" in ISO format
Segmentation faulthola, senoras y senores
been away for a summer (mmmm, sweet summer of leisure and love...)
for which i do not apologize at all, heh
BruteForce3C sends ReadBuffer (0x3C) command, as described in 'SCSI Primary Commands - 3 (SPC-3)'
to a specified drive
incrementally going through values 0x00..0xff for byte 1 and 2
checksum is calculated on returned data and if it's different from a checksum of zero-filled data,
buffer is logged to file for further examination
if at all, usually vanilla command 3c 02 00 would work (byte 1 : 02h - Data)
for MediaTek based Lite-Ons it's 3c 01 01 (byte 1: 01h - Vendor specific) for buffer;
3c 01 02 / 3c 01 e2 for EEPROM;
3c 01 f1 for KEYPARA
and buffer size is limited for LO
i've seen other custom commands, beside LO, but none that would return usable buffer data
other parameters might be custom too
and there might be completely custom commands, not based on ReadBuffer
in such cases this program will not help
you could try to determine it by other means (on forums, sources of programs for specific drives, disasm fw and such)
IDE2USB shouldn't matter
numbers at the end of execution are just timing
aboot Segmentation fault
i have
absolutely
no
idea
Hi all, señores, señoras, caballeros y damiselas en apuros 
I've just found this tool and compiled it for Linux/x86.
At first tested with a GDR8164B/0L06 (white bezel) it didn't work at all, nor with normal DVDs nor with a WOD.
Then with another GDR8164B/0L06 (black bezel) it is currently working at method 9 for ~950Mb/h.
This tool would be great if enhanced to support CDs and multi-track.
If it is interesting for anyone, I've modified this source to add an option to test all possible command/methods combinations on a single pass, and stop on the working one. For me it takes about 7 minutes if it fails, 50 different combinations, ~6hrs. of background unattended work You can download it on http://www.mediafire.com/download/ppz28 … .5.3.1.zip
memo/info/question
----
1. According to hitachi.c of friidump, MN103S microcontroller is required to dump a wii disc.
/*! \file
* \brief Memory dump functions specific to drives based on the Hitachi MN103 chip.
*
* Drives which are supported by this set of functions are, for instance, the LG GDR-8161B, GDR-8162B, GDR-8163B and GDR-8164B. All testing has been performed
* with the latter model, so I'm not really sure about the others, but they should work ;). Please report any issues and more compatible drives!
*
* This file contains code derived from the work of Kevin East (SeventhSon), kev@kev.nu, http://www.kev.nu/360/ , which, in turn, derives from work by
* a lot of other people. See his page for full details.
*/These drives can use a vendor specific command.
mmc.cmd[0] = 0xE7; // vendor specific command (discovered by DaveX)
mmc.cmd[1] = 0x48; // H
mmc.cmd[2] = 0x49; // I
mmc.cmd[3] = 0x54; // T
mmc.cmd[4] = 0x01; // read MCU memory sub-command
mmc.cmd[6] = (unsigned char) ((offset & 0xFF000000) >> 24); // address MSB
mmc.cmd[7] = (unsigned char) ((offset & 0x00FF0000) >> 16); // address
mmc.cmd[8] = (unsigned char) ((offset & 0x0000FF00) >> 8); // address
mmc.cmd[9] = (unsigned char) (offset & 0x000000FF); // address LSB
mmc.cmd[10] = (unsigned char) ((block_size & 0xFF00) >> 8); // length MSB
mmc.cmd[11] = (unsigned char) (block_size & 0x00FF); // length LSB2. I searched and found the spec of LG drive.
[1] https://www.manualslib.com/brand/lg/dvd-drive.html
[2] https://www.manualslib.com/brand/lg/cd-cdr-drive.html
[3] https://forum.cdrinfo.pl/attachments/f1 … e_v1.1.pdf
According to my drive, GDR-8160B has MN103S26E, GDR-8163B has MN103S89FDA, GCC-4241N has MN103S63GHA
According to [1], GDR-8161B has MN103S37F
According to [2], GCC-4241N and GCC-4242N have MN103S63GKD.
According to [3], MN103S is mainly used by GWA-xxxxB, GSA-Hxx and GHxx.
Model F/W Chipset Buffer Interface Type Special Features Clones Bootcode Notes OPU
GWA-4083B ---- MN103S86GSG / AN22112A 2048 kiB PATA DVD±RW N/A No DVD-RAM support HOP-7531TS
GWA-4084B ---- MN103S86GSG / AN22112A 2048 kiB PATA DVD±RW LightScribe N/A No DVD-RAM support HOP-7531TS
GWA-4161B 1.01 MN103S86GSG / AN22112A 2048 kiB PATA DVD±RW N/A No DVD-RAM support HOP-7531TS
GWA-4162B ---- MN103S86GSG / AN22112A 2048 kiB PATA DVD±RW LightScribe HP dvd640b N/A No DVD-RAM support HOP-7531TS
GWA-4166B ---- MN103SA6GSJ / AN22113A 2048 kiB PATA DVD±RW LightScribe HP dvd740b N/A No DVD-RAM support LPC-812R
GSA-4164B ---- MN103SA6GSJ / AN22113A 2048 kiB PATA DVD±RW N/A LPC-812R
GSA-4166B 1.02 MN103SA6GSJ / AN22113A 2048 kiB PATA DVD±RW LightScribe HP dvd840b N/A LPC-812R
GSA-H20N 1.02 MN103SB4GSA / AN22117A 2048 kiB PATA DVD±RW N/A LPC-812R
GSA-H20L 1.02 MN103SB4GSA / AN22117A 2048 kiB PATA DVD±RW LightScribe HP dvd840x N/A LPC-812R
GSA-H22N 1.02 MN103SD2GSA / AN22117A 2048 kiB PATA DVD±RW N/A LPC-812R
GSA-H22L 1.02 MN103SD2GSA / AN22117A 2048 kiB PATA DVD±RW LightScribe N/A LPC-812R
GSA-H30N 1.03 MN103SC0GSA / AN22117A 2048 kiB SATA DVD±RW N/A LPC-812R
GSA-H30L ---- MN103SC0GSA / AN22117A 2048 kiB SATA DVD±RW LightScribe N/A LPC-812R
GSA-H50N 1.03 MN103SC7GRT1 / AN22117A 2048 kiB PATA DVD±RW N/A LPC-815R
GSA-H54N 1.03 MN103SC7GRT1 / AN22117A 2048 kiB PATA DVD±RW N/A LPC-815R
GSA-H50L 1.03 MN103SC7GRT1 / AN22117A 2048 kiB PATA DVD±RW LightScribe N/A LPC-815R
GSA-H54L 1.03 MN103SC7GRT1 / AN22117A 2048 kiB PATA DVD±RW LightScribe N/A LPC-815R
GSA-H55N 1.06 MN103SC7GRT1 / AN22117A 2048 kiB PATA DVD±RW N/A Mainboard is slightly different from GSA-H50N/H54N LPC-815R
GSA-H55L 1.06 MN103SC7GRT1 / AN22117A 2048 kiB PATA DVD±RW LightScribe N/A Mainboard is slightly different from GSA-H50L/H54L LPC-815R
GSA-H58N 1.03 MN103SC7GRT1 / AN22117A 2048 kiB PATA DVD±RW N/A HOP-7662TL
GSA-H73N ---- MN103SC8GRT / AN22117A 2048 kiB SATA DVD±RW N/A LPC-815R
GH20NP20 1.00 MN103SD8GRA 2048 kiB PATA DVD±RW N/A LPC-817A
GH20LP20 1.02 MN103SD8GRA 2048 kiB PATA DVD±RW LightScribe N/A LPC-817A
GH22NP20 2.00 MN103SD8GRA 2048 kiB PATA DVD±RW ASUS DRW-22D1S N/A LPC-817A
GH22NP21 1.10 MN103SD8GRA 2048 kiB PATA DVD±RW ASUS DRW-22D1S N/A LPC-817A
GH22LP20 2.00 MN103SD8GRA 2048 kiB PATA DVD±RW LightScribe N/A LPC-817A
GH22LP21 1.10 MN103SD8GRA 2048 kiB PATA DVD±RW LightScribe N/A LPC-817A
GH22NS30 2.00 MN103SD9GRAB 2048 kiB SATA DVD±RW N/A LPC-817A
GH22LS30 2.00 MN103SD9GRAB 2048 kiB SATA DVD±RW LightScribe N/A LPC-817A3. According to acccuraterip.com, LG GDR-8161B, GDR-8162B, GDR-8163B and GDR-8164B have +102 offsets.
LG Electronics - DVD-ROM GDR8161B +102 430 100%
LG Electronics - DVD-ROM GDR8162B +102 703 100%
LG Electronics - DVD-ROM GDR8163B +102 1185 100%
LG Electronics - DVD-ROM GDR8164B +102 1222 100%GCC, GWA-xxxxB, GSA-Hxx and GHxx also have +102 offsets. (Of course not all drive)
----
From these, MN103S microcontroller has +102 offsets.
Question:
Do all this microcontroller have vendor specific command? If these drive have this command, can these dump a wii disc?
Redump Forum → General discussion → FriiDump 0.5.3 Source Code [Update: Linux build!]
Powered by PunBB 1.4.4, supported by Informer Technologies, Inc.
Currently installed 6 official extensions. Copyright © 2003–2009 PunBB.