yashsingh1/xdaforums huggingface dataset:
[T-Mobile, Samsung Galaxy SIII] flipster64:
Attached is a photo of the download screen.

Under Settings/About Device, the Model Number is and always has shown SGH-T999.

I've downloaded the SGH-T999 pit file from a couple of different places (both linked in previous posts).

I suppose they both might be bad ... but the second one I got through a post by DocHoliday on this forum.

Yes, the re-partition checkbox did come on after I chose the pit file.

First pit file I got through this thread (although as I mentioned before, the link was bad and I figured out I needed to add /android in front of /pit). But the download was funky ... defaulted to an htm file, even though it was binary and had the names of the boot files embedded.)

http://xdaforums.com/showthread.php?t=1848267

Page 4 of that same posts quotes a post from DocHoliday77 that links this:

http://www.androidfilehost.com/?w=files&flid=6471 , a site where he mirrors the PIT files ... this download went smoothly, saved as a pit ... much less suspect, and it's the one I have used on every subsequent try.
[T-Mobile, Samsung Galaxy SIII] flipster64:
^^ see previous post ... don't know why this is here.
[T-Mobile, Samsung Galaxy SIII] flipster64:
Ok, this is REALLY interesting.

I nuked all the drivers again, and went out of my way to find the RMNET driver file, too... got rid of it. Rebooted.

Plugged it in in download mode, first and let it load those drivers (and just for good measure, tried flashing again but failed again)

But the interesting part is, I put it in RMNET+DM+MODEM mode (*#7284#) and watched the device drivers load in Device manager.

It first came up as .... an SGH-i747. After it finished installing the driver, the name changed to the more familiar and generic

SAMSUNG Mobile USB RMNET Drivers

So Windows is seeing it, at first, as an SGH-i747 as well. And that first name I believe it reads right from the device before it downloads and/or loads a driver.

And yet the sticker says it's an SGH-T999, and the back cover is a T-Mobile back cover. i747's weren't made for T-Mobile, only T999's were.
[T-Mobile, Samsung Galaxy SIII] Richcar:
Well may be it was a T-Mobile t999 phone but during the repair the change the mother board and use a SGH-i747 mother board so the body of the phone will still display T-Mobile but your phone is now a AT&T SGH-i747 so may be that why Odin is failing try flashing roms from the AT&T forum. There is a good guide that you can read up on

http://xdaforums.com/showthread.php?t=1771021
[T-Mobile, Samsung Galaxy SIII] Perseus:
This helps clarify things a bit. Stop wasting your time with the PIT files. Leave it aside for a bit.

Do me a favor. Install GetProp on the phone. Find out what does it have to say about the value of ro.bootloader.

Also in addition, explicitly flash per instructions of this thread.
[T-Mobile, Samsung Galaxy SIII] flipster64:
Downloaded GetProp. Ran it.

Popup comes up: "An error has been detected". When the popup goes away, just a white rectangle with "Error" in blue lettering.
[T-Mobile, Samsung Galaxy SIII] flipster64:
I have done this several times over the past few days (that firmware update is currently on my sd card) ... but I get that error on the assert(getprop()) every time. It's the first line in the updater script.

assert(getprop("ro.product.device") == "d2tmo" || getprop("ro.build.product") == "d2tmo");

Now we have a better idea why (thanks for pointing me to GetProp ... I was trying to figure out how to piece together a CM "flashable" zip with no data to try to print what values it was getting for me). It's probably because it's not getting any value back, then.

(if you look back up in this thread you'll see the first 20 or so lines of my current build.prop ... which I got by flashing a stock mod T999 zip (also linked in this thread).

update:

To save you the trouble (I know it's a bit of a pain) I went back and got the build.prop lines mentioned above:

# begin build properties

# autogenerated by buildinfo.sh

ro.build.id=JZO54K

ro.build.display.id=JZO54K.T999UVDMD5

ro.build.version.incremental=T999UVDMD5

ro.build.version.sdk=16

ro.build.version.codename=REL

ro.build.version.release=4.1.2

ro.build.date=Mon Apr 15 11:54:03 KST 2013

ro.build.date.utc=1365994443

ro.build.type=user

ro.build.user=se.infra

ro.build.host=SEP-128

ro.build.tags=release-keys

ro.product.model=SGH-T999

ro.product.brand=samsung

ro.product.name=d2tmo

ro.product.device=d2tmo

ro.product.board=MSM8960

ro.chipname=MSM8960

ro.product.cpu.abi=armeabi-v7a

ro.product.cpu.abi2=armeabi

ro.product_ship=true

ro.product.manufacturer=samsung

ro.product.locale.language=en

ro.product.locale.region=US

ro.wifi.channels=

ro.board.platform=msm8960

# ro.build.product is obsolete; use ro.product.device

ro.build.product=d2tmo

# Do not try to parse ro.build.description or .fingerprint

ro.build.description=d2tmo-user 4.1.2 JZO54K T999UVDMD5 release-keys

ro.build.fingerprint=samsung/d2tmo/d2tmo:4.1.2/JZO54K/T999UVDMD5:user/release-keys

ro.build.characteristics=tmo

# Samsung Specific Properties

ro.build.PDA=T999UVDMD5

ro.build.hidden_ver=T999UVDMD5

ro.build.changelist=1128078

# end build properties

#

# system.prop for surf

#
[T-Mobile, Samsung Galaxy SIII] flipster64:
Also downloaded "Under the Hood" as well to see if it could provide more insight.

Not sure how he formats his output, but it says

Device: d2tmo d2tmo (interesting that that's what ro.product.device and ro.build.product, checked for with getprop in the updater script are both set to - but this program seems to get its info from issuing Linux commands like cat-ting files and netstat stuff)

Root Status: Device Rooted (which we knew)

It mostly issues network status commands.... shows me on WiFi (which I knew already) and it got nothing back from ifconfig -a

Anyway ... interesting.

.

In the file /proc/cpuinfo, the hardware is listed as SAMSUNG M2_ATT not sure if that was flashed there or if it was obtained from something in the hardware.

No wonder this thing is schizophrenic.

Well, wait. Just found this.

It was my understanding that the motherboards were identical... this lends some credence to that.

Nother Update...

I'd seen this before, just found it again:

http://xdaforums.com/showthread.php?t=2088220

Sorta makes me wonder if I ended up with that guy's phone as a refurb ;)
[T-Mobile, Samsung Galaxy SIII] Perseus:
Your most recent post is actually on Right Track. See here's the thing. GetProp is intended to grab values set by the Build Prop. (I could have also asked for Build.prop editor. ) But that was not my intention. What I wanted to see was what Android reported the bootloader as. I don't necessorily care for ro.device or ro.product as they are driven by build Prop.

Since GetProp ran into error, let's use long route that I was trying to short circuit. Install Android Terminal Emulator. Adjust the font size to your liking in Settings. Then Type the following commands and press enter after each.

SU

getprop ro.bootloader

After the first command, Terminal Emulator will ask for Root rights and make sure to grant those. Needless to say you'd have flashed Root66 version UVDMD5 for this to work.

Another chain of thought. This one from your most recent post. Please install Device Info app. Take a close look at what it has to say about your device. There'd be a clue. I am trying to see if the motherboard reports D2ATT but device reports D2TMO (due to Buildprop).
[T-Mobile, Samsung Galaxy SIII] flipster64:
Device Info...

Ah HA! We have a winner. What I have kinda suspected all along... (well, I didn't have a clue which file until last night when my hunch pointed me toward boot.img, but I still wasn't sure). The model is SGH-T999, but the bootloader is I747UCDLK3. Thankyouthankyouthankyou! :) We're on the right path!

So I have to install a new bootloader ... one for the right phone. If I can get past the security checks. That'll be the trick.

Unfortunately, I haven't yet found a root66 stockmod in zip format, and I can't get Odin to flash the tar.md5. But first things first.

In addition ... I read on another thread where someone was trying to apply the T999_UVDMD5_firmware update we've been looking at they were able to do it by using CM 6.0.3.0. So I installed it. But it still gave the same error, which doesn't surprise me now. (It looks like T999_UVDMD5_firmware update should replace the bootloader if I can get it to run)

What DOES suprise me is that I installed Philz 6.07.09 on here before (early last week), and now when I try to put it back I'm getting:

This package is for 'd2tmo' devices; this is a 'd2usc'. And it probably thinks that because the bootloader is I747UCDLK3.

Now ... to figure out how to start with a new bootloader. Right?

Not going to do this yet ... unless you think it's the way to go ... but it seems like if I unzipped that firmware update, edited the script (with Notepad++) and removed that first line and re-zipped it -- that it SHOULD just go ahead and nuke and pave. But caution is in the wind here.... and I didn't see a boot.img, but I'm not sure that I'm supposed to.

Here's what it does replace:

run_program("/tmp/dd", "if=/tmp/aboot.mbn", "of=/dev/block/mmcblk0p5");

run_program("/tmp/dd", "if=/tmp/NON-HLOS.bin", "of=/dev/block/mmcblk0p1");

run_program("/tmp/dd", "if=/tmp/rpm.mbn", "of=/dev/block/mmcblk0p6");

run_program("/tmp/dd", "if=/tmp/sbl2.mbn", "of=/dev/block/mmcblk0p3");

run_program("/tmp/dd", "if=/tmp/sbl3.mbn", "of=/dev/block/mmcblk0p4");

run_program("/tmp/dd", "if=/tmp/tz.mbn", "of=/dev/block/mmcblk0p8");
[T-Mobile, Samsung Galaxy SIII] Perseus:
Oh Goody! So we have bad bootloader.

I wouldn't go with the steps you have indicated. However I want you to do something similar.

But first, I understand you had downloaded the Root66 of UVDMD5. I think from your previous attempts that Odin went Ok. Can you try it again WITHOUT any PIT file ?

Now I know you have the zip of the UVDMD5 Bootloader alone from the thread I had linked. Be careful of what you do next. On PC, Open the zip with winzip or similar. DO NOT UNZIP the file. Navigate to the Updater Script file. Open it with Notepad. Look for

assert(getprop("ro.product.device") == "d2tmo" || getprop("ro.build.product") == "d2tmo");

Put a hash sign # at the begining of that line. Close Notepad. It will prompt you to save the file. Select Yes. Immediately Winzip will prompt that you may update the zip with changed file. Do so. Flash the file via custom Recovery.
[T-Mobile, Samsung Galaxy SIII] flipster64:
Yes I have. And I can certainly try again, but it'll probably die on aboot.

assert(getprop("ro.product.device") == "d2tmo" || getprop("ro.build.product") == "d2tmo");

Got it. Open it in notepad from the zip, comment that line out, and save it. Then try again.

Gotta go to a meeting....
[T-Mobile, Samsung Galaxy SIII] flipster64:
Yeah, when flashing with the root66 tar.md5 Odin, I'm getting:

<ID:0/006> Added!!

<OSM> Enter CS for MD5..

<OSM> Check MD5.. Do not unplug the cable..

<OSM> Please wait..

<OSM> root66_TMO_T999UVDMD5.tar.md5 is valid.

<OSM> Checking MD5 finished Sucessfully..

<OSM> Leave CS..

<ID:0/006> Odin v.3 engine (ID:6)..

<ID:0/006> File analysis..

<ID:0/006> SetupConnection..

<ID:0/006> Initialzation..

<ID:0/006> Get PIT for mapping..

<ID:0/006> Firmware update start..

<ID:0/006> aboot.mbn

<ID:0/006> NAND Write Start!!

<ID:0/006> FAIL! (Auth)

<OSM> All threads completed. (succeed 0 / failed 1)
​

On the download screen, under the QUALCOMM SECUREBOOT: ENABLE message, I get the message

SECURE CHECK FAIL : aboot

Very much like here:

http://xdaforums.com/showthread.php?t=2541437&page=2

I downloaded terminal emulator ...
[T-Mobile, Samsung Galaxy SIII] Perseus:
Where is

Coming from ? Did you have PIT selected or Re-Partition Checked ? Please don't use either one.

EDIT - STOP EVERYTHING YOU ARE DOING!

I am rechecking from the beginning of this thread. Something is Seriously Wrong. Don't keep trying or you will brick.

Ok Its all good. Just check regarding the .PIT file I mentioned at the beginning of this post.
[T-Mobile, Samsung Galaxy SIII] flipster64:
No, It wasn't checked. It just does it. Just PDA, and F.Reset Time (I unchecked Auto reboot, but that was a bit optimistic, it turns out).
[T-Mobile, Samsung Galaxy SIII] Perseus:
Manually Uncheck Re-Partition before trying the Flash this time.
[T-Mobile, Samsung Galaxy SIII] flipster64:
So I need to figure out what QUALCOMM SECUREBOOT is ... my guess is that somehow aboot is locked (though I've read about people get this error on aboot being anything from a bad cable to speculations about knox).

Speaking of Knox ... I was looking for a way to see if it had EVER been on this phone. A thread on another forum said look under device administrators and see if knox is listed.

There's nothing that says Knox, but there is, under Device administrators, an "Android Device Manager" which isn't checked. Underneath, it says "allow android device manager to lock or erase a lost device".

This sounds like what Knox does.

I went back through the thread, too ... noticed that I didn't actually ever successfully flash the root66 4.2 stockmod, because Odin wouldn't let me. I had installed the pre-rooted 4.3 stockmod with CM[on this phone (yes, I flashed the T999UVUEMJ4 Modem first), which is when I lost IMEI. It supposedly had knox removed ... but I just want to triple check that that isn't the problem. After that I went restored 4.1.2 from a backup, and then I flashed a 4.1.2 stockmod rom from here ... which is where we are now.

Yeah, something's definitely amiss here. I am not doing anything further until we have a better idea what might be going on.
[T-Mobile, Samsung Galaxy SIII] flipster64:
Actually, looks like it was never checked in the first place. Just tried it again to be sure ... it was never checked before or after I loaded the tar.md5 file under PDA. Could something in the tar file be causing it to do this?

Wonder if we should try Heimdall? (just a question, not charging ahead and doing it. Matter of fact, meeting my wife for lunch ....)
[T-Mobile, Samsung Galaxy SIII] Perseus:
I don't believe you ever had the Locked Bootloader. Knox is a Rom Thing and the Secure Bootloader is something else. The Device Admin thing is quiet different all together. Its not what Knox does.

What I suspect is that whoever flashed ATT image on this tried to use for ATT. But the ATT bootloader seems to be permanently glued on there. As things stand, I understand you have that ATT bootloader and T-Mo 4.1.2 OS. Is this correct? If so, can you try to flash a custom Recovery such as TWRP or CWM using Odin ?
[T-Mobile, Samsung Galaxy SIII] flipster64:
Yes on both counts, and I have CWM touch 6.0.3.0 on it right now. I had had Philz Touch 6.07.9 on there at one point, but downgraded to this one as mentioned above due to the fact that one guy with the same *symptom* said he got the UVDMD5 firmware to flash using it. But it didn't flash because of the assert(getprop()) error. And oddly, CWMOD won't let me flash back to Philz now (due to failing a device check in the script, but at least it's getting a value). Not that I think it matters if I'm using 6.0.3 or Philz (which is based on 6.0.4.5).

Never used TWRP. Would it make any difference, you think?

Or do you think re-flashing a custom recovery with Odin might shake something loose?
[T-Mobile, Samsung Galaxy SIII] flipster64:
Odin let me re-flash Philz.

But note the verbage about PIT again and I did NOT have it (repartition) checked! (or pick a PIT file)

<ID:0/006> Added!!

<OSM> Enter CS for MD5..

<OSM> Check MD5.. Do not unplug the cable..

<OSM> Please wait..

<OSM> philz_touch_6.07.9-d2tmo.tar.md5 is valid.

<OSM> Checking MD5 finished Sucessfully..

<OSM> Leave CS..

<ID:0/006> Odin v.3 engine (ID:6)..

<ID:0/006> File analysis..

<ID:0/006> SetupConnection..

<ID:0/006> Initialzation..

<ID:0/006> Get PIT for mapping..

<ID:0/006> Firmware update start..

<ID:0/006> recovery.img

<ID:0/006> NAND Write Start!!

<ID:0/006> RQT_CLOSE !!

<ID:0/006> RES OK !!
[T-Mobile, Samsung Galaxy SIII] flipster64:
aboot isn't a file I can go in with terminal emulator and chmod 770 or 777 it, is it?

Or will it just get regenerated when I boot with whatever permissions it has on it?
[T-Mobile, Samsung Galaxy SIII] Perseus:
So you were successful to flash Philz Touch. It doesn't / shouldn't matter which recovery you have. They all are good ones. Now can you try that UVDMD5 bootloader zip we modified earlier ? Flash it with this Philz Touch. Post the log and/or result.

aboot is not a file you can change permission on. Its part of a read only partition that is written to on special occasions alone.
[T-Mobile, Samsung Galaxy SIII] flipster64:
Yes, I modified it a bit ago by opening it FROM the zip, saving it, then re-opening it FROM the zip to make sure it "stuck" in the zip file.

It did.

So ... a little scary ... but ... You know it used to error out on sbl2 ... then after I flashed the 4.1.2 StockMod, it started erroring on aboot.

But they're both being replaced with that firmware zip.

So are you thinking that when I run this recovery it will be able to overwrite aboot whereas flashing the full root66 tar.md5 complains about it?

I guess it handles it differently?
[T-Mobile, Samsung Galaxy SIII] flipster64:
There must be more to this.

I have modified the script. When I open the zip file, I see that it's modified.

First time I commented the first line out. But it behaved as if it weren't commented out (failed on assert, just as before).

So the next time I just took the line out completely, and added ui_print line "SECURITY BYPASSED!!!!" line just to make sure it took...

But it is as if I have not modfied the script at all. It still fails on the assert(getprop()) ... which I have completely eliminated from the file.

I even opened the zip off the SD card itself to make sure it was copied there and modifed. It was.

So ...

When I was reading about how these zip files work, I understood the update-binary loads the script ... is that binary the same in every ZIP file, or does the script somehow get integrated into the binary using some other tool first?

Other question is, when I flash a ROM with ODIN ... should it replace the bootloader, or is the only way to replace a bootlodader through a custom recovery zip?
[T-Mobile, Samsung Galaxy SIII] Perseus:
Its not very easy to replace Bootloaders in Roms. There's a bit more complexity. Updater Binaries are not all the same. But the script does not get integrated into the Binary. Recoveries do have a different ways of overwriting System partitions. So it may succeed this way.

When you tried to flash the zip was it with the recovery or was it with Odin ? Also when you point the recovery to the file, make sure it does not goto your Internal SD card but does point to your External SD Card. If it still fails then switch to the latest CWM Recovery and then try.

Please remember, Custom recoveries may give errors if the updater binary is not compatible. So make sure to find only the latest version of the Recovery. CWM is at 6.0.4.5 and TWRP is at 2.7.0.0
[T-Mobile, Samsung Galaxy SIII] flipster64:
Philz recovery 6.07.9 which is based on CWM 6.0.4.5. The recovery is on the external SD card.

The message the recovery is giving is the "assert failed" and then spits out the line that was supposedly commented out ... I tried again and completely removed the line and it failed the same way ... spit out the assert line that was formerly in the script.

I'm going to try it again here at home.

I noted the last time it was opening with 7zip at work. But recovery didn't seem to have any problem with the zip file. Didn't whine about it at all. It just acted like it was the same old script inside.

Either I did something boneheaded three times in a row (not impossible! so I'll check again).... make sure winzip gets used here at home.

There's no way it would keep a copy of the zip cached even between reboots ... that seems like a lot of extra programming for questionable gain.

UPDATE:

Nah, it was Winzip at work. Apparently windows explorer and 7zip can't do what I thought. Working on it right now....
[T-Mobile, Samsung Galaxy SIII] flipster64:
Well, this time it took. Went ahead and ran the script. Went through the checksums. Said it was done.

I think we're hard bricked.

Don't even get a vibrate from the power button.

Is it worth sending anywhere?
[T-Mobile, Samsung Galaxy SIII] flipster64:
Wow,this can really be done with a microsd card and a usb cable?
[T-Mobile, Samsung Galaxy SIII] Perseus:
So you think its bricked ? What happens when you try to plug to a pc and hitpower button ? Does pc recognize it as before or some new device QHSUSB-DLOAD ?

If that's the case you can follow the De-Brick thread. If you find that's too much hassle, you could ask T-Mo for replacement.

If it does recognize correctly then let me know. Maybe the battery may be dead. Let it charge overnight.
[T-Mobile, Samsung Galaxy SIII] flipster64:
Yeah, actually the computer recognized it ... didn't succeed in installing the driver, but it recognized it as QSBHUB_DLOAD. Surprised me.

Seriously doubt the battery's dead. I keep it pretty charged, and I haven't had this thing more than 3 weeks - it's a good battery. I just swapped it out for a fresh fully charged battery (I always buy a spare for my phone, and I have an external charger), and no difference.

So I need a 16 MB class 10 micro SD.

I've downloaded the pre-4.3 debrick Win32disk image for this model (from that very thread, no less :) ). And I have Odin and ROMs out the yin yang. Hell I've come this far. Can't really get any worse, right? ;)

So if I go through this ... and if it works ... should it wipe everything on the phone and blow that bad bootloader away, or just get it back to where we were?
[T-Mobile, Samsung Galaxy SIII] WhoWhere:
I had a thought on this. If it hard bricked due to flashing the firmware update, it sounds like it might truly have an AT&T motherboard.

If that is the case, my understanding is that you would need an AT&T debrick image. Not T-Mobile. I could be wrong, my knowledge on how kasper's process works is limited.

Sent from my Samsung SGH-T999
[T-Mobile, Samsung Galaxy SIII] Perseus:
Yeah it should blow the bad Bootloader away if indeed its a T-Mo Motherboard. But if the Motherboard indeed is ATT then the De-Brick Process will likely fail.

Having said that, T-Mo should not be giving you a mish-mash Phone with mixed hardware anyhow.
[T-Mobile, Samsung Galaxy SIII] WhoWhere:
My understanding is that he purchased it off of Amazon with CM installed on it. I'm wondering if the previous owner did some kind of oddball fix.

Sent from my Samsung SGH-T999
[T-Mobile, Samsung Galaxy SIII] Perseus:
My impression was that he got it as a Refurb from T-Mo as a replacement with ATT 4.1.2 Rom on it.
[T-Mobile, Samsung Galaxy SIII] Perseus:
Yes there is a quiet real possibility that someone put a i747 board inside SGH-T999 and sold as Refurb. If that's the case then you will indeed need an ATT image not T-Mobile image. Since successful flash of T-mo bootloader bricked the phone, we may have to consider that this is a I747 despite what Sticker says. This may also explain why you lost IMEI upon flashing T-Mobile Modem.

Now that's not such a bad thing. There indeed is a big difference between i747 and T999. That is, i747 has an LTE Antenna and T999 does not. So, you are likely to get higher data speeds when T-Mo rolls out LTE in your part. But given your signal issues you couldn't care for that. There indeed is a ATT version of that same Stock Mod Rom you had tried earlier. It too needs you to flash an ATT modem before you flash that Rom. See if it allows WiFi Calling.

Next Steps ? Well you can try a T-Mobile De-Brick image. But if it failed, you know you will have to try ATT image. After the phone is back up, you can try the ATT StockMod Rom. If it doesn't have WiFi Calling then take their latest modem from that thread and then try the T-Mo StockMod rom you had tried earlier.

Thanks for giving background. It helps to know you have some techie background. Its the mindset that matters not knowledge.