Related
When we were back on NoDo there were quite a few homebrew apps that used native code to apply tweaks to WP7 devices. Most of those apps seized to work after the device is upgraded to Mango. There a several reasons for this behavior. I've done research on this, because I wanted to make WP7 Root Tools compatible with Mango. In this topic I'd like to explain how developers can fix their apps to work on Mango again. It has taken me quite some time to compile this guide, but I hope to give the Homebrew development on WP7.5 Mango a boost.
This guide is NOT about creating homebrew executables (exe-files) for WP7. This guide aims to utilize native code DLL's (C++ / ARM) from within your Silverlight app.
Note that with native code you get access to a lot of extra API's. But that does not mean you automatically get access to resources you normally won't have access to. For example, you can use the CopyFile() API. But if you try to copy a file to the \Windows folder, you will get errorcode 0x4ec (1260), which means "Blocked by policy". So you are still bound to the rules of the sandbox of your app. If you want Full Root Access for your app, you have to wait for a new version of WP7 Root Tools, which will allow you to give your app root-access. I'm also working on an SDK for that, which wraps all common task into a neat managed library. But don't hold your breath for that, because it's all taking a bit longer than I expected.
To understand everything in this guide you need basic knowledge of C++, COM-interop and Silverlight for Windows Phone. If you are new to all this, you might want to do some reading on these topics first. Currently there is no way to debug the native code. The only thing you can do is create test-functions which return formatted debug-info. This makes things pretty difficult. Read the guide carefully, because a little mistake can make your app crash easily!
Important note: If you have any long-running tasks, they may work fine while you are debugging. But you need to make sure that you start a new thread to run this code. Because, when you run without debugger the WatchDog will monitor your application and if the User Interface thread is blocked for more than 10 seconds the WatchDog will exit your app ungracefully!
It has been suggested that native homebrew DLL's need to be signed with approved code-signing keys. This is in fact not true! You can use native DLL's on Mango devices, which are not signed at all!
Basically there are two reasons why homebrew apps are not working anymore:
- Interop Lock
- DLL's were built against libraries, which are not supported anymore on Mango
Interop Lock is discussed in this thread. Interop Lock is a new protection mechanism in WP7.5 Mango. Basically it means you can't use apps with ID_CAP_INTEROPSERVICES, unless a device is Interop Unlocked. Without ID_CAP_INTEROPSERVICES an app can't call any drivers. And most homebrew apps call these drivers directly or indirectly. So if an app uses the Interop Capability, it can only run on devices that are Interop Unlocked. If you're going to build an app that uses this capability on Mango, you'll have to give your users instructions on how to apply Interop Unlock on their device.
Most of the native code libraries that were used on NoDo, were based on a hand full of projects. These projects were created and then extended for their own needs by other developers. The result was that most of these projects had the same project-types and library-references. In Mango, a lot of DLL's that were not used anymore by Microsoft, have been removed from the OS. Mostly in the ShellCore. The DLL's were meant for MFC-type functionality, which was never even supported on WP7. Actually, these DLL's are not even used by the homebrew apps either, but there are references to these DLL's in the homebrew libraries, which will cause the library to fail loading into memory. You can see this behavior when you try to run an app with non-Mango-compatible native code on an Interop Unlocked device from within the Visual Studio 2010 development environment. When the COM-class is instantiated it will throw an COMException: "COM object with CLSID '{...}' cannot be created due to the following error: The request is not supported." This is errorcode 0x80070032. This exception is actually caused due to the fact that the previous call to RegisterComDll() failed. If you get the returnvalue of that function you should have 0. In this case the return-value is probably 0x8007007E, which is "Module Not Found". This actually means that you directly or indirectly refer to a DLL, which cannot be found on the device. To fix this we need to create a clean project and add our new or existing native code to that project.
Here are the steps to setup your development environment and create a new, clean project for your native code. Please keep in mind that this guide is still work-in-progress. I may add more detailed instructions and examples later on, when people ask for it.
Update 2011/10/15: Some improvements in the guide, based on comments of rudelm and GoodDayToDie.
Install Visual Studio 2008 with latest service pack and hotfixes. Make sure you install C++. You need Visual Studio 2008, because the necessary SDK does not support Visual Studio 2010.
Install Windows Mobile 6 Professional SDK Refresh.
Install Visual Studio 2010 with latest service pack and hotfixes. You need this to create your Windows Phone Silverlight app.
Install Windows Phone SDK 7.1.
Download the attached Microsoft.Phone.InteropServices.zip. After you downloaded the zip-file, open the file-properties and make sure the file is "unblocked" (Windows will block downloaded files). Some unzippers, including the built-in unzipper from Windows will mark the unzipped files as "blocked", which would give problems later on if you don't unblock first.
If your developmachine is 32-bit you go to "C:\Program Files\Reference Assemblies\Microsoft\Framework\Silverlight\v4.0\Profile\WindowsPhone71" or if you have a 64-bit machine you go to "C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\Silverlight\v4.0\Profile\WindowsPhone71". Extract the DLL from the zip-file in this folder.
Open the Visual Studio Commandprompt and change directory to the folder where you just extracted the DLL. Then enter this command:
Code:
SN -Vr Microsoft.Phone.InteropServices.dll
In the same folder there is a subfolder called "RedistList". Open that folder and open the file "FrameworkList.xml". Add this line to that file:
Code:
<File AssemblyName="Microsoft.Phone.InteropServices" Version="7.0.0.0" Culture="neutral" ProcessorArchitecture="MSIL" InGac="false" />
Thanks to Tom Hounsell for this tip!
Install the latest version of Zune.
Open Visual Studio 2008 and create a new project.
Choose Visual C++ / Smart Device / ATL Smart Device Project and fill in a name and location for your native library. Do NOT choose MFC, or your library won't work on WP7! The name will be the name for the DLL. Later on you will create a COM-class. Choose a different name for your library and for your COM-class!
In the new wizard click "Next".
Remove the "Pocket PC 2003" from the Selected SDK list and add "Windows Mobile 6 Pro SDK" to the selected SDK's. Click "Next".
In "Application Settings" keep everything default and click "Finish".
Set your configuration to "Release", because you won't be able to debug anyway.
Go to Project Properties / Configuration Properties / C/C++ / Preprocessor / Preprocessor Definitions and add this: _CE_ALLOW_SINGLE_THREADED_OBJECTS_IN_MTA
Right-click the project and click "Add" / "Class" and choose "Simple ATL object".
In the new dialog enter the "Short name" for your COM-class. All other names are filled in automatically. Keep those names default to avoid naming-conflicts. Also make sure the name of your COM-class is different from the name of the library. All other options can are default, so you can click "Finish" now.
The basic layout for your native project is now ready. Note that you have these files: for your library you have a header-file (.h), a code-file (.cpp) and a COM-definition-file (.idl) and for your COM-class you have a header-file (.h) and a code-file (.cpp). I will refer to these files in the following steps, so make sure you can identify these files.
The COM-class you have now is based on IDispatch. IDispatch is the COM-interface that supports reflection-like functionality. The COMBridge in WP7 does not support this interface. Instead we should use IUnknown, which is the base-interface for all COM-objects and supports reference-counting.
In the header file of your COM-class you can see the public inheritance of IDispatchImpl. This is no problem and you can leave it as it is. But you can also see this COM-mapping:
Code:
COM_INTERFACE_ENTRY(IDispatch)
You need to remove that line.
In the IDL file of your library you need to change the inheritance of the COM-class from IDispatch to IUnknown.
Your native code layout is now ready to add your methods. A method in COM-class should always have HRESULT as return-type. This value should be 0 or positive in case of success (normally use constant S_OK for success). If you have an errorcode which should throw a COMException do a logical OR with 0x80070000 and return that value. If you want to return a variable, you'll to declare that as parameter of your method and decorate it as returnvalue in the IDL-file. The parameter-types are bound by the definition of COM. You can read about the supported COM-datatypes here and here. Study those parameter-types closely, because any mismatch in your managed and unmanaged declarations will make your app crash definitely. You need to add all your methods in 3 different places: in the COM-class code, in the COM-class interface and in the IDL-file. Later on you need to add an exactly matching interface to your managed code. All the declarations have their own specific format and decoration. I will give an example of two different functions for these 3 files. Note that in these examples, the COM-class was named "Native", so the class implementation is called "CNative" and the interface is called "INative". You have to change that if your class has a different name.
In the COM-class implementation (.cpp-file) add this code:
Code:
STDMETHODIMP CNative::TestMethod1()
{
BOOL result = ::CopyFile(L"\\Windows\\0000_System.Windows.xaml", L"\\Windows\\Test.xaml", TRUE); // This will fail due to insufficient privileges. This is expected behavior to show how errors can be handled.
if (result)
return S_OK;
else
return 0x80070000 | ::GetLastError();
}
STDMETHODIMP CNative::TestMethod2(BSTR InputString, BSTR* OutputString)
{
size_t size = 1000; // in chars
TCHAR* msg = new TCHAR[size];
wcscpy_s(msg, size, L"\0");
LPWSTR value = new WCHAR[20];
_itow((int)wcslen(InputString), value, 10);
wcscat_s(msg, size, L"Length of string is: ");
wcscat_s(msg, size, value);
*OutputString = SysAllocString(msg);
delete[] msg;
delete[] value;
return S_OK;
}
In the interface of the COM-class (.h-file) add this code immediately after END_COM_MAP():
Code:
STDMETHOD(TestMethod1)();
STDMETHOD(TestMethod2)(BSTR InputString, BSTR* OutputString);
Locate your interface in the IDL-file of the library. This may look a bit weird, because there are a lot of attributes that decorate the empty interface. Add these declarations to your interface (note the decoration of the parameters, read more here):
Code:
HRESULT TestMethod1();
HRESULT TestMethod2(BSTR InputString, BSTR* OutputString);
Now we need to locate two GUID's and copy them in a text-file, because we need these GUID's later on. These GUID's are in the IDL-file. We will call the first GUID "interface-GUID". It is the "uuid" in the tag RIGHT ABOVE the interface-declaration. We will call the second GUID "coclass-GUID". It is the "uuid" in the tag RIGHT ABOVE the coclass-declaration. There also a "uuid" in the tag above the library-declaration, but we don't need that one.
Open Visual Studio 2010 and create a new project: Visual C# / Silverlight for Windows Phone and choose a project-type, name and location.
Now go back to your native project in Visual Studio 2008. The compiled result DLL of this project will be used in your Windows Phone app. To make sure you always use the latest version of the native DLL in your Windows Phone app, you can add a Post Build Event to this project. This example assumes you will have a folder with a subfolder for the native solution and a subfolder for the Windows Phone solution. Go to Project Properties / Configuration Properties / Build Events / Post-build Events and add this (change the paths according to the soluton-foilder you will create for your Windows Phone app):
Code:
copy "$(TargetPath)" "$(SolutionDir)..\MyApp
If you checked the option "Create folder for solution" when you created the Windows Phone project, you may want to add another subfolder "\MyApp" to the path.
Now build your native project! The compiled DLL should now also be copied to the folder of your Windows Phone app.
Create a new file called "WPInteropManifest.xml" in the folder of your managed Windows Phone app. Copy this content in the file:
Code:
<?xml version="1.0" encoding="UTF-8"?>
<Interop>
</Interop>
Switch back to Visual Studio 2010. In the solution explorer click on "Show all files". Your native DLL and the "WPInteropManifest.xml" should be shown now.
Select the "WPInteropManifest.xml" file and in the file-properties set "Build action" to "Content" and set "Copy" to "Always". You will always need this file in your project, regardless you will be calling drivers or not. If you don't have this file in your project, you won't be able to use your native DLL.
Select your native DLL and in the file-properties set "Build action" to "Content" and set "Copy" to "Always".
In the solution explorer, right-click on the project and choose "Add Reference". Then select "Microsoft.Phone.InteropServices".
Open the "WMAppManifest.xml" file and add this line below the other capabilities:
Code:
<Capability Name="ID_CAP_INTEROPSERVICES" />
Later on, you can try if your app will work without this capability. If you only use native code without calling drivers (directly or indirectly), you don't need the capability and your app will also work on devices that are not Interop Unlocked then. This specific example does not call any drivers, so in this example the ID_CAP_INTEROPSERVICES can be omitted and then it would run on non-Interop-Unlocked devices.
Now add a code-file to your project and copy this code into the file. You need the the coclass-GUID and interface-GUID you copied into a text-file earlier and you also need to replace the name of the class and interface to the names you used. Also note that the declaration must be an exact match (order and parameters) with the declaration in the IDL-file, although the IDL-file is differently formatted.
Code:
using System.Runtime.InteropServices;
[ComImport, ClassInterface(ClassInterfaceType.None), Guid("YOUR-COCLASS-GUID-GOES-HERE")]
public class CNative
{
}
[ComImport, Guid("YOUR-INTERFACE-GUID-GOES-HERE"), InterfaceType(ComInterfaceType.InterfaceIsIUnknown)]
public interface INative
{
void TestMethod1();
[return : MarshalAs(UnmanagedType.BStr)]
string TestMethod2([MarshalAs(UnmanagedType.BStr)] string InputString);
}
Note that the interface is declared as IUnknown.
Now you need to call the native code. You can add this code to the constructor of your Page or to the eventhandler of a button, or anywhere you like. Be sure to replace the DLL-name, interface-name and class-name and use your coclass-GUID. The exception is a well-known error-code and the exception will be casted to a UnauthorizedAccessException, instead of a COMException.
Code:
uint retval = Microsoft.Phone.InteropServices.ComBridge.RegisterComDll("WP7Native.dll", new Guid("YOUR-COCLASS-GUID-GOES-HERE"));
INative MyNativeCodeInstance = (INative)new CNative();
string result1 = "OK";
try
{
MyNativeCodeInstance.TestMethod1(); // UnauthorizedAccessException is thrown due to insufficient privileges. This is expected behavior to show how errors can be handled.
}
catch (Exception ex)
{
result1 = ex.Message;
}
string result2 = MyNativeCodeInstance.TestMethod2("Hello, Mango!");
MessageBox.Show(result1 + Environment.NewLine + result2);
You can now run your project! Be sure that you deploy it to your device. The emulator won't work, because you project uses native ARM code. The emulator runs on x86, so your native DLL won't load in the emulator.
When you go more advanced, you may need the Marshal-class. For example to copy a native memory-block to a managed byte-array. Be aware that there are actually two "Marshal" classes. There is "Microsoft.Phone.InteropServices.Marshal" and "System.Runtime.InteropServices.Marshal". They both look the same. But be sure you are using "Microsoft.Phone.InteropServices.Marshal", because it will allow you to do a lot more! Most methods in "System.Runtime.InteropServices.Marshal" will throw a MethodAccessException, because they are tagged [SecurityCritical], while the same methods in the other Marshal class will work.
I hope this will help you port your homebrew apps to Mango or create some fresh new homebrew! If you created an app with native code, drop me a line here. Show me your Screen Recorders, Accent Changers and more!
Ciao,
Heathcliff74
looking fwd to the native apps , a universal screenshot apps would be awesome..
Update :
scratch that, just ready that the app will be bound to the rules of the sandbox of your app.I guess that means no universal screenshot app yet
Its time to get native! Thanks Heathcliff.. I think I have a very good idea on something I could use native code for.. Ill pm you =)
Sent from my SGH-i917 using XDA Windows Phone 7 App
Suddenly, awesomesauce! Wow, big thanks Heathcliff74! Eve since you said you'd figured out homebrew native DLLs on Mango, I was really excited to see what people could do. I never guessed the real reason homebrew DLLs didn't work on Mango, although in retrospect this makes sense. You're awesome for investigating this for us.
Thoughts that immediately come to mind:
Update the existing screen capture apps.
Update the existing WebServer app.
(As part of the above) update the sockets DLL so we have server sockets again.
Explore how much filesystem access we have. Can files be copied from one app's isostore to another app's isostore?
Explore accessing drivers. The HTC update breaks filesystem access for HTC homebrew, but maybe there's another driver entry point we can use.
Investigate direct access to the SMS store (message backup?)
... and so much more. Oh, this is going to be fun!
the0ne said:
looking fwd to the native apps , a universal screenshot apps would be awesome..
Update :
scratch that, just ready that the app will be bound to the rules of the sandbox of your app.I guess that means no universal screenshot app yet
Click to expand...
Click to collapse
Hi!
Screenshots apps are definitely possible! The API for this can be called from within the sandbox and using OEM drivers it is possible to switch off dehydration. I already discussed this with fiinix and gave him this info. And I believe he almost has a Mango version ready.
Thanks for writing the article
Ciao,
Heathcliff74
great to hear about the progress
thanks Heathcliff74 for sharing!
Wooohooo nice HowTo! I will definitively try it and will report later. However, that will require that I go back to NoDo and back to Mango first. I'm not looking forward to that procedure... anyways awesome work Heathcliff, thank you!
@GoodDayToDie: you mentioned that the HTC libraries are fixed regarding file access. Julien Schapman from TouchXplorer mentioned something like that a while ago on twitter. Do you have any additional information on that topic? Is it just the DLL files from the HTC apps or is it something with the Mango HTC Update? I'll hope this is reversible, if I go back to NoDo and want to try Heathcliffs instructions :/
@rudelm, I only have experimental knowledge; I haven't dug into the actual update. However, the way that things like ComFileRW.dll work is by calling into some high-permission module in the HTC firmware (probably a driver using an IOCTL, though it could possibly be an RPC call to a privileged process) which then executes the requested action with high permissions. That's why the HTC DLLs don't do anything on other phones; they can't talk to the component that actually does the work.
My guess is that the HTC update simply turned off whatever it was that the COM DLLs are calling into. It could be more complex than that - for example, they could be trying to validate the caller, and prevent it from being used by homebrew - but whatever they did, neither DLL works anymore once you have the HTC update *even though the DLLs themselves did not change.*
Is it reversible? Well, "fixing" whatever component they were calling into is one option. Using Heathcliff74's Root Tools to gain full permissions on a "normal" homebrew app is another. There might be more, but it would need more study.
Thanks. Will try it. Hopefully i can get "GetPhoneNumber" from Windows Mobile 6 SDK to run or maybe trying http://blogs.msdn.com/windowsmobile/archive/2004/11/28/271110.aspx
GoodDayToDie said:
@rudelm, I only have experimental knowledge; I haven't dug into the actual update. However, the way that things like ComFileRW.dll work is by calling into some high-permission module in the HTC firmware (probably a driver using an IOCTL, though it could possibly be an RPC call to a privileged process) which then executes the requested action with high permissions. That's why the HTC DLLs don't do anything on other phones; they can't talk to the component that actually does the work.
My guess is that the HTC update simply turned off whatever it was that the COM DLLs are calling into. It could be more complex than that - for example, they could be trying to validate the caller, and prevent it from being used by homebrew - but whatever they did, neither DLL works anymore once you have the HTC update *even though the DLLs themselves did not change.*
Is it reversible? Well, "fixing" whatever component they were calling into is one option. Using Heathcliff74's Root Tools to gain full permissions on a "normal" homebrew app is another. There might be more, but it would need more study.
Click to expand...
Click to collapse
uhoh... sounds pretty bad for HTC users. If it was a firmware update, we will have a bigger problem. I will try to revert back to Nodo and will try Heathcliffs instructions for Native Code first. InteropUnlock is still something I need to try for Mango
rudelm said:
uhoh... sounds pretty bad for HTC users. If it was a firmware update, we will have a bigger problem. I will try to revert back to Nodo and will try Heathcliffs instructions for Native Code first. InteropUnlock is still something I need to try for Mango
Click to expand...
Click to collapse
No worries. I did some testing with contable and we just got confirmation that my exploits for HTC will still work on HTC Interop Unlocked Mango devices (needs a little adjustment, but No Problem!) Still working on a version of WP7 Root Tools for Samsung/HTC/LG RTM/NoDo/Mango!!
Ciao,
Heathcliff74
A screenshot app is allready there:
TouchXperience for Mango from Schaps.
Atm there is only missing the WPDM Mango update for being able to save the screenshot...
Heathcliff, could you please try to fix that HTC bug first? I am running into this problem with the HTC update and now my old code does not work anymore But at least my phone is finally interop unlocked because I could deploy the app on Mango but I get this error:
COM object with CLSID '{C6BD09B4-96AA-4524-89C4-665A15DD7C9B}' cannot be created due to the following error: The request is not supported. .
Which is one of the errors you mentioned on the first page. So far, so good
rudelm said:
Heathcliff, could you please try to fix that HTC bug first? I am running into this problem with the HTC update and now my old code does not work anymore But at least my phone is finally interop unlocked because I could deploy the app on Mango but I get this error:
COM object with CLSID '{C6BD09B4-96AA-4524-89C4-665A15DD7C9B}' cannot be created due to the following error: The request is not supported. .
Which is one of the errors you mentioned on the first page. So far, so good
Click to expand...
Click to collapse
I don't get what you mean. What HTC bug? What HTC update?
Ok, I will explain it:
There was a HTC Update when I upgraded from Mango B2 Refresh to the Mango RTM from Microsoft. It was followed by a smaller HTC Update. It was called HTC Update for Windows Phone. You can read it here in my blog.
Yesterday, I decided to revert back to NoDo, so that I could Interop Unlock my HD7 before I upgrade to Mango RTM. I did this with these tools and instructions from petbede.
However, ansar found out, that MS changed the update procedure and included the HTC update directly in the 7720.68 update.
Now you mentioned yesterday, that you and contable found a solution to use the HTC DLLs although there was this HTC update on our phones. That was when I already feared that the HTC update will break everything I tried so far.
So I called it the HTC bug, because it breaks my stuff
rudelm said:
Ok, I will explain it:
There was a HTC Update when I upgraded from Mango B2 Refresh to the Mango RTM from Microsoft. It was followed by a smaller HTC Update. It was called HTC Update for Windows Phone. You can read it here in my blog.
Yesterday, I decided to revert back to NoDo, so that I could Interop Unlock my HD7 before I upgrade to Mango RTM. I did this with these tools and instructions from petbede.
However, ansar found out, that MS changed the update procedure and included the HTC update directly in the 7720.68 update.
Now you mentioned yesterday, that you and contable found a solution to use the HTC DLLs although there was this HTC update on our phones. That was when I already feared that the HTC update will break everything I tried so far.
So I called it the HTC bug, because it breaks my stuff
Click to expand...
Click to collapse
I see. Well, I didn't find a solution. I just checked if MY exploit still works. And it does! I don't even know what you use exactly (I assume you use some HTC DLL's, but I don't know which and I don't know which functions). I don't use the HTC DLL's myself. Mainly because I don't want to get copyright issues when releasing WP7 Root Tools. Just look at the current release of WP7 Root Tools. No OEM code in there. So I don't think I can fix that for you.
Ciao,
Heathcliff74
Hm ok, I understand. I was using a HTC dll for changing a registry value (overriding DHCP DNS Server). However, it is interesting to know why the HTC DLLs all of sudden stopped working after this update. The DLLs inside the HTC tools seem to be the same size and should not be changed by the update.
But this shouldn't then influence the DLL made with your instructions in this thread i guess?
@rudelm:
The HTC devices have HSPL support, so why you don´t flash the latest xboxmod rom ? This saves a lot of time and all available types of unlocking can be sent via cab sender.
For writing registry keys or doing file operations you can use DiagProvXML til Heathcliff has finished the next version of WP7 Root Tools.
Is there any other reason why you are updating your phone the official way ?
@rudelm: The HTC DLLs don't actually have elevated permissions by themselves. To do things that an app n ormally lacks permissions for (like accessing the whole filesystem or writing to the registry), it needs to call into a high-permission component (probably a driver or a high-permission process). All HTC had to do to make the registry and filesystem COM DLLs stop working is to change that component so it didn't do what the COM DLLs told it to do.
@contable: I've heard enough reports of things that *should* work on HTC phones not working on the custom ROMs that I'm hesitant to install one. Then there's the risk of bootloader issues. Then there's the lose-all-your-data-because-your-phone-gets-reformatted issue - until I have my backup app working fully, I prefer to avoid the last one in particular.
Edit: If you are looking for working attachments, please look at this posting.
@contable:
I need an unmodified version of WP7 for my master thesis. The other thing is that I don't want to play around with HSPL without having the original SPL or firmware. It's like GoodDayToDie said: I'm still hesitating of the said reasons.
@GoodDayToDie:
The HTC applications still work and they were not updated afaik. So they are using the same DLL files. If there would be some driver running in TCB or ECB and they changed something, then their applications should stop working too. However, they can still be executed without problems. I am not sure what DLLs are used by advancedexplorer, but I think it were also the HTC dlls. My own application which used the HTC dlls stopped also.
@Heathcliff:
I've tried your instructions and found some errors in it:
step 23: *OutpuString = SysAllocString(msg); instead of *OutputString = SysAllocString(msg);
step 25: ; missing after OutputString)
step 28: add \MyApp to path, because VS2010 Solutions always have a subfolder with the same name of the solution
step 36: [return : MarshalAs(UnmanagedType.BSTR)] should be [return : MarshalAs(UnmanagedType.BStr)]
step 37: result 2 needs a type => string result 2 = ...
on first run:
Error 1 Could not load the assembly file:///C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\Silverlight\v4.0\Profile\WindowsPhone71\Microsoft.Phone.InteropServices.dll. This assembly may have been downloaded from the Web. If an assembly has been downloaded from the Web, it is flagged by Windows as being a Web file, even if it resides on the local computer. This may prevent it from being used in your project. You can change this designation by changing the file properties. Only unblock assemblies that you trust. See http://go.microsoft.com/fwlink/?LinkId=179545 for more information. NativeTestApp
Click to expand...
Click to collapse
This is because you forgot to register the DLL first. Look here: http://thounsell.co.uk/2010/11/avoi...g-the-interopservices-library-to-the-wp7-sdk/ and then down in the comments:
You must open the visual studio 2010 command prompt as administrator and call:
SN -Vr Microsoft.Phone.InteropServices.dll
then close and reopen Visual Studio, now it should work
Click to expand...
Click to collapse
In addition that, you will have to unblock the file in Windows Explorer, Properties of the file. Otherwise you will get this error in Xaml view:
Could not load file or assembly 'Microsoft.Phone.InteropServices, Version=7.0.0.0, Culture=neutral, PublicKeyToken=24eec0d8c86cda1e' or one of its dependencies. Operation is not supported. (Exception from HRESULT: 0x80131515)
Click to expand...
Click to collapse
This unblock will only work, if you use the Windows Explorer in administrator mode. The DLL file should be copied to a path were every user can access the file. Unblock it there and move it than back to the WindowsPhone71 folder. I've extracted it directly to the WindowsPhone71 folder and I couldn't change its properties there.
I've created a VS2008 and VS2010 sample project on your instructions and tried to add some comments to the sources. I've attached them to this post. Here are a few extra information to my project:
Interface-GUID: D28D8CB9-F8BC-4379-9D0A-FA77C87EF814
coclass-GUID: 7300CD4A-03F4-4569-B2D8-F1515385D46D
COM Class: NativeTestClass
INativeTestClass and CNativeTestClass
Always results in retval 0 and this exception:
System.MethodAccessException was unhandled
Message=Attempt to access the method failed: System.IO.FileInfo..ctor(System.String)
StackTrace:
at Microsoft.Phone.InteropServices.ComBridge.RegisterComDll(String dllFileName, Guid clsid)
at NativeTestApp.MainPage.actionButton_Click(Object sender, RoutedEventArgs e)
at System.Windows.Controls.Primitives.ButtonBase.OnClick()
at System.Windows.Controls.Button.OnClick()
at System.Windows.Controls.Primitives.ButtonBase.OnMouseLeftButtonUp(MouseButtonEventArgs e)
at System.Windows.Controls.Control.OnMouseLeftButtonUp(Control ctrl, EventArgs e)
at MS.Internal.JoltHelper.FireEvent(IntPtr unmanagedObj, IntPtr unmanagedObjArgs, Int32 argsTypeIndex, Int32 actualArgsTypeIndex, String eventName)
Click to expand...
Click to collapse
I've rechecked every step but I am still stuck. The phone itself should be interop unlocked, otherwise I couldn't have deployed the app with the capability activated. Could you please look into it? I know this error from my earlier attempts to access the HTC dll directly, but then I used the NativeLibrary here from XDA which took care of all the GUID things etc.
AGPS Patch Wildfire S 3.1 & 2.2 | GET BACK TO RAPID GPS LOCK, CAN LOCK ONTO MORE SATS
AGPS PATCH
REVIEW THE WHOLE THREAD BEFORE POSTING QUESTIONS.
List of officially supported devices is at the bottom of this post.
Use this if you're having GPS issues (unreliability, no functionality, etc.)
This patch provides a worldwide solution to GPS issue for multiple devices. Using a general ROM without this has resulted in 10+ minutes of GPS delay. Also, GPS lock kept being lost. By using this patch, most people experience a GPS lock within 10 seconds (2 - 20 seconds range can be expected). Typically, a device using this patch will lock onto 7 - 9 satellites. Users have reported up to 11 satellites being locked at once. Without this patch, the average satellite count is 4.
HOWTO INSTALL: (Remember to make a backup. See Notes section for what this patch does.)
Method 1:
1. Download the "ADB Push Installer". This contains all versions for the latest build and old v1.3 versions.
2. Extract the files into a specific folder.
3. Plug your device into the computer and get it ready for adb pushing. Nothing out of the ordinary required.
4. Open the batch file called "ADB Installation Script - RUN THIS" if you use Windows. Otherwise, run the Linux SH script if you use Linux.
5. Select the version you want from the list.
6. Follow the prompts to reboot. You're done.
4. Review the NOTES section.
Method 2:
1. Download the patch
2. Copy all file(s)* into /etc/ of the system (not sd-card) using ES File Explorer, Root Explorer, or some other form. You must have SYSTEM set to Mounted and Root enabled. Check your explorer app's SETTINGS to do this.
**Files will be: gps.conf & SUPLROOTCERT -OR- only gps.conf for NO-SSL builds.**
3. Reboot the device
4. Review the NOTES section.
*Files are located in the /system/ folder of the ZIP. Do not copy the other directories or folders.
Method 3 (easiest if you use a compatible version of CWR or CWM)*:
1. Download the patch
2. Boot into CWR (Clockwork Recovery)
3. Mount /system/ partition (on the main menu, select the "Mounts and storage" option, then "mount /system")
4. Flash the patch (on the main menu, select "Install zip from sdcard," then "choose zip from sdcard," and find the zip and select it)
If you receive "(Status 0) Installation aborted" this Method will not work for you. Use one of the other methods.
5. Reboot the device
6. Review the NOTES section.
*This was built for and works on Inspire 4G and DesireHD versions of Clockwork Recovery. The Google CWM Flashable Build has binaries known to work with CWM on the X8. It may work on other devices. Please message me your success if you try and flash with recovery version and phone model as part of the message.
Downloads:
SEE THE NOTES SECTION (PARTICULARLY NOTES 1,2, & 3) FOR ALL SORTS OF INFORMATION AND FACTS ABOUT THIS PATCH, WHAT EACH BUILD IS FOR, VERSION DIFFERENCES, AND KNOWN ISSUES WITH SOLUTIONS.
Recommended Builds (pick either):
Download the Google Specific No-SSL v3.1 build here. (Like it? Don't forget to click on "Thanks" and to rate the thread)
Download the Google Specific v3.1 build here. (Like it? Don't forget to click on "Thanks" and to rate the thread)
Confused with all the options below? As the Notes section dictates: I recommend the GOOGLE BUILD of all devices. Other builds have changes in their SUPL server information and/or other variables pertinent to that manufacturer. These builds do not appear to operate as fast as Google build's but are available for your enjoyment.
3.x trunk Alternative Options (currently v3.1)
Download the ADB Push Installer here. (contains all current builds and v1.3 builds) (Like it? Don't forget to click on "Thanks" and to rate the thread)
Download the Google Specific build here. (Like it? Don't forget to click on "Thanks" and to rate the thread)
Download the Google Specific NO-SSL build here. (Like it? Don't forget to click on "Thanks" and to rate the thread)
Download the Google Specific Alternate* build here. (Like it? Don't forget to click on "Thanks" and to rate the thread)
Download the Google Specific CWM Flashable build here. (Like it? Don't forget to click on "Thanks" and to rate the thread)
Download the AT&T Specific build here. (Like it? Don't forget to click on "Thanks" and to rate the thread)
Download the T-Mobile Specific build here. (Like it? Don't forget to click on "Thanks" and to rate the thread)
Download the LG Phone Specific build here. (Like it? Don't forget to click on "Thanks" and to rate the thread)
Download the LG Phone Specific Alternate* build here. (Like it? Don't forget to click on "Thanks" and to rate the thread)
Download the Sony Ericsson Specific build here. (Like it? Don't forget to click on "Thanks" and to rate the thread)
Download the GPS.CONF only build here. (Like it? Don't forget to click on "Thanks" and to rate the thread)
Download the GPS.CONF only Alternate* build here. (Like it? Don't forget to click on "Thanks" and to rate the thread)
*The alternate patch removes a variable that some GPS hardware on older models cannot handle. Try this if you have problems with the standard patch.
2.x trunk Alternative Options (currently v2.2)
Download the ADB Push Installer here. (contains all current builds and v1.3 builds) (Like it? Don't forget to click on "Thanks" and to rate the thread)
Download the Google Specific build here. (Like it? Don't forget to click on "Thanks" and to rate the thread)
Download the Google Specific NO-SSL build here. (Like it? Don't forget to click on "Thanks" and to rate the thread)
Download the Google Specific Alternate* build here. (Like it? Don't forget to click on "Thanks" and to rate the thread)
Download the Google Specific CWM Flashable build here. (Like it? Don't forget to click on "Thanks" and to rate the thread)
Download the AT&T Specific build here. (Like it? Don't forget to click on "Thanks" and to rate the thread)
Download the T-Mobile Specific build here. (Like it? Don't forget to click on "Thanks" and to rate the thread)
Download the LG Phone Specific build here. (Like it? Don't forget to click on "Thanks" and to rate the thread)
Download the LG Phone Specific Alternate* build here. (Like it? Don't forget to click on "Thanks" and to rate the thread)
Download the Sony Ericsson Specific build here. (Like it? Don't forget to click on "Thanks" and to rate the thread)
Download the GPS.CONF only build here. (Like it? Don't forget to click on "Thanks" and to rate the thread)
Download the GPS.CONF only Alternate* build here. (Like it? Don't forget to click on "Thanks" and to rate the thread)
*The alternate patch removes a variable that some GPS hardware on older models cannot handle. Try this if you have problems with the standard patch.
Changelog: (I'll try to keep this correct and current)
Code:
v3.1 update - New Version
introduced the NO SSL version for Google build. Shows faster performance times.
v3.1(HELP WITH THE MAINTANENCE COSTS - DONATE A FEW BUCKS)
introduced my own NTP pools
repaired the LG Alternate build (was same as standard build, compilation error)
v3.0 (HELP WITH THE MAINTANENCE COSTS - DONATE A FEW BUCKS)
based on v2.2 configuration
has my own XTRA/AGPS server instead of Qualcomm
re-added two AGPS variables from v1.3 (two beta-testers saw instant results with these re-added)
re-added on USE SUPL variable from v1.3 (two beta-testers saw instant results with these re-added)
variables are now divided into sections and sections have descriptions
Code:
v2.2 update - New Version
introduced the NO SSL version for Google build. Shows faster performance times.
v2.2 (additional builds added)
added a new SUPL version using data from Sony Ericsson
added an alternate release using LG SUPL servers
added an alternate release using Google SUPL servers
updated the ADB PUSH to include new versions
fixed broken download links for the patch
v2.2
removed local AGPS variable
removed local XTRA_SERVER variable
created LG Build with LG SUPL servers (some LG ROMs fail to work with non-LG SUPL servers)
reduced redundancy in NTP and XTRA (unnecessary entries)
added newly located SUPL server to T-Mobile build
v2.1 (encompassing changes between 1.3 to 2.1)
removed two NTP server pools
removed xtra1 server
removed multiple SUPL_HOST entries
aligned SUPL_HOST with SUPLROOTCERT in each package
increased QOS timeout from 89 to 100
removed QOS standalone timeout variable
removed extra AGPS variables
Old Versions:
3.x Trunk:
v3.0 ADB Push Installer
v3.0 Google Build
v3.0 Google Alternate Build
v3.0 Google CWM Build
v3.0 AT&T Build
v3.0 T-Mobile Build
v3.0 LG Build
v3.0 LG Alternate Build
v3.0 Sony Ericsson Build
v3.0 GPS Only Build
v3.0 GPS Only Alternate Build
2.x Trunk:
v2.1 Google Generic Build
v2.1 AT&T Specific Build
v2.1 T-Mobile Specific Build
v2.1 GPS.Conf Only Build
v2.1 GPS.Conf Only Build (alternate)
v2.0 Google Generic Build
v2.0 AT&T Specific Build
v2.0 T-Mobile Specific Build
v2.0 GPS.Conf Only Build
v2.0 GPS.Conf Only Build (alternate)
1.x Trunk:
Worldwide 1.3
Worldwide 1.3n (alternate)
North America 1.2
Worldwide 1.2
Worldwide 1.2n (alternate)
North America 1.1
Worldwide 1.1
Worldwide 1.0 (not recommended)
North America 1.0 (not recommended)
Rules For Posting Questions:
Read the Notes Section first. I will refuse to answer questions that can be answered by some reading. If it is based upon something in the Notes Section, REFER TO THE NOTE when asking.
Answer the following questions: What ROM you are using?, What kernel are you using?, What GPS apps you have installed?, Where is your general location?, Are you using a case?, Has your GPS worked fine before?, Does it work fine with some apps and not others?, What else happened around the time your GPS stopped working? -AND- Have you reviewed the Notes Section?
DO NOT criticize the user of custom third-party NTP pools and xtra.bin data as dangerous. You obviously HAVE NOT read the Notes section OR reviewed the concurrent branch 2.x to discover it offers the standard NTP pool and Qualcomm-based xtra.bin server.
Don't indulge yourself in ignornat posts. Provide information that may be relevant to helping. Simply stating "this stopped working" or "I can't get it to work" helps nothing and only annoys other readers AND those who may be willing to help you just will not do it.
NOTES Section:
This patch will work with virtually all Qualcomm, Android phones and has been reported to work with other chipsets as well. That means hundreds of devices could see a benefit to GPS performance from this patch.
This patch has various objectives to ensure stability and efficacy with GPS. Locally, the patch will replace your /system/etc/gps.conf and your /system/etc/suplrootcert if you have this file. You can compare the difference in what you have to this one to get an idea of all the changes. V3.1, onward, contains section descriptions for variables in use. Most notably, starting with v3.1 the aGPS Patch uses my own central NTP DNS pool and my own central xtra.bin server by default. The xtra.bin does have fallback servers should mine fail. But, that is very, VERY much an unlikely scenario. These two imperatives allow for better stability and speed by providing top-rated NTP servers and prime-routed network access to transmit the xtra.bin to your phone.
I recommend the GOOGLE BUILD of all trunks. However, you can use any build with any phone. You may have good luck with specific builds that do not fit your phone or carrier criteria. If you're curious, test it and see.
This works with ANY ROM unless the ROM has aGPS and/or GPS disabled in the code. This happens with CMx nightlies and some betas! I cannot fix this, neither can you.
Remember, this has to be reflashed when you update or change ROMs.
Short patch history: The 1.x trunk only flashed a modified gps.conf file which relied solely on Qualcomm and NTP.ORG. Starting with 2.x, a gps.conf and a matching SUPLROOTCERT file for SUPL server authentication is included. The 3.x trunk offers the same as v2.x but adds better sourcing for NTP data and for the xtra.bin file; it utilizes my own server to do so.
Why toss out SSL?Whether or not you have a current SUPL certificate is questionable. Some have expired. Some will expire soon. Either way, the servers may provide SSL access without proper certificates depending upon configuration. That aside, I have found that SSL and secure communications over data networks slows the response times. I see no reason to use SSL for location information. If someone has a logger to obtain your location, SSL will not assist in stopping it. The bad app will continue to obtain your information by "stealing" it and you have more problems than a simple SSL-SUPL communications leak.
NO-SSL Builds will not have a SUPLROOTCERT because these builds do not use SSL. The SUPLROOTCERT is a certificate used for authentication of SSL connections. There is no need for this file for the GPS at this point.
IF you have issues with v2.x or v3.x, your ROM might require more variables. Try the old worldwide v1.3 version in this instance.
IF you still are facing issues, it might be that your GPS hardware is very much outdated. Try any "Alternate" build to see if this helps.
CMx ROM users may not experience benefits from this patch. However, we have had good reports from CM users with one negative one. Remember to do all of the steps when flashing and the following notes are important too!
Reports indicate that this patch DOES WORK with the next iteration of Android, Jelly Bean. This patch has worked from Android 2.2 (Froyo) up through Android 4.1 (Jelly Bean). Therefore, it works with all iterations on the market. I will remove support as soon as it is confirmed to NOT work with a new version of Android.
Reports show that certain ROM's including some CM builds require a modification in the build.prop. You need to change "ro.ril.def.agps.mode = 2" or "ro.ril.def.agps.mode = 0" to be "ro.ril.def.agps.mode = 1" in order for aGPS to properly function. Only do this IF YOU ARE HAVING PROBLEMS after attempting the standard patch.
Your phone "learns" about the individual GPS satellites. This is part of the aGPS design. Don't be surprised if the first time you use GPS Status that it takes 20+ seconds to "lock".
I have read a lot that indicates that it is best to let your GPS run using any application for a while to "learn" aGPS information. I let GPS Status run for about 10 minutes (it has an option to disable the screen timeout, which I do) each "first time" to learn. I say each because I test a lot of tweaks and fully reset/delete GPS cached information to start retesting.
Remember, this has to be reflashed when you update or change ROMs. Each ROM will have its own gps.conf, normally not suited to all devices.
I use GPS Status to test my signal strength. It isn't 100% accurate, but it gives a very good sense of how the GPS is performing.
If you're wondering why GPS is slow on certain apps? Or, you show up as on a street when you're 6 meters away from it? Well, those apps process GPS data differently which is out of anyone's control except the app developer. Certain apps will force your location to a street until you pass the app error threshold. Food for thought.
DO NOT USE ANY OTHER GPS FIXING APPS with this patch. If you do, and you still have problems, I cannot help you. A number of these Apps will overwrite what my patch does dynamically.
Variables are described starting in v3.0. Open up gps.conf in a text editor to read about what variable sections are for. It isn't in-depth, but should be enough to help you get a general understanding.
Still having weak GPS reception? Take your case off. Cases have been known to affect signal, though some argue against it. Personally, I get 3 more sat's when I remove my case.
There is a reported variable that can cause some GPS units not to work as well as it should with this patch. This is very odd as it's hit-and-miss and only seems to cause problems on less than 10% of handsets. This doesn't mean it screws up anything! It's possibly an older piece of GPS hardware incompatible with this variable. Have no fear, v1.2 will remove this variable for the worldwide version. This issue is more prone to occur in DHD.
Tried taking the battery out for 30 seconds? Some have reported that their phone required the battery to be removed. First, power off the device. Second, remove the battery for 30 seconds. Third, put it back in and give it a try. I cannot explain this except for possible cache clearing.
Some Inspire 4G and DHD devices have hardware problems. There is a known problem that the spring connectors to the GPS antenna sometimes are out of place or quit touching. http://forum.xda-developers.com/showthread.php?t=1101066 provides a video on self-repair.
An error in flashing this patch means that this method will not work for you. Use one of the other methods for flashing this patch. Don't ask why or for a fix. There are hundreds of variations of recovery systems and update binaries. I do not have the time or desire to support them all. This is why I describe other install methods. Reference error: E:Error in /sdcard/android apps/agps.patch.google.build.nossl.v3.1.zip (Status 0) Installation aborted.
Location is way off? Like, not near you at all? This means your GPS is not actually being used. Try the following to resolve it: Goto Settings -> Locations and disable ALL options. Reboot into recovery. Clear Cache and Dalvik Cache. Reboot normally. Go back to Settings -> Locations and only enable GPS. Reboot once more and try your GPS again. If this didn't work, did you read all of the Notes such as the one about the battery or RIL?
Donations: If you wonder why I asked for donations, it's simple. Users of v3.x are gaining extra, noticeable benefit over v2.x. This comes at a cost to someone. I pay the bills to provide a reliable data setup to transmit the xtra.bin data file and to provide the top NTP SERVERS in one DNS pool. To help keep this going, I just ask for the user to consider a donation. Nothing more, nothing less. Thank you for your consideration.
AGPS Patch Officially Supported Devices:
Acer Iconia
Asus Transformer Prime
Asus Transformer (TF101)
Asus Transformer TF300T
HTC Inspire 4G
HTC Desire HD
HTC Sensation
HTC Incredible S
HTC Salsa
HTC Flyer
HTC Evo 3D
HTC Desire S
HTC Wildfire
HTC Wildfire S
HTC Droid Incredible 2
HTC Thunderbolt
HTC Desire
HTC Desire Z
HTC One X
LG GT-540 OPTIMUS
LG Optimus One
Motorola Triumph
Motorola Droid X2
Samsung Galaxy S II Skyrocket (SGH-I727)
Samsung Galaxy S II (I9100)
Samsung Galaxy S II (SGH-T989)
Samsung Galaxy S Plus I9000
Samsung Galaxy Nexus
Samsung Galaxy S III (AT&T, Rogers, Bell, Telus)
Samsung Galaxy S III I9300, I9305
Samsung Galaxy S 4G
Sony Ericcson XPERIA X8
* I do not officially support all devices that this patch is known to work on at this time. You may private message me your success story for official support considerations.
Thanks Section
While this has gone a long distance since its inception, I want to still send thanks to Angeldeath for permitting me to take his early work and start tweaking it for HTC Inspire 4G users. This inevitably led to what we have here today.
Thank you to all those who joined and participate in the testing community. Without their help, I couldn't get enough data to know how well this works on different devices and in various regions of this planet we call Earth.
Thank you eagleeyetom, husky69, and tamagotono for their work in building an ADB pushing environment for Windows and for Linux respectively.
If you are happy with the patch and find this thread useful, please consider pressing the "Thanks" button on any of my posts on this thread. You may also consider rating this thread with five stars if you're satisfied. You may do so just below "Search This Thread" on the right-side at the top of this post. Donations are appreciated (See last NOTE)
REVIEW THE WHOLE THREAD BEFORE POSTING QUESTIONS.
Currently: this is a tentative supporting thread for my aGPS patch. Assuming more report success, I will start officially supporting this device.
Please let me know your success rates. Thus far, a few people have sent me messages and emails stating that this patch works great on this device.
As such, I'm thinking it would be good to provide this officially for this device.
This has been used on over 40 devices successfully. I don't offer official support for all devices. Rather, I offer official support once users convince me to do so for that particular device. That happened here.
Statistically, here is part of my post from mid-December on all official threads:
So, let me give you a general update directed to those 3.x trunk users:
My server has automatically generated an xtra.bin file for your GPS excitement 3,980 times since September 26th when the first beta went online to test it out.
My server attempts to build a new version every 30 minutes. Depending on what it can decypher from other xtra.bin sources, it provides a totally fresh xtra.bin approximately every 1.2 hours.
My server has served up over 500,000 xtra.bin files to users like you on XDA since v3.1 was released.
My server continues to provide a reliable NTP pool to v3.x users by directing your phones to a handful of RELIABLE and FAST-RESPONDING NTP servers around the world. This ensures you can travel and not have to switch NTP pools.
Click to expand...
Click to collapse
Enjoy!
Dude i have question about the Patch
1st i already done this on my Wildfire S : http://forum.xda-developers.com/showthread.php?t=1239713
Im with the Latest Stock EU 2.3.5 ROM and i must to tell you
that after i donte this gps.conf file now when u turn on my GPS even from cold start i need 2 to 5 seconds to Lock the Satelites
But i saw just your pach now and wondering to try it too.
So what does the patch do exactly?
And can you tell me witch one to install i mean will be better for me and my stock ROM?
Thank you in advance!
P.S Now im cheking what is writen inside your gps.conf file if you need i can give you mine i don`t know do is posible the GPS to lock for 1 seconds but im sure that my gps.config work because im using GPS all the time and befor to edit it i waiting 3 times more for satelites. this is why im interesting in your pach too
tsalta said:
Dude i have question about the Patch
1st i already done this on my Wildfire S : http://forum.xda-developers.com/showthread.php?t=1239713
Im with the Latest Stock EU 2.3.5 ROM and i must to tell you
that after i donte this gps.conf file now when u turn on my GPS even from cold start i need 2 to 5 seconds to Lock the Satelites
But i saw just your pach now and wondering to try it too.
So what does the patch do exactly?
And can you tell me witch one to install i mean will be better for me and my stock ROM?
Thank you in advance!
Click to expand...
Click to collapse
Good question. First, that user used my work as a base for his article. I spoke with him on that because no credit was given. Apparently, someone else gave him my work and my explanations to be a basis and didn't inform him that it was verbatim something I said.
However, my patch does more than what is discussed there especially if you choose the 3.x trunk. The reliance on NTP.ORG is not the most prudent choice. So, I created my own centrally controlled DNS pool for NTP servers that have proven to be reliable across cellular networks. NTP.ORG pools thousands of servers that do not always have the best networking transmissions. This causes issues to phones who are served that NTP server by NTP.ORG.
Next, v3.x uses my own centrally maintained xtra.bin file. My server and its mirrors have proven to provide users with that data file much faster than Qualcomm servers. Further, we use a series of scripts to ensure that we are serving the most reliable file. Sometimes, Qualcomm files aren't reliable enough for our tastes. We replace it with a custom file when Qualcomm falls below a minimal reliance threshold.
Literally, a large number of ROM developers bake this into their ROMs on already supported devices. From that, thousands of users operate with this patch daily. My servers are sending xtra.bin files and NTP server information constantly.
I always recommend the "Google Build" to all users. Most ROM dev's use the 3.1 Google Build in their ROM's at this time. Other builds are available for those who want Network specific options.
The alternate build is for those who have an old Qualcomm GPS chipset that cannot handle particular data processing. This resolves that problem.
My GPS is working good but I'll test this tomorrow out of curiosity.
I stumbled upon your thread a couple of weeks ago and posted a link to it in a GPS thread for wildfire s, just never got round to trying it.
Thanks.
intel007 said:
My GPS is working good but I'll test this tomorrow out of curiosity.
I stumbled upon your thread a couple of weeks ago and posted a link to it in a GPS thread for wildfire s, just never got round to trying it.
Thanks.
Click to expand...
Click to collapse
Let me know how it goes. I'm looking forward to supporting more devices officially. Right now, I'm on target to do official support for 7 more devices including this one if all goes well.
crypted said:
Good question. First, that user used my work as a base for his article. I spoke with him on that because no credit was given. Apparently, someone else gave him my work and my explanations to be a basis and didn't inform him that it was verbatim something I said.
However, my patch does more than what is discussed there especially if you choose the 3.x trunk. The reliance on NTP.ORG is not the most prudent choice. So, I created my own centrally controlled DNS pool for NTP servers that have proven to be reliable across cellular networks. NTP.ORG pools thousands of servers that do not always have the best networking transmissions. This causes issues to phones who are served that NTP server by NTP.ORG.
Next, v3.x uses my own centrally maintained xtra.bin file. My server and its mirrors have proven to provide users with that data file much faster than Qualcomm servers. Further, we use a series of scripts to ensure that we are serving the most reliable file. Sometimes, Qualcomm files aren't reliable enough for our tastes. We replace it with a custom file when Qualcomm falls below a minimal reliance threshold.
Literally, a large number of ROM developers bake this into their ROMs on already supported devices. From that, thousands of users operate with this patch daily. My servers are sending xtra.bin files and NTP server information constantly.
I always recommend the "Google Build" to all users. Most ROM dev's use the 3.1 Google Build in their ROM's at this time. Other builds are available for those who want Network specific options.
The alternate build is for those who have an old Qualcomm GPS chipset that cannot handle particular data processing. This resolves that problem.
Click to expand...
Click to collapse
OKay thank you i already install Patch 3 Google you recomend will chek and will see how its working and will write a coment here
TEST: I install the Google one that you recomend And i test it outsite from cold Start what i mean is just restart the device and RUN the GPS after 6-7 Seconds IS done and what i saw i have Locked 11 Satelites this is alot i think.
So this is when i run the GPS for 1st time after sistem rebot
After this if i run it again there is not time to lock the satelites i mean the satelites are lock for 1-2 seconds almost imideately after run the GPS
So im guessing your pach is working Because the result is cool and 11 Satelites is serious
How fast received data is "expiring" ? I'm asking this because my phone rarely has internet connectivity while using gps (mobile internet disabled).
__DS__ said:
How fast received data is "expiring" ? I'm asking this because my phone rarely has internet connectivity while using gps (mobile internet disabled).
Click to expand...
Click to collapse
The xtra.bin data files upon creation are valid for 24 hours. The least amount of time from my server (v3.x uses it) is 23 hours if you download it right before rebuilds.
Version 3.1 flashable works great on the marvelc.
Sent from my HTC_A510c
Hello Bigchillin what file and method did you use for our version of the phone i am running S-off rooted 2.3.4 insink71Marvelc rom
Turtlejoe22 said:
Hello Bigchillin what file and method did you use for our version of the phone i am running S-off rooted 2.3.4 insink71Marvelc rom
Click to expand...
Click to collapse
If you want to give it a try before you hear a response from him, I'd start off with the v3.1 Google build. That is used almost all the time. It's also the version ROM dev's include in the ROM's that do include this patch.
But what method should i use ??
Turtlejoe22 said:
But what method should i use ??
Click to expand...
Click to collapse
I prefer flashing the file from my SD card in recovery mode.
Sent from my Desire HD using XDA App
btw, where downloaded file stored in phone filesystem ?
__DS__ said:
btw, where downloaded file stored in phone filesystem ?
Click to expand...
Click to collapse
It depends on what files you are discussing. Do you mean the files that the patch flashes? If so, it flashes gps.conf and suplrootcert to your /system/etc/ directory.
I used the version 3.x trunk cwm flashable zip. Just download and flash just like any other zip.
Sent from my HTC_A510c using Tapatalk
crypted said:
It depends on what files you are discussing. Do you mean the files that the patch flashes? If so, it flashes gps.conf and suplrootcert to your /system/etc/ directory.
Click to expand...
Click to collapse
No, downloaded file with gps info.
__DS__ said:
No, downloaded file with gps info.
Click to expand...
Click to collapse
Good question. In theory, it should be downloaded and stored in /data/ but that never happens. The daemon, gpsd, is in charge of downloading and parsing it. Various configurations operate differently. I would imagine yours downloads, parses, and stores it as data within its general gps temp files containing operative information.
Sorry I cannot be more specific at this point. My work focuses on better retrieval of information, time, and enabling extra variables which permit faster processing of the GPS data.
I haven't played with the internal guts and libs of the GPS system itself. I have found the internal structure is fine as it is based on our work thus far; the problem for many of us lies in the gps.conf configuration and latency for data downloads.
I install it via the ADB push i think this is even more easy because no need to put the file in the storage card then go in recovery and flash it etc
Its simple download just the ADB conect the device run the bat press 3 or whatever you want hit enter and you are ready then will ask you for rebot its a job for a seconds super easy so i flash it like this
The result of probably more than 100 hours of solo hackery: a working COM DLL for allowing any application to elevate itself to SYSTEM (root) permissions.
What you need:
An interop-unlocked HTC phone. Sorry second-gen and Arrive users.
A working HtcUtility driver. It's possible some HTC update at some point crippled this. It works for me; if it doesn't work for you let me know what updates you have.
What it does:
Allows changing the security token of any application to give that app unrestricted permissions. At this point, you can call any user-mode API, perform any operation, with full access.
It also allows you to read or write any value from memory, even kernel memory (this is how it modifes the security token).
What it can be used for:
Darn near anything. If it can be done while the phone is booted, you can do it.
What it can't be used for:
Modifying the ROM - the R and O stand for "read only" and they mean it.
Interop-unlocking a phone - it requires interop-unlock to get root in the first place.
How to use it:
In your app, include the HtcRoot.dll library.
Include the code from DriverAccessTest.cs in the test app (defines the COM API and enables using it).
Call the OpenHtcUtility function (will throw an exception if your device is incompatible).
Call the MakeMeRoot function (can also throw exceptions).
(OPTIONAL) Call the ReturnZeroIfRoot function to make sure your app is elevated (does not throw exceptions, will return an error code if you get one).
Do stuff with SYSTEM permissions (probably using another COM DLL, such as for registry or filesystem access).
Call the RestoreToken function (failure to do this *might* cause a kernel memory leak).
Call the CloseHtcUtility function (OS will probably handle this if program just exits).
What you can do right now:
Try the test app. It should pop up a series of messge boxes. Hopefully none of them say anything like "FAILURE".
Report any bugs or failures you discover.
Build things with this library, and publish them!
Breakdown of the download:
There are two folders in the ZIP, one for the Visual Studio 2010 C#/Silverlight XAP project, and one for the Visual Studio 2008 C++/COM DLL project.
The test XAP is in the HtcUtilityTest\bin\Debug folder.
The native (COM) DLL is also available in that folder, or under its own project.
If you want to mess with this, I'm going to assume you are already familiar with hybrid native/managed development for WP7. If not, Heathcliff74 has posted an excellent tutorial on this forum.
Special thanks to:
Heathcliff74 for the hybrid app tutorial and interop unlock info.
Paul_Hammons for the links and info about HtcUtility, the driver that makes this possible. Thread: http://forum.xda-developers.com/showthread.php?t=1434793
Supported devices / firmware versions / ROMs
All HTC devices (if interop-unlocked and with the right firmware numbers) should be compatible.
Some custom ROMs work, some do not. This will depend on the version of the firmware that the ROM's HtcUtility driver is taken from.
I believe I compiled the test app as Mango-only, but the native library doesn't care at all.
Compatible:
Stock ROMs with compatible firmware for HD7, Trophy, Mozart
HD2 (BttF [XBmod-Yuki] v2 SP1)
Not compatible:
Firmware version 2250.21.51004.401 or newer
Verizon Trophy firmware version 2305.13.20104.605 or newer
DFT ROM with build 8107, Firmware 5.10.401
Arrive (except on pre-Mango), Titan, Radar, Titan 2 (no interop-unlock)
Others are untested or results are incomplete.
Goals and future work:
Support more devices:
* Try and add support for newer firmware.
* Help ROM cookers ensure the library is supported.
* Look for similar openings in other OEM libraries.
Future-proofing:
* Allow installation of a mod to support this capability after known updates.
* Resilience against possible future updates.
* Allow users with incompatible devices to downgrade (possibly to NoDo), install the mod, and be able to use the phone after upgrading.
Improve the library:
* Fix some memory leaks.
* Clean up the code - remove dead code and improve comments.
* Allow reading/writing more than 4 bytes at a time from managed code.
* Add APIs to elevate other processes (by name or ID) to SYSTEM.
Develop homebrew around the library:
* Support accessing common APIs (filesystem, etc.).
* Resurrect the Advanced Explorer app, perhaps (registry and filesystem).
* Support native app launching on stock ROMs.
Also reserved
Reserved for OP #2
It does not work on HTC 7 Mozart (HTC Europe):
Error to Write the value 1337 to test address - System.Runtime.InteropServices.COMException (0x8007001F): A device attached to the system is not functioning
Click to expand...
Click to collapse
OS: 7.10.7740.16
Firmware: 2250.21.51101.401
Radio: 5.71.09.02a_22.51.50.21U
Boot: 5.11.2250.1(133487)
Please include the full error message or a description of what went wrong.
Failure on fully updated devices is unfortunately possible - my phone is (intentionally) a few updates behind. I'm looking into ways to make it work anyhow (either sending an older CAB update to roll back, or using the root acess to create an unlocker/root-enabler that survives subsequent updates). I'm going to look into how the full-unlock ROMs differ from standard ROMs, and see if I can do the same thing in running software.
Does it works with custom roms?
If the custom ROM has a working HtcUtility driver, then yes. My goal is to unlock the kind of capabilities normally restricted to custom ROMs on stock firmware, though.
@bleh815: Thanks for the report. That's frustrating; it looks like it is capable of doing read but not write. Write might just be restricted in what addresses is allowed, or it might be disabled entirely (the driver gives the same error code for every problem that I've encountered so far). Time to figure out
A) what update causes the problem (I'm on 2250.21.30102.531, HD7, stock ROM)
B) what restrictions that update introduces
C) how to work around those resrtictions (possibly by downgrading and then using root access to add something that will still work after upgrade).
GoodDayToDie said:
A) what update causes the problem (I'm on 2250.21.30102.531, HD7, stock ROM)
Click to expand...
Click to collapse
I've just downgraded a mozart of mine back to stock NoDo (TMOB-DE) to find out which OEM update breaks (actually fixes) it.
Cool, thanks! It's one of the post-Mango HTC updates; a Microsoft update wouldn't have modified an HTC driver, and my phone has all the pre-Mango HTC updates but it still works.
.
..........
Hi, at first it says "SUCCESS!", then it says "Trying to open a file gives error 1260" and then it says "Now opening a file gives error 0" and finally "Finally, opening a file gives error 1260".
System informations:
OS=7.10.7720.68
Firmwareversion=2250.21.12200.162
Radio=5.68.09.05a_22.50.50.21U
Bootloader=4.6.2250.0(129185)
HTC 7 Trophy.
That is *exactly* the sequence of messages it is supposed to give!!
In particular, the messages I need to see are the "SUCCESS" (the rest is potentially interesting info, but not very important) and then the "Now opening a file gives error 0".
The "SUCCESS" means that a sequence of read/write tests succeeded.
The "Now... error 0" means that the process has been elevated to full permissions.
The "Finally... error 1260" means that the security token was successfully restored at the end, so it was unable to open the file again. This is the expected and correct behavior.
I don't recognize your Firmware Version number; I'm guessing it's specific to your phone. What method did you use to upgrade to Mango?
how do i install it?
Tried on interop-unlocked HTC Surround, not working Tested any call in VS debug mode - no luck at all.
I can confirm that it works with any OS version, from 7004 to 8107.79
On a HTC 7 Mozart (TMOB-DE) it works with firmware 2250.21.13201.111 (Stock NoDo ROM) but the hole gets fixed with 2250.21.51101.111 (1st Post-Mango HTC Update).
You guys are gods taking programming to a hole new level!
I wish to see ms take you all more serious and not let wp7 fail like minmo6.5 did!
I wish I could get on your level!
I realy need some help lerning basic silverlight my self!
But I have read how hybrid working ant this is just fantastic!
conradulations on all your developments so far you guys are truly amazing!
Oh, that code, beautiful reading that!
Thanks for sharing this learnfull code!
I'd like to try it on my Verizon HTC Trophy, I would love to get file access back....
I downloaded the package and I even have VS 2010 installed but beyond that I have no idea as I am not a programmer.
Can someone post a compiled XAP for us to try to see if our phone works with it or not ?
Or some step by step VS 201 directions to try would also be helpful.
@Ttblondey: *FACEPALM* The path to the test XAP is given in the opening post. You install the XAP on your phone using any XAP deployment tool. It requires that your phone be interop-unlocked; Heathcliff74 has a nice long thread about that. The app is called called HtcUtilityTest. Run it, and report the results. If you want to actually *use* the DLL, the instructions for doing that are given too but you need to write some code.
@sensboston: PLEASE give a more complete report! Success and error messages, at the least. Also, your phone version info. Thanks!
@bleh815: THANK YOU! I mean, it's a little annoying to know how far back this was fixed ("First post-Mango HTC update" means the one that was included *with* Mango for most people, or the one after that?) but good to know. Now, to look at exactly what they changed...
@jackrabbit72380: Thanks man! As for working with it yourself, like I mention below, I'm planning to provide a universal homebrew library that people can easily use to do whatever they want.
@fiinix: You're welcome! Honestly, I didn't expect anybody to call my mess of debug-commented and mildly hacky C++ "beautiful" but that hack itself *is* pretty awesome. My only concern with using it is the risk of a context switch causing the wrong app's token to get overwritten, and I should probably look into that, but I think it's OK for the moment. There are bigger fish to fry.
In the meantime, it should open up a huge list of capabilities for tools like your DllImport project. I'm currently considering reviving Advanced Explorer (like TouchXplorer + Registry Editor, but open source; was never ported to Mango though) using the root access instead of using ComFileRW and the provxml driver. Let me know what you want to do with it!
One other thing I'd like to add is the ability to easily elevate *another* process; it's not hard to do but I haven't written it yet. This could be handy for apps where we don't have the source code (for example, elevate Schaps registry editor, which uses low-privilege native code for browsing, so it can read *all* registry locations instead of just some of them).
@DavidinCT: Well, running the test app is easy, just install the XAP. It just runs a battery of tests though, it doesn't actually *do* anything useful. To get filesystem access, you'll need to write some native code (which means using Visual Studio 2008 and the CE/Smart Device plug-in, see Heathcliff74's toturial on the subject). Basically, you would first use this DLL (accessed via COM, you can look at my own C# code for how to do that) to opent he driver handle and elevate the process to root. You could then write your own COM DLL that uses the standard Win32 filesystem APIs (CreateFile, etc. - all are documented on MSDN) and exposes those APIs, or the results of them, to managed code via COM. Then, back in your phone app (the one that called into my HtcRoot DLL) you can call into your own DLL to access the file system.
If that's too big a leap, don't worry. I plan to release a general-purpose high-privilege homebrew DLL that exposes some of the most-used functionality (filesystem, registry, provxml, and other things by request), is easily extensible (possibly using something like the DllImport project, where you just specify the function you want to call and the DLL it's located in right from C#), and that will be a lot easier to hack with. You'll still need to know C# and basic Silverlight, but it'll be a lot easier (and hopefully useful without knowing any C++ or COM).
GoodDayToDie, you are amazing, always keeping me interested!
When starting the test xap, I get the below, it then goes into the "Page Name" and that's it.
Device Info here, running a FullUnlock DFT Rom by a Chinese dev from the DFT Forum.
Nonetheless, top work on getting this started and can't wait to keep reading about the progress!
XeKToReX
UPDATE: Still working on a newer version of the webserver, but I've been distrcted by a number of other projects lately (including getting a new job). The most important news is that the Root Webserver works great with WP7 Root Tools; you don't need a full-unlocked ROM or HtcRoot compatibility anymore! Just mark the app as Trusted in the WP7 Root Tools policy pivot, and you're good to go.
Sorry for the long delay, I've been working on many different things. One of them is re-write of a substantial part of this app, to make it more modular and extensible and also to add more features. That re-write is far from done, any may end up being broken into a few smaller pieces once any of the new or re-written features reach release-quality without the whole app being unusably broken.
This project started out as a child of the HtcRoot project. It no longer requires HtcRoot; full-unlock or WP7 Root Tools work fine. It's also a child of the Functional Webserver / WebServer (Mango) projects, and builds on their open-source foundations. Its goal is to allow unfettered access to your phone through the convenience of a web browser.
Fifth release (v2.3.1)
Platform release, minor feature release, minor library update, bugfixes
Should now be compatible with fully unlocked custom ROMs, even if they can't use the HtcRoot project.
This release does not include NativeIO_Mango source, as it was not changed. If you need the source for this library, extract it from the 2.2.0 download.
Homebrew library (v1.6.3)
Better detection and reporting of exceptions due to not being root.
Should be safe to use the HtcRoot functionality on fully-unlocked ROMs.
Please see the changelog in the app for details and history
Note that this app requires a slight update to NativeIO_Mango from @fiinix's version. There were some bugs in the library that were making things difficult, so I fixed them. I also changed the return values of a couple functions (though the signatures are unchanged) to give the ability to return error codes from COM. Source code for both the managed Homebrew and COM NativeIO_Mango libraries is included, along with compiled binaries. Source code for the HtcUtility library can be downloaded from the HtcRoot proect.
Features:
View folder and ROM Module last-modified dates. (NEW 2.3.1)
File attribute info now presented better. (NEW 2.3.1)
Upload files anywhere. (2.2.0)
Create and delete directories anywhere. (2.2.0)
Delete writable files.
Add or Remove readonly attribute from files. (2.2.0)
See file size and attributes for any file.
Browse the entire filesystem.
Download any file (still not ROM modules, though).
Static HTML files in a "Content" folder for easier editing.
Easy link to browse (and add your own files) to Content folder (2.2.0)
All features of previous WebServer versions (IsoStore uploading, authentication, etc.)
Changelog
Bugfixes:
Fixed a case where setting file attributes or uploading a file would fail due to lacking permissions.
Fixed the potential for infinite loops on fully-unlocked ROMs compatibel with the HtcRoot project.
More effort to eliminate RootException / Error 1260.
Upcoming:
Access the registry as well as the filesystem.
Better access to installed application info and folders.
View, edit, move, and rename files.
Rename and move directories.
Server-side commands (process provxml, for example)?
Filesystem/Registry/Application search?
Known Bugs:
App may take several seconds to close; don't re-launch it immediately or weird things may happen.
Touching the screen while the app is in "root" mode appears to cause a crash, and posible resource leak.
Error 1260 (Least Privileged Chamber) may still occasionally appear on first access attempt or two... really wish I knew why.
Requirements:
Developer-unlocked phone (if you remove ID_CAP_INTEROPSERVICES it will work without root access, cutting off most of the filesystem).
For root access, you need *EITHER*
* A fully-unlocked ROM
* An interop-unlocked HTC phone with working HtcUtility driver
If your phone is compatible with the HtcRoot project, you're OK.
Thanks To:
Davux (original author of the "Functional Webserver" app)
Fiinix (Ported the NativeIO library and Webserver app to Mango)
MarysFetus (designed icons and graphics for the webserver app - site http://klaus-widraw.de)
Everybody who helped make the HtcRoot project possible.
Have fun!
Reserved for OP
Also reserved.
pretty neat
I'm not by my HTC HD2 but anybody know if will this work on it under the B.t.t.F ROM?
Awesome work GDTD!
EDIT: Doesn't work on a HTC HD2 on B.t.t.F v2.1 @ 8107 (no SP1) I get the following error when trying to connect from my PC:
Code:
Exception while getting the listing for /!
Homebrew.InteropException: Error listing subdirectories of ! GetLastError: 1260 at Homebrew.IO.DirectoryInfo.GetDirectories(String filter) at Homebrew.IO.DirectoryInfo.GetDirectories() at WebServer.MainPage.handler.BuildDirectoryListing(String dirPath) at WebServer.MainPage.handler.Process(RequestContext context) at HttpServer.Server.ProcessModules(RequestContext context) at HttpServer.Server.HandleRequest(RequestEventArgs e) at HttpServer.Server.OnRequest(Object sender, RequestEventArgs e) at HttpServer.HttpListener.OnRequest(Object sender, RequestEventArgs e) at HttpServer.HttpContext.OnRequest(Object sender, FactoryRequestEventArgs e) at HttpServer.Messages.MessageFactoryContext.OnMessageComplete(Object sender, EventArgs e) at HttpServer.Messages.Parser.HttpParser.OnComplete() at HttpServer.Messages.Parser.HttpParser.GetHeaderName() at HttpServer.Messages.Parser.HttpParser.Parse(Byte[] buffer, Int32 offset, Int32 count) at HttpServer.Messages.MessageFactoryContext.Parse(Byte[] buffer, Int32 offset, Int32 length) at HttpServer.HttpContext.ParseBuffer(Int32 bytesLeft) at HttpServer.HttpContext.OnReceive(Int32 bytesLeft) at HttpServer.HttpContext.b__a() at System.Threading.ThreadHelper.ThreadStartHelper(ThreadHelper t) at System.Threading.ThreadHelper.ThreadStart_Context(Object state) at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state) at System.Threading.ThreadHelper.ThreadStartHelper()
It is interop unlocked so I don't get the error.
NOOOO I AM CRYING !!! THIS IS WHAT I WANTED AND I CAN'T EVEN TRY IT !!
Kill me now ;_; sigh sob sigh
EDIT : good work and good luck
@voluptuary: If you can run the HtcUtilityTest app successfully (from the HtcRoot page) then yes, this will work.
On that thread, I have the following listed as compatible:
HD2 (BttF [XBmod-Yuki] v2 SP1)
That your ROM?
@Voluptuary:
To quote from the Known Bugs section:
First attempt to access the filesystem will often fail or take too long; hit refresh a couple times and it should work.
I don't know why it does this. I built in some delays and some automatic retries, and that improved things dramatically - it will *almost* always work on the first freresh attempt (or second click on the Filesystem link) now - but didn't eliminate the problem. I'm not sure what it is; on the test app the switch to SYSTEM token is effectively instant. Maybe it has to do with the number of threads or something?
Anyhow, give it another shot and it should work. I contemplated just putting in a 5-second auto-refresh on the error page...
GoodDayToDie said:
@Voluptuary:
To quote from the Known Bugs section:
First attempt to access the filesystem will often fail or take too long; hit refresh a couple times and it should work.
I don't know why it does this. I built in some delays and some automatic retries, and that improved things dramatically - it will *almost* always work on the first freresh attempt (or second click on the Filesystem link) now - but didn't eliminate the problem. I'm not sure what it is; on the test app the switch to SYSTEM token is effectively instant. Maybe it has to do with the number of threads or something?
Anyhow, give it another shot and it should work. I contemplated just putting in a 5-second auto-refresh on the error page...
Click to expand...
Click to collapse
Sorry, I should have read your post better. I hate when people do that to me in my threads, I should know better.
Anyways I got it working, kinda. It still gave the error at the top of the page but then it listed the directories anyways, then navigating to Windows always fails, just times out or stays loading forever. This is over Wifi, I guess it could be a latency problem but everything else on my network runs fine.
I install but it does nothing.It shows serial on usb, softwareloopback interface1,bcmsddhd1
I'm looking into ways to resolve the read error issue. Once it decides to work, I can leave the app running for hours (on USB power, idle detection disabled of course) and browse with no trouble, but when I first open the app it's ornery for a few minutes. Very weird (and annoying). I'm guessing it's due to a threading issue, which would technically be a bug in the HtcRoot library, but I'll need to explore more.
By the way, the Windows folder takes a moment to load (it's huge). It should work pretty reliably though (you can open it for reading without having root at all, actually) and it opens a lot faster on my version than it did on the earlier ones (StringBuilder + half as many FileSystem calls + eliminated one of the slowest calls).
@Ttblondey: Dude, it's a W E B S E R V E R app. It runs a web server on your phone. You browse it through a web browser. I literally don't know what else to tell you, except to go read the threads on the other web server apps.
New version uploaded!
This contains some bigfixes - in particular, the Error 1260 bug (failure to elevate to root before trying to access the filesystem) has been mitigated to the point where it shouldn't be a problem.
It also uses a new version of the Homebrew library, 1.6.0, which incorporates access to the HtcRoot project under the Homebrew.HtcRoot namespace. Previously, the HtcRoot project was tacked onto the webserver directly, which meant the Homebrew library was unaware of its existence.
Requirements and major features have not changes in this update. Source code is included.
Great work you are doing here man! Too bad i don't own a HTC
@Briefcase: Thanks! I wish I could support more phones. Heathcliff74 may be able to enable something for Samsung (gen1 at least) but he hasn't released a library for doing so yet.
FEATURE RELEASE 2.1.0 is out.
Major changes: File attributes information, file deletion.
You should talk with ROM chefs here to include read/write enabled HtcUtility in their roms because all recent ROMs unfortunately doesn't support your findings.
@Pr0xiMUS: That's a good point. This tool is potentially more powerful that TouchXplorer or Registry Editor from TouchXperience, but those are the primarily-targeted apps in custom ROMs.
I wonder if adding registry support will be as straighforward (and simultaneously frustrating, due to bugs) as filesystem support...
New version (2.2.0).
Some bugfixes, more file operations (uploading any file anywhere, adding and removing directories). Add your own files to the Content folder so you can serve them directly, if you want.
If anybody knows of a ready-made and Mango compatible registry COM library (that's open source, thanks a ton @schaps), this would save me some time. If not, I can either ports one from NoDo or write my own well enough.
I am not able to browse the File System getting the following error.
Exception while getting the listing for /!
System.Runtime.InteropServices.COMException (0x8007001F): A device attached to the system is not functioning.
Using DFT V3 rom on Htc 7 Pro (Gold)
@Kr3i0s: Your ROM is not compatible with the HtcRoot project, due to it having a crippled HtcUtility driver. If the ROM is updatable, it might be possible to downgrade the HtcUtility driver using a custom CAB. Otherwise, you'll need to wait for (or switch to) a ROM that has a working HtcUtility driver.
EDIT: Actually, a fully-unlocked ROM can probably use this app even without HtcRoot compatibility. I'll modify the app so that it detects Error 31 and tries to fall back on whatever permissions it already has.
Hello guys! I am a bit tired today to explain all the details, we will be writing a better post soon. But for now this will have to suffice.
TL; DR;
We are going public on how to hack the headunit for HKMC vehicles. This applies to pretty much all Gen5W models, requires no soldering, and yeah, its fun I guess.
This is pretty much for devs tho, so if you expect to run youtube with this today, sorry, but not yet. It will be possible tho, but so far we were focused on getting the access.
What is all this about?This project aims to give users ownership of the headunit on their cars. You paid for your car, you own it. That includes its computers. With this project we aim to provide you with the ability to extend your stock functionality on certain korean models.
We are not on this for commercial gain, however, you can use whatever we've learnt so far to build and sell CFW if you wish, that is up to you. I only ask that you contribute back and share your findings. Basically, open source mentality between us here. We all want the same at the end of the day, which is completely owning our cars and the systems on it.
We do not sell the access to the hack.
We do not sell the tools to get access to the system.
We share our knowledge.
You can:
Build and sell your CFW using the tools / knowledge that comes from collaborating. (Please, strongly consider sharing how things are done so we can attract more developers when we decide to go "public")
Also, consider safety first. Let's try not allow non-technical people to drive while watching netflix. But this is completely to your discretion.
Tha Links
hkm-gen5 / gen5w / update_decryptor · GitLab
This is just a docker image that you can build on your own. You must provide the files yourself, we can't provide them to you. But its got...
gitlab.com
hkm-gen5 / gen5w / navi_extended · GitLab
This app is meant to replace AppNavi temporarily so you can execute things from the headunit.
gitlab.com
README.md · main · hkm-gen5 / DOKUMENTATION · GitLab
This is the place were you'll find all the general documentation for the project. What we've learned so far, and how to get things done. WIthin the projects...
gitlab.com
We will be posting things on the forums, but if you want to start doing stuff, that's where we have it. Good luck, and please share back whatever you find / learn.
EDIT: We have a new face!, you can find relevant links there as well as some troubleshooting! https://g4933.gitlab.io/wideopen
more info to come
im a bit too tired to repost the images here
but i have posted them here
Gen5W for HKMC root access
Hello guys! I am a bit tired today to explain all the details, we will be writing a better post soon. But for now this will have to suffice. TL; DR; We are going public on how to hack the headunit for HKMC vehicles. This applies to pretty much all Gen5W models, requires no soldering, and yeah...
www.ioniqforum.com
gen5w said:
Hello guys! I am a bit tired today to explain all the details, we will be writing a better post soon. But for now this will have to suffice.
TL; DR;
We are going public on how to hack the headunit for HKMC vehicles. This applies to pretty much all Gen5W models, requires no soldering, and yeah, its fun I guess.
This is pretty much for devs tho, so if you expect to run youtube with this today, sorry, but not yet. It will be possible tho, but so far we were focused on getting the access.
What is all this about?This project aims to give users ownership of the headunit on their cars. You paid for your car, you own it. That includes its computers. With this project we aim to provide you with the ability to extend your stock functionality on certain korean models.
We are not on this for commercial gain, however, you can use whatever we've learnt so far to build and sell CFW if you wish, that is up to you. I only ask that you contribute back and share your findings. Basically, open source mentality between us here. We all want the same at the end of the day, which is completely owning our cars and the systems on it.
We do not sell the access to the hack.
We do not sell the tools to get access to the system.
We share our knowledge.
You can:
Build and sell your CFW using the tools / knowledge that comes from collaborating. (Please, strongly consider sharing how things are done so we can attract more developers when we decide to go "public")
Also, consider safety first. Let's try not allow non-technical people to drive while watching netflix. But this is completely to your discretion.
Tha Links
hkm-gen5 / gen5w / update_decryptor · GitLab
This is just a docker image that you can build on your own. You must provide the files yourself, we can't provide them to you. But its got...
gitlab.com
hkm-gen5 / gen5w / navi_extended · GitLab
This app is meant to replace AppNavi temporarily so you can execute things from the headunit.
gitlab.com
README.md · main · hkm-gen5 / DOKUMENTATION · GitLab
This is the place were you'll find all the general documentation for the project. What we've learned so far, and how to get things done. WIthin the projects...
gitlab.com
We will be posting things on the forums, but if you want to start doing stuff, that's where we have it. Good luck, and please share back whatever you find / learn.
Click to expand...
Click to collapse
hello good friend. Do you have any information about HU Gen5w using Motrex's android 9.0 backend?
Gen5Premium has different encryption key i guess. All files are empty
Tank-piercing said:
Gen5Premium has different encryption key i guess. All files are empty
Click to expand...
Click to collapse
Just to be clear, did you extract a key already from the unit? I haven’t included any decryption binary nor key on the gitlab, the files you see there (DecryptToPIPE & the .DER file) are just placeholders, read te contents of those files for details
trannamptv said:
hello good friend. Do you have any information about HU Gen5w using Motrex's android 9.0 backend?
Click to expand...
Click to collapse
American Units actually use Android, but I don’t think it’s that latest android tho. In any case i know somebody else is working with android units but I don’t know how far they are
gen5w said:
did you extract a key already from the unit?
Click to expand...
Click to collapse
Ah, that's it. You need to dump headunits software first.
So decryption key is uniq for each car?
Tank-piercing said:
Ah, that's it. You need to dump headunits software first.
So decryption key is uniq for each car?
Click to expand...
Click to collapse
Not entirely sure. Nobody has yet found the key besides me (or haven’t spoken up) so I can’t compare if keys are unique across units. But the key in your unit will be able to decrypt all gen5w updates up to date. To get the key you don’t need to dump the whole software, it’s enough to just rename a program in the unit, put a shell script where that program was , once called, get the args passed to the script (you’ll have one of the args as a path) copy the content of that path to your usb and then lastly call the original program so the process works as expected for the headunit. (Man in the middle).
The reason we don’t share the key (or the DecryptToPIPE software) it’s because that might be copyrighted material, and we are avoiding any copyright infringement.
I don't have AppNavi update option in Engeneering Mode > Dynamics > Navigation.
There is no Config section. I checked the rest with no luck.
210513 firmware. Should i update to 220210?
Tank-piercing said:
I don't have AppNavi update option in Engeneering Mode > Dynamics > Navigation.
There is no Config section. I checked the rest with no luck.
210513 firmware. Should i update to 220210?
Click to expand...
Click to collapse
Yup. You need to update to the latest.
FYI: I've updated the repo and added the method to extract encryption keys for the updates:
https://gitlab.com/g4933/gen5w/navi...REMELY_RISKY_BECAREFUL/spoof_decrypttopipe.sh
USB_FILES/DecryptToPIPE_FK · main · hkm-gen5 / gen5w / navi_extended · GitLab
This app is meant to replace AppNavi temporarily so you can execute things from the headunit.
gitlab.com
maybe someone can decrypt Appengineermode app codes from february update?
Tank-piercing said:
maybe someone can decrypt Appengineermode app codes from february update?
Click to expand...
Click to collapse
Codes don't seem to have changed... is it not working for you? (0652)
0652 no longer works
andreaslev said:
0652 no longer works
Click to expand...
Click to collapse
That’s strange. Are you from the US or EU? Can you share the details of your unit ? (Version and model )
Gen5Prem
RJAS.P5LN.RU
RJ.RUS.P5.001.008.220210
Can anyone decode the Appengineermode app from the February update?
DNA.USA.S5W_M.V007.001.211123
model
DN8AS.S5BMC.D4US
platfrom
standard-class Gen5W Navigation
Hello guys, I want to tell you my story, and I need a little help from you also :
My car : Kia Sportage QLE Gen5 navi, updated to sw : 211029 fw : 210930
After update , no way to find pin for engineering mode, only dealer mode with pin 2400 and 7,3,1 volume combination. But with navigation hack, showed in this thread I managed to enter engineering, and managed to make adb to work on ethernet, but the only way to do adb to work was by installing an USB to Ethernet converter into USB, connect and ethernet cable between converter and my laptop. Don't know for sure if it is necessary or not, but after installing everything ( usb, cable, etc) I made an Reset to factory . Connected the wifi of unit and phone to house router, and finally was able to install apps with Easy fire tools.
I manage to install boot hack and now when I press 2 times on SETUP is going to engineering menu, and from there I can access all other applications that I have installed ( file manager, soundabout).
So I hope someone else who wants , can now get adb to work and install what he wants.
Now I want to ask the ones who already managed to install apps, if they can help my with some apps that are tested and working OK : I need an IPTV software, I installed GSE IPTV, with was working ok before upgrade, but now it does not start playing, only loads m3u list, you can select channel, but .. not start. Youtube working has anyone? I installed an older version, but it say it can not work without google services. And last, is there a way to add shortcuts to apps in oem menu? or a way to quick access them? or something like task manager? not to be forced every time to go to all apps and start app from there?
Thank you, end if someone needs more help with adb to work, and did not understood complete what I said, please fell free to ask, if I can I help with pleasure.
I downloaded the my20 update for xceed, but the installation checks update files section gives an error at %30 and I still could not update. Can you help me?
New updates on this guys ? Is this project abandoned ?