Jump to content


Photo

Autohacker V2.1


  • Please log in to reply
71 replies to this topic

#31 ZprivateZ

ZprivateZ

    X-S Enthusiast

  • XS-BANNED
  • 1 posts
  • Location:USA
  • Xbox Version:v1.6
  • 360 version:v4.0 (jasper)

Posted 11 April 2010 - 11:41 PM

I haven't had the chance to try this yet but nice job, anything to simplify things is always appreciated.

#32 BadBloke

BadBloke

    X-S Enthusiast

  • Dev/Contributor
  • 17 posts
  • Location:Greece
  • Xbox Version:none
  • 360 version:v4.0 (jasper)

Posted 12 April 2010 - 01:28 AM

AUTOHACKER V2.1 IS OUT  

CHANGELOG:
============

v2.1     :
          Fixed a bug where CB version 6723 was reported as not exploitable.
          Added a self-check upon startup so that all the files are in place and correct version.
          Added feature to automatically unpack XBR images in case the user threw them in the folder without decompressing first.

v2.00BETA:
          Complete rewrite. v2.00 Initial Release

Updated first post with download links etc.


danthaman673, thanks for trying this out. I want to make a quick note on the "two same bad dumps" thingy. It is obvious that the chances of that happening is about the same as the chances of achieving 3 bulls-eye's by randomly throwing a bucket that contains three darts out of the window on the third floor of a building, while the target is on the ground. That's TOUGH biggrin.gif
I also think that if two dumps are the same, but contain errors (the same errors), but are REPORTED by NandPro, the reads are good, it's the blocks that are bad...

Which brings us to our second topic.
Regarding the bad blocks:

The type of solution you are suggesting indicates that one doesn't understand the "problem".
The bad blocks are automatically relocated during write. That is what the controller and ECC is for.

A small FAQ on how NAND memory works (for anyone interested for discussion, because I see a lot of people confused about such stuff):

When NAND is erased, all bits are set to 1' (that means 0xff on all bytes if we ever dumped an erased NAND memory).
We can change as many bits as we want to '0'.
We can't set a bit back to '1' by simply writing. We have to erase a whole erase block instead and set again the rest of the bits to '0'
The number of erase cycles per block is not infinite. Wear is introduced each time we erase and write a block (which can also be done by the controller automatically, without asking us, if it has to set a bit back to '1').
If a bit reaches the limit of its erase/write cycles, it will not get back to 0xff. This is a bad block. A bad block does not affect the performance of valid blocks because it is isolated from the bit line and common source line by a select transistor.

Now, some blocks are bad even in an untouched xbox360 (and any NAND memory, for that matter). The vendor just marks those blocks as bad to cut down costs (similar to dead pixels, only more bearable and not at all a deal-breaker). When a block has been marked as bad, the NAND will not simply fail to write, but the conrtoller will skip it, thus relocating it automatically.

Now, there are some special blocks that are vital to the xbox360 functionality. It's three blocks that contain our KeyVault and our ConfigBlock. These have an address in the NAND, that will not change. It is always in the same spot. These are the only three blocks that we need to patch XBR (we just take full backups for extra-safety).

Obviously, if, say, Hynix sends a NAND memory with one of these three blocks marked as bad, the xbox will fail to power up, and the memory will be sent back. In fact I doubt that the vendors even sends such NANDs, they just know, it will not work (many times there are some special block ranges that have been tested out and guaranteed too survive a big number of erase-write cycles, used for important stuff such as bootloaders, this may well be the case with XBOX360, too). Knowing that these blocks not bad (because if they were the xbox wouldn't have existed in the first place) and the fact that they can be written successfully, is the reason why we shouldn't care much about bad blocks. I have never seen any xbox fail due to bad blocks. Or else, even normal xboxes without JTAG would fail on their own during updates.

Edited by BadBloke, 12 April 2010 - 01:38 AM.


#33 GOTitCUZiMODDED

GOTitCUZiMODDED

    X-S Member

  • Members
  • Pip
  • 88 posts
  • Location:In the nutsack of TX!
  • Xbox Version:v1.4
  • 360 version:v4.0 (jasper)

Posted 12 April 2010 - 02:41 PM

Wow... you totally answered all my questions I had about bad blocks. I am currently comfy with Plexo's script but will definitely give this a shot and attempt to put together my own Xellous/XBR nand images! Thanks for the NAND lesson! Much appreciated! biggrin.gif

#34 danthaman673

danthaman673

    X-S Expert

  • Members
  • PipPipPip
  • 504 posts
  • Interests:Modding and Gaming 24/7
  • Xbox Version:v1.6d
  • 360 version:v5.0 (360S - trinity)

Posted 12 April 2010 - 04:57 PM

QUOTE(BadBloke @ Apr 12 2010, 09:58 AM) View Post

AUTOHACKER V2.1 IS OUT  

CHANGELOG:
============

v2.1     :
          Fixed a bug where CB version 6723 was reported as not exploitable.
          Added a self-check upon startup so that all the files are in place and correct version.
          Added feature to automatically unpack XBR images in case the user threw them in the folder without decompressing first.

v2.00BETA:
          Complete rewrite. v2.00 Initial Release

Updated first post with download links etc.
danthaman673, thanks for trying this out. I want to make a quick note on the "two same bad dumps" thingy. It is obvious that the chances of that happening is about the same as the chances of achieving 3 bulls-eye's by randomly throwing a bucket that contains three darts out of the window on the third floor of a building, while the target is on the ground. That's TOUGH biggrin.gif
I also think that if two dumps are the same, but contain errors (the same errors), but are REPORTED by NandPro, the reads are good, it's the blocks that are bad...

Which brings us to our second topic.
Regarding the bad blocks:

The type of solution you are suggesting indicates that one doesn't understand the "problem".
The bad blocks are automatically relocated during write. That is what the controller and ECC is for.

A small FAQ on how NAND memory works (for anyone interested for discussion, because I see a lot of people confused about such stuff):

When NAND is erased, all bits are set to 1' (that means 0xff on all bytes if we ever dumped an erased NAND memory).
We can change as many bits as we want to '0'.
We can't set a bit back to '1' by simply writing. We have to erase a whole erase block instead and set again the rest of the bits to '0'
The number of erase cycles per block is not infinite. Wear is introduced each time we erase and write a block (which can also be done by the controller automatically, without asking us, if it has to set a bit back to '1').
If a bit reaches the limit of its erase/write cycles, it will not get back to 0xff. This is a bad block. A bad block does not affect the performance of valid blocks because it is isolated from the bit line and common source line by a select transistor.

Now, some blocks are bad even in an untouched xbox360 (and any NAND memory, for that matter). The vendor just marks those blocks as bad to cut down costs (similar to dead pixels, only more bearable and not at all a deal-breaker). When a block has been marked as bad, the NAND will not simply fail to write, but the conrtoller will skip it, thus relocating it automatically.

Now, there are some special blocks that are vital to the xbox360 functionality. It's three blocks that contain our KeyVault and our ConfigBlock. These have an address in the NAND, that will not change. It is always in the same spot. These are the only three blocks that we need to patch XBR (we just take full backups for extra-safety).

Obviously, if, say, Hynix sends a NAND memory with one of these three blocks marked as bad, the xbox will fail to power up, and the memory will be sent back. In fact I doubt that the vendors even sends such NANDs, they just know, it will not work (many times there are some special block ranges that have been tested out and guaranteed too survive a big number of erase-write cycles, used for important stuff such as bootloaders, this may well be the case with XBOX360, too). Knowing that these blocks not bad (because if they were the xbox wouldn't have existed in the first place) and the fact that they can be written successfully, is the reason why we shouldn't care much about bad blocks. I have never seen any xbox fail due to bad blocks. Or else, even normal xboxes without JTAG would fail on their own during updates.

Thankyou for your thoughfull reply,

Might I say on the dump issue that the effect I was refering to is usally caused by LPT port logic levels being consistently inconsistent (If that makes sense) And that some controller nuances can put long strings of 1's for exsample as slightly shorter than they are (In exactly the same way every time). Also what if you get two dumps of all zero's?? Granted these things happen rarely to those who haven't done it successfully before (or if some one has been playing with ur bios settings), but it does happen :-)

Also isn't there somewhat of a difference between blocks marked as bad from manufacture and those that become so after a while from 'write leveling'? Also what if ECC becomes corrupted by voltage spike or what-not?? Obviously I see ur point about there only needing KV end Config from the zero paired, I would think config block prolly doesn't make it into the 'un-remappable @ mobo manfacture' category. I would like to be certain they don't also re-map KV if it suited them (God knows M$ will pinch every concieveable penny they think they can get away with grr.gif ) As I wouldn't imagine them being worried about a retail mobo's nand being re-written by an outside controller.The onboard would know to re-map those blocks I always thought(unlike that of the PC's) - but I'm frequently wrong jester.gif .
Often it's the older boxes that have seen at least one update that show bad-blocks apon forensic inspection (It's not that much drama to remap with redline's tool anyway - In my experiance it sometimes prevents random RROD'ing that doesn't seem to be attributable to anything else it would seem) I guess what I'm saying (what I've always thought) is that if you have a box that has badblock(s) that have in the original been remapped and you write over the top without 1st remapping surely you run the risk of having a cruicial part of the new image landing on one or more of those bad blocks??? (Given the fact that PC's controller doesn't test-write each block or read ECC as it goes)
Or have I misunderstood 'the problem'

Brgds/Dan
PS:Sorry if this post may lack readability but I don't have the time to proof/edit etc..



#35 BadBloke

BadBloke

    X-S Enthusiast

  • Dev/Contributor
  • 17 posts
  • Location:Greece
  • Xbox Version:none
  • 360 version:v4.0 (jasper)

Posted 12 April 2010 - 05:28 PM

QUOTE(danthaman673 @ Apr 12 2010, 06:57 PM) View Post

Thankyou for your thoughfull reply,

Might I say on the dump issue that the effect I was refering to is usally caused by LPT port logic levels being consistently inconsistent (If that makes sense) And that some controller nuances can put long strings of 1's for exsample as slightly shorter than they are (In exactly the same way every time). Also what if you get two dumps of all zero's?? Granted these things happen rarely to those who haven't done it successfully before (or if some one has been playing with ur bios settings), but it does happen :-)

Also isn't there somewhat of a difference between blocks marked as bad from manufacture and those that become so after a while from 'write leveling'? Also what if ECC becomes corrupted by voltage spike or what-not?? Obviously I see ur point about there only needing KV end Config from the zero paired, I would think config block prolly doesn't make it into the 'un-remappable @ mobo manfacture' category. I would like to be certain they don't also re-map KV if it suited them (God knows M$ will pinch every concieveable penny they think they can get away with grr.gif ) As I wouldn't imagine them being worried about a retail mobo's nand being re-written by an outside controller.The onboard would know to re-map those blocks I always thought(unlike that of the PC's) - but I'm frequently wrong jester.gif .
Often it's the older boxes that have seen at least one update that show bad-blocks apon forensic inspection (It's not that much drama to remap with redline's tool anyway - In my experiance it sometimes prevents random RROD'ing that doesn't seem to be attributable to anything else it would seem) I guess what I'm saying (what I've always thought) is that if you have a box that has badblock(s) that have in the original been remapped and you write over the top without 1st remapping surely you run the risk of having a cruicial part of the new image landing on one or more of those bad blocks??? (Given the fact that PC's controller doesn't test-write each block or read ECC as it goes)
Or have I misunderstood 'the problem'

Brgds/Dan
PS:Sorry if this post may lack readability but I don't have the time to proof/edit etc..


You have a point about having two dumps full of zeroes or ones. Perhaps a command-line utility can be written that checks the KV and the ConfigBlock and returns errorlevel 1 if it full of zeroes or ones. Then if the errorlevel is 0, AutoHacker knows it's all good. Will keep that in mind, perhaps you can help, too, if you want (i'm too busy this month) smile.gif

ECC getting corrupt by a voltage spike? Right, can be true, but two times?
The rest you mention (shorter strings of 1's than needed/bad logic levels) fall into the category of the more general "LPT is unstable as hell" category, which is, of course, true, as is the nature of all unbuffered transfers. The best way to overcome this is to put a warning that USB is the way to go and LPT is generally risky, unless you have manually tested that it works perfectly, haha! Also, please bear in mind that as much as we want to, we can't protect users from everything (they could as well make giant solder blobs and damage the mainboard/NAND/what-not - how could AutoHacker protect them from that? smile.gif ) I clearly mention in the disclaimer that it is VITAL to know what you are doing and have a fair understanding of how the hack works.

#36 danthaman673

danthaman673

    X-S Expert

  • Members
  • PipPipPip
  • 504 posts
  • Interests:Modding and Gaming 24/7
  • Xbox Version:v1.6d
  • 360 version:v5.0 (360S - trinity)

Posted 12 April 2010 - 07:04 PM

QUOTE(BadBloke @ Apr 13 2010, 01:58 AM) View Post

You have a point about having two dumps full of zeroes or ones. Perhaps a command-line utility can be written that checks the KV and the ConfigBlock and returns errorlevel 1 if it full of zeroes or ones. Then if the errorlevel is 0, AutoHacker knows it's all good. Will keep that in mind, perhaps you can help, too, if you want (i'm too busy this month) smile.gif

ECC getting corrupt by a voltage spike? Right, can be true, but two times?
The rest you mention (shorter strings of 1's than needed/bad logic levels) fall into the category of the more general "LPT is unstable as hell" category, which is, of course, true, as is the nature of all unbuffered transfers. The best way to overcome this is to put a warning that USB is the way to go and LPT is generally risky, unless you have manually tested that it works perfectly, haha! Also, please bear in mind that as much as we want to, we can't protect users from everything (they could as well make giant solder blobs and damage the mainboard/NAND/what-not - how could AutoHacker protect them from that? smile.gif ) I clearly mention in the disclaimer that it is VITAL to know what you are doing and have a fair understanding of how the hack works.



Cheers M8 will do if I can find the time (Maybe a bit later next week), also very busy, partially with those solder blobs you speak of (They're all the rage at the moment .. hehe .. :-)



Thanks again, Dan

#37 numlockhome

numlockhome

    X-S Young Member

  • Members
  • Pip
  • 33 posts

Posted 12 April 2010 - 09:58 PM

Just dropping by to thank the author of this software, it works perfectly!

Its always a good idea to simplify things in my opinion biggrin.gif

cheeers!

Edited by numlockhome, 12 April 2010 - 09:59 PM.


#38 dokworm

dokworm

    X-S Expert

  • Members
  • PipPipPip
  • 744 posts

Posted 13 April 2010 - 01:06 AM

QUOTE(BadBloke @ Apr 12 2010, 05:28 PM) View Post



The rest you mention (shorter strings of 1's than needed/bad logic levels) fall into the category of the more general "LPT is unstable as hell" category, which is, of course, true, as is the nature of all unbuffered transfers. The best way to overcome this is to put a warning that USB is the way to go and LPT is generally risky, unless you have manually tested that it works perfectly, haha!


or have the user spend the extra $3 to make a buffered interface for their jtag.

http://forums.xbox-s...howtopic=697104


#39 ravihpa

ravihpa

    X-S Enthusiast

  • Members
  • 22 posts

Posted 13 April 2010 - 05:26 AM

This is FANTASTIC biggrin.gif Awesome job dude. I recently procured an RROD Xbox in excellent condition, and got it repaired by a very good friend of mine who is a professional modder and is REALLY REALLY good at soldering smile.gif

Mine's a Falcon 360 and the current dash is 6717. I am very excited about getting this JTAGGED.

I was reading up on how to do a JTAG and stumbled onto this thread. This is going to make it so very easy now biggrin.gif

But the problem here is, it's going to be very hard for us to find parts to make a USB flasher for doing JTAG, and seeing the above posts, it's become clear to me that LPT is quite risky. I've invested quite a lot in procuring this Falcon and getting it repaired. I wouldn't wanna risk bricking it sad.gif

What would you guys recommend me ? Should I proceed with LPT ? One thing is for sure, if I tell my modder friend where to solder LPT points, his solder job is gonna be 100% PERFECT.

Also, I am trying to decipher what "dokworm" in his post above has posted. I'll read up on it and will try to find those "extra parts" and see if I can make the LPT more stable.

Please recommend. Desperately waiting for a reply smile.gif

Edited by ravihpa, 13 April 2010 - 06:02 AM.


#40 BadBloke

BadBloke

    X-S Enthusiast

  • Dev/Contributor
  • 17 posts
  • Location:Greece
  • Xbox Version:none
  • 360 version:v4.0 (jasper)

Posted 13 April 2010 - 10:31 PM

QUOTE(ravihpa @ Apr 13 2010, 07:26 AM) View Post

This is FANTASTIC biggrin.gif Awesome job dude. I recently procured an RROD Xbox in excellent condition, and got it repaired by a very good friend of mine who is a professional modder and is REALLY REALLY good at soldering smile.gif

Mine's a Falcon 360 and the current dash is 6717. I am very excited about getting this JTAGGED.

I was reading up on how to do a JTAG and stumbled onto this thread. This is going to make it so very easy now biggrin.gif

But the problem here is, it's going to be very hard for us to find parts to make a USB flasher for doing JTAG, and seeing the above posts, it's become clear to me that LPT is quite risky. I've invested quite a lot in procuring this Falcon and getting it repaired. I wouldn't wanna risk bricking it sad.gif

What would you guys recommend me ? Should I proceed with LPT ? One thing is for sure, if I tell my modder friend where to solder LPT points, his solder job is gonna be 100% PERFECT.

Also, I am trying to decipher what "dokworm" in his post above has posted. I'll read up on it and will try to find those "extra parts" and see if I can make the LPT more stable.

Please recommend. Desperately waiting for a reply smile.gif


Your best bet is indeed to buy a usb spi flasher (there are plenty of choices in ebay ranging in build quality and price) but LPT is not THAT bad. If you do it properly I seriously doubt you will encounter any problems. If you've never done it before, use AutoHacker to dump the NAND. If it succeeds ( = the files are identical), manually open one of them in a hexeditor to be sure it is not full of 0's or 1's, then you're good to go (I will include such tests sometime in AutoHacker, just don't know when).

You could also try to do the LPT buffer thingy that dokworm recommends, it *will* make LPT safe if used correctly, but the speed will stay the same (slow) plus you need some fairly serious skills in electronics to do that (a tiny bit easier than building your own usb spi flasher), which is the main reason to go for the usb flasher (if costs are an issue and you have the skills go for LPT buffered, if neither is available just go with LPT unbuffered, be cautious and you'll be fine).

Edited by BadBloke, 13 April 2010 - 11:09 PM.


#41 catchthabeat

catchthabeat

    X-S Senior Member

  • Members
  • PipPip
  • 204 posts
  • Location:O-H-I-O, U.S.A.
  • Xbox Version:unk
  • 360 version:v4.0 (jasper)

Posted 14 April 2010 - 04:52 PM

I seem to get an error, "libusb0.dll not found". I tried reinstalling multiple times and still doenst work.

#42 BadBloke

BadBloke

    X-S Enthusiast

  • Dev/Contributor
  • 17 posts
  • Location:Greece
  • Xbox Version:none
  • 360 version:v4.0 (jasper)

Posted 14 April 2010 - 05:54 PM

libusbo.dll is a file used by NandPro.

NandPro needs the original envinroment to run, including the external libraries that are used, the executable isn't going to run on itself. Install NandPro 2.0b properly (that is downloading the .rar file from xbins and extracting all of the files in the AutoHacker directory).

#43 catchthabeat

catchthabeat

    X-S Senior Member

  • Members
  • PipPip
  • 204 posts
  • Location:O-H-I-O, U.S.A.
  • Xbox Version:unk
  • 360 version:v4.0 (jasper)

Posted 14 April 2010 - 05:56 PM

QUOTE(BadBloke @ Apr 14 2010, 12:54 PM) View Post

libusbo.dll is a file used by NandPro.

NandPro needs the original envinroment to run, including the external libraries that are used, the executable isn't going to run on itself. Install NandPro 2.0b properly (that is downloading the .rar file from xbins and extracting all of the files in the AutoHacker directory).


Ahh, thank you very much. Keep up the good work!

#44 ravihpa

ravihpa

    X-S Enthusiast

  • Members
  • 22 posts

Posted 14 April 2010 - 11:36 PM

Hi BadBloke,

My friend was successful in applying the LPT connections and the JTAG connections. When starting AutoHacker, I can get to the screen where it shows my mobo as Falcon and my CB being exploitable.

Now, whenever I try to make dumps of my nand, they ALWAYS seem to be different and automatically get deleted sad.gif I even tried manually dumping with nandpro by manually putting commands. The 2 MB ones are perfect matches, but the 16 mb ones don't match.

I also compared them with Total Commander, but it said there were 14 differences.

What would you recommend me to do ? By the way, here are 2 pictures of my JTAG connections. We had a little bit of difficulty connecting the J2D2.1 to DB1F1. Pardon the crap quality of the pics. It's the best I could take using my phone sad.gif

IPB Image

IPB Image

He said, and I am quoting, "we almost lost that point - DB1F1". In the end, he managed to solder a wire to DB1F1 and another wire to J2D2.1 and put the 1N4148 diode in between smile.gif

The white wire is going from J2D2.2 to RF panel 6 (1N4148 diode).

Since Autohacker was able to get the CB and mobo version, etc., I am quite certain our LPT setup is PERFECT smile.gif So, please recommend me as to what should I do now smile.gif

Desperately waiting for a reply smile.gif

Edit: By the way, here's how the LPT cable looks like....

IPB Image

smile.gif

Edited by ravihpa, 14 April 2010 - 11:49 PM.


#45 BadBloke

BadBloke

    X-S Enthusiast

  • Dev/Contributor
  • 17 posts
  • Location:Greece
  • Xbox Version:none
  • 360 version:v4.0 (jasper)

Posted 15 April 2010 - 12:15 AM

Well, the read failures have nothing to do with AutoHacker and therefore I'm not the only one that can help you. That said, I am happy to try smile.gif

As a start the LPT wires are way too long from what I see in the pictures. Keep them to a minimum length. The shorter the better. This by far the most suspicious element of your setup and is most likely the source of your problems. In my experience 30cm is bound to succeed.

Secondly, It is not a good practice to solder the JTAG wires/diodes before getting rid of the NANDwork. It seems to cause some sort of write errors in some cases. So I would recommend unsoldering the JTAG wires first (just unsolder the easy side of the wires, the circuit will open and it'll be like the wires are not there), reading/patching/writing your NAND and then re-solder them.

As for your DB1F1, you should have used way thinner cables as the weight of the cable you have used is going to stress the point a lot. It is too much of a strain for the tiny/fragile DB1F1 to handle. Don't panic there are still alternative points at the bottom of the motherboard in case it gets screwed up, but don't give up on it unless it is gone (the alternative points are not infinite and you should be extra careful). Make sure it is making contact (by successfully doing the JTAG hack and booting at least once into XeLL and once into XBR) and before you screw the cover back on, try to relief the stress off the DB1F1 point by hot-glueing the connection (again, with extreme care).

I look forward to your success!

Edited by BadBloke, 15 April 2010 - 01:00 AM.





0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users