XeDK Important information database

Protecting an XeDK
Many XeDK's have been wiped off the market due to malicious user created executables designed to wipe a XeDK of its operating software and Microsoft's attempt to thwart black market kit's. Here are some steps to protect your investment.


[*]Backing up your NAND


Backing up your NAND after every fresh recovery is a great way to ensure a Development kit's revival after a bad flash or a malicious attack. To do so visit the usual places in search of "Flash360". This is a Homebrew application developed by Redline. Place this on your hard drive's development volume via neighborhood and run the .XEX (executable) and select "backup current nand to file". After doing so you should find flashdmp.bin in the same place you saved Flash360 at. Place this somewhere safe on your pc where you will not lose it, do this after every fresh recovery also note that it doesn't hurt to keep multiple backups incase one somehow corrupts.


[*]Prevent writing to the nand


This isn't a must but it can save you a lot of time encase you come across malicious code that might affect your nand. You can use a dual nand solution but it would be far easier to write protect your nand.


Here is a video showing how this is done, note use the alternate points!
http://www.youtube.com/watch?v=A5wXzu3cHcQ

While the switch is active the writing to your NAND is disabled meaning nothing can touch it, you will have to disable it after (Reason for after is because malicious code disguised as a recovery doesn't boot into this screen) the recovery screen comes up and after the xbox 360 reboots it is best to re-enable the write protect.


[*]Prevent fuse blowing


This one is fairly simple, look for u6t1/2 on the bottom of your motherboard follow the image that matches your motherboard and bridge the two points selected on either u6t1 or u6t2.



This in theory should stop Microsoft from blowing your Efuses in your cpu rendering your console useless.


[*]Writing back to the nand


I recommended purchasing and installing one of these products from your modchip store.

- Nand-X
- Maximus
- Cygnos 360

This will allow you to flash back to your nand with the flashdmp.bin that you received from Flash360 encase of a corrupted nand. There will be soldering involved with this.


[*] Abstinence method


Keep your devkit's ethernet connection removed, any outside packets can be used to brick your kit if you MUST use your ethernet cord for transfering data and you do not own a external hard drive then you must do the following.

- Go into launcher tools > Network Settings > Game Network Configuration > IP Settings. Write down the IP Address.

- Disconnect the ethernet cord and backup your Hard drive to your PC

- Insert the recovery disc you are on and run it from your disc tray with Hard Drive attached. This will give you a new clean Nand and a Formatted HDD

- Enter in your Xbox 360 name and go to launcher tools > Network Settings > Game Network Configuration > IP Settings set it to Manual and input the IP you wrote down leaving the rest blank.

- Go to launcher tools > Network Settings > Game Network Configuration > DNS Servers set it to Manual leaving the fields blank

- Go to launcher tools > Network Settings > Debug Network Configuration and set it to Manual putting in the same IP as before but adding +1 to the IP (example: 192.168.1.10 / 192.168.1.11)
leave the rest blank (MAC Address won't be blank)

- Connect your network cable and test your PN connection, if it does not connect then that is good and you should be able to connect to neighborhood through your router.

Most of all DO NOT under any circumstances leak anything,

Also make sure that all content you run on your kit uploaded by others have been verified and tested!

XeDK game emulation

If you simply do not have bigger hard drive's that you can use, there is always the ability to stream a game from your PC to your XeDK! Make sure your Xbox 360 Development Kit and the PC are on the same network!

Here is my tutorial for setting up Remote PC. I had some problems with it at first so hope this helps. Also note that the drive after hard reboot will show up under Neighborhood and you can launch executeables from there. You don't have to make a HDD but I recommend it for easy management and your xedk files won't take up space on your primary.











Converting Retail Games to Devkit


[*]Essential Hardware


Retail Xbox 360
- Xbox compatible HDD
- Any Hard drive transfer Hardware

Development kit Xbox 360
-Xbox Compatible HDD


[*]Software Essentials


SDK

X360FExT

X360GameHack

Xbox 360 Backup Creator

God2Iso

Xport360

Le Fluffie


[*]Converting your legal game disc to devkit (Proper)


Step 1
Save your game to the retail Xbox HDD

Step 2
Hook up your retail xbox HDD to your PC and open up Xport360
Browse through content -> 000000000000 till you find your game. Extract both the "folder".data and the file included with it

Step 3
Open up the file that is not the data folder in God2Iso, select your output folder and convert this may take a few minutes. After this is finished open up the newly created ISO with X360FExT and select extract all to a folder with the game name of the disc.

Step 4
Open up X360GameHack and only have "Make Devkit" checked, everything else needs to be unchecked. Click Fix, and receive this message at the bottom of X360GameHack "# Xex files were successfully patched". Close the program. Go to your game folder and delete "default.xex.org" and "$systemupdate".

Step 5 Using your SDK open up Game Disk Layout Editor. Go to File-> Add-> New rule and for source path browse to your game folder and click OK.
Now go to tools-> Create Image (it will ask if you want to save, select no).
Select Image for developing and testing and browse to where you want to save your ISO, name it what your game name is and click next and ignore anything about a xdb file.

Step 6 Convert the newly created ISO file with gdf2content in later builds of the SDK. Can be found at
C:\Program Files (x86)\Microsoft Xbox 360 SDK\bin\win32\gdf2content.exe (64 bit)
C:\Program Files\Microsoft Xbox 360 SDK\bin\win32\gdf2content.exe (32 bit)


[*]Converting your legal game disc to devkit (Improper)


Step 1
Save your game to the retail Xbox HDD

Step 2
Hook up your retail xbox HDD to your PC and open up Xport360
Browse through content -> 000000000000 till you find your game. Extract both the "folder".data and the file included with it

Step 3
Open up the file that is not the data folder in God2Iso, select your output folder and convert this may take a few minutes. After this is finished open up the newly created ISO with X360FExT and select extract all to a folder with the game name of the disc.

Step 4
Open up X360GameHack and click Fix. You will receive this message at the bottom of X360GameHack "# Xex files were successfully patched". Close the program.

Step 5
Copy your game folder to your USB stick/HDD and use the homebrew loader of your choice to launch the default.xex. Do note that you must never format this USB device for the Xbox 360 otherwise it can complicate this system, Homebrew loaders should be able to map your USB device just fine as is. You can also launch these xex's from your Devkit however newer games (AP2.5) will most likely not boot unless booted from external media through a homebrew loader.

Working Together


[*]Partnering up!


Port forward your router to 730 to your Devkit's debug IP Address and make sure to lock your Xbox 360 by right clicking it in neighborhood and clicking lock, set a password and only give it out to team mates you trust! They can now add your internet IP (http://www.whatsmyip.org/) to neighborhood and add it as a guest kit for you and your partner to better work together. Never unlock your kit until you remove your open port from your router otherwise outsiders who are aware of your Devkit and open port can access your kit freely and even execute Devkit XEX's of their choice on your kit!


[*]System Link


Ever needed to play with your buddies who also have Devkits but couldn't due to the dangers and banning on Partnernet? Now you can with an executable Anth0ny created. http://rapidshare.com/files/450838569/_Systemlink.rar
Open the package with winrar and extract it to somewhere on your devkit to be launched. Launch the Default.xex and it should return you back to the XNA Launcher (or what ever is set as your default dash) You must launch this XEX everytime your Devkit powers on it isn't permanent every power off will stop the Keychange that allows you to connect to Retails and JTAGs. JTAGs with Dashlaunch and Devkits with this XEX can host and join your game, however retails can only host. Go download Xlink kai and make sure you read the FAQs! This will allow you to use the systemlink option in games as a online service. Have fun.

More tutorials soon

 

Thanks for this guide
Chances are I'll be keeping my kit of the net, but still hooking it up to my local network (which has net access). I don't have a recovery disc so I'm just not creating any Live enabled profiles\accessing pnet. Would this be fine or does the kit announce it's presence as soon as it has an internet connection?

Halo 2 beta, I'm jealous now

 

While I (and I assume others) appreciate the effort you took to reproduce all this information, fear mongering shouldn't be used.

You could have presented the information in a purely neutral tone.

While most of the information has had a degree of research put into, and proven within the scene, at least one aspect stands out:

Is there any evidence, or research into this ?

I am also not convinced you should be telling people to create administrator accounts that would have known username/passwords. This could be the case if someone were to follow your tutorial step for step - line for line.

For example, it wouldn't be impossible for someone here to know your IP address (admins can see it right off the bat) - knowing you have an admin account set with xedk/xedk user/pass with full security on at least one drive + your dev kit itself is a massive risk.

What other tutorials do you have planned ?

 

This Deserves to be stickyed, its to late for me though my last kit got bricked :'(

 

awesome dude !!

 

Alot of very good safety measures here although I think backing up the nand with the lpt method gives less corruption From what I've read at other sites.

What's confusing me is the whole R6T3/U6T1/2 thing, which is better? And why?

 

Bridging is easier. All this is saying, that if first one is populated with that component try the following diagram.

You should also note that adding the bridge is the equivalent of the Chinese Anti ban. Yes it may even allow a kit destined for brick-age to access Pnet.

 

R6T3 removal just prevents fuses from being burned.

 

So I could do both then to be extra safe? :lol:

I know what it does, what I don't know is which is the better solution.

 

i wish i could go back in time and remove r6t3, i guess it wouldn't help i some how get the feeling m$ just remove the boot loader from the CPU as there is no way to fix that

 

1. I am not using fear tactic's those are suggestions all up the end user.

2. A development kit can be bricked without signing into a profile.

3. The Username/Password suggestion assumes that all users would have created their own, this poses no risk to the XeDK unless someone decides to replace one of your files in your remote folder with a malicious xex. This person would however need direct access to your network which is too far of a stretch to think someone would go through all that trouble. In the odd case this did happen however your write protection would block the attack. The files on your XeDK can't be accessed directly if thats what your saying unless you port forward your XeDK with its debug ip. The username/password was an example.

4.

As stated above the sharing folder doesn't affect anything on your physical development kit.

More tutorials will include basic usage of a kit and more for newer users.

 

thanks man, good info collected here

 

M$ can't change the CPU bootrom at all. The only thing they can do is burn fuses, which prevents low CB's/SB's from booting.

 

No thats backwards, the 360 reads itself directly from flash and dumps it to hard drive versus external connections held together with solder. Bad blocks are usually found with external readers, not so much usb but the middle man is still there you get the point.

 

Why would you suggest a live acquisition of the NAND is better than a non-live one ? AFAIK, that has never been the case with non-volatile storage.

I would have to agree with johnace, acquiring the NAND while the xbox is off (soft) is a much safer (regarding corruption) solution than otherwise.

There is also the issue that you have to actually boot the box to get to Flash360. The would leave you open to the possiblity of NAND change during boot/time before Flash360 launch.

 

When you write it back it should be no different then if you had just turned off the box and turned it back on. This is why its always good practice to remove the power cable after every fresh flash. Just as assembler stated beggars can't be choosers. You also need to take into account that in the very rare instance that a backup does go wrong (which has never happened to me in the history of using flash360 even back when I was testing it for redline) you need to take into account that a recovery disc is a fool proof way to recover from a partial brick, you just need enough of the flash to boot into it. Could you elaborate on any significant problems this could cause? In personal experience it hasn't caused me any trouble just wondering.

 

Can you edit your main post to not have 3 images on the same line? Makes the thread supppppppperrrrr wide.

:>

-Doom

 

thanks good info.

 

If i bridge u6t1/2 ,i still can do recovery ?