"This thread is intended to explain the principles behind tethering and how to use RadioComm to modify the NVM to allow tethering via all methods
on any Motorola Droid device by all users, regardless of whether they are rooted or not.
This is the method we at TeamBlackHat used to create the Tether_Repair patches that were released recently for rooted DX/D2 users in update.zip format
and applied via the Koush bootstrap recovery.
It is based on years old knowledge developed in the early days of CDMA Motorola hacking on the V710/V3c/e815 devices.
All of the information, techniques and software tools to do this are in the public domain already.
What we did is simply take that knowledge and apply it with the latest Service software and methods to the Droid generation devices and packaged it
in a new format for delivery that was never previously available to us before the advent of Android.
We will be releasing the manual method for RadioComm when we have worked through all the details for doing it on Win 7.
Currently the versions of RadioComm available on the net are for Win XP only.
We did it initially as a Proof of Concept of methods for writing to NV items via update.zip using Motorola's own binaries that we have recently developed.
We were not intending to release it at all and all agreed that it would be very controversial and raise many ethical questions as well as attracting the wrong
kind of attention to us as a group at a time when we had just been served a C&D for leaking the 2.3.9 update.zip file.
All of this really came about as a direct result of the examination of the NVM we did investigating nenolod's claims about an Engineering mode "switch"
that unlocked the bootloader on DX/D2. Those claims turned out to be unfounded and false and our work, and in particular MotoCache1's incisive analysis
of the boot process with help from [mbm], was instrumental in revealing that fact.
Not exactly what we had in mind to do but we were among the few who had the tools and wherewithall to determine the validity of what nenolod was claiming,
particularly in the beginning when he had released very little hard data to back up his suggestion that there was such a string hiding in the NVM.
Nonetheless, while revisiting the NVM and exploring methods to dump the memory we came upon this set of NV items that determines how the radio builds the
authentication strings it autowrites at bootup for data services. I was aware of their existence for month's since they were revealed in a thread
I participated in on HoFo for service programming on the original Droid. That thread was directed towards the methods required to get the Droid on
a different carrier like Cricket or Metro.
In any event, I knew what they would do if modified in this way and decided to use that as a test of MotoCache1's work with the update.zip binaries.
I used RadioComm to edit them individually and MotoCache1 did the really brilliant work of turning this very old school hack into a beautiful,
elegantly delivered package. This proved the power of what we were capable of as a team and we still unanimously decided against releasing
a packaged theft of services hack as not the right thing to do.
We have reconsidered now in the light of these other exploits surfacing which utilize various software level tricks for getting "Free" tethering
with the new 3G Mobile Hotspot app included on DX and D2. I had always felt that this was inevitable and that others would soon put the pieces together
in the same way we had done.
This is a fundamentally different modality but accomplishes exactly the same thing as any other exploit designed to subvert VZW's intent
to differentiate between externally routed modem data and internal data use and charge for that service.
This includes all forms of exploits and applications like PDAnet and WMWiFiRouter(WinMo 6.1) and now Barnacle, whose entire business model is to use
software level methods to mask tethered data and have marketed them as such for years.
All of these methods absolutely violate the TOS agreement with VZW.
This method simply alters that behavior at the lowest level possible on the device, the radio NVM.
It works because of the way VZW chose to setup authentication on their network when they released the first EvDO capable phones in late 2004-2005.
The methods and software tools to access the NVM as well as the blocks put in place by Qualcomm and Motorola for protecting these
authentication components have evolved dynamically over the years with advancements in chipset design and software, but the principles
have always remained the same. Hex editing the NVM items via a given tool to make the Tethered NAI(Network Access Identifier) strings
match the NAI strings for internal data.
These are basically your user name on the network and consist of the MIP profile byte, a line length byte and your 10 digit telephone number
followed by either @dun.vzw3g.com for tethered NAI or @vzw3g.com for the NAI. By removing the "dun." from the tethered NAI string
you enable all forms of data use to appear to the network as internal and using the normal NAI string.
The difference between the current technique and former methods is that the items edited for this hack are not those strings themselves,
but actually where the default values are stored that the radio uses to build the full strings that it autowrites to the fixed, protected locations in the NVM
for the authentication components in the MIP(Mobile Internet Protocol) profile itself, which happens at bootup.
This is the means by which they prevented the items from being modified by typical service programming tools like QPST.
But, because we know the location for those hidden partial strings, it actually makes our work much simpler.
After editing these four strings, the phone itself uses those values to autowrite the properly configured MIP profile strings for you.
It couldn't be any easier!
Despite our initial concern about releasing this publicly, we have decided after much discussion to do so anyway.
With all of the recent exploits that are directly targeting the 3g Mobile Hotspot app we feel that revealing the way to do it properly
will level the playing field for everyone as well as giving the community a truer and more complete understanding of how it works.
This way users can make up their own minds as to whether to use any of the available methods of "free" tethering with a clear view
of the ethical and technical issues involved.
Hopefully this thread will generate a healthy discussion about the issues.
We at TeamBlackHat believe in providing the knowledge so users can make their own decisions with the best information available.
Please use your own judgment about whether to use this or any tethering modifications.
Enjoy!
CellZealot
TeamBlackHat"
