yashsingh1/xdaforums huggingface dataset:
[Verizon Samsung Galaxy S III] newuser134:
sorry for the confusion, didn't mean to....

Ok, when ac21365 took his phone to Germany, he had wcdma 2100 working, NOT 1900. Only the 2100 band seems to work on this phone on wcdma (for HSPA+). Then you said that since 2100 worked and he could get HSPA+, that is proof enough that you guys should be able to get 1900 to work as well just by adjusting menu settings, without having to cross-flash an AT&T modem, so the long sentence was my response to that. What I meant was that I have personally exhausted all tries on the band selection menu under *#2263#, and nothing worked, so just like on the Samsung Note i717, even though the hardware may be there, menu manipulation may not work by itself, a different modem of hardware firmware may be required to unlock the 1900 band, the way a t-mobile modem unlocked the 1700 band on an AT&T Note, which wouldn't otherwise run on 1700 MHz.

The reason we all think that the wcdma 1900 MHz hardware is there, is that gsm 1900 works just fine with that same UMTSZ menu selection, and to date, there has been no Qualcomm radio chip that has had all gsm bands and wcdma 2100, but not 1900, 2100 and 1900 almost go hand in hand, so it seems unlikely that they went to all this length to make one without it. Besides, the radio chip is the exact same chip as in the AT&T i747, and that one has 1900 and 2100 MHz bands. Hope this clarifies what I meant a litte better. Thanks for your help again.
[Verizon Samsung Galaxy S III] E:V:A:
1) Can you provide a small code excerpt of this?

2) Then perhaps we could get this working through direct modem manipulation. Have anyone been able to speak AT command to your phone modem? (I remember asking this in the unlock bootloader thread long time ago, but apparently the AT command interpreter wanted some "magic" code in order to set the phone into debug/development mode so that tweaks could be done. If anyone here have been able to connect, that could be a way to change settings. Like in previous galaxy's the service mode functions were contained in the modem image. Not sure how it is with Qualcomm phones though...

3) Odia suggested long ago, you might be able to set your IMSI to 9999... to pretend to have a "Factory SIM", on SGS2. (*#46744674#, "IMSIIMSI") This would allow you to have more options in But this was not confirmed for the SGS3 (GT-I9300), in addition it wasn't clear if this was persistent after reboot...(which could be very bad.) Look in that thread and perhaps you can reverse some more APKs specific to the i535, to get new values & codes that can be used for this...

My bad, misunderstood as you having 1900 working as well... No difference, but pure menu manipulation is then probably not enough.
[Verizon Samsung Galaxy S III] ac21365:
Sorry if my post last night was unclear and a bit condescending/snarky, and thanks to newuser1234 for clarifying the point I was trying to make.
[Verizon Samsung Galaxy S III] newuser134:
From the thread about enabling the AT&T Galaxy S3 i747 to work on AWS 1700

This is currently, so before the completion of the refarming to 1900 MHz.

http://xdaforums.com/showpost.php?p=31984817&postcount=148

More wind in the sail for our case scenario.
[Verizon Samsung Galaxy S III] mybook4:
I will post this and the file list when I get home. The original goal of the SecSettings.apk decompile was to make a 4g toggle (rather that use phone info).
[Verizon Samsung Galaxy S III] newuser134:
Taken from the AT&T Note thread, how to unlock it for t-mobile, this is kind of like what we're trying to do, but from 2100 to 1900, instead of from 1900 to 1700 in the case of the Note.

http://xdaforums.com/showpost.php?p=22891862&postcount=7

I wonder if anyone can find the factory manual for the i717 Note and see if the specs state anything about the AWS 1700 band in it, just to see how similar the case is to the i535.
[Verizon Samsung Galaxy S III] mybook4:
ParanoidBackup mmcblk0pX partition backup script

Down the road if we flash another modem, we can use this script to backup our paritions (other than system, data, and cache). This doesn't replace the Synergy IMEI backup, but will make copies of all the little mmcblk0pX partitions just in case there are things on them that flashing another modem could break.

The script works for Linux. It can be run by extracting the zip files, opening a terminal to the directory, and typing "./ParanoidBackup.sh" or "bash ParanoidBackup.sh".

Restore takes manual dd commands (PM and I'll send a restore script). I left the restore feature out for safety. Eventually I could make this into a CWM script or a Windows Batch script if enough people want it.

Linux ParanoidBackup script v1
[Verizon Samsung Galaxy S III] newuser134:
Yes, could you please make a Windows batch script if you don't mind?

Thank you
[Verizon Samsung Galaxy S III] mybook4:
New versions of each (v1). Give the Windows one a try. Worked fine on my PC. If it doesn't work for you, PM me and I'll fix and repost.

Paranoid Backup Script Linux v1

Paranoid Backup Script WIndows v1
[Verizon Samsung Galaxy S III] E:V:A:
Very nice work! Some time ago, I created a brief tutorial based on the devmaze stuff for using the Android Internal Java API:

"[APP][DEV][GUIDE] Using the Android Java Internal/Hidden API classes"

I had some trouble getting it all to work for successfully using your own android.jar but the essence is there, and using another one, I could successfully compile...

If we're to explore this route, I have the following comments:

1) We may try to replace the SecSettings.apk with that for the other device, or see if they differ in any way.

2) Probably (1) doesn't differ, but the C-sources used by that apk most likely do. So if we have the sources available (as we should), perhaps we can run a diff on the relevant C-code...

Because any hash function would fail for any difference, you'd miss-out if that difference consisted of just one bit... So I'd suggest to run a bindiff on the files with the same size to see if there are just a few bits changed, or entire blocks. If entire blocks are unreadable, they could be compressed or encrypted... ==> No go.

In addition:

a) I'm curious to know why the files have the same size, if they are different?

b) Does adding-up all the file sizes in the NON_HLOS.bin directories, from the two different firmwares, add up to the same size? (It's probably not enough to just compare file size of the two "NON_HLOS.bin" files, on their own...compression levels and packaging algorithms...)

c) Can you please post direct download links to the modems you're working on, so that we can be sure to work on the same thing.
[Verizon Samsung Galaxy S III] mybook4:
File Name:

dsps.b05

File Size:

13824 bytes

Observations about differences:

End of file seems to have a regular pattern.

Differences between VRLG1 and UCLG1 are many (too comprehensive to list manually). Manually open in vbindiff or see this diffnow report for differences. VZW file on the left, ATT file on the right.

---------- Post added at 01:10 PM ---------- Previous post was at 01:06 PM ----------

File Name:

dsps.b00

File Size:

244 bytes

Observations about differences:

No differences (not sure how/why the md5 comparison showed a difference)

---------- Post added at 01:14 PM ---------- Previous post was at 01:10 PM ----------

File Name:

dsps.b03

File Size:

31872 bytes

Observations about differences:

Some scattered changes as well as some blocks with a regular pattern of differences.

Differences between VRLG1 and UCLG1 are many (too comprehensive to list manually). Manually open in vbindiff or see this diffnow report for differences. VZW file on the left, ATT file on the right.

---------- Post added at 01:17 PM ---------- Previous post was at 01:14 PM ----------

File Name: dsps.b01

File Size: 160 bytes

Observations about differences:

Small file, half of it is different

Manually open in vbindiff or see this diffnow report for differences. VZW file on the left, ATT file on the right.

---------- Post added at 01:20 PM ---------- Previous post was at 01:17 PM ----------

File Name:

dsps.b04

File Size:

6220 bytes

Observations about differences:

Scattered changes with a regular pattern of differences near the end of the file.

Manually open in vbindiff or see this diffnow report for differences. VZW file on the left, ATT file on the right.

---------- Post added at 01:22 PM ---------- Previous post was at 01:20 PM ----------

File Name: dsps.mdt

File Size: 404 bytes

Observations about differences:

Small file, differences at the end of the file.

Manually open in vbindiff or see this diffnow report for differences. VZW file on the left, ATT file on the right.

That's all for now...
[Verizon Samsung Galaxy S III] E:V:A:
Woa! I think you understood me perfectly on all points.

DiffNow was a cool happy addition to my bookmarks.

But I think it should be enough to only check the modem files, since the other ones are for: (Audio) DSP, Wifi (WCNSS), TZ (Trust Zone) and Q6 I don't remember, but I think its the PMIC watchdog...

There must be a more efficient way to do this. Perhaps by scripting a diff of strings output.

Also I'd like to know the functional difference between the f1 and f2 labelled modem files (for the same firmware)? Anyone have any idea?

I'm afraid that we risk wasting time/effort on this, since we're basically just looking to activate something that should already be available, this diffing seem like finding a needle in the haystack. So does anyone else have any opinions or suggestions? I also suspect that this can be found/controlled in and by the NV entries, as seen by QPST.
[Verizon Samsung Galaxy S III] mybook4:
Haha, I didn't put two and two together. I was staring at the files but didn't notice that the names correlated to different functionality. I'll focus just on the modem files.

I have no clue what the difference is between the f1 and f2 modems.

Maybe we should focus on the following (what does everyone think?):

1) find someone with JTAG (or through proof from koriotto) who can tell us whether or not flashing an AT&T modem will brick our device (if it works it may just be the simplest solution (similar to the note2TMobile thread)).

This could also tell us how far we can go. If we can flash a modified modem (add a file or flip a bit), we could potentially make a custom modem if the AT&T one doesn't work outright.

2) Find pictures of an i747 teardown. We already have i535 teardown pics from Adam in the bootloader unlocking thread. If there are extra radio/modem chips on the i747 then we are probably out of luck.

3) keep diffing the modem files to look for something that might be meaningful

4) look at the NV items in QPST for the i747 and i535. Compare for clues.

5) reverse engineer the modem files (using something similar to Ralekdev's method) of an i747 and an i535 to see if there are any i535 1900MHZ WCDMA blocks or any i747 code we could add to help enable 1900Mhz WCDMA.

6) continue to follow the rabbit hole from SecSettings.apk down to the modem (through apktool decompiling, looking through Android internal API, etc). If there is a block or lack of functionality, it could be before the modem.

Thoughts? Additions? Anything I'm forgetting?
[Verizon Samsung Galaxy S III] worldlyinquirer:
I would to add $10 to the bounty
[Verizon Samsung Galaxy S III] E:V:A:
Ok, so I have been looking again at the Qualcomm tools: QPST and QXDM.

At least the "latest" publicly available QPST (2.7.378) is what we need in order to read the NV items that are related to enabling your band PCS 1900 (if I understood this right). Problem is that that version of QPST doesn't properly support the MSM8960 yet, only the MSM8660, so you will probably have to be extremely careful, if you hope to try to write those items back, if it works at all!

There are also other tools that can be used to modify Qualcomm devices. I don't remember which, but search in the threads related to restoring IMEI. In fact these tools may be safer to use, as they are available of a later version...

Here is a picture of QPST showing the preferred UMTS bands. The one we are interested in is called PCS 1900.

Here are the related (and changed?) NV items for selecting only PCS 1900.

The NV item of interest is called:

946 NV_BAND_PREF_16_31_I

This is a 8*16 (128) byte array, where PCS1900 is controlled by byte #2 in which case there should be an 0x80 in that position, AFAICT.

So if we choose to do this the tough way, by some risky hacking of modem images, we need to understand where the NV items are stored in all those files we mentioned earlier. This is not recommended, but could prove very educational for creating our own tools...

Finally after inspecting some of those modem files, it seem that modem.b03 is the one that contain the Service Menu functionality, including the menu text of the switch to PCS1900 (at offset 0x8d43).

So I'd like someone to try to:

1) Make a me a NV backup and post a download link (via PM if you're paranoid.)

2) Making sure you have set RAT to use WCDMA

3) You might need to select a preferred mode as well...

I'm a bit worried about the "reading and writing of WCDMA 1900 RF NV", whether it is to or from the phone NV??
[Verizon Samsung Galaxy S III] mybook4:
Nice work!

This may help find the location of where nvitem related data is stored. The comprehensive IMEI backup script backs up:

-mmcblk0p11 (efs)

-mmcblk0p12 (modemst1)

-mmcblk0p13 (modemst2)

-mmcblk0p20 (backuo

-mmcblk0p21 (fsg)

-/data/misc/radio

The script seems to do a good job of restoring people's IMEI (which is an nvitem).

I noticed there were other items that were circled. Why would only 946 need to be adjusted? Were i535 and i747 nvitems compared? Not trying to be skeptical in any way, I'm just interested in the rationale.
[Verizon Samsung Galaxy S III] newuser134:
I only had a prepaid AT&T sim when I flashed the AT&T rom, it updated the APN's on its own, bu I had to use phone info app to even get gsm signal. Once I did that, I got voice, sms and edge data, nothing else. The only difference was that I was no longer getting the "non-verizon sim" warning. Judging from this, the lack of wcdma on PCS1900 is NOT controlled by secphone or ANYTHING that is on the /system partition, it must be deeper. I was also able to manually switch bands, through netmonitor app or *#2263# menu, to gsm 850, 900, 1800 and 1900, and to wcdma 2100 (IMT2000), but not to wcdma 1900, so whatever disables the 1900 band, is deeper than either Verizon or AT&T rom, it's either modem or NV items.

I think items 4) and 5) above from mybook's post are going to be our best bet if there are no radio chips missing, and I strongly don't think there is any hardware missing.

I think E:V:A's post 79 has almost hit the nail on the head, if NV settings were found on the msm8660 that point to what frequencies are enabled, we should look at the same entries on the msm8960 to see what the differences are, I know it was said that QPST is not yet compatible with 8960, but shouldn't we able to just read the differences I not write to NVitem just yet? Just reading a different value would tell us if wcdma 1900 is disabled or not. Anyway, wasn't QPST used on msm8690 to restore the imei for those who had the missing imei error after CM-9 or CM-10? If so, why can't it be compatible now to read/write NV items?

Our best bets are:

1) Follow the NV solution that E:V:A has started on.

2) Find out for sure if the AT&T modem will brick or not, and if not, proceed to flashing an AT&T modem along with the AT&T rom, use with a "real" post-paid AT&T sim, make sure all the correct APN's ("ptn", "phone" and "wap.cingular") are there under network settings, and if a pure AT&T modem doesn't solve it or give any signal reception, proceed to find the "missing" modem code portion for wcdma 1900, and make a hybrid modem that will enable 1900 MHz.
[Verizon Samsung Galaxy S III] newuser134:
I've proceeded to look for and price RIFF boxes to get a jtag connection setup. I have no prior experience with this specifically, but I have the necessary hardware knowledge. Would someone help do some research on how to build the connection board from the RIFF box to the i535 main board, where the jtag pad is on the i535, and what RIFF firmware is required to connect to the i535 Galaxy S3 and to restore it to Odin mode/restore bootloader? On their website, they have some information about how to restore an i747 (AT&T version). It wouldn't be any more expensive to set up for using jtag than to buy a new Galaxy S3, and since I believe I might have the hardware knowledge and experience, I might as well do that. Then we can basically flash any modem we want.
[Verizon Samsung Galaxy S III] E:V:A:
@mybook4: That was done on the AT&T I747 modem you linked to above.

But "that" modem image, to what partition(s) does it go?

Also, when changing only that one band (PCS1900), all those NV items appeared, which imply that they are all involved. (For band selection purposes and check sums, etc.) The one I mentioned above is the location responsible for "our" band.

BTW. The NV items, as shown, was not obtained from anywhere, just an empty QPST run, with nothing connected!

Also, I have not searched XDA properly for NV items and NV settings modification. This is a very common thing to do for many other purposes, so please let's check around again... Especially in the IMEI rebuild threads.
[Verizon Samsung Galaxy S III] E:V:A:
That's correct, we should always be able to read already existing items, but only maybe write. Writing success depend on if they have introduced additional NV items for the MSM8960. (Read accompanying docs of QPST, on how QPST handles new and old values.)

RIFF box should already come with an appropriate JTAG connector that should fit your i535, you should not have to build anything! (Ask them about it!) ... Not sure what you mean with "any modem", you can already flash any modem, if you know how to.

Finally, about bricking. You will not be able to hard brick your device, unless you physically mess it up. The emergency download mode in Primary bootloader ensures this. However, the problem is that I have not yet seen any posts/instructions on how to use this feature, for this device.
[Verizon Samsung Galaxy S III] E:V:A:
Just for reference, here is the "official" Samsung partition table layout.

Damn if I know if this has any connection to reality, but that is up to you guys to check...

As you can see there are several possible locations where "NV items" can be stored...
[Verizon Samsung Galaxy S III] newuser134:
Oh, sorry, I didn't mean that then we can physically flash any modem we want as opposed to not before having the RIFF box, or due to not knowing how to. I meant then we don't have to worry about "hard bricking", as in getting stuck during the boot chain and not make it to Odin or CWM after flashing any AT&T modem, because when we have the jtag recovery ability, we can always recover from that kind of brick, so we can flash any modem without the worry about anything any more, because now we have the peace of mind that we can recover from it no matter what, if we have jtag and know how to use it. So that statement meant that we're mentally prevented from flashing right now because we don't have a consistent way of recovering if the AT&T modem causes failure to boot the phone, not because of not knowing how to flash an AT&T modem, and that with a RIFF box we would figure out how to flash a modem. It's more like if you know how to fix something or recover from something, you won't be worried about breaking it and getting stuck, so you'll try more things without the worry of messing something like that.
[Verizon Samsung Galaxy S III] mybook4:
Modem is flashed to mmcblk0p1.

Sarcastic IMEI restore example (based on looking at the CWM scripts in the Synergy backup script) :

-A savy/cool user goes on xda/rootzwiki and finds out that he should back up his IMEI.

-Using the Synergy IMEI backup script, he backs up his IMEI. The script makes backups of his mmcblk0p11, mmcblk0p12, mmcblk0p13, mmcblk0p20, mmcblk0p21, and /data/misc/radio. The script creates a restore zip with these files and a CMW friendly META-INF folder (which contains a restore script). If the user loses IMEI, all he has to do is flash the restore zip.

-user loses IMEI (Thanks Qualcomm / Samsung for the factory firmware easter egg). It's a "feature".

-user rushes to CWM, flashes the restore zip and his IMEI backup is restored. The restore CWM script inside the restore zip flashes the user's backup copies back to their respective locations (overwriting the messed up data caused by the firmware routine which borked IMEI).

-user rejoices knowing he dodged a bullet

In all seriousness, based on this info, I believe Nvitems are stored in modemst1, modemst2, and efs partitions. This is supported by the fact that the user does not have to reflash the modem partition to restore IMEI. This is also supported by the partition map.

The belief in the IMEI comprehensive backup thread is that modemst1, modemst2, and efs are the primary nvitems storage locations, with fsg and backup being backups of them. It's unknown what the /data/misc/radio directory holds but it is believed by TrevE to potentially hold important info, so the script backs it up. See below:

Explanation of EFS and IMEI related partitions as well as nvbackup/restore boot entry points

Some theory of what happens during IMEI corruption

---------- Post added at 08:45 AM ---------- Previous post was at 08:34 AM ----------

Let's grab nvitem backups of both the i535 and i747. If we compare and use the info EVA provided, we might be able to write the appropriate nvitem(s) to enable 1900Mhz WCDMA. I don't believe the modemst1 and modemst2 partitions are signed (so we should be able to make the necessary modification without running into a bootloader issue. Plus we'd have a way to backup. Since we know what hex blocks we are looking for, it might make sense just to manually pull modemst1 and modemst2, make the changes in a hex editor and then flash back. This would remove the potential for QPST/8960 incompatibilities. We would need confirmation that QPST actually only writes to modemst1 and modemst2.
[Verizon Samsung Galaxy S III] mybook4:
Verizon i535 NV Data

Attached is my (i535) NVItem 946

I'm looking at my NVItems and comparing to modemst1 and modemst2
[Verizon Samsung Galaxy S III] mybook4:
Disclaimer, since this version of QPST doesn't support the 8960, I'm not even sure if we are looking at properly labeled settings.

In the i535 NVItems, there are many GSM, GSM 850, GSM 900, GSM 1800, GSM 1900, EDGE 850, EDGE 900, EDGE 1800, EDGE 1900, WCDMA and WCDMA 2100 settings, but nothing that explicitly states WCDMA 1900

I noticed that values change between WCDMA settings.

For example:

NVItem 856 (NV_WCMDA_VGA_GAIN_OFFSET_I) is a different value than NVItem 3759 (NV_C1_WCDMA_2100_VGA_GAIN_OFFSET_I). Not sure if this means we would need specific values for 1900Mhz.

It could potentially be beneficial to compare the i535 QPST backup to an i747 backup to see if the i747 has defined settings for WCDMA 1900.

I searched through my modemst1, modemst2, and EFS partitions for my NVItem 550 data (my IMEI) but couldn't find anything. I tried searching for several combinations (forwards, backwards, only subsections, reversing bytes/nibbles) but couldn't find anything. This doesn't necessarily mean the IMEI data, or the rest of the NVItems, aren't stored on these partitions. It could mean that they are stored in a way we don't understand. I just have a hard time believing that they aren't stored in modemst1, modemst2, or EFS considering that the IMEI backup script successfully restores IMEI after restoring these partitions (along with fsg, backup, and /data/misc/radio).
[Verizon Samsung Galaxy S III] E:V:A:
Because it's called PCS 1900 and WCDMA is known by many other names...

Not sure what you mean about "values", but I wouldn't worry about it right now. The thing we should worry about are possible check-sums. All others are tuning parameters etc.

Certainly we don't understand how these are stored. But the resulting QPST *.qcn files may have some hints.

Perhaps someone can post an NV backup file from QPST?