yashsingh1/xdaforums huggingface dataset:
[Verizon Samsung Galaxy S III] newuser134:
Maybe that's why wcdma 1900 or the PCS band is not active. They call it wcdma in the service menu, so I wouldn't be surprised if that's what they would be calling it in the NV code too, I never saw it referred to as PCS, but that's not saying that it might not be called that. Anyway, if we compare the AT&T NV items equivalent to these, and they do contain code referring to wcdma 1900, I'd say that's a good step toward sniffing out a major difference between the phones. We need someone to make up a dump of the exact same partitions from an i747 to compare to these in the hex editor to look for wcdma 1900 references. That would be a major step, even if it may not necessarily be the one we're looking for.

One question, even though restoring these partitions would restore imei, does imei necessarily have anything to do with a certain frequency being locked out? All phones, regardless of what band they operate on, have an imei, it's just something that identifies the phone to the carrier, it may not have anything to do with frequencies being active or locked out. What is the logic behind connecting the restoration of the imei partition with finding what might be locking out the 1900 MHz band?
[Verizon Samsung Galaxy S III] mybook4:
The logic behind connecting the restoration of the IMEI with the 1900Mhz stuff is as follows:

-When a user loses his IMEI, restoring his IMEI backup (from the Synergy script) restores his IMEI (...yo dawg, we heard you like IMEI...)

-The script restores mmcblk0p11, mmcblk0p12, mmcblk0p13, mmcblk0p20, mmcblk0p21, and /data/misc/radio

-Since the user had no IMEI previously (and no data connection), but now has it, at minimum the IMEI NVItem is most likely stored on one of those partitions

-It would make sense that all NVItems are stored in the same location

-If we find that location definitively, it not only adds to the community's general knowledge of the device, but also gives us an opportunity to see how we could make changes to the NVItems to potentially add 1900Mhz PCS (WCDMA/HSPA+)

-One method is to use the version of QPST (2.7.323 which doesn't have native support for the 8960). Another would be manually editing the partitions.

-If we are only talking about changing values within a few known NVItems, then a simple hex editor could do it. If we'd have to add more NVItems or perform a more comprehensive overhaul, then we're probably better off taking the risk of using QPST.

-However, we still need to know what would be affected if QPST doesn't perform the changes correctly (due to it lacking native support of the 8960)

-If all NVItems are stored in a partition that the Synergy IMEI backup script backs up, then we might not have anything to worry about. In that case, a simple restore would probably fix any QPST problems we'd create.
[Verizon Samsung Galaxy S III] newuser134:
I am just wondering though, if you lose your imei and therefor lose data, it's not because of the lack of radio connection, it's because the network doesn't recognize you and doesn't authenticate your phone on the network, hence a lot of people that lost their imei, could still roam, which means the radios on the phone would still receive and transmit.

The lack of PCS 1900 MHz could be due to either of these reasons: 1) disabled radio on that band 2) The lack of authentication for the use of that band. Since wcdma 1900 isn't used by Verizon anyway, I would assume authentication would not really play a role, the AT&T sim should still allow the use of that band, so this tells me the problem is deeper, it's not on the same level of losing imei and not having data, but I could be wrong, this is just my thought. I would assume it would be due to lack of something that controls the radio itself, not data that helps authenticate the phone on the network, because that would mean there still is radio activity. Whatever disables 1900 MHz, disables that radio band for wcdma (not for GSM) all together, it doesn't just not allow it not to register on the network (AT&T's network in this case). These are just my thoughts in an attempt to try to understand the logic behind this, I do not in anyway imply that we shouldn't follow this path as well as any other path, because we should try all possibilities if they seem likely at all to have anything to do with the 1900 MHz issue. So please don't stop checking into the NV items on the account of my questions. I think the work you devs are doing on this, especially mybook's amazing line-by-line search for a clue, is extremely groundbreaking, and we all really appreciate it. It seems that with the help of everyone, we'll find the cause one way or another.
[Verizon Samsung Galaxy S III] mybook4:
This is a guess, but if you erased all your nvitems, I imagine you wouldn't even be able to connect to a tower/network. The thought that E:V:A provided is that we may just need to tweak some Nvitems to gain 1900Mhz HSPA. I'm not 100% on this, but specific Nvitems settings may be able to enable or disable certain capabilities that the modem already has. This is the driving point of the investigation into comparing i535 and i747 nvitems as well as locating where they are stored on the device.

You bring up a good thought. We don't really know the extent that the IMEI erasing firmware bug messes up nvitems. It would be interesting to compare all three nvitem sets (i535, i535 after loss of IMEI, and i747).
[Verizon Samsung Galaxy S III] autoprime:
mybook4, I noticed on the previous page you were unable to locate the NV item containing your IMEI? Is this still the case? Which version of QPST are you using... build 378 works for me and my Sprint Galaxy S 3. Try sending the 16-digit password to the phone to see if it unlocks more NV items. The 16-digit password can be sent using QXDM or DFS or CDMA Workshop. I'd assume the password would be - 2010031619780721.

If you did erase your nv items, you def wouldnt be able to connect to anything. phone might not even stay booted.

And as for the IMEI loss bug... I thought that was just wiping the ERI file(causing a cosmetic roaming issue) and the IMEI NV item(550).. and restoring those 2 files fixes all. Is this not the case after all? are there confirmed other nv items affected?

*edit*

Again I want to specify I have a Sprint model. I decided to backup my EFS.. I used QPST EFS Explorer 2.7 build 378 and backed up everything.. folder by folder. Obviously /nvm/num/ contains our NV items. After backing up all NV items I closed QPST, opened DFS and sent the 16 digit password for my device. Copying over the NV items again showed that not all NV items were previously available and now were.. 550 for example. Some NV items you have mentioned previously are not available on my device. NV items 856 and 3759 for example. Obviously we don't have a sim slot in our sprint version so these NV items were left out. This just makes me think previous assumptions may work.. adding NV items present in the ATT version that are missing in the Verizon version. Or edit previously available NV items to match ATT version.

also, I havent read all 10 pages but it seems no one has flashed an ATT modem? For what it's worth, I've flashed an ATT modem to my Sprint device. The modem had to be flashed in CWM not Odin. I had no signal whatsoever with this modem. I'm not suggesting anyone try this.. just saying what I've done on my Sprint version.
[Verizon Samsung Galaxy S III] jclendineng:
Yea 16 digit pass works. Used dfs and qpst to verify.
[Verizon Samsung Galaxy S III] E:V:A:
Hello Autoprime, nice to see you here!

Yes we definitely need to use at least build 378!

Woa! Where did you get that from?? (Or is that the SPC?)

@newuser134:

Yes, that's right. There are at least four ways to disable networks, given that it's supported by the hardware.

1) Is on the SIM card, where access to certain carriers can be blocked. I assume that whoever is trying to use PCS1900 is also doing this with a AT&T SIM card. I have no idea how this is done, in SIM-less phones... Anybody? This is also why it may prove useful to get a direct modem AT command connection. We can check your SIM card to see if these features are enabled or disabled, including many other network settings & behaviors.

2) By NV items, in the service providers. If you fire up QPST you will find several tabs/places and ways that one can block and/or configure what and when to connect to certain bands and providers. Even if you don't have the guts to run QPST on your own phone, it's very educational to fire it up for a "dry" run without anything connected, just to get an idea what is possible. In the QPST distribution there is also a (outdated and lacking) manual, that explain many of these functions. Including how NV items are added and appended, with new and old ones.

3) The network itself. E.g. if you're on AT&T and trying to use the Verizon network at a their premium (highest supported) bandwidth, you may be blocked by their network. <== my speculation!

EDIT! 4) Our modem firmware may be completely crippled by leaving out all functionality of certain bands/networks. But our previous discussion about roaming in Germany, seem to have excluded this possibility. (Which would indeed have been a ridiculous thing to do.)

@ "ALL":

I'd like to understand the *.qcn NV-file structure. I've been searching, but not found any one concrete description how these files are structured. If anyone have more information or idea where to find this relevant information. Please post. All I can tell as of now is that running strings with 16-bit little-endian yield different info than just using 7-bit ASCII...

[SIZE=2]strings -a -4 -t x [B]-e l[/B] i535_GS3_QCN_IMEI_censored_copy.qcn

200 Root Entry
280 File_Version
300 00000000
380 default
600 Root Entry
680 File_Version
e00 NV_NUMBERED_ITEMS
e80 Mobile_Property_Info
f00 Feature_Mask
f80 Roaming_List_00000000
1000 EFS_Backup
1080 NV_Items
1100 EFS_Dir
1180 EFS_Data
1200 EFS_Dir
1280 EFS_Data
1300 NV_ITEM_ARRAY
1380 00000000
...

strings -a -4 -t x i535_GS3_QCN_IMEI_censored_copy.qcn

16ca M8960A-AAAANAZM-1.0.442802
16e6 QPST Software Download 2.7.0.323
1748 pdp_profiles/config
2840 LWpN
4732 ( l
...[/SIZE]
[Verizon Samsung Galaxy S III] autoprime:
Good to see you as well! It seems you always end up in the interesting threads. :good:

As for that password, the exact definition can be found in QXDM itself. By opening QXDM and click on the "View" dropdown menu, select "Script Help for DM Commands" which shows the following for the "password" command:

"Send the security password to the target. This is the password associated with the A/DMSS security plan, not the service programming code (SPC). If a target has this password set, sending this command with the correct password will unlock secure features (memory peek/poke, port I/O). If the wrong password is sent then the target powers down"
​

The password I supplied, 2010031619780721, worked on a Verizon Samsung Fascinate(Galaxy S1 device) so I assumed it'd work on the VZW Galaxy S 3. For our Sprint devices the password 01F2030F5F678FF9 works on the entire Galaxy S line. Here's an example of more - http://xdaforums.com/showpost.php?p=19686140&postcount=32

I am not sure if GSM carriers have this? Either way.. the Verizon devices are able to edit NV item this way. So it is possible to read all WCDMA settings from a GSM GS3 device and then manually write them with QPST EFS Exp or QXDM NV Browser(See further down)

And for example.. the command would be entered as: password 01F2030F5F678FF9

Are you able to use QPST EFS Explorer to see the NV items? I am able to view each NV item. I can edit the item by copying it to the PC and then editing it manually with a hex editor then copying it back into EFS Exp(sometimes the file in EFS must be deleted first before the edited NV item can be written). An alternate method to this is using QXDM NV Browser. QXDM NV browser should be able to read all active NV items once the SPC/Password is sent to the device. If ALL WCDMA related NV items match between AT&T/VZW models then HSPA+ should work. If HSPA+ still fails, then I'd have to assume the "block" is coming from the modem itself.
[Verizon Samsung Galaxy S III] E:V:A:
Awesome! Obvious OT question is then, how do you obtain it? (Where is it located?)

Ah, also very nice. But I failed to state my intention. I wanted to find the relevant raw *.qcn file offsets for some obvious NV items, in hope that we could use that hex data to directly search for the settings inside the modem images...

This should work, unless NV items are encoded in some other way, once in memory. Once in memory, we may be able to write (hexedit) directly in the modem memory...or at least on the backup partitions.
[Verizon Samsung Galaxy S III] mybook4:
@Autoprime: Thank you and welcome!

We were able to use QPST to read the NVItems, but I'm unsure of exactly where they are located on the device (useful for backing up before messing with the NVItems). I preliminary searched through mmcblk0p11 (EFS), mmcblk0p12 (modemst1), and mmcblk0p13 (modemst2) in a hex editor, but was unable to find any of the NVItems (I searched for my IMEI from NVItem 550; I also searched for variations of it). I'll try some of the modem partition files next. I was hoping to see the files in modemst1 and modemst2 as the "official" partition map labels them as NV data. They could very well be in those partitions but be obfuscated in such a way (encryption?) that I didn't recognize it.

Thank you for the info on the ATT Modem flashing. We are a bit hesitant to flash one on the i535 due to signature checking and enforcement (secure boot). @All, Autoprime's description (modem flashed but no signal whatsoever) also matches what Koriotto said happened when he supposedly flashed an ATT modem on the i535.

Like you mentioned, it sounds like our best bet is to update NVItems to match ATT (if necessary), then if that doesn't work dive into making modem changes.

Could searching for 1111111111 in the file I sent you help to find surrounding data and learn about file structure? Would we instead need the defined file structure for a qcn file?

I was unable to find NVData in EFS, modemst1, and modemst2 but I will be looking deeper into them. Good point about searching in the modem images. I'll take a look at them next. Although I highly doubt any NVItem data would be stored on the modem image (mmcblk0p1) as every i535 user can flash a modem but every i535 user has a different IMEI (NV Item 550).

That brings us to some of our previous questions. The modem partition (mmcblk0p1) is signed. Not sure if the leaked aboot (mmcblk0p5) we are using enforces signature compliance (as it doesn't force signature compliance for the kernel mmcblk0p7). The following questions are rhetorical, as we don't know the answer yet. If we modified the modem partition (by changing a file, etc), would we be prevented from completely booting into Android? Would we be able to access CWM or use Odin to restore if the altered modem prevented completely booting into Android? From Autoprime's description, it sounds like he was able to boot into Android after flashing an ATT modem, but we should keep in mind that the other variants (non-i535) don't enforce partition signature compliance.

It sounds like we need to compare the ATT and VZW NVItems. We should find a willing ATT participant. I would be willing to walk the user through hex editing the QCN file to adequately censor user-specific information (and to avoid legal issues). All we need is the important stuff (like which NVItems are defined, values, etc).
[Verizon Samsung Galaxy S III] E:V:A:
I couldn't find any string of "111...", in what you sent me, but only

"5555....", "LLLL...", "kkkk..." and "0000...".

Almost a facepalm, as it was very late when I wrote that. But NV items must be saved in many places. Because you have the "fixed" items, like those for used in tuning the radio and selecting network and "is what we need" etc. Then there are the dynamic variables, that has to do with your settings, like roaming and preferred network or what have you, etc. But where? Thus the modem images must have the fixed NV items (?) inside. And the dynamic ones need to be on other writable partitions. I think we should look closer at partitions p10,p11 and p16 (PARAM, EFS, PERSIST), for the dynamic NV items.

Moreover, I really think that all this should have been resolved somewhere else. I can't believe that no one on XDA knows where the various NV items are stored...

Unfortunately I don't have any answers to those...
[Verizon Samsung Galaxy S III] mybook4:
Sorry, I said string when I should have said hex. Searching for the hex 111111... should do it. I'm not in front of it right now, but before each item there is something similar to "80 00 DE 15" where DE 15 should be interpreted as 15DE, or nvitem 5598. One thing I noticed is that most of the items seem to be listed sequentially, but others are all over the place.

I'm interested to see where the info is stored on the actual device. It may not follow the same format as the qcn file, but we may get lucky. I'll search for my IMEI and once I find that, try to look at the general structure. Hopefully there is a structure which is human readable. If not, we might be able to reverse assemble the modem code and find out which lines reference the mmcblk0 address that I find the IMEI in. This could give us clues about the structure as the program may have a generic routine (often reused throughput the code) to read-in an nvitem (just a guess). If persistent nvitems are indeed stored in the modem, we might have to reverse assemble it anyway.

---------- Post added at 06:46 AM ---------- Previous post was at 06:30 AM ----------

Well here's another verizon teardown caught on camera. http://xdaforums.com/showthread.php?p=29166420

I'll search the ATT forums for an ATT teardown.
[Verizon Samsung Galaxy S III] E:V:A:
Copy that. Comparing NV-items between i747 & i535 is probably the easiest way...less to learn but simpler solution.

Someone care to put up a new thread in the i747 forum?

Please remember to try to make it easy for them to understand what we're doing...

@mybook4: I'm now very convinced that the NV-items are "compressed" when saved on disk, and then expanded when read into memory. NV-items consists of mostly 0's and text, so that would make sense. Thus the *.qcn files, is probably how it would look while in memory... (?)
[Verizon Samsung Galaxy S III] mybook4:
I sent a PM to a mod. Before we post a thread in the i747 forum, does anyone here know someone active in the i747 forum who may be interested in and comfortable with providing NVItems (after censoring the personal info)? If we don't have any options, then we'll have to post a REQ in i747 General. I personally don't recognize many users in the i747 forum because I've been on Verizon for quite some time. I'll keep looking as my last phone was part of the galaxy s series and there was much sharing between the fascinate and captivate.

Compressed NVItems would make a lot of sense. It also could mean that adding a few NVItems might not be a big deal (plenty of storage if compressed).
[Verizon Samsung Galaxy S III] newuser134:
What if the NV items need to be changed to match the AT&T NV items exactly, AND then we need to flash an AT&T (or manually modified hybrid) modem, maybe it is only without the matching wcdma NV items that the cross-device modem will result in no signal at all? I'm still not recommending to flash the AT&T modem due to the whole secure boot and signature checking, I'm simply ignoring that for the sake of the idea for now, obviously this would have to be tried on a device that is known to boot with the AT&T modem, or at least back to Odin/CWM. I'm just thinking maybe changing the NV items or the modem won't work by themselves, but both need to be there for it to mean anything.
[Verizon Samsung Galaxy S III] marcustaz:
I am not a Dev by any means but I do have an att variant as well as verizon of this phone. I am certainly interested in getting my verizon on straight talk but I think it will need to be GSM based only i.e. converting it to mock an att variant, so I am following the progress of this thread. I will consider helping with a dump of my att phone let me know what to do.
[Verizon Samsung Galaxy S III] csong95:
Would like to help make SSG 3 GSM but dont have a SSG3 but anyone willing to try them for me please contact me
[Verizon Samsung Galaxy S III] mybook4:
Please PM me and I will provide instructions to remove all personal data from your NVItems dump.
[Verizon Samsung Galaxy S III] mybook4:
We will shortly have an AT&T NVItems dump. I'll take a look at it tonight after work and post all non confidential pertinent information.

Be sure to thank marcustaz!
[Verizon Samsung Galaxy S III] autoprime:
I believe E:V:A has explained in another thread... "If you read the ReadMe.txt that come with your QPST, you will see that this chip is not mentioned (supported) in any version below 2.7.373, with the introduction of the SURF8960 (model ID 4069). However, this support is for the development platform, so you can only expect partial functionality with that QPST version. After that there are many many other bugfixes, and the latest QPST I have seen is the 2.7.378, and the MSM8960 has still not been mentioned, so I know this is already old! "

But.. as far as EFS goes... I haven't personally had any issues with build 378 and the Sprint GS3. Builds prior to 378 gave me EFS issues but 378 seems good. As long as the 16-dig password is sent to your phone FIRST, QPST build 378 should have no issues reading the full EFS.

Using DFS and RevSkills, I was unable to copy the entire set of NV items... with QPST I seem to have got them all. The NV items that you seem to have that I do not, I assume were just left off my device since it's not set up for any sort of GSM roaming. If I do add those extra NV items, I'm curious if that could change things. Of course I'd still have no way to pop in a GSM sim.. but adding NV items to see how the phone reacts is kinda neat.

As for dd'n the partitions.. I think E:V:A is exactly correct, the NV items are compressed somehow... or perhaps even encrypted? Not sure. Either way.. perhaps backing them up does actually work.. tho it seems actually editing them individually would be quite the pain. QPST EFS Exp seems like the best bet to compare/contrast with ATT version.

Also wanna throw this out there.. you are aware of the Samsung Test Mode menu in Touchwiz that allows us to run an NV backup, erase it or restore it? It's not the most ideal backup method.. as you need to be able to boot into Touchwiz to be able to execute the restore... but I find it very hard to get to a non-booting situation and you should always be able to get back into touchwiz. Make 3 nv edits that didnt work out.. hit the test mode restore... all fixed. I made a thread on this for the Sprint GS3.. similar steps could be used on Vzw model - http://xdaforums.com/showthread.php?t=1815580

I kinda answered this above... I stand corrected. I think it may prove useful for backup.. but not for actual editing of the nv items. I don't think we would want to write the entire EFS from an ATT device over to VZW's.

Also.. good job on acquiring those ATT NV items... I'm looking forward to the results. How did you go about getting all the NV items off of the device? (I have almost 0 experience with GSM devices)