***THIS POST IS NOT COMPLETE, I WILL UPDATE MORE LATER***
First, an introduction:
The Image Update system allows the OEM (us! ) to issue updates to a "Live" filesystem - without disrupting user data. This allows, for example, a buggy driver to be updated after the phone has been shipped, or a software package to be updated to the latest version, with minimal knowledge on the user's part. The system validates all updates against an internal list of certificates, and refuses the update if a match is not obtained. This system can also be used to deploy entirely new software to the device (such as support for another locale, input method editor, application support for a new feature the carrier is rolling out, etc.)
Potential usage scenarios for this system
A central server could be maintained for all SYS/OEM updates - each ROM Chef would need to maintain a list of original packages, any updated package(s), and download URL's for each updated package. The user would then receive these updates through the built-in AutoUpdate facility in Windows Mobile, which can check periodically, or on-demand. Each Chef could maintain seperate download servers from the update server to minimize server load.
Alternatively, a chef could provide .cab.pkg updates in his or her ROM thread, on their own web site, etc., and the user could download these and install them at will. These packages can optionally be authenticated to be coming from the Chef, if the Chef wants to ensure updates are coming from him only. A public certificate could also be used to allow users to issue updates as well.
The more technical Summary
Image Update allows an OEM to issue updates to the OEM's, XIP, SYS, (possibly) Radio, or any combination of these. The update can be pushed to the user via a specially formatted SMS or by manual execution. There are at least 2 levels of certificate checking involved in the process, I believe against \SYS\Metadata\DefaultCerts.dat. The system reboots into the ULDR to apply the update, because the filesystem cannot be modified while actively mounted. The ULDR provides a minimal operating enviornment to facilitate this.
How does a Chef need to prepare a ROM for Image Updating?
The Chef would need to use a ROM Kitchen that leaves the .dsm and .rgu file structure intact (i.e. an "unprotected" ROM) - All .dsm's in this ROM would need to be properly formatted with Package Name, versioning info, etc. during the cooking process, in order to facilitate version checking, etc. Each .dsm would need to be signed with a certificate the Chef would use to validate the update as coming from him or her. (Alternatively a public certificate could be used like SDKCerts if the Chef chooses not to maintain direct control over updates, and allow other users to create updates as well)
The Chef also needs to ensure not to Reduce the ULDR partition or remove it; this would cripple the Update Loader and prevent the Image Update system from functioning.
The .cab.pkg format
At the root of a package, the .dsm defines the Package structure (all files, registry entries, etc.) It contains version info, certificates, and other data. A ROM consists of a number of these packages, in an area of flash memory that is not user-writable. When someone wants to issue an update using the ImageUpdate system, they create a matching .dsm, same guid, with a newer version number, same internal package name, same processor ID, os version, etc., there is also a flag that can be marked as an update package or a new package - in this .dsm they define the files that will make up the new, updated package. Here they can add or remove files. One of the files defined by the package is optionally an .rgu, and this defines the registry entries associated with the package. Also optionally included is a provxml to facilitate file operations (copy/replace/delete/rename/etc.) and further registry or metabase operations. This collection of files is rolled up into a ".cab.pkg" archive by a program like cabarc. Once in a pkg.cab format, the package is signed.
A .cab.pkg is referred to as a "Canonical Package" and multiple Canonical Packages can be rolled up into a single "Super Package" to facilitate updating multiple Packages at the same time.
Inside this .cab.pkg is where the "MNGE" file format comes in to play. Essentially, this format is Microsoft's way of storing an XIP Module in the filesystem. (Their equivalent of our imageinfo.bin + s000, s001, etc.) - The "MNGE" format is simply a 4-byte MNGE header, followed by the imageinfo.bin, followed by the s00x sections attached to the end. When the Image Update system processes a file in this MNGE format, it is added to the IMGFS as an XIP Module.
Deploying a .cab.pkg to a device
Now there are several ways to deploy this package to the device, the primary way is an OMA-DM SMS message, which triggers the Image Update system to initiate a download from a server defined in the SMS message. The server can be either a normal HTTP server or a secure HTTPS server. The Image Update system will prompt the user to plug in the usb cable to download over the users home connection if the user has not already authorized the Auto Update system to utilize their GPRS data connection.
Another way for a .cab.pkg update to be pushed to the system is simply through a file copy operation, be it ActiveSync, SD Card, Bluetooth, or otherwise. Once on the device, the .cab.pkg is executed by the user the same way a .cab would be.
The Update Agent
Initiated by either a completed download from push SMS, or user-executed, the "Update Agent" program (which is part of the \SYS\FWUPDATE Package) attempts to validate the Certificates, Package dependancies, and other info contained in the .cab.pkg and .dsm. Once validated, the "Update Agent" sets a flag that the bootloader reads, the flag is a boolean, off = boot into normal OS, on = boot into ULDR - so then the system reboots, the flag is read, and you load into...
The Update Loader
The "Update Loader" or "ULDR" which is a minimal kernel configuration, that provides just enough driver support to display info on screen, respond to user input, and read/write from the internal flash (NAND or NOR)
From here the ULDR does further validation on the .cab.pkg, and applies it to the filesystem. If there are any modules in the package it dynamically relocates the memory map to make sure there are no overlaps. This is why it's important that reloc's not be removed from your ROM - ULDR will fail in this case.
The End Result
Once the ULDR has completed updating, the device is again rebooted, back into the full system, where the now-updated packages are now a part of the IMGFS, any updated files are processed (.rgu, .provxml, etc.) - The package is now a full part of the ROM.
The new .dsm replaces the old .dsm (along with the other files in the package) and now a future update will be checked against this new package.
If the update was pushed via OMA-DM SMS, or AutoUpdate, the device Pushes a notification to the OMA-DM server notifying it of the update status.
What's missing right now to implent the ImageUpdate system?
We need a Kitchen that's properly configured to allow us to create versioning info, proper package names, and insert this along with a certificate (or multiple certificates) into the .dsm's.
We also need the Kitchen to be able to modify \SYS\Metadata\DefaultCerts.dat with the certificates used, so that it passes authentication. Alternatively the authentication checking could be patched out. (this one is easily doable at build-time)
We need a program that can convert from a standard file to an MNGE format, so we can implement modules in our .cab.pkg's. (done it seems, thanks ervius!)
We (optionally) need a properly configured web server that supports HTTP/HTTPS, can communicate the proper xml configuration data, and can be updated with new packages by Chefs. (this one's a ways off)
We (optionally) need a program to convert from MNGE format to a standard file to facilitate extracting modules from .cab.pkg's. (working hard on that)
I've attached a .cab.pkg for NetCF2. Open up mscoree.dll in a hex editor, and check out the MNGE header. This file becomes a module once processed by the ImageUpdate system. Note that all the executables (.exe/.dll/.mui) that become modules contain this MNGE header. All executables that are inserted into ROM as files keep their normal MZ file header. The first major step here will be in being able to convert between MZ<-->MNGE freely NetCF2 is a well known package that can be found in any stock ROM, so with this we have a good baseline to work with.
http://rapidshare.com/files/238295848/netcf.cab.pkg
--Reserved--
More Technical Specifications
The basic ImageUpdate Layout consists of:
[IPL] -- [MBR] -- [ULDR] -- [NK] -- [IMGFS] -- [TFAT]
[IPL] is the "Initial Program Loader" that handles basic init functions and determines if control should be handed over to ULDR, or NK through a flag set by UpdateBin.exe - the IPL is not contained within a partition. The IPL is copied entirely to RAM and executed from there. IPL loads NK into RAM, and also handles any decompression of NK if it's required - some SmartPhone's ive seen use SRPX compression for the NK partition. Once NK is copied to RAM it is then executed. The IPL is handled seperately from the other parts of the operating system, and is not flashed during a normal update.
[MBR] is the "Master Boot Record" and contains partition tables for the below components - it points to NK so when IPL loads the MBR, control is handed over to NK. The MBR contains information on where each partition is located on the flash (memory address), the size of the partition(s), and the type of each partition. The MBR is referenced from many components on the device such as IPL and ULDR in order to facilitate handoff of control between ULDR and NK. The MBR also serves as a boundry between the IPL which is not part of the regular partition structure, and the rest of the flash, which is part of the partitioning structure.
[ULDR] is the "Update Loader" and provides a basic WinMo system so that file operations can be done on the IMGFS partition while it's unmounted. The Update Loader is even able to update itself - during operation it is loaded entirely to RAM. On development workstations the ULDR supports a KITL connection, that can be used to load updates directly from the "Release" folder. It seems it may be possible through this method to flash a new image to the device, possibly opening up the ability to flash to devices that have not yet been flashed with "HardSPL"
[NK] is the "Kernel Partition" - or what we know as xip.bin - This component is updatable by ImageUpdate, and has a pre-defined "free space buffer" with room to grow, which defaults to 512KB. This partition holds only the kernel and drivers necessary to bring up the rest of the filesystem, from which the rest of WinMo is loaded. The Kernel Partition uses the same "Package" format as the IMGFS and is updatable in the same manner.
[IMGFS] is the "System Partition" - running the Image Update filesystem. This component is updatable by ImageUpdate, and has a pre-defined "free space buffer" with room to grow, which defaults to 9.5MB. The IMGFS uses the "Package" format to further split its components.
[TFAT] is the "Transaction Safe FAT File System" which is where all user-writable data goes.
In most Device Designs, there's a single NOR or NAND chip used for flash. This is important as due to the typical layout above, both NK and IMGFS must have a pre-defined amount of free space - because TFAT is the last partition on the drive, and cannot be shifted once flashed to the device. It's possible for the partition layout to be setup differently (Partitions in different order) to help alleviate that problem. The ImageUpdate system would really shine on a device with 2 flash chips, a NOR chip dedicated to the ImageUpdate partition and a NAND chip dedicated to the TFAT, but no OEM has created such a design yet.
Packages
Package Types
There are 3 different types of packages, Canonical, Update, and Super.
Canonical contains the entire contents of the package. It is used for a first-time package install, and if there are any major updates to be issued that would require the complete package. The file extension is .cab.pkg
Update contains a binary delta between a package already on the device, and the updated version of that package. In this manner the limited space is conserved (i.e. if a package change was a simple registry entry - no need to replace the 5mb of .dll and .exe in that package, just alter the .rgu with the new data. These packages are also referred to as "Delta" packages. The concept is similar to the unix implementation of Diff/Patch. The file extension is .cab.pku
Super contains a collection of update and/or canonical packages. This is very useful when you are attempting to bring in a new package that has dependencies on other packages - rather than reboot into ULDR for each individual package in the proper dependency order, they can all be introduced at once. Every package contained inside a super package is validated, and if one fails, the remaining valid updates may still be applied, as dependencies allow. A super package is simply an un-compressed .cab containing other packages, renamed to .cab.pks
The package layout itself is quite basic, it consists of a .dsm which contains all versioning info, association info, and dependency info. It also contains a list of all modules and files inside the package, and a certificate store of all approved certificates that will be allowed to update that package. Alongside the .dsm is an optional .rgu, which defines the registry settings associated with that package. Also optional is a .provxml file, which can be: mxip_[packagename]_[version].provxml, mxipcold_[packagename]_[version].provxml, or mxipupdate_[packagename]_[version].provxml. mxip and mxipcold are effectively treated the same, executed only on a cold boot. mxipupdate_ provxml's will be executed any time that package is updated, in addition to a cold boot - so if you are adding new .cab.pkgs and wish the .provxml to be executed immediately, it would need to be mxipupdate. This may not be desirable in some cases, such as when the provxml might override a user preference - in that case you would only want it to run on a cold boot, in order to avoid "strange" behavior on the user's side of things.
There is a "shadow order" defined in the .dsm as well - this controls what "priority" .rgu's are compiled together into the device registry hive - a package that shadows another package will override any .rgu entries that shadowed package may contain. This is important to consider when utilizing .cab.pkgs in order to obtain your desired end registry. This shadow order also applies to provxmls inside the package - a package that shadows another package will override its provxml settings as well.
The user registry hive is always top-most in the shadow order (except in the case of an mxipupdate_ provxml) - so any changes to .rgu registry settings will not override a user-changed registry setting. (example: You had foobar set to 5 in your initial deployment. At some point after flashing to his/her device, the user modified the registry, changing the value of foobar to 6. Your new .cab.pkg contains an .rgu changing foobar to 7 - on device, foobar will remain set to 6, as the user registry is higher in the shadow order than the .rgu) - in the case of an mxipupdate_ provxml these will override user settings.
So theoretically if we get this working we can apply updates to ANY portion of a rom via the .cab.pkg system. To XIP,SYS,or OEM without flashing a new rom. Essentially with this system working we would never need to flash again unless a major corruption occured?
Ive always been confused as to why autoupdate was included in roms still. I guess this sheds some light on it. I know that several individuals have toyed with OTA updates in the past. This could make that and a whole lot more a reality.
It seems to me silly that we aren't exploiting the MS autoupdate feature already...
I have no idea how to get it to work, but I'd love to have it working!
Yes, the .cab.pkg is the key to this whole thing, I already know how to redirect the Windows Mobile Auto Update client to look at another server, and i've studied the connection, it's a simple HTTPS connection, WinMo sends the server a manifest of all the .dsm's contained within your ROM, with version info, then the server checks against it's internal list of packages, if it finds an update, it pushes a URL to the device, which then triggers a download (it requests you to plug in the activesync cable if you've not checked the box to 'use my data connection for updates') - once the .cab.pkg is downloaded, it's checked against the signatures on the system, once verified the system reboots into the ULDR, and the update is applied.
I've attached a NetCF2 package to my first post, I can't get it to deploy on my ROM (fails during validation step) but it contains the modules in MNGE format, if we can decipher that format there's a whole bunch of goodies that will become available...
Also these packages can even be used to update the radio rom, it seems. So essentially everything but the Bootloader/ULDR can be updated with .cab.pkgs. It even looks like we can resize existing packages (i.e. remove files or modules from the ROM entirely) - this is something we can't do at all right now without a flash!
Da_G said:
Yes, the .cab.pkg is the key to this whole thing, I already know how to redirect the Windows Mobile Auto Update client to look at another server, and i've studied the connection, it's a simple HTTPS connection, WinMo sends the server a manifest of all the .dsm's contained within your ROM, with version info, then the server checks against it's internal list of packages, if it finds an update, it pushes a URL to the device, which then triggers a download (it requests you to plug in the activesync cable if you've not checked the box to 'use my data connection for updates') - once the .cab.pkg is downloaded, it's checked against the signatures on the system, once verified the system reboots into the ULDR, and the update is applied.
I've attached a NetCF2 package to my first post, I can't get it to deploy on my ROM (fails during validation step) but it contains the modules in MNGE format, if we can decipher that format there's a whole bunch of goodies that will become available...
Click to expand...
Click to collapse
So in theory, there could be a central place for SYS/XIP packages, where as and when new XIP/SYS updates come out, they can be uploaded and pushed to every device?
Have you worked out how to create the cab.pkg files, or is the one you've attached one taken from platform builder?
Just a thought:
Could the MNGE headered files not be replaced by files from a converted module, thus getting around the problem of what the hell the MNGE format does? Sure, we lose the ability to have modules instead of files, but it does bring more immediate benefits to your findings...
EDIT:
The MNGE headered files are smaller than the MZ equivalents... Are they simply a compressed version?
Yep, not pushed though as that needs to be triggered via an OMA-DM SMS message, and it's not practical for someone to maintain a database of all our numbers for such a purpose.. but easily though settings - autoupdate
I am able to extract files from .cab.pkg with winrar and 7zip, not able to create them just yet.. working on that. This one came from a blue birdy.
The MNGE headered files could indeed be replaced by a converted module, but in this case, there's a different reason for needing to convert from MNGE -> MZ,
It appears to me as though the file size difference had to do with the PE executable headers that are missing..
Da_G said:
Yep, not pushed though as that needs to be triggered via an OMA-DM SMS message, and it's not practical for someone to maintain a database of all our numbers for such a purpose.. but easily though settings - autoupdate
I am able to extract files from .cab.pkg with winrar and 7zip, not able to create them just yet.. working on that. This one came from a blue birdy.
The MNGE headered files could indeed be replaced by a converted module, but in this case, there's a different reason for needing to convert from MNGE -> MZ,
It appears to me as though the file size difference had to do with the PE executable headers that are missing..
Click to expand...
Click to collapse
Oh right. It's not hard to just check for updates every so often.
I just ran Cab2OEM on the cab.pkg files, and it extracts fine. So cab.pkg files are just cab files in terms of compression.
Is that because there are more up to date MNGE file versions than the MZ equivalents?
Is it just a case of replacing the file headers? *opens up hex edit*
Yep. the compression is your typical cab compression. That's why winrar and 7zip can open 'em and extract, but they don't support adding (i imagine cabarc would...
Yes, there are more up to date MNGE file versions than the MZ equivalents.
Unfortunately it doesn't look quite as simple as a simple hex copypasta, not terribly much more difficult though.
Da_G said:
Yep. the compression is your typical cab compression. That's why winrar and 7zip can open 'em and extract, but they don't support adding (i imagine cabarc would...
Yes, there are more up to date MNGE file versions than the MZ equivalents.
Unfortunately it doesn't look quite as simple as a simple hex copypasta, not terribly much more difficult though.
Click to expand...
Click to collapse
Where are you getting your MNGE files from? Or does your blue birdy wish to remain anonymous?
EDIT:
Looking at the hex, apart from the file header, the main difference seems to be that the whitespace has been removed in the MNGE version...
l3v5y said:
Where are you getting your MNGE files from? Or does your blue birdy wish to remain anonymous?
Click to expand...
Click to collapse
Do you know what a "hint" is ? I'd say quit asking... If he wanted to say who the birdy was, he would. Thank you!
Da_G said:
Yep. the compression is your typical cab compression. That's why winrar and 7zip can open 'em and extract, but they don't support adding (i imagine cabarc would...
Yes, there are more up to date MNGE file versions than the MZ equivalents.
Unfortunately it doesn't look quite as simple as a simple hex copypasta, not terribly much more difficult though.
Click to expand...
Click to collapse
put cabarc.exe intoa folder, then create a new subfolder called "package", put inside all files you need for package (dsm and rgu also!)
open in cabarc.exe root folder a dos prompt and write:
cabarc.exe N new_pack.cab.
pkg package\*.*
some seconds and you'll have the .pkg file ready, but nothing I know on how to install by the rom!
Thanks for the input ervius!
Installing into the ROM is simple, .cab.pkg is treated similar to a .cab by Windows Mobile, simply copying to device and clicking on it in file explorer allows you to install - device will authenticate signature, then do some further checking (i think checking on current packages in device by .dsm) - then once validated reboot into ULDR to apply update.
ervius said:
put cabarc.exe intoa folder, then create a new subfolder called "package", put inside all files you need for package (dsm and rgu also!)
open in cabarc.exe root folder a dos prompt and write:
cabarc.exe N new_pack.cab.
pkg package\*.*
some seconds and you'll have the .pkg file ready, but nothing I know on how to install by the rom!
Click to expand...
Click to collapse
for posted netcf example, the optimum is:
cabarc.exe - 20 N new_pack.cab.
pkg package\*.*
so, header (-s 20 reserve space for sign!), is same size, but how and with , sign it, I don't know!
Da_G said:
Thanks for the input ervius!
Installing into the ROM is simple, .cab.pkg is treated similar to a .cab by Windows Mobile, simply copying to device and clicking on it in file explorer allows you to install - device will authenticate signature, then do some further checking (i think checking on current packages in device by .dsm) - then once validated reboot into ULDR to apply update.
Click to expand...
Click to collapse
shure, but now maybe we have to fight against right sign code!?!?
bye!
Yes, I think the ROM will need be cooked with additional certs, in \SYS\Metadata\DefaultCerts.dat - these appear to be the certs that are being checked against. So we can replace with SDKCerts, sign .cab.pkgs with that, should be good!
Da_G said:
Yes, I think the ROM will need be cooked with additional certs, in \SYS\Metadata\DefaultCerts.dat - these appear to be the certs that are being checked against. So we can replace with SDKCerts, sign .cab.pkgs with that, should be good!
Click to expand...
Click to collapse
ok, go to work then, I ', yet thiniing about oldstyle buildos with this all new features of visualkitchen without platformrebuilder if someone wants use oldstyle (maybe I'm at my goal!)
ervius said:
ok, go to work then, I ', yet thiniing about oldstyle buildos with this all new features of visualkitchen without platformrebuilder if someone wants use oldstyle (maybe I'm at my goal!)
Click to expand...
Click to collapse
Can we not look at removing the signing check the same way cmonex did for the kernel? Or is that the same signing check?
Just so I am getting this right? I could cook a ROM with a custom DaveShaw https update server IP and then provide automatic updates to my ROM, bug fixes, new build release, normal CABs, etc. all using Windows Update from my website??
That would be damn useful, no more re-flashes
Dave
probably to create MNGE from module folder we just need
copy /b imageinfo.bin + S000 + S001 + ... module.dll
and add MNGE header to the beginning of the file.
but maybe i am wrong and this will not work in all cases.
at least when i converted in this way dll module from 21725 to MNGE and compared it to the same file which was originally in MNGE format, there were 0 differences.
Okay the zip thing didn't work..
How about:
Create C# command line executable.
Reference following dlls:
Microsoft.Smartdevice.Connectivity.dll
( C:\Program Files\Common Files\microsoft shared\Phone Tools\CoreCon\10.0\Bin\Microsoft.Smartdevice.Connectivity.dll )
Microsoft.VisualStudio.DeviceConnectivity.Interop.10.0.dll
( C:\Windows\Microsoft.NET\assembly\GAC_MSIL\Microsoft.VisualStudio.DeviceConnectivity.Interop.10.0\v4.0_10.0.0.0__b03f5f7f11d50a3a\Microsoft.VisualStudio.DeviceConnectivity.Interop.10.0.dll )
and add following code:
Code:
using System.IO;
using System.Linq;
using System.Reflection;
using Microsoft.SmartDevice.Connectivity;
using Microsoft.VisualStudio.DeviceConnectivity.Interop;
namespace Conn
{
class Program
{
static void Main(string[] args)
{
Platform plat = new DatastoreManager(1033).GetPlatforms().Single(p => p.Name == "Windows Phone 7");
uint proc;
uint handle;
bool useEmulator = true;
Device dev = null;
if (useEmulator)
dev = plat.GetDevices().Single(d => d.Name == "Windows Phone 7 Emulator");
else
dev = plat.GetDevices().Single(d => d.Name == "Windows Phone 7 Device");
dev.Connect();
ConManServer con = dev.GetType().GetField("mConmanServer", BindingFlags.NonPublic | BindingFlags.Instance).GetValue(dev) as ConManServer;
con.LaunchProcess("", "", (uint)FileMode.Open, out proc, out handle);
}
}
}
the launchprocess is the interesting part here. Apparently you can launch executables with parameters.
and some executables to start:
"\Windows\Calc7.exe" (yay)
"\Windows\CertInstaller.exe" install custom cert?
("Content Type"="application/x-x509-ca-cert")
"\Windows\AppPreInstaller.exe" - does nothing?
"\Windows\devicereg.exe"
"\Windows\FileBrowser.exe" - not found?
"\Windows\NativeInstallerHost.exe" - Cannot run \Windows\NativeInstallerHost.exe in Win32 mode.
and some exes cannot be started with following error:
"This program is blocked by group policy. For more information, contact your system administrator."
"\Windows\OBEXParser.exe" - Operation failed. Failed to Save. Received data may be incomplete. - parse obex data here?
"\Windows\PolicyLoader.exe" - does nothing?
"\Windows\Pxl.exe" - tries to start something
"\Windows\CFPreloadClient.exe" and "\Windows\CFLauncher.exe" - worth checking out?
Also worth mentioning:
I added executable to windows phone project and saved it to the isolated storage, then used launchprocess to start it but only got following error:
"An attempt was made to load a program with an incorrect format."
Did you compile it as a x86 exe or with the wm sdk? But excellent job it looks like ConManServer can copy files to and from the phone...
Also \\windows\\iexplore.exe
It's a normal x86 console application.
I tried the file copying too but always got access denied exception.
Another thing worth trying is cooking up compact framework 3.7 dll with all the normal stuff you find in windows phone 7 dll and then making a xap file with all needed files (like mscorlib.dll) and deploying it to the phone.
- phone says invalid license when trying to execute it.
Not the console app the app you tried to copy to the phone is it a X86 exe or ARM?
Does it through that message with a custom app or with a XAP with cooked .net modules? I doubt you can put .net modules with the XAP and expect it to load properly...where is the exact path for isolated storage? We should be able to copy anything there.
crozzbreed23 said:
where is the exact path for isolated storage? We should be able to copy anything there.
Click to expand...
Click to collapse
Your application is installed (essentially by decompressing it) in \Applications\Install\{GUID}\Install\ where {GUID} is the ProductID found in your WMAppMinfest.xml.
I tried running a native EXE I copied to the Emulator inside a XAP by running the LaunchProcess(@"\Applications\Install\{GUID}\Install\application.exe"...) and it finds the file, but throws an Error saying I don't have permissions (I'll get the exact error tomorrow). It seems it'll only run files from certain locations, such as in the Windows Folder, but I'm yet to find a way to copy a file into there.
Is it the same function that XNA uses to deploy a XAP to the emulator? I doubt it only runs apps from the windows folder, sense Office is a native application which doesn't reside in the iwndows folder.
hounsell said:
I tried running a native EXE I copied to the Emulator inside a XAP by running the LaunchProcess(@"\Applications\Install\{GUID}\Install\application.exe"...) and it finds the file, but throws an Error saying I don't have permissions (I'll get the exact error tomorrow). It seems it'll only run files from certain locations, such as in the Windows Folder, but I'm yet to find a way to copy a file into there.
Click to expand...
Click to collapse
Did you ever find a way to get this to work, hounsell? Where did you get the application.exe in WP7 native code?
crozzbreed23 said:
Is it the same function that XNA uses to deploy a XAP to the emulator? I doubt it only runs apps from the windows folder, sense Office is a native application which doesn't reside in the iwndows folder.
Click to expand...
Click to collapse
The system doesn't install your app as an exe, it installs it as a C# DLL (managed code). Thus it doesn't need permission to execute files in that directory, it just needs permission to load a DLL from that directory.
That said, the problem could be the DLL hounsell used wasn't signed.....
athompson said:
Did you ever find a way to get this to work, hounsell? Where did you get the application.exe in WP7 native code?
The system doesn't install your app as an exe, it installs it as a C# DLL (managed code). Thus it doesn't need permission to execute files in that directory, it just needs permission to load a DLL from that directory.
That said, the problem could be the DLL hounsell used wasn't signed.....
Click to expand...
Click to collapse
I haven't got it to work. I think I might have got the EXE from one of those pre-release HTC ROMs. Probably wouldn't have run, but it was throwing errors anyway.
Exactly, And there's a "LaunchApplication" in the same Interface as LaunchProcess, where you just pass the GUID anyway.
Got an interesting error today: Tried running PacmanInstaller.exe (Which appears to be the XAP installer, where Pacman is "Package Manger", rather than an amusing game), and it thew a COMException saying that the application couldn't be run in Win32 mode. (COMException because this trick uses a COM DLL on the desktop, rather than any COM on the mobile)
Code:
Cannot run \Windows\PacmanInstaller.exe in Win32 mode
Was most surprised. Not sure what that's all about. Still trying to get something happening with that "MediaCenterFinal.xap" on the Omnia 7 ROM.
I've been working on a set of scripts that will install Debian on a running XDAndroid. There are a lot of sites that offer similar pre-packaged collection, but they always seem to include too much (aka 700M downloads) or have files from various places.
I have so far gotten the initial setup up and running pretty consistently. This is not meant to replace Rhodbuntu, but act as a co-existing subsystem along with Android using what is known as chroot. As Android uses the kernel derived from Linux, Debian's GNU subsystem can interface pretty well with our kernel.
One of the major stumbling blocks for the msm72k chips is that it is based on the older ARM1136 (ARM6) cpu, and the current armel distribution targets Cortex (ARM7) platform, which is incompatible and will segfault when run on our msm's. To my knowledge, Debian 5.0 (lenny) or Ubuntu 9.04 is the last supported binary-compatible distribution widely available. Debian is semi-supported with patches for the near future, but the same cannot be said for Ubuntu. While it is possible to cross-compile a newer version to run on ARM6, that is beyond the scope and man-effort for this project.
Currently, the files required to get a bare-bones Debian system is what I wrote in the past 24hr, plus either a debian root tarball (which runs about 90M on mine) or a Debian cdebootstrap-static that can be downloaded from your nearest Debian mirror. Using cdebootstrap means a consistent root image can be made from official Debian sources, as well probable support for Ubuntu or other Debian-based distribution having an armel static cdebootstrap (cdeb). In fact, since I have no desire to upload 90M over my phone, using cdeb is your only way to get your system using my script for now. Please read top part of debian.sh inside the zip file to understand how to use the cdeb support.
Using it is pretty straightforward. Unzip the contents to /sdcard, open terminal, su and cd, and sh debian.sh (along with what's necessary for cdeb). Once you have run debian.sh and have a working GNU subsystem, typing "linux shell" is enough to start a chroot'ed bash shell. I suggest starting off with "apt-get update" and start installing some other packages.
The script should be generic enough to work on any Android system that does not have a brain-dead busybox residing in /sbin (aka Epic). The only "odd" requirement is that lenny cdeb requires quite a few files in "/usr". I solved that by symlinking it to the toolset mount directory. You will also need at least 600M free on your SD card to create a looped fs image. Don't ask about VNC support yet, I need to go through installing it before that is supported.
As for other FS support that is up to the xdandroid kernel developers. They would need to add support for fs other than ext2 before I can even add support for that. Feel free to suggest ideas to improve this.
http://db.tt/pFkD9ou
Update for 0.20:
Rewrote the linux scripts.
No longer allow linux to start without su, due to restrictions by superuser.apk.
Added check command, will e2fsck the image if e2fsck is available.
Uses mount -t auto instead of -t ext2.
Update for 0.15:
Fixed typo for cp tool/data that caused copying of directory instead of content.
After running cdebootstrap continue with the rest of script instead of exiting.
Use mountpoint instead of relying on -e hack.
Add restart to list of commands.
Make sure stuff is unmounted after running script and make "stop" a bit more intelligent.
Change cdebootstrap default to squeeze.
Create /usr/conf/fs* if it doesn't exist, should get rid of error messages.
-- Starfox
Not sure where you got your info about 6.0 segfaulting - Squeeze is going pretty strong on my rhod 400.
Two-step debootstrap ftw.
Well, I've had supposed ARM6 binaries segfault or illegal instruction on me. If squeeze works, great. Perhaps you'd be willing to upload a root tarball for those who don't want to go through with doing debootstrap.
I was told by more than one person that lenny was the latest that properly supported ARM6 armel. My script is easy enough to modify to support different Debian distros.
-- Starfox
I just wanted to give you a heads-up in case you hadn't tried squeeze - it works just fine. I haven't put it through its paces yet, but I did get a vncserver up and going last night just to satisfy my curiosity. Other than some resolution issues, this too was fairly painless.
I think it'll take me more effort to upload a tarball on my connection than for a non-noob user to debootstrap 6.0 on their phone. As far as the beginner, I am not sure that a tarball would be doing them any favors, there's something to be said about head-butting against the installation process.
Good job with the script by the way.
Nice script. Worked on second try, some corrupt packages, not the scripts fault. Its a bit slow with connectbot but using a local dropbear helps alot.
Thanks
Updated to 0.15. Script shouldn't encounter mount-point issues and should create /usr/conf automagically. Updated the default to squeeze, I still used lenny-backport cdeboot-static to test it out.
-- Starfox
Updated to 0.20. Mostly internal changes, but now supports other filesystem types. Also added linux check to allow e2fsck to make sure nothing is corrupted.
-- Starfox
can someone help me, i get an error that cant execute /bin/bash no such file or directory, i installed busybox, what can i do?
Not sure if I have anything worth while, but ASUS left a "Tools" folder on my desktop...attached a screenshot of what it included.
phxtravis said:
Not sure if I have anything worth while, but ASUS left a "Tools" folder on my desktop...attached a screenshot of what it included.
Click to expand...
Click to collapse
Can you please zip that and upload them?
Yeah please zip it up and upload them so we can see what it's doing.
Yes, ZIP them please - the auditmode files are for sysprep audit mode, securebootdebug - are probably from microsoft HCK and add debug key to key storage (so you can run testsigned apps), FWVar - probably allows editing UEFI firmware variables (I've already made the same tool myself), everything is interesting of cause.
Here you go
Thank you for the tools.
SetAuditMode/ClearAuditMode - clears the sysprep audit mode (useless)
setup.cmd, SecureBootDebug* - installs "secure boot debug" policy. I.e. allows running of testsigned (or unsigned) apps. More info: http://msdn.microsoft.com/en-us/library/windows/hardware/hh998740.aspx
Securebootdebug needs the signed policy file. It is probably left on your device too, as "tools" directory is not erased. To obtain it - run CMD or powershell as administrator, then type there: "mountvol S: /s" without quotes. This would assign S: to your BCD partition. There should be SecureBootDebugPolicy.p7b file. Please share it too
To dismount disk S: after copying that file - type "mountvol s: /d"
reset.cmd - this file would delete the tools directory and all other files reverting things back.
hsc.vbs, pdq.vbs - tiny support scripts for reset.cmd
FWVar.exe - writes firmware variables. Not UEFI vars that are documented, but it plays with some other asus-specific vars like sensors calibration and platform IDs. Would be interesting to decompile it
mamaich said:
Thank you for the tools.
SetAuditMode/ClearAuditMode - clears the sysprep audit mode (useless)
setup.cmd, SecureBootDebug* - installs "secure boot debug" policy. I.e. allows running of testsigned (or unsigned) apps. More info: http://msdn.microsoft.com/en-us/library/windows/hardware/hh998740.aspx
Securebootdebug needs the signed policy file. It is probably left on your device too, as "tools" directory is not erased. To obtain it - run CMD or powershell as administrator, then type there: "mountvol S: /s" without quotes. This would assign S: to your BCD partition. There should be SecureBootDebugPolicy.p7b file. Please share it too
To dismount disk S: after copying that file - type "mountvol s: /d"
reset.cmd - this file would delete the tools directory and all other files reverting things back.
hsc.vbs, pdq.vbs - tiny support scripts for reset.cmd
FWVar.exe - writes firmware variables. Not UEFI vars that are documented, but it plays with some other asus-specific vars like sensors calibration and platform IDs. Would be interesting to decompile it
Click to expand...
Click to collapse
I was unsuccessful at finding the file, I wiped the tablet yesterday as it was running like crap(freezing, and wouldn't download updates), not sure if that wiped what you are looking for.
OK, I see what that setup.cmd file is doing. It generates an unsigned SecureBootDebug.p7b file authorizing full debug unlocking for the particular serial number of your device - the -u switch to createsecurebootpolicy.exe locks it to your device. It then sends that file to a server aptly named "\\secureboot" on ASUS's internal network and waits for a reply. Sometime later, a signed version of that file appears on that server's share, and the Vivo RT copies it to the EFI system partition to use with SecureBootDebug.efi.
After the service center does what it needs to do, they run reset.cmd, which deletes the Secure Boot policy from EFI NVRAM at next reboot and deletes SecureBootDebugPolicy.p7b from the EFI system partition.
phxtravis said:
I was unsuccessful at finding the file, I wiped the tablet yesterday as it was running like crap(freezing, and wouldn't download updates), not sure if that wiped what you are looking for.
Click to expand...
Click to collapse
If you had not done that, we could have made an image of your EFI system partition and recovered the deleted SecureBootDebugPolicy.p7b file, which would have permanently jailbroken your Vivo RT forever. Sadly, it was locked to your device. What method did you use to wipe it? Did you ask it to repartition your system?
Myriachan said:
OK, I see what that setup.cmd file is doing. It generates an unsigned SecureBootDebug.p7b file authorizing full debug unlocking for the particular serial number of your device - the -u switch to createsecurebootpolicy.exe locks it to your device. It then sends that file to a server aptly named "\\secureboot" on ASUS's internal network and waits for a reply. Sometime later, a signed version of that file appears on that server's share, and the Vivo RT copies it to the EFI system partition to use with SecureBootDebug.efi.
After the service center does what it needs to do, they run reset.cmd, which deletes the Secure Boot policy from EFI NVRAM at next reboot and deletes SecureBootDebugPolicy.p7b from the EFI system partition.
If you had not done that, we could have made an image of your EFI system partition and recovered the deleted SecureBootDebugPolicy.p7b file, which would have permanently jailbroken your Vivo RT forever. Sadly, it was locked to your device. What method did you use to wipe it? Did you ask it to repartition your system?
Click to expand...
Click to collapse
I did the "remove everything and reinstall windows" option in settings.
phxtravis said:
I did the "remove everything and reinstall windows" option in settings.
Click to expand...
Click to collapse
It *might* still be there then if we take an image of your EFI System Partition and search it manually with a hex editor. There are definitely no guarantees, though. Also, this would likely reveal your device's serial number to whoever you give the image to. It probably would *not* have any other information, though, like personal documents or your Windows RT CD key--those're on the main partition.
If this file were found, I think it would permanently jailbreak your device - Windows RT would let you run whatever unsigned code.
The SecureBootDebug.efi tool needed to use this .p7b file is also part of the publicly-available final 8.1 Windows Driver Kit. The one in your .zip file looks like the 8.0 version.
Myriachan said:
It *might* still be there then if we take an image of your EFI System Partition and search it manually with a hex editor. There are definitely no guarantees, though. Also, this would likely reveal your device's serial number to whoever you give the image to. It probably would *not* have any other information, though, like personal documents or your Windows RT CD key--those're on the main partition.
If this file were found, I think it would permanently jailbreak your device - Windows RT would let you run whatever unsigned code.
The SecureBootDebug.efi tool needed to use this .p7b file is also part of the publicly-available final 8.1 Windows Driver Kit. The one in your .zip file looks like the 8.0 version.
Click to expand...
Click to collapse
Not sure if I am sold on jailbreaking, what's the advantages other than being able to run "hacked" exe's? Aslo, what would you need me to do?
The EXEs are not "hacked" in any proper sense of the word, just recompiled. Sometimes some changes are needed, but they're usually basic. It lets you run (normal) Windows programs. .NET programs run as-is, native ones need to be ported (usually a pretty simple recompile, if they built under Visual Studio in the first place, but we need the source code), and it unlocks full Powershell scripting power. Programs written in other languages, like Python and Java, can be run using ported runtimes. In fact, it's even possible to run some x86 programs (unmodified Win32 native EXEs) via a dynamic recompilation layer written by @mamaich here on XDA; I can play some old games and run some nice old programs that I like that way.
phxtravis said:
Not sure if I am sold on jailbreaking, what's the advantages other than being able to run "hacked" exe's? Aslo, what would you need me to do?
Click to expand...
Click to collapse
Hacked EXEs?
No hacking. We legally take the source code for a program and compile it for win32 in THUMB_2 instead of win32 on x86. You can then run these desktop applications on your lovely ARM tablet as you could on a normal windows PC. That is an absolutely huge advantage which should have been a default option.
Quake alone makes it worth it.
I didn't mean to use "hacked" in a negative context, merely meant it as a general term of modifying original EXEs to run on ARM, I haven't been following the RT jailbreaking at all.
Can't modify an existing EXE. Totally incompatible (unless its a .NET application in which case no mods needed). Need to rebuild the EXE and any supporting libraries from source.
phxtravis said:
Here you go:
https://docs.google.com/file/d/0BzebTu1H3-aIbXlTV09BMjZsLVk/edit?usp=sharing
Click to expand...
Click to collapse
This requires approval. Does anyone still have a copy?
jordanmills said:
This requires approval. Does anyone still have a copy?
Click to expand...
Click to collapse
It doesn't require approval
Curiously, there is a Secure Boot debug policy creator ,signed by Microsoft for ARM but sadly not generating signed policies...
It may be used for jailbreak as the other tools are unsigned(most of them) if there is a bug allowing to load a unsigned policy somewhere(there should be one)
Will try downloading the HCK to see if there is something useful there
black_blob said:
It doesn't require approval
Click to expand...
Click to collapse
Hmm, it doesn't now. But there doesn't seem to be any way to download the whole thing. It only shows individual files.
jordanmills said:
Hmm, it doesn't now. But there doesn't seem to be any way to download the whole thing. It only shows individual files.
Click to expand...
Click to collapse
There is the download button at the top