XeBuild 1.08 with new update feature

Xecuter

Staff member
Top TX Brass
Dec 6, 2002
11,465
128
Asia
team-xecuter.com
XeBuild 1.08

Introduction:
xeBuild is a command line system image builder for JTAG, glitch, and clean images.
Run the xeBuild program with no (or incorrect) args to see it's usage info.

What's New:

  • new boot chain and patches for trinity/corona that uses virtual efuses from CBB onward
  • added ability to fine tune content of the BL that glitching targets
  • new nolan addon patch for machines with bad wired LAN phy (boots to E75/76/77)
  • single addon provided to disable all internal memory units on arcade consoles
  • added client and update modes
  • minor bug fixes

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
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 interal USB and corona 4G mmc memory units

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

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-conn...x.php?board=8.0 (english/french)

Credits:
Without ikari this would not have been possible, thanks!

[v0.09 - 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 ******.

Don't believe what random people *cough* write on forums ..

Changes:
1.08

  • align patch slots properly on glitch images
  • add ability to make zero-paired dual cb images (retail/glitch)
  • unknown devkit smcs were not being checked properly and always reported hacked
  • added support for 'blmod.bin' per-build file, can assist fine tuning glitch machines that don't play well with standard patches
  • added CPU key corruption checks
  • added a secondary check on naddump.bin size after determining big block/small block
  • added new build target, glitch2m, which uses mfg cba to boot (currently only trinity/corona 16203 provided) with virtual fuses
  • added nolan addon patch for 16197+ for those with bad wired lan phy getting E75/76/77; should not affect wireless dongles
  • consolidate internal memory unit disable patches into nointmu addon, Corona 4G internal memory can now be disabled (16197+)
  • added integrity checks for: blocks that appear to be remapped but are outside the remap area; CF slot size
  • updated all patch sets to use hv built in memcpy (better peek support for things that require 64bit reads like 1bl ROM)
  • check for SU container in version\$SystemUpdate subfolder as well as version folder
  • nonces will attempt to be kept when providing NANDdump.bin (some claim this affects glitch boot times, makes differential flashing more effective)
  • Xstress.settings has been renamed to Manufacturing.data
  • update jtag freeboot core to V0.9 - use options stored in flash header instead of patched directly into the binary
  • added update and client mode
  • -d options no longer need to be relative to the exe launch path
  • checks keyvault signature (if present) when MAST_pub.bin is available from update server or file in .\ or .\common\
  • checks CB/CBA signature when 1BL_pub.bin is available from update server or file in .\ or .\common\
  • updated xell builds to XeLL_Reloaded-2stages-v0.993

[video=youtube;UL9rrDXfhCU]http://www.youtube.com/watch?v=UL9rrDXfhCU[/video]

Source: The Real Mod Scene
 

Attachments

ZerOneX

Full Member
Sep 20, 2011
56
8
Hi there, anyone has more inputs about this new mode glitch2m?

Thanks in advance.

Regards,

ZerO.
 

ZerOneX

Full Member
Sep 20, 2011
56
8
I would like to understand what is it.. the diff btw glitch2 and glitch2m... just reading the txt I couldn't get yet.

Most of users are reading it and letting it be... but I can't :D

Thank you
 
Last edited:

Antalpromille

VIP Member
Aug 4, 2011
3,165
0
Borås, sweden
its for slims with damaged efuses/cpukey and glitch2 doesnt work
creates virtual efuses afaik
Nice to know, and i just knew there was only a matter of time before i got the answer without asking the question :)
 
V

VampireSwizzy

I would like to understand what is it.. the diff btw glitch2 and glitch2m... just reading the txt I couldn't get yet.

Most of users are reading it and letting it be... but I can't :D

Thank you
Like stefanounick said it's for consoles with broken efuses where the cpukey got mangled and normal glitch2 don't work... a little more details about it:

It uses the leaked MFG bootloader patched to use virtual fuses (like JTAG) which would make these consoles work fine once more...
 

BL4K3Y

VIP Member
Jul 7, 2010
12,843
118
Colne, Lancashire (UK)
Like stefanounick said it's for consoles with broken efuses where the cpukey got mangled and normal glitch2 don't work... a little more details about it:

It uses the leaked MFG bootloader patched to use virtual fuses (like JTAG) which would make these consoles work fine once more...
It would also have a random/blank CPU key as well wouldn't it?

Nitram (from IRC) told me a little bit about it before.
 
  • Like
Reactions: ZerOneX
V

VampireSwizzy

It would also have a random/blank CPU key as well wouldn't it?

Nitram (from IRC) told me a little bit about it before.
You still have to supply a cpukey, they are validated by xebuild now a days, afaik it doesn't just make a random one... i have a tool to generate random valid cpukey's :)

** edit: **

https://dl.dropboxusercontent.com/u/43280539/betareleases/Alpha/CPUKeyGenerator.rar <--- here you go, it also validates keys that you put there ;)

** edit2: **

I've removed the file ^ now, it's no longer available unless you know where to find my private server...
 
Last edited:

ZerOneX

Full Member
Sep 20, 2011
56
8
OWW, just awesome guys... apart from that it would be possible to use it on my dual boot console to make it even safer!! Am I right?
 
V

VampireSwizzy

OWW, just awesome guys... apart from that it would be possible to use it on my dual boot console to make it even safer!! Am I right?
How so? it's not going to change anything with live... it's simply fixing consoles with f*cked up fuses by using virtual fuses...

If you are concerned about safety use 2 machines... that's how normal ppl do it ;) there is no safer way to be playing on Xbox Live and having a hacked machine, nobody can say against that statement... if they do... they're just idiots that have no idea what they're talking about... Microsoft CANNOT ban a untouched machine... and they CANNOT ban you for having a hacked console at home...
 

ZerOneX

Full Member
Sep 20, 2011
56
8
Man, I'm talking about DUAL nand consoles... forget the original nand.. I am ONLY considering the glitched nand if, for some how, it goes online signed in LIVE!!

This is why during a dual boot hack I always create the glitched nand using different KV from a banned console... using this is a PLUS to make it even safer...

And just to be clear, I am NOT talking play online on glitched nand... I am saying if goes online on glitched nand by accident, you will get your KV banned forever... got it now?
 
V

VampireSwizzy

And just to be clear, I am NOT talking play online on glitched nand...
Yes, and i am also NOT talking about LIVE on the hacked nand, once the keyvault has been decrypted (which it is during startup) the data sent to microsoft is exactly the same no matter what key you used to encrypt it... like i said, if you're worried about live bans... get yourself 2 consoles, one untouched and your hacked one... then they cannot ban you...