Currencies: USD_0 EUR_1 GBP_2 CAD_3 AUD_4 CNY_5 JPY_6 
Happy shopping with Dwtechz.com!  0 Items in Cart: US$0.00
Product Search:    R4i 3DS    R4I GOLD    Gateway 3DS    MT-card    Supercard DSTWO

X360Pro V4 Modchip for XBOX360

US$30.85

  • Model: DW-X360PRO-4
  • Shipping Weight: 0.15kg
  • 181 Units in Stock

FREE SHIPPING
Add to Cart:







Product Description

X360Pro (Fourth Generation ) Features:

Now, you can play your xbox on live and RGH homebrew on one console, don't worry to be ban.It is a dual nand solution for RGH consoles, allowing one NAND to be used for online play, and a seperate NAND to be used for RGH and thus running of homebrew etc, so effectively the best of both worlds.

Main Features:

  • NextGen Dual NAND Device
  • Easy Switch Between Stock Onboard NAND and Custom NAND by Extenal switch
  • No need to cut any tracks on the Xbox360 motherboard
  • Easy QSB Solution (Quick Solder Board)
  • Easy Wire Install Option Also Available(only 3 wires for slim/5 wires for phat)
  • Both Phat and Slim Versions
  • Compatible with any xbox360 with 16 MB NAND
  • Original Brand NAND to Match Stock For Security & Compatibility
  • Built-In USB, support MCU update no open your xbox and no others hardware
  • NAND Read/Write Hardware, quickly dump nand (Other SPI Hardware Not Required)
  • Compatible with Nandpro 2.0 and 3.0 software
  • Boot time almost in 5~30 seconds
  • More Premium Features Will Be Announced Very Soon……
 
  • Q: x360pro V4 some suggestions on some problems:
  • A:1. if it takes a long time to boot, you can improve it by adjusting the wire length of A line(12cm-18cm).
    2. under RGH, if you get into the following cases: it doesn't want to glitch(the blue light never flash) or the fan speeds up, you can only solve these problems by turning off the console and cut off the power, then connect the power and turn on it.

    If you have more problems, please send email here: support@x360pro.com. our engineers are there ready to help. it is much appreciated if you fixed your problems and share with our other users here. thanks in advance!
  • Q: which kind of X360 console the 4th generation support?
  • A:only support Trinity Slim console, not support X360 fat yet, We will release the firmware for X360 fat in a short term, please mantain your attention!
  • Q: The fats crack the principle?
  • A:On fats, the bootloader we glitch is CB, so we canrun the CD we want.
    cjak found that by asserting the CPU_PLL_BYPASSsignal, the CPU clock is slowed down a lot, there's a test point on themotherboard that's a fraction of CPU speed, it's 200Mhz when the dash runs,66.6Mhz when the console boots, and 520Khz when that signal is asserted.
    So it goes like that:
    - We assert CPU_PLL_BYPASS around POST code 36 (hex).
    - We wait for POST 39 start (POST 39 is the memcmp between stored hash and image hash), and start a counter.
    - When that counter has reached a precise value (it's often around 62% of entire POST 39 length), we send a 100ns pulse on CPU_RESET.
    - We wait some time and then we deassert CPU_PLL_BYPASS.
    - The cpu speed goes back to normal, and with a bit of luck, instead of getting POST error AD, the boot process continues and CB runs our custom CD.
    The NAND contains a zero-paired CB, our payload in acustom CD, and a modified SMC image. A glitch being unreliable by nature, weuse a modified SMC image that reboots infinitely (ie stock images reboot 5times and then go RROD) until the console has booted properly. In most cases,the glitch succeeds in less than 30 seconds from power on that way.
  • Q: the slims crack the principle
  • A: The bootloader we glitch is CB_A, so we can run theCB_B we want.
    On slims, we weren't able to find a motherboard trackfor CPU_PLL_BYPASS. Our first idea was to remove the 27Mhz master 360 crystaland generate our own clock instead but it was a difficult modification and itdidn't yield good results. We then looked for other ways to slow the CPU clockdown and found that the HANA chip had configurable PLL registers for the 100Mhzclock that feeds CPU and GPU differential pairs. Apparently those registers arewritten by the SMC through an I2C bus. I2C bus can be freely accessed, it'seven available on a header (J2C3). So the HANA chip will now become our weaponof choice to slow the CPU down (sorry tmbinc, you can't always be right, itisn't boring and it does sit on an interesting bus
    So it goes like that:
    - We send an i2c command to the HANA to slow down the CPU at POST code D8 .
    - We wait for POST DA start (POST DA is the memcmp between stored hash and image hash), and start a counter.
    - When that counter has reached a precise value, we send a 20ns pulse on CPU_RESET.
    - We wait some time and then we send an i2c command to the HANA to restore regular CPU clock.
    - The cpu speed goes back to normal, and with a bit of luck, instead of getting POST error F2, the boot process continues and CB_A runs our custom CB_B.
    When CB_B starts, DRAM isn't initialised so we choseto only apply a few patches to it so that it can run any CD, the patches are:
    - Always activate zero-paired mode, so that we can use a modified SMC image.
    - Don't decrypt CD, instead expect a plaintext CD in NAND.
    - Don't stop the boot process if CD hash isn't good.
    CB_B is RC4 crypted, the key comes from the CPU key,so how do we patch CB_B without knowing the CPU key? RC4 is basically:
    - crypted = plaintext xor pseudo-random-keystream
    So if we know plaintext and crypted, we can get thekeystream, and with the keystream, we can encrypt our own code. It goes likethat:
    - guessed-pseudo-random-keystream = crypted xor plaintext
    - new-crypted = guessed-pseudo-random-keystream xor plaintext-patch
    You could think there's a chicken and egg problem,how did we get plaintext in the first place? Easy: we had plaintext CBs fromfat consoles, and we thought the first few bytes of code would be the same asthe new CB_B, so we could encrypt a tiny piece of code to dump the CPU key anddecrypt CB_B!
    The NAND contains CB_A, a patched CB_B, our payloadin a custom plaintext CD, and a modified SMC image. The SMC image is modifiedto have infinite reboot, and to prevent it from periodically sending I2Ccommands while we send ours.
    Now, maybe you haven't realised yet, but CB_Acontains no checks on revocation fuses, so it's an unpatchable hack !
  • Q: The reset glitch in a few words?
  • A: We found that by sending a tiny reset pulse to the processor while it is slowed down does not reset it but instead changes the way the code runs, it seems it's very efficient at making bootloaders memcmp functions always return "no differences". memcmp is often used to check the next bootloader SHA hash against a stored one, allowing it to run if they are the same. So we can put a bootloader that would fail hash check in NAND, glitch the previous one and that bootloader will run, allowing almost any code to run.
  • Q: Details for the slim hack?
  • A: The bootloader we glitch is CB_A, so we can run the CB_B we want.

    On slims, we weren't able to find a motherboard track for CPU_PLL_BYPASS.
    Our first idea was to remove the 27Mhz master 360 crystal and generate our own clock instead but it was a difficult modification and it didn't yield good results.
    We then looked for other ways to slow the CPU clock down and found that the HANA chip had configurable PLL registers for the 100Mhz clock that feeds CPU and GPU differential pairs.
    Apparently those registers are written by the SMC through an I2C bus.
    I2C bus can be freely accessed, it's even available on a header (J2C3).
    So the HANA chip will now become our weapon of choice to slow the CPU down (sorry tmbinc, you can't always be right, it isn't boring and it does sit on an interesting bus ;)

    So it goes like that:
    - We send an i2c command to the HANA to slow down the CPU at POST code D8 .
    - We wait for POST DA start (POST DA is the memcmp between stored hash and image hash), and start a counter.
    - When that counter has reached a precise value, we send a 20ns pulse on CPU_RESET.
    - We wait some time and then we send an i2c command to the HANA to restore regular CPU clock.
    - The cpu speed goes back to normal, and with a bit of luck, instead of getting POST error F2, the boot process continues and CB_A runs our custom CB_B.

    When CB_B starts, DRAM isn't initialised so we chose to only apply a few patches to it so that it can run any CD, the patches are:
    - Always activate zero-paired mode, so that we can use a modified SMC image.
    - Don't decrypt CD, instead expect a plaintext CD in NAND.
    - Don't stop the boot process if CD hash isn't good.

    CB_B is RC4 crypted, the key comes from the CPU key, so how do we patch CB_B without knowing the CPU key?
    RC4 is basically:
    crypted = plaintext xor pseudo-random-keystream
    So if we know plaintext and crypted, we can get the keystream, and with the keystream, we can encrypt our own code. It goes like that:
    guessed-pseudo-random-keystream = crypted xor plaintext
    new-crypted = guessed-pseudo-random-keystream xor plaintext-patch
    You could think there's a chicken and egg problem, how did we get plaintext in the first place?
    Easy: we had plaintext CBs from fat consoles, and we thought the first few bytes of code would be the same as the new CB_B, so we could encrypt a tiny piece of code to dump the CPU key and decrypt CB_B!

    The NAND contains CB_A, a patched CB_B, our payload in a custom plaintext CD, and a modified SMC image.
    The SMC image is modified to have infinite reboot, and to prevent it from periodically sending I2C commands while we send ours.

    Now, maybe you haven't realised yet, but CB_A contains no checks on revocation fuses, so it's an unpatchable hack !



Related News