 Show Posts
|
|
Pages: 1
|
|
1
|
Research & Technical XboxHacking (Xbox 360) / DVD-ROM Drive and Media / Re: breakthrough: XBOX 1 firmware hacked !
|
on: January 31, 2006, 08:29:40 PM
|
You cannot cause a bufferoverflow on the 360!  Because stack memory is not executable I reapeat since some people wont shutup about this You cannot cause a bufferoverflow on the 360 c ya Buffer overflows don't only apply to corrupting stack memory. You could overflow a non-stack buffer that's (for example) followed by a list of function pointers. So, unless you can prove that it's impossible to write to RAM, or that it's impossible to use function pointers on the Xbox360, I don't think people will "shutup" about it. - Paulb |
|
|
|
|
2
|
Research & Technical XboxHacking (Xbox 360) / DVD-ROM Drive and Media / Re: breakthrough: XBOX 1 firmware hacked !
|
on: January 31, 2006, 06:45:22 PM
|
As for whether/not you should release it: you're definitely looking at copyright issues if you release the binary image. Releasing a "patcher" would be releasing a "copyright circumvention device", so you could be in trouble with the DMCA. Actually, much of the discussion on this board could have DMCA issues, IMO, since it may not be directly related to getting another OS running on the 360 (which is the DMCA 'exception' that Xbox-Linux hacking claims covers them).
About the DMCA .. "The Digital Millennium Copyright Act (DMCA) is a United States copyright law. The act criminalizes production and dissemination of technology that can circumvent measures taken to protect copyright, not merely infringement of copyright itself, and heightens the penalties for copyright infringement on the Internet. Passed on May 14, 1998 by a unanimous vote in the United States Senate and signed into law by President Bill Clinton on October 28, 1998, the DMCA amended title 17 of the US Code to extend the reach of copyright, while limiting the liability of Online Providers from copyright infringement by their users."  By highlighting "United States", I assume you're trying to say: it's a US law, so it's "OK" for us non-US people to ignore it? I believe both Europe and Australia have similar laws (or they are in the process of making similar laws). I could be wrong about that. Perhaps TheSpecialist is a US citizen? Perhaps TheSpecialist just doesn't want to risk it - no matter where he lives? It's TheSpecialist's right to decide whether/not to release the code, patcher, documentation, whatever else. I don't think we should second-guess. Of course, that's my opinion... - Paulb |
|
|
|
|
3
|
Research & Technical XboxHacking (Xbox 360) / DVD-ROM Drive and Media / Re: breakthrough: XBOX 1 firmware hacked !
|
on: January 31, 2006, 06:18:53 PM
|
|
First of all: VERY nice work, Specialist!
I think you can ignore the flamers. People who have been watching your progress can tell that you've learned the firmware/authentication process inside-and-out - you've now seen the fruits of your labor (in a working hack).
As a fellow hacker, I don't think you'd have gone to all of that work, only to 'lie'. The people who post 'lies' don't actually do the background work - they just post crap and expect people to believe it. Anyone can take a look at the DVD hacking thread and see that you've really been doing work on this (along with others).
As for whether/not you should release it: you're definitely looking at copyright issues if you release the binary image. Releasing a "patcher" would be releasing a "copyright circumvention device", so you could be in trouble with the DMCA. Actually, much of the discussion on this board could have DMCA issues, IMO, since it may not be directly related to getting another OS running on the 360 (which is the DMCA 'exception' that Xbox-Linux hacking claims covers them).
With all the details given in the threads here, I'm sure 'mod' companies can replicate what you've done. I haven't kept fully up to date on the threads, but I believe (roughly) you've proven that you can embed a single 'authentication' sector in the DVD firmware, and always give its info to the Xbox (instead of using the on on the disc). Maybe I'm way-off here - that's how I interpreted it when I last read the thread. With that theory proven, a competent 'mod' company can make their own DVD firmware. So, whether/not you release your version probably won't stop 'mod' companies from taking your ideas - if they see it as profitable.
I definitely understand your reluctance to release details - and it annoys me the way people jump on you. If they don't believe you, then fine: move along/ignore you.
Anyway, again, congrats on the breakthrough!
- Paulb
|
|
|
|
|
4
|
Research & Technical XboxHacking (Xbox 360) / DVD-ROM Drive and Media / Re: hacking DVD firmware ?
|
on: January 07, 2006, 11:17:04 PM
|
I just finished working my way through a *HUGE* decryption routine, still don't know exactly how it works, but it seems to be some RC4/SHA1 routine. I'm not really into encryption, I'd have to spend quite some time on this routine to understand how it exactly works. RC4 code is typically pretty small. SHA-1 can be pretty huge. Some 'standard' constant values used in SHA-1 initialization code are: 0x67452301; 0xEFCDAB89; 0x98BADCFE; 0x10325476; 0xC3D2E1F0; If you see these values in the code you're looking at, I'd guess it's SHA-1 code (or, both SHA-1 and RC4). - Paulb |
|
|
|
|
5
|
Research & Technical XboxHacking (Xbox 360) / DVD-ROM Drive and Media / Re: hacking DVD firmware ?
|
on: January 07, 2006, 08:33:45 PM
|
Anyway, like MacDennis and Anita999 are saying: someone has send me the logged data from the x360 communication, containing this read dvd structure block. If his logging was correct, then the x360 drive ENCRYPTS the data, because his log contained completely other data then you guys are showing (it didn't contain the large zero sections for example). We'll have to find out if encryption is done in the FW or in the MPU hardware.
I can confirm that the read dvd structure command contains code to encrypt data. The encryption key is taken from 90004F00, still need to figure out what kind of encryption is being used. The first 20 bytes are not encrypted. Takires - Can you post some more addresses from the firmware, like the address of the encryption function, and where you determined the first 20 bytes are not encrypted? I would suspect RC4 encryption is being used, just because MS has used it a lot in the past. But, that's really just a 'wild guess' at this point. Thanks, - Paulb |
|
|
|
|
6
|
Research & Technical XboxHacking (Xbox 360) / DVD-ROM Drive and Media / Re: hacking DVD firmware ?
|
on: January 05, 2006, 11:56:33 AM
|
So, to summarize, you believe that 'descrambling' functionality is part of the CPU and not part of any code in ROM or flash?
I've always believed that the 'descrambling' is done in hardware somehow - either because the address lines are wired-up to the CPU in a non-standard fashion (with some address-line inverting as well), or because the CPU/microcontroller has built-in 'scramble/descramble' support. After seeing Flash code that talks to 'normal' addresses, I believe this must be a function of the CPU/microcontroller (that can be turned ON/OFF in software). One thing that still perplexes me (that I'll investigate further): if "WRITE BUFFER" reads the flash at 0x4f00/0x4f80 (into a RAM buffer) while the CPU is auto-descrambling the values, then (presumably) writes it back with a 'byte program' function that disables all of the descrambling, then the data written back to 0x4f00/0x4f80 would need to be scrambled by the software before it's written (so that the next time it's read back (while the CPU is auto-descrambling) it'll be correct). As I said, I'll dig into that further and report my findings. - Paulb |
|
|
|
|
7
|
Research & Technical XboxHacking (Xbox 360) / DVD-ROM Drive and Media / Re: hacking DVD firmware ?
|
on: January 05, 2006, 10:53:58 AM
|
Sorry for an offline question. When I use objdump, the output result isn't in hex format when it interprets a immediate value. But the disasm from Paulb's post can do it. example:
Paulb's result:
2fded: fa d0 55 55 add 0x5555,a0 ;a0 now (chip_base + 0x5555)
My result:
2fded: fa d0 55 55 add 21845,a0
I know there must be a option switch controls this. But I couldn't find it. I am using a recompiled version for win32. Can anyone help me out here?
I couldn't find an option to control this. I have the source, and modified it/re-built for Linux (sorry, I can't seem to get a win32 build to compile - I use 'mingw' for my Unix-like environment under Windows). If you have the source/can re-build, the file to change (in 'binutils') is "opcodes/m10300-dis.c". Look for the fprintf_func call with "%ld" (near the end of the file), and change it to use "0x%lx". - Paulb |
|
|
|
|
8
|
Research & Technical XboxHacking (Xbox 360) / DVD-ROM Drive and Media / Re: hacking DVD firmware ?
|
on: January 05, 2006, 10:23:47 AM
|
I've done a bit more analysis of the flash programming code in the image (I believe I'm looking at a decoded "GDR-3120L_0047DH.BIN" right now - I'm not 100% sure). There are two basic 'chunks' of flash code. One from 0x9002f8b7 to 0x9002fd27, the other from 0x9002fd29 to 0x900300f5. The first 'chunk' represents all of the code necessary to erase a flash sector. This code is NOT executed directly from the flash chip (since, while programming/erasing flash, you can't do opcode fetches from the chip). The code at 0x9002f46f-0x9002f4c9 copies this 'chunk' of flash code to RAM (starting at 0x80000000), then calls the code at 0x80000000. The second 'chunk' of flash code represents the code necessary to program a byte (or bytes) of flash. Again, this chunk of code isn't executed directly from flash. The code at 0x9002f4cc-0x9002f535 copies this chunk of code to RAM (at 0x80000000) and calls the code there. Each of these chunks of code that gets copied to RAM starts/ends with similar sequences. For example, the first chunk starts out like: 9002f8b7: cf 08 movm [other],(sp)
9002f8b9: cf 20 movm [a2],(sp)
9002f8bb: f8 fe fc add 0xfffffffc,sp
9002f8be: fc ff 29 04 calls 0x9002fce7
9002f8c2: 00 00
9002f8c4: f8 fe 04 add 0x4,sp
9002f8c7: 34 a8 d9 movbu (0xd9a8),d0
9002f8ca: 85 01 mov 0x1,d1
9002f8cc: f2 14 or d1,d0
9002f8ce: 02 a8 d9 movbu d0,(0xd9a8)
The sequence above calls a function at 0x9002fce7 (see that func below), then "or's" a bit (D0) into what appears to be a hardware register. Here's the function that gets called from above: 9002fce7: 34 04 d9 movbu (0xd904),d0
9002fcea: f8 e0 80 and 0x80,d0
9002fced: c9 fa bne 0x9002fce7
9002fcef: cb nop
9002fcf0: cb nop
9002fcf1: 80 01 mov 0x1,d0
9002fcf3: 02 00 df movbu d0,(0xdf00)
9002fcf6: cb nop
9002fcf7: cb nop
9002fcf8: 80 00 mov 0x0,d0
9002fcfa: 02 01 df movbu d0,(0xdf01)
9002fcfd: cb nop
9002fcfe: cb nop
9002fcff: 2c 9a 00 mov 0x9a,d0
9002fd02: 02 28 df movbu d0,(0xdf28)
9002fd05: f0 fc rets
The above function seems to wait until a bit (in a hardware register?) goes to zero, then writes to three more hardware registers. Similar code is seen at the end of the 'chunk' of flash code: 9002f92d: 34 a8 d9 movbu (0xd9a8),d0
9002f930: 2d fe 00 mov 0xfe,d1
9002f933: f2 04 and d1,d0
9002f935: 02 a8 d9 movbu d0,(0xd9a8)
9002f938: f8 fe fc add 0xfffffffc,sp
9002f93b: fc ff cc 03 calls 0x9002fd07
9002f93f: 00 00
9002f941: f8 fe 04 add 0x4,sp
9002f944: ce 20 movm (sp),[a2]
9002f946: ce 08 movm (sp),[other]
9002f948: f0 fc rets
This time, it clears the same D0 bit in the same hardware register that was set at start, and calls another function that looks similar to what was called at the start of the 'chunk' (except that it does different register writes): 9002fd07: 34 04 d9 movbu (0xd904),d0
9002fd0a: f8 e0 80 and 0x80,d0
9002fd0d: c9 fa bne 0x9002fd07
9002fd0f: cb nop
9002fd10: cb nop
9002fd11: 80 00 mov 0x0,d0
9002fd13: 02 00 df movbu d0,(0xdf00)
9002fd16: cb nop
9002fd17: cb nop
9002fd18: 80 00 mov 0x0,d0
9002fd1a: 02 01 df movbu d0,(0xdf01)
9002fd1d: cb nop
9002fd1e: cb nop
9002fd1f: 2c 9a 00 mov 0x9a,d0
9002fd22: 02 28 df movbu d0,(0xdf28)
9002fd25: f0 fc rets
I suspect that the 'entry sequence' to these flash functions temporarily disables address-line remapping, and that the 'exit sequence' re-enables the mapping. This allows the standard flash functions to just work without worrying about bit-swapping. I've looked at several places which call these 'erase sector' and 'byte program' functions. So far, they all look like they are related to things like DVD region setting. They operate on data at offset 0x4f00 and 0x4f80 in the flash image (which I had previously suspected contained the drive/Xbox serial numbers). I haven't looked closely enough at the code - maybe these regions contain both the "DVD region" info and the drive/Xbox serial numbers. I'll study it more later and see if I can figure that out. Of course, I could be way-off here - feel free to correct me in any of my assumptions/guesses. - Paulb |
|
|
|
|
9
|
Research & Technical XboxHacking (Xbox 360) / DVD-ROM Drive and Media / Re: hacking DVD firmware ?
|
on: January 05, 2006, 09:16:09 AM
|
2fde7: fc dc 00 00 mov 0x90000000,a0 ;chip_base is 0x90000000
2fdeb: 00 90
2fded: fa d0 55 55 add 0x5555,a0 ;a0 now (chip_base + 0x5555)
2fdf1: 2c aa 00 mov 0xaa,d0
2fdf4: f0 50 movbu d0,(a0) ;write 0xaa to (chip_base + 0x5555) (start of "Product ID entry" sequence)
2fdf6: fc dd 00 00 mov 0x90000000,a1
2fdfa: 00 90
2fdfc: fa d1 aa 2a add 0x2aaa,a1 ;a1 now (chip_base + 0x2aaa)
2fe00: 80 55 mov 0x55,d0
2fe02: f0 51 movbu d0,(a1) ;write 0x55 to (chip_base + 0x2aaa)
2fe04: 2c 90 00 mov 0x90,d0
2fe07: f0 50 movbu d0,(a0) ;write 0x90 to (chip_base + 0x5555) (end of "Product ID entry" sequence)
Good finding paul_b, this should also prove that probably no data/address pin swapping is done in hardware, right? otherwise there will be no standard flash commands. Reading manufacturer ID at an higher address...maybe some king of check to see if for mistake the real 0x0 adrress was readed instead of manufacturer ID, to see if the falsh accept write commands Very good point about the address/data lines not being swapped in hardware (because the standard flash addresses/commands used in the above function are 'normal' ones). But, that doesn't make sense to me: we know that the data stored in flash has the bits swapped around in every 32-bit dword (people have de-soldered their flash chips/dumped them directly). Maybe 8-bit accesses to the flash region are un-swapped, but 32-bit accesses get swapped? I'm just waking up after little sleep - so maybe I'm not thinking this through enough. After some coffee, I'll think about it some more/re-read the flash code to see if it makes more sense (I've also identified some other flash code in the image - I'll look at it too). - Paulb |
|
|
|
|
10
|
Research & Technical XboxHacking (Xbox 360) / DVD-ROM Drive and Media / Re: hacking DVD firmware ?
|
on: January 04, 2006, 05:06:28 PM
|
More proof of Flash chip being at 0x90000000: 2fde7: fc dc 00 00 mov 0x90000000,a0 ;chip_base is 0x90000000
2fdeb: 00 90
2fded: fa d0 55 55 add 0x5555,a0 ;a0 now (chip_base + 0x5555)
2fdf1: 2c aa 00 mov 0xaa,d0
2fdf4: f0 50 movbu d0,(a0) ;write 0xaa to (chip_base + 0x5555) (start of "Product ID entry" sequence)
2fdf6: fc dd 00 00 mov 0x90000000,a1
2fdfa: 00 90
2fdfc: fa d1 aa 2a add 0x2aaa,a1 ;a1 now (chip_base + 0x2aaa)
2fe00: 80 55 mov 0x55,d0
2fe02: f0 51 movbu d0,(a1) ;write 0x55 to (chip_base + 0x2aaa)
2fe04: 2c 90 00 mov 0x90,d0
2fe07: f0 50 movbu d0,(a0) ;write 0x90 to (chip_base + 0x5555) (end of "Product ID entry" sequence)
2fe09: cb nop
2fe0a: cb nop
2fe0b: fc a8 00 00 movbu (0x90000000),d0 ;read manufacturer ID from flash chip
2fe0f: 00 90
2fe11: fc 82 20 10 movbu d0,(0x80001020) ;flash manufacturer ID stored here (RAM)
2fe15: 00 80
2fe17: fc a8 00 10 movbu (0x90001000),d0 ;hmm... reading device IDs at offset 0x1000 and 0x2000 as well??
2fe1b: 00 90
2fe1d: fc 82 24 10 movbu d0,(0x80001024)
2fe21: 00 80
2fe23: fc a8 00 20 movbu (0x90002000),d0
2fe27: 00 90
2fe29: fc 82 28 10 movbu d0,(0x80001028)
2fe2d: 00 80
2fe2f: fc a8 01 00 movbu (0x90000001),d0 ;read device ID from flash chip
2fe33: 00 90
2fe35: fc 82 04 10 movbu d0,(0x80001004)
2fe39: 00 80
2fe3b: 2c aa 00 mov 0xaa,d0 ;write 0xaa to (chip_base + 0x5555) (start of "Product ID exit" sequence)
2fe3e: f0 50 movbu d0,(a0)
2fe40: 80 55 mov 0x55,d0
2fe42: f0 51 movbu d0,(a1) ;write 0x55 to (chip_base + 0x2aaa)
2fe44: 2c f0 00 mov 0xf0,d0
2fe47: f0 50 movbu d0,(a0) ;write 0xf0 to (chip_base + 0x5555) (end of "Product ID exit" sequence)
2fe49: cb nop
2fe4a: cb nop
2fe4b: f8 fe fc add -4,sp
2fe4e: fc ff 47 02 calls 0x30095 ;wait for flash to be ready for reads
2fe52: 00 00
2fe54: f8 fe 04 add 4,sp
2fe57: 85 1f mov 0x1f,d1 ;1F is Atmel MFG ID
2fe59: fc a8 20 10 movbu (0x80001020),d0 ;previously stored flash MFG ID stored here
2fe5d: 00 80
2fe5f: a4 cmp d1,d0
2fe60: c9 19 bne 0x2fe79
2fe62: fc a8 24 10 movbu (0x80001024),d0
2fe66: 00 80
2fe68: a4 cmp d1,d0
2fe69: c9 10 bne 0x2fe79
2fe6b: fc a8 28 10 movbu (0x80001028),d0
2fe6f: 00 80
2fe71: a4 cmp d1,d0
2fe72: c9 07 bne 0x2fe79
2fe74: c9 05 bne 0x2fe79
2fe76: cc 6e 01 jmp 0x2ffe4
The above code is reading the Flash chip's manufacturer/device ID, accessing the chip starting at address 0x90000000. In addition, it's calling the 'wait until data stops changing' function posted here previously (at offset 0x30095). The above is just the start of the function to read the flash Identifier. It also tries some more sequences. It's very standard-looking Flash 'read identifier' code. - Paulb |
|
|
|
|
11
|
Research & Technical XboxHacking (Xbox 360) / DVD-ROM Drive and Media / Re: hacking DVD firmware ?
|
on: January 04, 2006, 04:44:37 PM
|
- The external firmware flash starts at 0x90000000
Opinions anyone? I agree - it looks like external flash firmware (the code we have dumped) is at 0x90000000. Looks at this funtion: 30095: fc a8 00 00 movbu (0x90000000),d0
30099: 00 90
3009b: cb nop
3009c: cb nop
3009d: fc a9 00 00 movbu (0x90000000),d1
300a1: 00 90
300a3: cb nop
300a4: cb nop
300a5: a1 cmp d0,d1
300a6: c9 ef bne 0x30095
300a8: fc a9 00 00 movbu (0x90000000),d1
300ac: 00 90
300ae: cb nop
300af: cb nop
300b0: a1 cmp d0,d1
300b1: c9 e4 bne 0x30095
300b3: f0 fc rets
Looks to me like it is debouncing a memory mapped something or other at 0x90000000. My vote is that flash is not mapped at 0x90000000. Nor do I vote for 0x80000000 because there are absolute writes to this range. This looks like it could be code related to flash programming (programming at chip at 0x90000000). Often, when a flash chip is in programming mode, it will return different data on back-to-back 'reads' until the programming operation is complete (one bit of the byte 'toggles' on each read from the chip). When you get two consecutive 'reads' that are identical, you know that the chip finished programming. So, the above code is consistent with flash being at 0x90000000, IMO. Also, look at the following: 60eb: fc cc c2 60 mov 0x900060c2,d0
60ef: 00 90
60f1: 01 c0 df mov d0,(0xdfc0)
60f4: fc cc e2 64 mov 0x900064e2,d0
60f8: 00 90
60fa: 01 b4 00 mov d0,(0xb4)
60fd: fc cc 71 61 mov 0x90006171,d0
6101: 00 90
6103: 01 00 00 mov d0,(0x0)
6106: fc cc a8 61 mov 0x900061a8,d0
610a: 00 90
610c: 01 04 00 mov d0,(0x4)
610f: fc cc aa 61 mov 0x900061aa,d0
6113: 00 90
6115: 01 08 00 mov d0,(0x8)
6118: fc cc ac 61 mov 0x900061ac,d0
611c: 00 90
611e: 01 0c 00 mov d0,(0xc)
6121: fc cc bf 61 mov 0x900061bf,d0
6125: 00 90
6127: 01 10 00 mov d0,(0x10)
612a: fc cc d2 61 mov 0x900061d2,d0
612e: 00 90
6130: 01 14 00 mov d0,(0x14)
6133: fc cc f5 61 mov 0x900061f5,d0
6137: 00 90
6139: 01 28 00 mov d0,(0x28)
It appears that a bunch of 'function pointers' are being initialized to point to functions in the 0x9000xxxx range. If you look at the corresponding offsets in the disassembly (example: at 0xxxxx60c2, 0xxxxx64e2), you'll see what looks like the start of a function at each address. Some of the functions are 'null/empty' functions - just a 'rets' instruction. But, the offsets never point into the middle of a function - always to a valid function start. So, these functions must exist in memory based at 0x90000000. Either the flash chip is there, or the flash code gets copied to RAM at 0x90000000 before the above code snippet is used. - Paulb |
|
|
|
|
12
|
Research & Technical XboxHacking (Xbox 360) / DVD-ROM Drive and Media / Re: hacking DVD firmware ?
|
on: December 22, 2005, 02:13:33 PM
|
|
How many people have dumped their flash? Do we only have the one image?
I see 'interesting' stuff at offsets like $4f00 and $4f80 that "stand out" as possibly being something like a serial number. (maybe someone else already noticed this earlier in the thread - sorry if I missed it).
Since we know that you can't swap drives between Xbox's, maybe we could determine if these values are either the drive's serial #, or the Xbox's serial # that the drive came from.
Having more than one flash dump would help find 'unique' data in each drive.
- Paulb
|
|
|
|
|
13
|
Research & Technical XboxHacking (Xbox 360) / DVD-ROM Drive and Media / Re: hacking DVD firmware ?
|
on: December 22, 2005, 01:36:10 PM
|
|
Phantasm -
Very nice work! I was thinking along the same path (bit flipping), but since I'm on vacation, I haven't had time to write a tool to test the theory.
How did you figure out which of the 24 remaining bit combinations were correct? Are you 100% sure of your final bit combinations? I ask because in the decoded output (using "loser's" most recently posted version of the code), the start (offset 0) doesn't look like reasonable code to me (other example MN10300 code I saw started with real code at offset 0). But, I see 'good' code at offset $1000, so maybe the stuff at 0 isn't really code in this particular hardware.
Something to consider (if we think offset 0 should be code): address-line flipping.
Again, great work (to everyone involved in this discovery)!
- Paulb
|
|
|
|
|
14
|
Xbox 360 / XboxHacking - General / Re: Raw Dump Extractor released.
|
on: December 12, 2005, 08:59:43 AM
|
These dumps are no more then what it says they are. They are raw dumps. A drive does not need to read a file system or anything at all. With some modified frimware and software that can use it then it simply needs a start point and an end point. Everything inbetween is called 'raw data'. After the dump has been made then software can be used to read the raw image. This process allows for trying new/different ways to access the file system w/o worrying about what the drive is capable of seeking on command. The only complication would be if the file system was encrypted which they have said it is not. That would have made it hard to find the names and seperations of files.
Xbox1 DVDs are copy protected. Normal DVD drives are physically incapable of reading the entire disc (because they are fooled to think the disc has a lot less burned onto it than it really does). The Xbox1 DVD drive can 'see' all of the data - but only after sent a special sequence of commands from the Xbox (so you can't just take the Xbox1 DVD drive and make it work inside a normal PC). I assume Xbox360 DVDs are also copy protected. I also assume normal PC DVD drives are not capable of reading the entire disc/extracting "raw dumps", and that an Xbox360 drive won't work "as is" in a PC. - Paulb |
|
|
|
|
15
|
Xbox 360 / XboxHacking - General / Re: Raw Dump Extractor released.
|
on: December 08, 2005, 11:28:34 PM
|
|
OK... call me stupid, but what exactly do you mean by a 'raw dump'??
A 'raw dump' of what?? The hard drive?, a memory card?, a DVD?, a network trace?, (somehow) the SDRAM on the Xbox?, OR something else???
Sorry - I didn't bother following the link. I think your description should let me know WTF you're talking about before I bother following the link.
- Paulb
|
|
|
|
|
17
|
General / XboxHacker Site Discussion / Do people know that Xboxhacker is back?
|
on: November 29, 2005, 12:42:31 AM
|
|
Hi -
First of all, I'm glad to see that xboxhacker is back! This is where all of the real hacking/discussion of the original Xbox was done - I hope it'll be a good place for technical info on the Xbox-360.
I don't even know how I found out that xboxhacker was back - I think it was a link buried in another forum thread (perhaps xbox-scene forum).
Has it been 'announced' that xboxhacker is 'back'? Maybe I just missed it (I'm not on top of xbox stuff too much anymore, but do check xbox-scene occasionally).
If it hasn't been announced, should it be? (Obviously, an announcement might find other 'old timers' like me, which I think would be good for the forums here, but could also attract a lot of non-technical people who may fill the forums with non-tech stuff...)
- Paulb
|
|
|
|
|
