Jump to content
RealModScene
Sign in to follow this  
cory1492

XeBuild 1.11

Recommended Posts

xeBuild 1.11============Introduction:=============    xeBuild is a command line system image builder for JTAG, glitch, and clean images.    Run the xeBuild program with no (or incorrect) arguments to see it's usage info.What's New:===========    - minor bug fixesCurrent Limitations:====================    - STAY THE HELL OFF LIVE! Nuff said, we're not you're mum.How To Use:===========    - See individual folders for lists of files to provide    - if desired provide replacement cpu and 1bl keys in text files    - open a command window in the xeBuild directory    - on the command line type, for example:    example - if you provided keys in appropriate text files        xeBuild.exe -t glitch -c falcon -d myfalcon myfalconout.bin        -t glitch = build a glitch type image        -c falcon = use falcon bl and patch set        -d myfalcon = a folder is present called "myfalcon" with per machine files, this uses it        myfalconout.bin = the file that will be produced    - type 'xeBuild.exe -?', 'xebuild client -?' or 'xebuild update -?' for command line infoUpdate and Client modes:========================    Both modes require the supported updsvr running on the xbox, full functionality may require    updating console patches with the included hv patches. Both the PC and the xbox need to be on    the same subnet/LAN router.        Client mode is a simple way to read, write and patch flash as well as few other simple commands    such as the patch updater. The patch updater will look in the folders beside the exe for    {version#}binpatches_{type}.bin    which are full patches for whichever console and hack type, it will load and strip the patches    if needed and send them to the console. Note that only xebuild images are truly supported for this.    Most of the client mode commands should be available on any console, even unhacked devkits. See output    from 'xebuild client -?' for more information on the options available.    Update mode attempts to retain as much data about the console as possible, without having to    provide any info on the command line aside from optional/addon patches if required. After you    copy the $SystemUpdate folder into (in this example) the folder 16203 it is capable of taking    a simple command line like:    xebuild update -f 16203 -a nohdmiwait    It will fetch all the info from the console, and use the updater to update both the system flash    and avatar data on the console (provided you have an 360 formatted HDD internally in the console.)    It has some more advanced options to allow one to build the update image as well as dump the data    from the console as it's acquired, while even leaving the console data untouched. See output    from 'xebuild update -?' for more information on the options available.        Neither update or client image writes are able to affect bad blocks, but are able to write new ones.    If this happens mistakenly, an erase block command has been provided in client that will attempt to    clear the bad block - use with caution though, blocks get marked as bad for good reasons and is a normal    occurrence on NAND when a block becomes unreliable.        With big block machines, the server will attempt to retain any NAND mu data in the system area, provided    there is no system data to write in the image being sent. It's not foolproof, but update mode should not    corrupt NAND mu.Example:========    -take original console dump, put it in mytrinity folder as NANDdump.bin    -set CPU key and 1BL key in ini file, verify LDV from NANDdump.bin matches console fuses      if not set cfldv in ini file    -build (xeBuild.exe -t glitch -d mytrinity -f 13599), flash and hopefully life is good.ini files:===========    Just a word on the format... the ini parser is not very robust, the files need    to be plain ASCII, everything after a ; on a line is ignored, and spaces are    not acceptable (they get removed).    Things like CPU key and 1BL key, if present in the per box ini file need not be    placed anywhere else.Optional Patches:=================    Various optional patches are included for use with the -a option, they are:    nofcrt     - removes fcrt.bin requirement on some drives    nohdd      - disables detection of internal SATA HDD    nohdmiwait - HDMI consoles will no longer wait or EXX screen when video is not ready    nolan      - disables wired LAN to prevent E75/76/77 on machines with a damaged PHY    nointmu    - disables jasper NANDmu, trinity 4G internal USB and corona 4G MMC memory unitsblmod.bin:==========    Changing the patches to the BL that follows the BL that is executing during glitch attempts    has a direct effect on whether a machine will glitch. The provided patches are generic    and work well on most machines, but this per machine build addon can now be supplied without    modifying the base patches to CBB or CD via a file in the perbuild folder, they will simply be    tacked onto the end of CBB or CD, and the BL size adjusted to include this new data in the hash.    Keep in mind, it can take multiple attempts and re-flashing with different binary data to find    something that will boot at all, let alone be more effective for your console.        blmod is currently not supported by update mode.Note:=====    - DON'T USE THIS UNLESS YOU KNOW FOR SURE THAT YOU NEED IT! Using an incorrect    controller config can result in problems remapping bad blocks (even manually.)    If you have a 16M jasper, an additional build type has been added    'jaspersb', by default the image will be built for jasper with big block    controller (config 00023010), use this alternate switch to build for small    block controller (config 01198010.)Multi build/options example:============================    when you specify -f 13599 on the command line:        13599filelist.ini    is parsed instead of datafilelist.ini    Also the bin directory is used from        13599bin    instead of        bin    allowing anyone to create multiple builds without multiple instances or    rebuilds/hex edits/hacks of the main app.    The example provided is the last version of 13599 patch set from dash launch and        other files to build freeboot 13599    example use:    ------------    xeBuild -f 13599 -d myfalcon x13599out.bin    -f 13599     : use .13599filelist.ini, and .13599 for firmware files, .13599bin for patches    -d myfalcon  : use .myfalcon for per build files (cpu key, keyvault, security files, ini etc.)    x13599out.bin: override auto generated name and produce .x13599out.bin as the final NAND image    note, if -d ***** is not specified it will still use the original /data and /bin dirsDevkit image building:======================    This feature is currently considered Beta/Work In Progress.    A new image target type was added, "-t devkit" which builds 64M flash images for devkits. Currently untested,    building with a 00 filled CPU key will create a zeropaired devkit image that may allow one to boot a software    bricked devkit that one does not know the CPU key for and recover it to an operational state. By powering on    the console with such an image present, with a recovery DVD in the drive, the recovery software should be able    to create a new keyvault, re-pair the DVD drive to the new keyvault, and allow normal operation once complete.        Normal devkit image building when one does know their CPU key and thus has security files and keyvault should    work as expected.        Building devkit for glitch/jtag is also possible using the standard -t glitch/jtag methods. Sample ini    have been provided with this release, but will not work unless patches and files are supplied. Note that devkit    is not our focus, but was relatively easy and straight forward option to supply for those that wish to make    use of it.jasperbigffs:=============    Those who use large block NAND are now able to nearly double the size of the system file area    with this option with no apparent ill effects. Normally this option wouldn't be needed, but if one    wanted to experiment with more files in flash, or one was building a devkit image for a devkit with    a big block flash, this option is required.support:========    If you've found a bug or have a suggestion, please comment at    http://www.realmodscene.com/index.php?/forum/15-xebuild/ (English)    http://homebrew-connection.org/forum/index.php?board=8.0 (English/French)Credits:========    Without ikari this would not have been possible, thanks!          __               ____   ___   ___ _____         / _|_ __ ___  ___| __ ) / _  / _ _   _|        | |_| '__/ _ / _   _ | | | | | | || |        |  _| | |  __/  __/ |_) | |_| | |_| || |        |_| |_|  ___|___|____/ ___/ ___/ |_|                     [v0.10 - inspired by ikari]        R.I.P.    No this isn't freeboot, it is a clone and has always been since the last    release of ibuild.    Thanks and greetz to everyone who has contributed to hacking this    wonderful machine. Thanks to the engineers and countless others who made    the machine what it is... we only wish they had listened and RROD was    not a problem. If we were to list everyone here, there would be no time    left to play on the machine!    Thanks Team Xecuter for the Corona 4G! Thanks to JuggaHax, dayton360mods,    glitch360team and all other contributors for helping find a way to make Corona 4G golden!    Thanks to Free60, LibXenon.org, Redline99 and Tuxuser for providing xell builds <3    Thanks to Swizzy for making the official GUI front end for xeBuild, for always    adding the new stuff we shovel at him and never once complaining.        Big thanks to the folks at #freeboot on efnet for the tireless    hours of help you all give freely. Thanks to the testers who tirelessly    made sure stuff worked. Thanks to rgloader for doing the work yourselves,    there *is* no spoon, just a glitch in the matrix.    Don't believe what random people *cough* write on forums ..-----//2014-----Changes:========1.11- fix a bug which caused an infinite loop when a mobile*.dat was smaller than 512 bytes - Foo you too mobileE.dat! (thanks blakcat!)

xeBuild_1.11.zip

  • Like 5

Share this post


Link to post
Share on other sites

Thanks for the new release! However I am getting the following error on both 1.10 and 1.11 release

Any advise would be appreciated*

 

*****could not read cba_9188.bin  (-1) *****

*******ERROR : critical bootloader files are missing, cannot proceed! *************

********FATAL UPDATE ERROR ; -1 unable to complete NAND image

 

I am connected to the update server and Dashlaunch (3.11[541]) is running on xbox

Flash: Trinity 

Type: Glitch 2

Share this post


Link to post
Share on other sites

Read the tutorial...

Why does nobody do that??

it cannot find "cba_9188.bin" because you didn't include it... it's not part of the xeBuild package... never has, never will...

you can download this package and run xebuild from there instead: http://www.homebrew-connection.org/files/xbox/nand_builder/xeBuild_GUI/dl_xeBuild_GUI_2.092.rar

Share this post


Link to post
Share on other sites

Thanks for all this good stuff :-). Works great.I've got one question. Why 1BLkey was changed from DD88AD0C9ED669E7B56794FB68563EFA  to  dummy DVD key ?? (8CFC1DFDCF5C37A52AE427C397A45363)Worked very well for me with old one :-)EDIT: Actually i have one more question.If I have Xbox Slim with Trinity MB and first revison of CoolRuner from TX (I think it's rev. A) is it important to choose between glitch and glitch2 ??I mean, should I use this:xeBuild.exe -t glitch -d mydata -f 16547  nandflash.binor that:xeBuild.exe -t glitch2 -d mydata -f 16547  nandflash.binI was always using "-t glitch" but i tried your updateserver solotioun on xeBuild v1.09 and it changed my hack type in DL to Glitch v2.EDIT2: Hah, When I used -t glitch instead of -t glitch2 it downgraded my kernel to 16203 LOL :-)So -glitch2 is what I should use from now on.EDIT3: I'm confused now. When I'm using xeBuild "-t glitch2" seems to work for me, but when I'm using xeBuild GUI Parameter sent to xeBuild is -t glitchSo why when I tried to use -t glich on normal xeBuild it actually downgraded my dash to 16203 ??

Plese someone explain me that.

 

EDIT4: One more thing. When I'm building Image i get this in log:"could not check signature of cba_9188.bin, 1BL RSA key not present!"But when I use Update server i get this:"cba_9188.bin signature is good"Is it important? Does it mean my NAND image is builded wrong?P.s. I have modified Keyvault. 

Share this post


Link to post
Share on other sites

Dunno why your configuration build a 16203 when using -t glitch (makes zero sense!!!) but... for trinity it makes no difference if you select -t glitch or -t glitch2 as both have the same output for trinity...

about the cba_9188 1bl rsa key thingy doesn't matter, it's a security thing that was added, it's not required for building images, but if you're not sure that the data is actually untouched, then it's useful to have ;)

About 1bl key... it's always been that way in the standard configuration, to make it legal to release, that is also why there is no bootloaders included etc... (they contain copyrighted code!)

  • Like 1

Share this post


Link to post
Share on other sites

OK. This clears things up. Thanks for reply.About that downgrade to 16203, weird, right? But it's true.

I was really suprised when i saw 16203 as my new kernel version (I was on 16537 before update). I didn't provide any 16203 files so it was strange.Anyway, -t glitch2 works very well so I'm happy :-).Thanks again. Cheers :-)

Share this post


Link to post
Share on other sites

Great release , thank you to the xeBuild team and all involved in this programs continued support, please know there are a great many of us that truly appreciate all the effort put in to make this program what it is today :thumbsup:

Share this post


Link to post
Share on other sites

Hi, this is excellent!! i did rgh my xbox 360.. at the startup mostly take much time to boot... i read about the CPU-RST wire.... i read to the optional patch of xebuild "nohdmiwait" too... this could help me with my problem??? or just the long of the wire?? sorry for my english...

 

Hola esto esta exelente, recientemente le hice hacer RGH a mi consola, funciona bien pero casi siempre demora mucho en arrancar... lei que es el largo del cabre CPU-RST... aunque tambien lei el opcional "nohdmiwait" del xebuild.... podra esto ultimo ayudarme con la demora en el arranque? o es solo que tengo que hacer revisar el largo del cable CPU-RST? gracias!!!!!

Share this post


Link to post
Share on other sites

nohdmiwait is only useful for when your console don't boot at all, basically when it gets stuck after final glitch... (and only if you are connected with HDMI) the cause is the HDMI Handshake for HDCP

Share this post


Link to post
Share on other sites

nohdmiwait is only useful for when your console don't boot at all, basically when it gets stuck after final glitch... (and only if you are connected with HDMI) the cause is the HDMI Handshake for HDCP

thanks, that means the problem for the time booting is cpu-rst wire?.... somtimes boots faster with tv off....

thanks again.

Share this post


Link to post
Share on other sites

thanks, that means the problem for the time booting is cpu-rst wire?.... somtimes boots faster with tv off....

 

The CPU_RST wire will affect glitch times, but this patch takes effect after the console has glitched (when no handshake has taken place between your display and the console).

 

The patch simply allows your console to boot without waiting for the "HDCP" signal from the display.

 

This means your console will boot up with the display off or with the HDMI cable disconnected from the console.

 

I don't use the patch because I don't need it, but it would be useful in a situation where your display does not "handshake" properly (if at all) with the console.

Share this post


Link to post
Share on other sites

thanks, that means the problem for the time booting is cpu-rst wire?.... somtimes boots faster with tv off....thanks again.

cpu_rst, post_out, i2c_sda and i2c_scl can all effect the glitch timings... also the chip you're using, the position of the chip, the timing files you've used, the patches also play a role in the glitch timing success... there is a feature that was added in iirc the previous version of xeBuild (1.09) which allows you to fine-tune using bootloader modifications (add random or specific data to make the bootloader take a different time to load/process causing it to be closer to the timing range which everything else is causing)there is no "do this and you'll have perfect glitches" thing to do, all you have is tips on how ppl have done installs that worked for them, each install is unique, the details tend to be difficult to spot (very small differences can have a huge impact on the timing) basically what you have to do is place the chip and wires mostly like others and try your way around that...

Share this post


Link to post
Share on other sites

cpu_rst, post_out, i2c_sda and i2c_scl can all effect the glitch timings... also the chip you're using, the position of the chip, the timing files you've used, the patches also play a role in the glitch timing success... there is a feature that was added in iirc the previous version of xeBuild (1.09) which allows you to fine-tune using bootloader modifications (add random or specific data to make the bootloader take a different time to load/process causing it to be closer to the timing range which everything else is causing)there is no "do this and you'll have perfect glitches" thing to do, all you have is tips on how ppl have done installs that worked for them, each install is unique, the details tend to be difficult to spot (very small differences can have a huge impact on the timing) basically what you have to do is place the chip and wires mostly like others and try your way around that...

Swizzy - BL4K3Y, thanks for the time to explain all this to me, i will take your tips!!!

 

The CPU_RST wire will affect glitch times, but this patch takes effect after the console has glitched (when no handshake has taken place between your display and the console).

 

The patch simply allows your console to boot without waiting for the "HDCP" signal from the display.

 

This means your console will boot up with the display off or with the HDMI cable disconnected from the console.

 

I don't use the patch because I don't need it, but it would be useful in a situation where your display does not "handshake" properly (if at all) with the console.

Share this post


Link to post
Share on other sites

Is it possible to apply nohdmiwait after nand flash ? i mean without re-flashing the whole thing over again :S

Share this post


Link to post
Share on other sites

Is it possible to apply nohdmiwait after nand flash ? i mean without re-flashing the whole thing over again :S

Well, technically... yes... but... there is no tool to do that... so, the short answer is; no...

Share this post


Link to post
Share on other sites
xeBuild 1.11============Introduction:=============    xeBuild is a command line system image builder for JTAG, glitch, and clean images.    Run the xeBuild program with no (or incorrect) arguments to see it's usage info.What's New:===========    - minor bug fixesCurrent Limitations:====================    - STAY THE HELL OFF LIVE! Nuff said, we're not you're mum.How To Use:===========    - See individual folders for lists of files to provide    - if desired provide replacement cpu and 1bl keys in text files    - open a command window in the xeBuild directory    - on the command line type, for example:    example - if you provided keys in appropriate text files        xeBuild.exe -t glitch -c falcon -d myfalcon myfalconout.bin        -t glitch = build a glitch type image        -c falcon = use falcon bl and patch set        -d myfalcon = a folder is present called "myfalcon" with per machine files, this uses it        myfalconout.bin = the file that will be produced    - type 'xeBuild.exe -?', 'xebuild client -?' or 'xebuild update -?' for command line infoUpdate and Client modes:========================    Both modes require the supported updsvr running on the xbox, full functionality may require    updating console patches with the included hv patches. Both the PC and the xbox need to be on    the same subnet/LAN router.        Client mode is a simple way to read, write and patch flash as well as few other simple commands    such as the patch updater. The patch updater will look in the folders beside the exe for    {version#}binpatches_{type}.bin    which are full patches for whichever console and hack type, it will load and strip the patches    if needed and send them to the console. Note that only xebuild images are truly supported for this.    Most of the client mode commands should be available on any console, even unhacked devkits. See output    from 'xebuild client -?' for more information on the options available.    Update mode attempts to retain as much data about the console as possible, without having to    provide any info on the command line aside from optional/addon patches if required. After you    copy the $SystemUpdate folder into (in this example) the folder 16203 it is capable of taking    a simple command line like:    xebuild update -f 16203 -a nohdmiwait    It will fetch all the info from the console, and use the updater to update both the system flash    and avatar data on the console (provided you have an 360 formatted HDD internally in the console.)    It has some more advanced options to allow one to build the update image as well as dump the data    from the console as it's acquired, while even leaving the console data untouched. See output    from 'xebuild update -?' for more information on the options available.        Neither update or client image writes are able to affect bad blocks, but are able to write new ones.    If this happens mistakenly, an erase block command has been provided in client that will attempt to    clear the bad block - use with caution though, blocks get marked as bad for good reasons and is a normal    occurrence on NAND when a block becomes unreliable.        With big block machines, the server will attempt to retain any NAND mu data in the system area, provided    there is no system data to write in the image being sent. It's not foolproof, but update mode should not    corrupt NAND mu.Example:========    -take original console dump, put it in mytrinity folder as NANDdump.bin    -set CPU key and 1BL key in ini file, verify LDV from NANDdump.bin matches console fuses      if not set cfldv in ini file    -build (xeBuild.exe -t glitch -d mytrinity -f 13599), flash and hopefully life is good.ini files:===========    Just a word on the format... the ini parser is not very robust, the files need    to be plain ASCII, everything after a ; on a line is ignored, and spaces are    not acceptable (they get removed).    Things like CPU key and 1BL key, if present in the per box ini file need not be    placed anywhere else.Optional Patches:=================    Various optional patches are included for use with the -a option, they are:    nofcrt     - removes fcrt.bin requirement on some drives    nohdd      - disables detection of internal SATA HDD    nohdmiwait - HDMI consoles will no longer wait or EXX screen when video is not ready    nolan      - disables wired LAN to prevent E75/76/77 on machines with a damaged PHY    nointmu    - disables jasper NANDmu, trinity 4G internal USB and corona 4G MMC memory unitsblmod.bin:==========    Changing the patches to the BL that follows the BL that is executing during glitch attempts    has a direct effect on whether a machine will glitch. The provided patches are generic    and work well on most machines, but this per machine build addon can now be supplied without    modifying the base patches to CBB or CD via a file in the perbuild folder, they will simply be    tacked onto the end of CBB or CD, and the BL size adjusted to include this new data in the hash.    Keep in mind, it can take multiple attempts and re-flashing with different binary data to find    something that will boot at all, let alone be more effective for your console.        blmod is currently not supported by update mode.Note:=====    - DON'T USE THIS UNLESS YOU KNOW FOR SURE THAT YOU NEED IT! Using an incorrect    controller config can result in problems remapping bad blocks (even manually.)    If you have a 16M jasper, an additional build type has been added    'jaspersb', by default the image will be built for jasper with big block    controller (config 00023010), use this alternate switch to build for small    block controller (config 01198010.)Multi build/options example:============================    when you specify -f 13599 on the command line:        13599filelist.ini    is parsed instead of datafilelist.ini    Also the bin directory is used from        13599bin    instead of        bin    allowing anyone to create multiple builds without multiple instances or    rebuilds/hex edits/hacks of the main app.    The example provided is the last version of 13599 patch set from dash launch and        other files to build freeboot 13599    example use:    ------------    xeBuild -f 13599 -d myfalcon x13599out.bin    -f 13599     : use .13599filelist.ini, and .13599 for firmware files, .13599bin for patches    -d myfalcon  : use .myfalcon for per build files (cpu key, keyvault, security files, ini etc.)    x13599out.bin: override auto generated name and produce .x13599out.bin as the final NAND image    note, if -d ***** is not specified it will still use the original /data and /bin dirsDevkit image building:======================    This feature is currently considered Beta/Work In Progress.    A new image target type was added, "-t devkit" which builds 64M flash images for devkits. Currently untested,    building with a 00 filled CPU key will create a zeropaired devkit image that may allow one to boot a software    bricked devkit that one does not know the CPU key for and recover it to an operational state. By powering on    the console with such an image present, with a recovery DVD in the drive, the recovery software should be able    to create a new keyvault, re-pair the DVD drive to the new keyvault, and allow normal operation once complete.        Normal devkit image building when one does know their CPU key and thus has security files and keyvault should    work as expected.        Building devkit for glitch/jtag is also possible using the standard -t glitch/jtag methods. Sample ini    have been provided with this release, but will not work unless patches and files are supplied. Note that devkit    is not our focus, but was relatively easy and straight forward option to supply for those that wish to make    use of it.jasperbigffs:=============    Those who use large block NAND are now able to nearly double the size of the system file area    with this option with no apparent ill effects. Normally this option wouldn't be needed, but if one    wanted to experiment with more files in flash, or one was building a devkit image for a devkit with    a big block flash, this option is required.support:========    If you've found a bug or have a suggestion, please comment at    http://www.realmodscene.com/index.php?/forum/15-xebuild/ (English)    http://homebrew-connection.org/forum/index.php?board=8.0 (English/French)Credits:========    Without ikari this would not have been possible, thanks!          __               ____   ___   ___ _____         / _|_ __ ___  ___| __ ) / _  / _ _   _|        | |_| '__/ _ / _   _ | | | | | | || |        |  _| | |  __/  __/ |_) | |_| | |_| || |        |_| |_|  ___|___|____/ ___/ ___/ |_|                     [v0.10 - inspired by ikari]        R.I.P.    No this isn't freeboot, it is a clone and has always been since the last    release of ibuild.    Thanks and greetz to everyone who has contributed to hacking this    wonderful machine. Thanks to the engineers and countless others who made    the machine what it is... we only wish they had listened and RROD was    not a problem. If we were to list everyone here, there would be no time    left to play on the machine!    Thanks Team Xecuter for the Corona 4G! Thanks to JuggaHax, dayton360mods,    glitch360team and all other contributors for helping find a way to make Corona 4G golden!    Thanks to Free60, LibXenon.org, Redline99 and Tuxuser for providing xell builds <3    Thanks to Swizzy for making the official GUI front end for xeBuild, for always    adding the new stuff we shovel at him and never once complaining.        Big thanks to the folks at #freeboot on efnet for the tireless    hours of help you all give freely. Thanks to the testers who tirelessly    made sure stuff worked. Thanks to rgloader for doing the work yourselves,    there *is* no spoon, just a glitch in the matrix.    Don't believe what random people *cough* write on forums ..-----//2014-----Changes:========1.11- fix a bug which caused an infinite loop when a mobile*.dat was smaller than 512 bytes - Foo you too mobileE.dat! (thanks blakcat!)

thank

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
Sign in to follow this  

×
×
  • Create New...