• After 15+ years, we've made a big change: Android Forums is now Early Bird Club. Learn more here.

Cant Unlock, Unknown serial. ADB problems

Seems to be decent. I don't have a backup chipid, but that might be because I'm already unlocked. The unlocker tool uses that file as well as /proc/cpuinfo to register the device, so it might be nice to see that folders to see what he has there.
yjy7egu3.jpg
 
I cannot properly confirm/deny SA as some of those commands are beyond my ability to craft. I can see what you're doing there but if there were a few small items out of place, I would not be sure.

All I can say though is bravo sir for an amazing effor here. :thumb:
 
Thanks guys! :) :thumbup:

@miskas,

If you are going to try the above (I.e., the commands in post #50 above), please:

- note I won't really be available to help you debug until I get home from work tomorrow evening

- I've added some commands to help display some helpful information at some key points for us to be able to see how things are going

- the very first echo "$ssn" command you can omit or edit before pasting here for us if that serial number is personal or can be used to identify you (I think I saw that you redacted it on the first page of this thread)

- when doing these, if you run into any warnings or errors or syntax issues being reported, go-ahead and stop at that point and let us know so that we can assess what is going on and try to figure out a fix

- I'm not sure I really need your cardhu_backup_chipid file anymore now that I've looked at how it's used (it's used to create a new UUID file), but feel free to extract and post if you've already gone to the trouble

I think that's it for now...I'll check back in later tomorrow :).

Thanks!
 
Thats where i get up too before this happens

"shell@android:/ $ su
su
root@android:/ # ssn=C7OKASQR00JW
ssn=C7OKASQR00JW
root@android:/ # echo "trace: $ssn"
echo "trace: $ssn"
trace: C7OKASQR00JW
root@android:/ # dd ibs=1 count=17 if=/sys/devices/platform/cardhu_misc/cardhu_b
ackup_chipid of=chipid
es/platform/cardhu_misc/cardhu_backup_chipid of=chipid <
/sys/devices/platform/cardhu_misc/cardhu_backup_chipid: cannot open for read: No
such file or directory
1|root@android:/ #"

Screenshot_2013-07-10-09-48-471_zps3875ad02.png.html
Screenshot_2013-07-10-09-48-471_zps3875ad02.png Photo by headslicer4 | Photobucket
 
miskas said:
Thats where i get up too before this happens

"shell@android:/ $ su
su
root@android:/ # ssn=C7OKASQR00JW
ssn=C7OKASQR00JW
root@android:/ # echo "trace: $ssn"
echo "trace: $ssn"
trace: C7OKASQR00JW
root@android:/ # dd ibs=1 count=17 if=/sys/devices/platform/cardhu_misc/cardhu_b
ackup_chipid of=chipid
es/platform/cardhu_misc/cardhu_backup_chipid of=chipid <
/sys/devices/platform/cardhu_misc/cardhu_backup_chipid: cannot open for read: No
such file or directory
1|root@android:/ #"

Screenshot_2013-07-10-09-48-471_zps3875ad02.png.html
Screenshot_2013-07-10-09-48-471_zps3875ad02.png Photo by headslicer4 | Photobucket
Click to expand...

Ah, that's very interesting and could / might very well explain why ratchet was dying on you: i.e., your device doesn't have the /sys/devices/platform/cardhu_misc/cardhu_backup_chipid file?

(I copied / pasted that reference directly from the ratchet.c code, so I know that it's what that program expects)

Can you check for it's presence with a rooted file manager (Root Explorer or ES File Explorer)?

Thanks!
 
scary alien said:
Ah, that's very interesting and could / might very well explain why ratchet was dying on you: i.e., your device doesn't have the /sys/devices/platform/cardhu_misc/cardhu_backup_chipid file?

(I copied / pasted that reference directly from the ratchet.c code, so I know that it's what that program expects)

Can you check for it's presence with a rooted file manager (Root Explorer or ES File Explorer)?

Thanks!
Click to expand...

I had suspected that after not finding that file on my tf700. 4.1.1 (4.2.1 in my case) must have changed the file from what it was in 4.0.3, perhaps showing that IBT was correct that version had something to do with it.
 
scary alien said:
Ah, that's very interesting and could / might very well explain why ratchet was dying on you: i.e., your device doesn't have the /sys/devices/platform/cardhu_misc/cardhu_backup_chipid file?

(I copied / pasted that reference directly from the ratchet.c code, so I know that it's what that program expects)

Can you check for it's presence with a rooted file manager (Root Explorer or ES File Explorer)?

Thanks!
Click to expand...
Nope its not there...
What now?
 
iowabowtech said:
Yeah this sort of thing is exactly what I was afraid of. Looks like we're not alone here:

http://forum.xda-developers.com/showthread.php?p=40663381
Click to expand...

^^^ LOL--I should have gotten the mount command from that thread ;) :) :p.

I don't know if the other chipid file (cardhu_chipid) that jhawkkw referenced would suffice for the purposes of populating the p5 directory to get you where you want to be (i.e., unlocked). It's trivial to change my commands above to reference a different file (and use the same mount command referenced in the XDA thread).

That XDA thread seems to indicate that it will and won't work...need more time to read and make sense of it (but jhawkkw can probably advise better than I).
 
Alright, just finished. This issue still hasn't been resolved, but I found what is causing the issue with unlocking and the no serial in this case. What happened is that most likely, you received a refurb or your own repaired tablet with a brand new motherboard. The repair technician failed to reprogram the serial number in. Ratchet or doing this manually can help put the serial back but it isn't guaranteed to fix the problem. When they replaced the motherboard, it gives the tablet a new MAC address which is different from your original one and it cannot be changed by the user from what I've read. ASUS' system keeps MAC and serial paired and if they match, it will unlock. Since your device may have a different MAC address than what the system has registered to your serial, it will deny you unlocking even if we fix the serial number issue. ASUS' only suggestion is to RMA, but from what I gather they're only fixing the issue from users in the US and Canada. If you're using a WW edition, you will be out of luck. Since your device is out of warranty, they will most likely make you pay for their mistake :banghead:

If the motherboard wasn't touched, then this may still work. However I'm not sure if the normal cardhu_chipid will work over the backup one. I think it may, because looking at the ratchet code, it is expecting a 16 character string which is what the normal one has. But I'm not 100% sure.
 
jhawkkw said:
Alright, just finished. This issue still hasn't been resolved, but I found what is causing the issue with unlocking and the no serial in this case. What happened is that most likely, you received a refurb or your own repaired tablet with a brand new motherboard. The repair technician failed to reprogram the serial number in. Ratchet or doing this manually can help put the serial back but it isn't guaranteed to fix the problem. When they replaced the motherboard, it gives the tablet a new MAC address which is different from your original one and it cannot be changed by the user from what I've read. ASUS' system keeps MAC and serial paired and if they match, it will unlock. Since your device may have a different MAC address than what the system has registered to your serial, it will deny you unlocking even if we fix the serial number issue. ASUS' only suggestion is to RMA, but from what I gather they're only fixing the issue from users in the US and Canada. If you're using a WW edition, you will be out of luck. Since your device is out of warranty, they will most likely make you pay for their mistake :banghead:

If the motherboard wasn't touched, then this may still work. However I'm not sure if the normal cardhu_chipid will work over the backup one. I think it may, because looking at the ratchet code, it is expecting a 16 character string which is what the normal one has. But I'm not 100% sure.
Click to expand...

so where does this bring us?
 
Does the unlock tool look for a specific ID at a specific location or does the user just have to provide that info? Just wondering if we need to adjust the command set and/or file structure on the phone to increase chances of unlock success?
 
iowabowtech said:
Does the unlock tool look for a specific ID at a specific location or does the user just have to provide that info? Just wondering if we need to adjust the command set and/or file structure on the phone to increase chances of unlock success?
Click to expand...
I believe it looks for a specific id as it never asks for info. it brings me up to the point where it tries to download but then gives me an error
 
iowabowtech said:
Does the unlock tool look for a specific ID at a specific location or does the user just have to provide that info? Just wondering if we need to adjust the command set and/or file structure on the phone to increase chances of unlock success?
Click to expand...

When the unlock tool was released, developers decompiled it. It uses the cardhu_chipid file as well as as /proc/cpuinfo to identify the hardware, then pulls the serial number from the place we're trying to write it to and then matches it to an entry in their system of devices. The unlock code from what I gathered is specific to each individual device which is why it has to make a successful match in order to unlock.
 
Ok. So what I'm getting at then is...do we try to adjust Ratchet so that it looks for the s/n, UUID at the location where it would be found in JB? Or do we mkdir the expected location from ICS, which was /sys/devices/platform/cardhu_misc/cardhu_backup_chipid and house the info there? Or am I off altogether on my thinking?

I'm just wondering if the unlock tool looks for mainver or similar and then with that in mind, if it looks to a specific directory for the info it seeks.

edit: ninja'd. :)
 
jhawkkw said:
When the unlock tool was released, developers decompiled it. It uses the cardhu_chipid file as well as as /proc/cpuinfo to identify the hardware, then pulls the serial number from the place we're trying to write it to and then matches it to an entry in their system of devices. The unlock code from what I gathered is specific to each individual device which is why it has to make a successful match in order to unlock.
Click to expand...

sooo... whats the next step?
 
Well, we can try to use that file and proceed as normal to restore the serial. If does work, and your device has its original mac address, it should allow you to unlock. However I don't believe the odds are in our favor. Or you can try to RMA it again. Those look like the only options.
 
You must log in or register to reply here.
Back
Top Bottom