Deprecated: preg_replace(): The /e modifier is deprecated, use preg_replace_callback instead in /home/xbh360/public_html/Sources/Load.php(225) : runtime-created function on line 3
More daydreaming ...
XboxHacker BBS
 
*
Welcome, Guest. Please login or register.
Did you miss your activation email?
August 22, 2014, 02:36:54 PM


Login with username, password and session length


Pages: 1 2 »
  Print  
Author Topic: More daydreaming ...  (Read 6045 times)
robinsod
Global Moderator
Xbox Hacker
*****
Posts: 648


Perl packed my shorts during global destruction


View Profile
« on: July 19, 2007, 04:49:27 AM »

NAND Flash has quite a complex electrical interface, its moot possible to attach a switch to 1 pin as has been done to make multi firmware DVD drives (NOR Flash). It would not be easy to do & if you want to easily change regions I suggest that you look at the XD card mod....
Logged
arnezami
Master Hacker
****
Posts: 214


View Profile
« Reply #1 on: July 19, 2007, 06:06:17 AM »

Thanks robinsod for the info.

I just realized something. We don't need to change the address lines (or better the command) to the NAND. The "only" thing to make this work is to (on-the-fly) patch the data at 6c in the NAND (now filled with the beginning address of the kv: 00 00 40 00).

But I'm not sure if the xbox will accept a change to that address.

Can somebody do the following:

Change the 00 00 40 00 at 6c in the NAND (if you've got ecc bytes its probably at a different address) into something like 00 09 40 00. Then copy-paste the entire kv to this address and FF the 4000-7fff part. Making sure of the ecc stuff of course. @SeventhSon: can this be done?

If that would work then a "small" on-the-fly patch (using some FPGA) might indeed work without the need of an extra NAND/xD card etc to make a game-region-switcher (you could even create many differently configured kv's and put them in the NAND, so you can switch between all of them).

Thanks. Smiley

arnezami
« Last Edit: July 19, 2007, 09:29:11 AM by SeventhSon » Logged
SeventhSon
Global Moderator
Master Hacker
*****
Posts: 276


View Profile WWW
« Reply #2 on: July 19, 2007, 09:29:28 AM »

Quote
Change the 00 00 40 00 at 6c in the NAND (if you've got ecc bytes its probably at a different address) into something like 00 09 40 00. Then copy-paste the entire kv to this address and FF the 4000-7fff part. Making sure of the ecc stuff of course. @SeventhSon: can this be done?
Yep.

I'm 99.9999999% certain that the 360 will allow other offsets at NAND[0x6C] and that it will work perfectly fine. After all, that's the whole point of referencing the KV indirectly, so that it can be moved (for example, because of a bad block).

On-the-fly patching of one of the bytes (or more, but one will do) in the KV offset value at NAND[0x6C] will work, I'm sure.
« Last Edit: July 19, 2007, 09:31:07 AM by SeventhSon » Logged
tmbinc
Global Moderator
Master Hacker
*****
Posts: 286


View Profile
« Reply #3 on: July 19, 2007, 09:42:23 AM »

Bad blocks are no issue, they will be replaced by the bad block replacement mechanism... But yes, it seems that it can be relocated.

Patching a single byte however won't work, as you have to fix the ECC bytes.
Logged

Please don't copy/quote full text outside this board. Instead, summarize and link to this post. Thanks! This lets me keep information updated and doesn't pull things out of context.
arnezami
Master Hacker
****
Posts: 214


View Profile
« Reply #4 on: July 19, 2007, 10:37:46 AM »

Quote
Change the 00 00 40 00 at 6c in the NAND (if you've got ecc bytes its probably at a different address) into something like 00 09 40 00. Then copy-paste the entire kv to this address and FF the 4000-7fff part. Making sure of the ecc stuff of course. @SeventhSon: can this be done?
Yep.

I'm 99.9999999% certain that the 360 will allow other offsets at NAND[0x6C] and that it will work perfectly fine. After all, that's the whole point of referencing the KV indirectly, so that it can be moved (for example, because of a bad block).

On-the-fly patching of one of the bytes (or more, but one will do) in the KV offset value at NAND[0x6C] will work, I'm sure.

Bad blocks are no issue, they will be replaced by the bad block replacement mechanism... But yes, it seems that it can be relocated.

Patching a single byte however won't work, as you have to fix the ECC bytes.


So in other words: if we can on-the-fly patch the first ecc block (512 bytes?) of the NAND we could choose the kv we want (if we put multiple kv's in the nand). Right?

Do we have (or could somebody add) some easy way of adding a second kv to the nand binary (I assume the ecc filesystem header stuff of the new position has to be used right?). And is there a reliable algo for pre-calculating the first ecc block in the nand (using its original header I assume) so that data can be used to patch on-the-fly? Thats basicly whats needed (data wise) and would be great to have for the person(s) who want to work on the hardware/FPGA part Wink.

Regards,

arnezami

PS. On a side-note: still thinking about this but would it be possible to move all other parts in the NAND aswell? If so it may be possible to more easely detect the request for retrieving the address of the kv (possible less bus lines needed). Tricky...
« Last Edit: July 19, 2007, 11:07:47 AM by arnezami » Logged
uberfry
Xbox Hacker
*****
Posts: 862



View Profile
« Reply #5 on: July 19, 2007, 02:26:53 PM »

arzenami, just store the 3 pages on serial flash...is easier Smiley
I can help you make this

ah btw!! anyone know if pages are read in blocks or just page by page?

edit: some code I just wrote...
keep in mind - this is just the concept - we assume you already read the page out of the serial flash into the FIFO (FIFO needs to be 528 bytes...like normal page Smiley)
this can of course be modified into on-the-fly-patching method, is not very hard either

the serial flash controller can be embedded with maybe 40 lines...maybe a lot less... (only needs statemachine - but need oscillator!)

Code:
library IEEE;
use IEEE.std_logic_1164.all;
use IEEE.std_logic_arith.all;
use IEEE.std_logic_unsigned.all;

entity ficcha is
port (
    CE_o: out std_logic;
    ALE : in std_logic;
    -- CLE : in std_logic; -- No need for now!!
    WE  : in std_logic;
    RE  : in std_logic;
    Din : in std_logic_vector(7 downto 0)
);
end ficcha;

architecture testadicazzo of ficcha is
signal addresslatch : std_logic_vector(23 downto 0);

begin

process(WE)
begin
    if rising_edge(WE) then
        if ALE = '1' then
            addresslatch <= addresslatch(16 downto 0) & Din;
        end if;
    end if;
end process;

CE_o <= '1' when addresslatch = X"00004000" else '0'; -- This is the "Read enable" that goes to the FIFO and the CE input of the NAND Flash
                                                        -- Make sure "Read Enable" of the FIFO is active high!!!
end testadicazzo;
« Last Edit: July 19, 2007, 02:54:38 PM by uberfry » Logged
arnezami
Master Hacker
****
Posts: 214


View Profile
« Reply #6 on: July 20, 2007, 01:56:58 AM »

arzenami, just store the 3 pages on serial flash...is easier Smiley
I can help you make this

ah btw!! anyone know if pages are read in blocks or just page by page?

edit: some code I just wrote...
keep in mind - this is just the concept - we assume you already read the page out of the serial flash into the FIFO (FIFO needs to be 528 bytes...like normal page Smiley)
this can of course be modified into on-the-fly-patching method, is not very hard either

the serial flash controller can be embedded with maybe 40 lines...maybe a lot less... (only needs statemachine - but need oscillator!)

Code:
library IEEE;
use IEEE.std_logic_1164.all;
use IEEE.std_logic_arith.all;
use IEEE.std_logic_unsigned.all;

entity ficcha is
port (
    CE_o: out std_logic;
    ALE : in std_logic;
    -- CLE : in std_logic; -- No need for now!!
    WE  : in std_logic;
    RE  : in std_logic;
    Din : in std_logic_vector(7 downto 0)
);
end ficcha;

architecture testadicazzo of ficcha is
signal addresslatch : std_logic_vector(23 downto 0);

begin

process(WE)
begin
    if rising_edge(WE) then
        if ALE = '1' then
            addresslatch <= addresslatch(16 downto 0) & Din;
        end if;
    end if;
end process;

CE_o <= '1' when addresslatch = X"00004000" else '0'; -- This is the "Read enable" that goes to the FIFO and the CE input of the NAND Flash
                                                        -- Make sure "Read Enable" of the FIFO is active high!!!
end testadicazzo;

Thanks Smiley. So as I understand the NAND is basicly switched off by using the CE_o. And the data in the FIFO takes over right? Don't quite see how you're trying to trigger this yet (how the retrieval of data at 6c is detected). Somebody with the hardware equipment and knowledge could strart trying this. I guess the first goal would simply be to replicate an existing kv (address) in the NAND. If that can be done then changing it should also be possible.

arnezami
Logged
uberfry
Xbox Hacker
*****
Posts: 862



View Profile
« Reply #7 on: July 20, 2007, 02:26:58 AM »

no no, is not changing address
is just saving the three pages into serial flash, then pre-loading fifo with one page
when that address was triggered (0x4000), it disables the nand flash and enables the fifo - on the falling edge, the fifo will output the data, just like the nand flash would
Logged
arnezami
Master Hacker
****
Posts: 214


View Profile
« Reply #8 on: July 20, 2007, 02:35:00 AM »

no no, is not changing address
is just saving the three pages into serial flash, then pre-loading fifo with one page
when that address was triggered (0x4000), it disables the nand flash and enables the fifo - on the falling edge, the fifo will output the data, just like the nand flash would
Ah. Right. Now it makes sense Smiley.

But I guess this could also be done with the first page at address 0000000000. Replacing the first bytes (including the four at 6c) with our own. No need for serial flash (assuming you can somehow use some "constants" needed to replicate the first 528 bytes, eg removing the "copyright text" Cheesy which makes it even easier). That way we could use the NAND for storage of kv's and change the address at 6c by "taking over" the first ~500 bytes. Right?

I'm also thinking about the need for all bus lines. Do you think it would be safe to change some bits in the output of the NAND? So not take over the NAND but intercept and change the output? I am asking because it just might be possible to create a hardware mod with only having to solder/break (very) few lines ... (I know this gives a problem with the ecc, still looking at mathematical possibilities here).

arnezami
« Last Edit: July 20, 2007, 02:44:56 AM by arnezami » Logged
arnezami
Master Hacker
****
Posts: 214


View Profile
« Reply #9 on: July 20, 2007, 02:58:58 AM »

I was also thinking about the possibilities of a pure software mod. Its probably risky but I guess in theory the following would be possible:

  • You own a xbox with fw <= 4548.
  • You patched your dvd drive.
  • You can run the KK + linux boot cd.
  • It is/will be possible to (reliably) retrieve the NAND (with edc) and the fuses using software only.
  • We will find a way to write to the NAND from within the xbox itself (risky ... but in essense similar to flashing your PC bios...)
  • We can create a boot cd (in combination with the kk exploit) that asks you to change the kv configuration (basicly giving you a menu). If a setup is choosen it flashes the NAND checks it and reboots.
  • You would be able to change you game region (and other settings) this way without ever touching an iron.

Again. Risky. But might be a nice goal. And you would always have infectus as a backup method...

arnezami
« Last Edit: July 20, 2007, 03:03:14 AM by arnezami » Logged
uberfry
Xbox Hacker
*****
Posts: 862



View Profile
« Reply #10 on: July 20, 2007, 03:53:01 AM »

but what if you don't have infectus?
is easier to just output one page and we're done
of course is possible to use fpga for on the fly patching the bytes (you'd also need a level translator or cut all the lines to go through the fpga) and infectus individually (which also has an fpga...) but I see no point in it...too high cost...
Logged
arnezami
Master Hacker
****
Posts: 214


View Profile
« Reply #11 on: July 20, 2007, 05:07:25 AM »

but what if you don't have infectus?
is easier to just output one page and we're done
of course is possible to use fpga for on the fly patching the bytes (you'd also need a level translator or cut all the lines to go through the fpga) and infectus individually (which also has an fpga...) but I see no point in it...too high cost...
Yeah. I guess outputting just one page would be the easiest way. Smiley

The idea behind patching lines on-the-fly is that it might take less soldering/cutting: by moving things around in the NAND it may be possible to trigger the patch using only 2-4 lines. If those lines could also be used to patch the output (eg if it would be possible to having to patch just those bits, there is the tricky part: edc bytes) this could mean only very few soldering/cuts would be needed.

But I guess that would be an enhancement. And even it were possible soldering a few more lines isn't a big issue. Probably better to first to try to make it work at all. Wink

Oh. And if you're going software only (and get into trouble) while you don't have infectus you're screwed (until you buy/install it of course).

arnezami
« Last Edit: July 20, 2007, 05:25:18 AM by arnezami » Logged
uberfry
Xbox Hacker
*****
Posts: 862



View Profile
« Reply #12 on: July 20, 2007, 06:09:19 AM »

or let be the patching...
maybe someone can just patch the kernel or hv to jump over the routine that checks it?
Logged
arnezami
Master Hacker
****
Posts: 214


View Profile
« Reply #13 on: July 20, 2007, 07:07:26 AM »

or let be the patching...
maybe someone can just patch the kernel or hv to jump over the routine that checks it?
No thats exactly what doesn't work and why we have to jump through so many hoops. The kernel is signed. In fact pretty much everything is. You can't patch it Wink

In short: we cannot change the code. We can only change the data (= the stuff in the kv).

That leaves three options:

1) Replace the entire NAND with another one having a different kv. eg use Xd card (but if there are many possible configurations for the kv this becomes impractical)
2) Somehow on-the-fly change the (address of the) kv like we are discussing here (that way you can have many different configs if desired).
3) Do a software patch: simply flash the NAND from within the xbox itself each time you want to change config (risky now but would be a nice solution if/once things are ironed out properly).

Regards,

arnezami
« Last Edit: July 20, 2007, 07:21:34 AM by arnezami » Logged
uberfry
Xbox Hacker
*****
Posts: 862



View Profile
« Reply #14 on: July 20, 2007, 08:15:57 AM »

and how about patching the sig check?
Logged
arnezami
Master Hacker
****
Posts: 214


View Profile
« Reply #15 on: July 20, 2007, 08:33:15 AM »

and how about patching the sig check?
Its in the cpu: and its in rom. No go. This is a general problem which has been discussed already Wink.
« Last Edit: July 20, 2007, 08:38:31 AM by arnezami » Logged
aaa2
Newbie
*
Posts: 2


View Profile
« Reply #16 on: July 21, 2007, 02:54:37 AM »

What if we change all the signation checking things at the same time in way they stop checking signation so these changed things can work together because none is checking eachother for signation.
(I apologize if i am talking crap since i have no technical knowledge whatsoever)

Then you have no business posting here - Banned. Robinsod

I've banned a couple of idiots who have signed up just to spam the technical boards HOWEVER I am getting p***ed off cleaning up and moving things are completely OT so it's now OPEN SEASON & even established users (who should know better) will be banned
« Last Edit: July 21, 2007, 03:27:20 AM by robinsod » Logged
arnezami
Master Hacker
****
Posts: 214


View Profile
« Reply #17 on: July 21, 2007, 04:26:58 AM »

Ok. I had the imrpression we were brainstorming not daydreaming. Smiley

Sorry if I did anything wrong. Wasn't aware of it. I assumed this was a discussion about the contents of the kv. And being able to change the contents looked like a natural extension of the topic. Thought it wasn't worthy of a new thread. Anyway: no harm intended.

Regards,

arnezami
« Last Edit: July 21, 2007, 04:45:01 AM by arnezami » Logged
aaa2
Newbie
*
Posts: 2


View Profile
« Reply #18 on: July 21, 2007, 06:07:37 AM »

hey if there was anything i did not mean to do then it was spamming. i just tried to find a possible kind of solution to a problem i often read (the thing with the signations and how they get checked by different things and these checking eachother) about but wasn't quite sure whether it might be a possible solution. i would like to express my deepest apology if someone felt isulted by my post and i am sure not visiting this forum for spamming it in any way. i just go here to see what progress is being made  and i respect all you hard working people for what you are doing i reckon i couldn't do it.
Logged
robinsod
Global Moderator
Xbox Hacker
*****
Posts: 648


Perl packed my shorts during global destruction


View Profile
« Reply #19 on: July 21, 2007, 06:23:31 AM »

Oh? Brainstorming are you? How can you possibly brainstorm when you haven't read the available documentation (You definitely have not looked at the Hynix datasheet & suggesting MS used a CRC or checksum in the KV is, frankly, ludicrous considering the level of security employed - even the south bridge code is 'crypted and then the hash checked later by the HV. MS obviously sacked M. Mouse or possibly moved him to heatsink design).  Sorry, no, this is ignorant, ill informed talking. All you achieve by chattering in the technical forums is to reduce the information density. There is a LOT more in the KV than just the region code and the thread exists to document that NOT random ideas on patching the region code.

I started contributing to this site because I found it frustrating that so little real technical info was available on the scene sites. I also want to "meet" and talk with like minded individuals with the skills to help each other go forward. It takes a lot of money and a huge amount of engineering effort to develop the tools and techniques that you benefit from - changing DVD region is the current best hack we have, you have a tool to do it because Seventhson, TS & I are prepared to work long hours (it's taken a minimum of 10 hours a day for perhaps 8 weeks - have you noticed TS is absent right now? Burnout Sad ). Be aware that these tools have existed in private arsenals for a long time, we wrote our own & made them public to aid other hackers, as a by product you got a new toy.   

Another motivation is to encourage others to take up the challenge, learn and have fun - that means I would encourage YOU to get involved and help YOU as far as I am able BUT please respect the contents of Arakon's sticky at the top of the Kernel Hacking Forum. We want an information rich site that allows people to build on each others work not a talking shop for the uninformed n00b (like lucky Luke and that other guy I banned). My reason for being a moderator is (a) so I can irritate Giggles (b) to help control some of the noise in the technical forums and enable people coming to the 360 to easily access good quality information without having to do everything themselves. That policy has benefited YOU as well since YOU have access to that information. I suspect you would prefer I continue working on the 360 (even if you dont like me much right now) and making the results public..... Or would you rather I quit and you can do it all yourself?

Spamming the technical threads discourages the few really talented guys out there who can contribute - Its a source of sadness to me that of the 6 of us who worked on the DVD firmware hack 18 months ago only 2 are still active here. I know Seventhson got bored with the scene because of the number of people posting BS questions about flashing DVD drives, he's back with a vengeance now so let's try not to lose him again.

Right, so having been extremely rude (& off topic Wink ) I would, humbly, suggest you consider adding an XD card interface, it really is a kick ass mod and 16, 32 or 64MB cards are cheap and easy to get. The effort in "on the fly patching" makes no sense (to me at least) when you can simply swap out an XD card



Logged
Pages: 1 2 »
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.11 | SMF © 2006-2009, Simple Machines LLC

Valid XHTML 1.0! Valid CSS! Dilber MC Theme by HarzeM