Xebuild 1.20 mit Dash 17544 Support

xeBuild 1.20
============




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:
===========
    - bug fixes
	- add 17502
    - !experimental! g2 and g2m patches based on 13182 CBB for coronas using winbond memory
      patch set for corona hardware issues that require 13182, use -r WB or -r WB4G on command line to select when building corona images
      thanks to 15432 and DrSchottky for doing the heavy lifting for corona winbond patches
      original release can be found http://www.hackfaq.net/main/xell_wb2k/
      Mileage may vary, though it's possible these can also improve boot times of older corona models and possibly even some trinity machines (use trinity smc).
      Also, it's unlikely vfuses will work fully on machines that have vfuse errors as mfg CBB patches never load them from NAND (CD onwards do still.)
      Big thanks also to Team Xecuter for first bringing this problem to our attention, and working out and testing the solution that proved it by successfully booting xell


Current 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 info


Update 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#}\bin\patches_{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
    noSShdd    - disables internal SATA HDD with valid retail security sector
    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 units
    nowifi     - disables usb wifi adapters including the ones built into 360S/E


blmod.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:
        13599\filelist.ini
    is parsed instead of data\filelist.ini


    Also the bin directory is used from
        13599\bin\
    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 .\13599\filelist.ini, and .\13599\ for firmware files, .\13599\bin\ 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 dirs


Devkit 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.


[rawpatch]:
===========
    It is now possible to force a raw patch of NAND image via files and offset both through the command line
    and via the data directory ini files. This causes a file to be read and byte copied into the raw flash image
    before spare ecd/ecc is calculated at the supplied offset in flash (without spare).

    Note that both the ini entries and the command line will interpret the offset as decimal if not preceded by '0x'.
    There will be no spare marks or file system entries created for such raw patches, it is user beware and up to
    anyone who needs this to ensure the data is being placed somewhere safe.

    No example is given in the supplied ini files, the segment can be placed anywhere above [flashfs] and would
    look something like this:
[rawpatch]
somefile.ext,0x123456; this offset is interpreted as hexadecimal
somefile2.bin,123456; this offset is interpreted as decimal




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 ..


-----
//2018
-----


Changes:
========
1.20
- add 17544