quick guide on how to upgrade your Transformer (any build) to a ROOTED WW 8.4.4.5 release (Android 3.1)

This is completely stock Android 3.1 but with root / Superuser and busybox added.

Please note that you follow this guide at your own risk! Although the process should not wipe your device, I advise backing up your data first.

PLEASE READ THESE INSTRUCTIONS THROUGH BEFORE YOU START!

• Download the 8.2.3.9 update zip - DOWNLOAD (Mediafire Pro) - MD5: d8e37ec527dd8d701633cd337f767b5c
• Extract the contents of the above zip (maintaining the directory structure) to a microSD card and insert in your Transformer. An update notification will appear in your system tray - click the notification and your device will reboot and rollback to 8.2.3.9.
• Download the rooted 8.4.4.5 rooted update zip - DOWNLOAD (Mediafire Pro) - MD5: 4375ddec4d3470037d58cd2434cd8bf5
• Copy the zip file to your microSD card. Do NOT extract it, just copy it as-is.
• Download the 8.4.4.5 root utlity zip - DOWNLOAD (Mediafire Pro) - MD5: ca37aa989698d17e690d1a89ac025487
• Extract the utility zip on your PC, and from a command prompt / terminal window at the location you extracted the files, enter the following commands (note that the Gingerbreak command may take a while), replacing adb with ./adb-mac or ./adb-linux as required:
  
  
  CODE
  adb push blob /data/local/
  adb push gingerbreakBB /data/local/
  adb shell chmod 4755 /data/local/gingerbreakBB
  adb shell
  /data/local/gingerbreakBB
  dd if=/data/local/blob of=/dev/block/mmcblk0p4
  reboot
• Your device will now reboot and show a blue progress bar. When this finishes and the screen goes black, hold down the 'volume down' butotn. When prompted, press 'volume up' to enter ClockworkMod recovery.
• Select 'install zip from sdcard' -> 'choose zip from sdcard' -> '8.4.4.5-rooted.zip' -> 'yes'.
• Reboot your device from the menus and that's it, job done!

source: http://android.modaco.com/content/asus-eee-pad-transformer-transformer-modaco-com/341227/upgrading-to-rooted-ww-8-4-4-5-android-3-1-from-any-version/

The inner workings of Secure Boot key and Nvflash

What is Secure Boot Key and how does it work?

I’ve been getting lots of questions about this, so here is some simple background:
The secure boot key is an AES128 encryption key that can used to encrypt various data on the flash memory. It’s a generic nvidia tegra2 thing, that the manufacturer can optionally use to make their device more “secure”.
When the SBK is set, it’s stored in a one-time-programmable “fuse”. This also means that now that the key is out, they can’t change it on already released devices, only new devices.
When the tegra2 starts up, the AES key is available to the hardware AES engine only. E.g. not even the bootloader can read it back! However, the bootloader can *use* the key to encrypt whatever data it wants through the hardware AES engine. And here is the explanation why the blob flashing method actually works! The bootloader checks for the blob in the staging partition and encrypts and flashes it as needed.
Once the bootloader is done, it clear the key from the AES engine which makes it impossible to encrypt or decrypt things from within the OS.

So what happens when it boots into APX/Nvflash mode?

The basic APX mode is stored in the BootROM and hence can never be changed. It appears to accept only a very limited range of commands, and each command needs to be encrypted using the SBK to be accepted. If it receives a command that’s not properly encrypted, it disconnects the USB and appears to be off. This is the dreaded “0×4″ error that people have been getting when attempting to get nvflash working.
It should be noted, that even with the SBK inputted into nvflash, most regular nvflash commands won’t be available. I’m still not entirely sure why (and I can’t rule out it will change).
What *is* available, is the nvflash –create command. What this command does is repartition and format all partitions, set bct and odmdata and send over all  needed partitions to the device (and encrypt them as needed). This means a full recovery is possible, but regular ability to flash e.g. just boot.img or read partitions off of the device is not possible at this point.

So what do we need for nvflash?

In order to get a working (e.g. –create) nvflash, we need a few bits of information as well as some files:

• Secure Boot Key
• BCT file (boot device setup, ram configuration and a bit more)
• ODM data (board-specific bit-field specifying various board settings. *Needs* to be correct
• flash.cfg (e.g. list of settings and names/identifiers of partitions.

On top of these files, we also need all the partitions, e.g. bootloader.bin, boot.img, recovery.img and system.img. Luckily, these partition files are available in official ASUS updates and can be extracted from the blob file using my blob tools :)
The first four peices aren’t readily available, but through lots of effort and a good deal of luck, we have managed to recreate the needed files. Secure Boot Key has already been released (note that this was by far the hardest!) and the rest will most likely follow over the weekend. Keep in mind that we want to keep this legal, so don’t expect us to release any ready-made packs for unbricking! We will however make the recreated files available. Since these are recreated and not actual ASUS files, there should be no problems with them.

source: http://androidroot.mobi/tf-secure-boot-key/