[We Need] Working Nvflash.... :(

Search This thread

shep211

Retired Forum Moderator
Sep 19, 2007
1,980
295
45
Layton, Ut
I rooted the galaxy tab using nvflash when it first came out in the US. With nvflash we can flash rooted roms and do full backups. I am trying the same process with the TP but I have ran into some issues. First issue was the drivers would not install. I added the TP device id then I installed the drivers. I tried nvflash --sync command but get a unkown device message. We need a updated nvflash that supports tegra 3. If anyone has an updated version of nvflash please pm me.
Thanks

Shep

Edit: I checked online and dev package for tegra platform from nvidia but could not find a updated version of nvflash that supports TP. Are device does have APX & nflash support(Vol+ then power button then hold both 15 secs then release).
 
Last edited:
  • Like
Reactions: Col.Kernel

biggem001

Senior Member
Sep 20, 2010
499
199
its not a driver issue. the drivers that come with the latest version of NVflash are the drivers supplied by ASUS, BUT the PID/VID

try adding these lines to the NvidiaUSB.inf under the x86 and amd64 lines

%USB\NvidiaUsb.DeviceDesc% = USB_Install, USB\VID_0B05&PID_4D01&MI_01
%USB\NvidiaUsb.DeviceDesc% = USB_Install, USB\VID_0B05&PID_4D03&MI_02


then force uninstall any drivers (you may even go as far as installing old google ADB drivers) and then try installing the nvflash drivers (with the new lines added)

i was trying to do this, but i cant find my device in hardware list. like literally its not that hahah
 

shep211

Retired Forum Moderator
Sep 19, 2007
1,980
295
45
Layton, Ut
its not a driver issue. the drivers that come with the latest version of NVflash are the drivers supplied by ASUS, BUT the PID/VID

try adding these lines to the NvidiaUSB.inf under the x86 and amd64 lines

%USB\NvidiaUsb.DeviceDesc% = USB_Install, USB\VID_0B05&PID_4D01&MI_01
%USB\NvidiaUsb.DeviceDesc% = USB_Install, USB\VID_0B05&PID_4D03&MI_02


then force uninstall any drivers (you may even go as far as installing old google ADB drivers) and then try installing the nvflash drivers (with the new lines added)

i was trying to do this, but i cant find my device in hardware list. like literally its not that hahah

I already got the drivers working. Nvflash says unknown device whe you try to use the sync command. We need new version of nvflash.
 

1wayjonny

Senior Member
Jan 3, 2007
466
1,197
I have same issue it says unknown device, we need a new EXE. Hope to get one soon.
 

biggem001

Senior Member
Sep 20, 2010
499
199
I went into NVFLASH and saw that it takes the USB PID of the device, and that tells how the device is what it is. so the TP needs to be added to NVFLASH.. im seeing if i can do it be playing with the exe
 
  • Like
Reactions: tylermaciaszek

di11igaf

Inactive Recognized Developer
Sep 6, 2010
1,898
739
East Coast
here is an nvflash that supports cardhu(tegra 3), this is for linux, its all use so all i have, i just issued the --sync command and have not gotten an unknown device error, just getting nvflash started, then it just sits there.
i havent used nvflash really at all, im just used to fastboot and adb, but hopefully this helps and i dont have much time today or tomorrow at all to mess with it.
Linux users- in your rules.d(android-rules-whtever you want to make it) first line will get ADB working with the prime, second should allow it to be seen in APX mode:
SUBSYSTEM=="usb", SYSFS{idVendor}=="0b05", MODE="0666"
SUBSYSTEM=="usb", SYSFS{idVendor}=="0955", MODE="0666"

Edit after messing with some nvflash commands I get a "USB write failed" error, which after Googling tells me Asus has used an SBK(secure boot key), rendering nvflash useless(unless asus gives it to us-128 bit encryption). Basically locked, encrypted bootloader and were f#$ked.
I really hope I'm wrong.
 

Attachments

  • nvflash.tar
    750 KB · Views: 250
Last edited:

Magnesus

Senior Member
Mar 7, 2011
1,225
129
Some small village
You are not wrong unfortunately. It's the same with the first Transformer. The first SBK was leaked, but they changed it and the second one is still unknown as far as I know. It's a real shame, because nvflash provides a lot of safety (you can reflash even almost bricked device).
 

compuw22c

Senior Member
Dec 26, 2007
621
237
Chicago, IL
Edit after messing with some nvflash commands I get a "USB write failed" error, which after Googling tells me Asus has used an SBK(secure boot key), rendering nvflash useless(unless asus gives it to us-128 bit encryption). Basically locked, encrypted bootloader and were f#$ked.
I really hope I'm wrong.

If this is true, I will return it on principle. I don't buy locked devices, which is why I will never buy Motorola
 

clouds5

Senior Member
Feb 8, 2011
1,933
512
I cant imagine this being a problem for long. Even iphones get jailbreaked after some time and Apple is known for their locked system. They probably have a whole department just for locking up and preventing jailbreaks.
I really cant imagine that Asus is doing a better job than Apple in that matter and making it impossible to do some magic with it.. It'll probably take some time though.

Is there a good channel to reach Nvidia or Asus with our demands? Crying loud enough worked with HTC after all :D
 

Top Liked Posts

  • There are no posts matching your filters.
  • 6
    here is an nvflash that supports cardhu(tegra 3), this is for linux, its all use so all i have, i just issued the --sync command and have not gotten an unknown device error, just getting nvflash started, then it just sits there.
    i havent used nvflash really at all, im just used to fastboot and adb, but hopefully this helps and i dont have much time today or tomorrow at all to mess with it.
    Linux users- in your rules.d(android-rules-whtever you want to make it) first line will get ADB working with the prime, second should allow it to be seen in APX mode:
    SUBSYSTEM=="usb", SYSFS{idVendor}=="0b05", MODE="0666"
    SUBSYSTEM=="usb", SYSFS{idVendor}=="0955", MODE="0666"

    Edit after messing with some nvflash commands I get a "USB write failed" error, which after Googling tells me Asus has used an SBK(secure boot key), rendering nvflash useless(unless asus gives it to us-128 bit encryption). Basically locked, encrypted bootloader and were f#$ked.
    I really hope I'm wrong.
    3
    I just sent Asus info and link to this thread and the other NVflash one. I told them unlocked users are very concerned & anxious for a new update on this issue & possible release date. hopefully Gary will let you all know something ASAP.
    2
    Lol @ all the people talking about brute forcing the keys. People have no idea at the true strength of AES encrypton. lets give some actual detail to this:

    1) Assume your CPU/GPU can try one septillion keys every second (10^24), current hardware is not even capable of a small fraction of this but let's say it can anyway. That's 1,000,000,000,000,000,000,000,000 keys per second.

    2) Now, assume you have 999,999 friends who are willing to help you, who also have the same impossibly fast CPU/GPU. So that's a million times faster, if you distribute the process over the internet.

    3) 16 bytes is 128 bits, so there's 2^128 possible keys to try. That's 3.4 * 10^48 keys.

    4) Do the math (you can use Google for this): 2^128 / 10^24 / 1000000 = 340282367 seconds.
    340282367 / 86400 = 3938.45 days
    3938.45 / 365 = 10.8 years for you and 999,999 friends to try every possible key.

    Now take into account that this assumes 0 delay from trying a key to verification that its found the correct key. This verification is a HUGE factor as well, for example:

    A GeForce GTX 460 working to break an AES-128 encrypted zip file is capable of trying 185,000 possibilities a second, however a AES-128 encrypted rar files its only capable of 3,500 possibilities a second.

    Jump up to 2 x GeForce GTX 570 working SLI and you get 495,000 possibilities a second for the AES-128 zip file and 14,000 for the AES-128 rar file.

    If you factor in the time it takes for any script to test and verify the keys its tested then its just not going to happen, not even if every single member of XDA developers devoted all their cpu and gpu time to this for years.
    1
    Yes I know you just have to restart udev service... But it seemed to me more accurate :D

    not even that much, udev as a rule automatically reloads the rules, you should only need to unplug and replug the device, and if that doesn't work then reload the rules (although most of the time completely unneeded) with
    Code:
    sudo udevadm control --reload-rules
    1
    might be interesting to try the sbkcheck from rayman
    http://xdaforums.com/showthread.php?t=1290503

    (note: IIRC there was a modified version at androidroot.mobi that could check for a "v3" SBK as well).