Hey Guys,
Below is a list of the things that my HTC 8x does when it checks for Windows Updates. I am waiting for Microsoft's server to decide to give me a new firmware, so I decided to sniff out the TCP stream. Of note, I found the following:
1. Phone contacts http://fe1.update.microsoft.com/WP8/MicrosoftUpdate/Selfupdate/5_UssDetection.dll
The Phone goes out and fetches this dll onto the system. It references the following certificates (which you can download):
root cert http://www.microsoft.com/pki/certs/MicRooCerAut_2010-06-23.crt
production cert http://www.microsoft.com/pkiops/certs/Microsoft Windows Phone Production PCA 2012.crt
time stamp PCA? http://www.microsoft.com/pki/certs/MicTimStaPCA_2010-07-01.crt
2. After that, it goes and fetches the following cab file: http://sds.download.windowsupdate.com/wp8/MicrosoftUpdate/Redir/duredir.cab. This cab file contains a single xml file called wuredir.xml. It has two values: the clientServerURL and the ReportingServer URL.
3. After this, some https traffic occurs to the clientserver URL. I am guessing this is it checking for updates.
4. Then it posts to http://statsfe1.update.microsoft.com/ReportingWebService/ReportingWebService.asmx with a SOAP action of http://www.microsoft.com/SoftwareDistribution/ReportEventBatch with a whole bunch of info on the phone.
The User Agent being used for all of these communications is as follows: Windows-Mobile-Device-Update-Agent
If this dll it is fetching is unsigned, I wonder if we could have some fun....I am also wondering what happens if we develop and sign an xap with Microsoft's certificate if it will allow us to do more things within the OS.
Sign with Microsoft's private key? If you have access this then your about to become very popular
Sent from my Arc using xda app-developers app
Hmm, the 5_UssDetection seems to be a normal PE32 .dll. Not .NET compiled. I don't see any COM Imports/Exports for it so finding this out may be a little difficult. I haven't used any tools like IDA though, just a normal PE explorer program.
This is good information though. I wonder if GoodDayToDie may have some further input?
Nice find. I've been monitoring phone traffic myself but hadn't caught this exchange yet.
The fact that it checks external cert files is very interesting. Typically, I would expect this to be using "certificate pinning" where the public key of the signing cert is stored internally in the software, and no other signature is trusted (even if it chains to a CA that is installed on the phone and would normally be trusted). MS does use pinning in a number of places; for example, this is how the original ChevronWP7 Unlocker was broken, and is used when adding a Microsoft account to the phone or when that account is updating. However, I figure there's an excellent chance that pinning is *not* being used in at least one place where it really should be (this can be tested using tools like Fiddler or Burp, which have the ability to intercept SSL traffic using a cert that chains to a cert installed in the phone's trusted authorities store).
If pinning isn't being used, it may be possible to modify/create our own detection DLL, then create our own CA cert, install the public key on the phone, use the private key to sign an intermediate cert (that we also create, and have the private key for), and use the intermediate cert to sign our customized DLL. If necessary, we could even intercept the lookups that the phone performs and control what is returned (assuming the lookups are actually over HTTP, or at least unpinned HTTPS).
The probability that the file is unsigned isn't even worth considering; it's quite likely that Microsoft is using a mandatory signing level on WP8 for all executable code. Unfortunately, if they are doing that, it's also likely that it's set to require a cert which chains to the MS root cert (this is how Windows RT is by default), which is effectively a form of system-wide cert pinning. However, if you want to check, signtool in the Visual Studio Command Prompt can dump authenticode certs on a file.
Reverse engineering the detection DLL is quite possibly worthwhile even if we can't modify it, too; it'll provide insight into the update process, which is one of the best places to mess with a system. It runs with high privileges and explicitly is capable of modifying system code.
That sounds quite enticing! I wish I knew x86/ARM assembly :/. I'll see what the sign tool outputs in VS
It feels great to see that you're here GoodDayToDie You helped out a lot on WinPho 7 for HD2 (a device I'll soon repurchase).
Hopefully there'll be some advancements on the "jailbreaking" of Windows Phone 8
I would be surprised if WP8 wasn't using the same code signing requirements as Windows RT.
As far as hijacking that dll goes, unless we can find an immediate privileged code execution exploit in it all it's most likely to do would be to give us write abilities to the FS, and there's a huge 'if' attached to that. That would be a big step if possible, though.
Something that would be interesting to check is if an EXE compiled for Windows RT (cdb, for example) would be capable of running on WP8. If MS used the same signing certificates it may be possible to put enough of Windows RT's dependencies on WP8 to allow it to run a simple console application. Obviously we wouldn't have any console windows or the sort, but it should be possible to capture output if it worked.
We have a decrypted OS dump around somewhere, right? It should be simple to check if they use the same signatures.
Good call on checking the signatures. I'd also like to take a look at reverse engineering the OEM apps again; even if they don't give us a device-agnostic hack directly, they may reveal interesting things about the WP8 app model internals and also may give device-specific breaks which can be used to gain the knowledge we need for crafting device-agnostic ones.
Slightly off-topic:
The zipview exploit still (sort of) works. Hard to believe, but I bet MS just recompiled the program for NT's Win32 and didn't bother with it beyond that. Decent chance that the same holds for the XAP installer, though I haven't tried yet. However, A) the filesystem layout has changed, so write-only access is even more poking blind than it used to be, and B) zipview may be running with lower privileges than it used to. On a simple test ZIP (attached for your testing pleasure), I can open files and create directories up to three levels above the zip root, but no further. Trying to open a file in a folder directly higher than that gives a "cannot extract to a read-only location" error, and trying to open a file inside a subfolder above the third level up gives a generic error message (probably due to failing to create the folder).
Also, I got wired tethering working on my Ativ S today. I'll create a post about doing that if nobody else has done so yet (it was almost identical to the WP7 Samsung devices, the only hard part being finding the right 64-bit drivers). WindowBreak didn't work, though (the folder that it extracts at is above the permissions cutoff, which makes me suspect zipview can't write to the drive root) and I don't think the subcomponent of the Diagnostics app works the same, either (a lot of the diagnostics codes have changed; we should learn the new ones).I don't even know if WP8 understands provxml (it's historically a CE feature, not an NT one), although I found references in the Diag app to provxml being "ready".
Here's what I came up with for a file list from some rudimentary (and possibly inaccurate) parsing of a .ffu: http://pastebin.com/hX6qJQeA
Got that from RM820_1232.2109.1242.1001_RETAIL_nam_usa_100_01_95122.ffu.
Great, thanks for that! Looks like provxml is definitely still here, and that's probably good. I'll bet they changed some things though, to make it more NT-ish (support for proper ACLs, for example). I should review those included provxml files for a look at how the phone is currently configured. Lots of potentially interesting .REG files too. I'll have to try some more things here!
No problem. All I did was pull out all text inside '<DevicePath>' tags inside one of the FFUs for the AT&T Lumia 920.
From looking at the FFU it appears to be a collection of CAB archives (or packages) encapsulated in some proprietary format. WP7.x tools don't work on them, sadly.
Edit: I'm blind sometimes, there is a tool to mount them and it does work.
More edit: Different signatures.
More more edit: Windows RT refuses to run the WP8 binaries without a jailbreak.
Hmm... but with jailbreak, do the binaries run? I mean, they're NT Win32-based PE binaries compiled for THUMB2 architecture, so I'm sure they can at least be executed, but do they actually run or do this simply error out or crash immediately?
It would be interesting to compare the certificate chains of RT and WP8 binaries. As far as I know, the default restriction level on RT should allow anything that chains to the Microsoft root Authenticode cert to run, which means either that we misunderstand that restriction or that the WP8 signatures chain to a completely different cert. I'm guessing it's the latter, but that does surprise me. I could understand if RT used the "Windows" signing level and WP8 binaries wouldn't work; despite having Windows in the name, using the Win32 API, and running on the NT kernel, the Windows Phone team is separate from the Windows team and quite likely has its own signing keys. I would think that an OS which accepts Office and DevDiv/Tools signatures (unless Office and the debuggers were re-signed by the Windows team? I haven't checked) would accept Windows Phone signatures too.
GoodDayToDie said:
Hmm... but with jailbreak, do the binaries run? I mean, they're NT Win32-based PE binaries compiled for THUMB2 architecture, so I'm sure they can at least be executed, but do they actually run or do this simply error out or crash immediately?
It would be interesting to compare the certificate chains of RT and WP8 binaries. As far as I know, the default restriction level on RT should allow anything that chains to the Microsoft root Authenticode cert to run, which means either that we misunderstand that restriction or that the WP8 signatures chain to a completely different cert. I'm guessing it's the latter, but that does surprise me. I could understand if RT used the "Windows" signing level and WP8 binaries wouldn't work; despite having Windows in the name, using the Win32 API, and running on the NT kernel, the Windows Phone team is separate from the Windows team and quite likely has its own signing keys. I would think that an OS which accepts Office and DevDiv/Tools signatures (unless Office and the debuggers were re-signed by the Windows team? I haven't checked) would accept Windows Phone signatures too.
Click to expand...
Click to collapse
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
As far as running, some have given me console output, but I haven't gotten a single GUI one to start. I've been considering on looking to see how complex the UI is to see if I can write some sort of WP8->Win32 translation layer. There are just so few WP8 xaps floating around that it's not really worth looking into, though.
I don't expect the GUI to work; the whole model (with the Back history and all that) is going to rely on stuff not found on Windows Client. Cool that you're able to get some CLI apps to work (which is funny in and of itself; WP8 doesn't support a terminal interface). This is only post-jailbreak though? That still seems weird, since the signatures chain to the MS root CA. Very weird. I'll poke around myself once I download a ROM to explore (busy with work at present).
I haven't really found any to work, per se, I've just gotten console output, generally in the form of an error message or a help prompt. I can't recall which files exactly I had tried with, though. I mostly just poked through system32.
GoodDayToDie said:
I don't expect the GUI to work; the whole model (with the Back history and all that) is going to rely on stuff not found on Windows Client. Cool that you're able to get some CLI apps to work (which is funny in and of itself; WP8 doesn't support a terminal interface). This is only post-jailbreak though? That still seems weird, since the signatures chain to the MS root CA. Very weird. I'll poke around myself once I download a ROM to explore (busy with work at present).
Click to expand...
Click to collapse
the GUI classes of windows phone are not compatible with the standard .Net library or windows RT. The only way to get them running is through some sort of virtual machine. Some MSFT guys confirmed this a few months back at a training course about W8 RT.
Basically, it is kinda difficult to have WP8 apps show any GUI at all outside of their WP8 runtime.
netham45 said:
Here's what I came up with for a file list from some rudimentary (and possibly inaccurate) parsing of a .ffu: http://pastebin.com/hX6qJQeA
Got that from RM820_1232.2109.1242.1001_RETAIL_nam_usa_100_01_95122.ffu.
Click to expand...
Click to collapse
In regards to the file "MMOS.wim", has anyone managed to extract it/analyze it?
I couldn't find anything about it online. I am able to mount the file to a virtual disk and view its contents, but I am not able to view/read/extract any of these files from the drive. Trying to copy any file from the drive gives a system error/exception message that I have never seen before.
Are the files inside of "MMOS.wim" even useful?
---------- Post added at 12:13 PM ---------- Previous post was at 11:22 AM ----------
mcosmin222 said:
the GUI classes of windows phone are not compatible with the standard .Net library or windows RT. The only way to get them running is through some sort of virtual machine. Some MSFT guys confirmed this a few months back at a training course about W8 RT.
Basically, it is kinda difficult to have WP8 apps show any GUI at all outside of their WP8 runtime.
Click to expand...
Click to collapse
Not difficult, more like impossible lol.
The entire native UI is very independent. It is best described as one single app that has multiple pages. The start menu is a page, settings app is a page, office 365 is a page, etc.
These different pages all cross-reference resources from each other and can modify each other. However, they are all compiled separately. Each "page" contains it's own resources and GUI markup in a dll, along with native code to interact with the markup. This native code can also call functions and access resources from other "page" dll's. There are no compiler dependencies between the "pages" when being created, only during actual runtime.
Things are very "coupled" by this model on purpose. Changing code/functionality in the startmenu.dll could potentially break everything. It is designed so that you cannot target and modify a specific element or feature without updating code in other areas of the system.
Basically, you need full access and understanding of the gui layouts/code to modify it.
The only reasonable possibility is the ability to modify the markup code (think XAML) to change layouts and visuals. But even that possibility is made difficult since the markup is compiled. However, no information is lost during the compilation, meaning that the markup can be decompiled back to its original form.
Windows 8/RT uses DUI (DirectUI), a similar framework, for all of it's native GUI elements.
Windows Phone 7/8 uses UIX/Splash.
Asking a former Microsoft employee about UIX/Splash is like asking a former U.S. government agent about Area 51. They seriously fear for their lives.
I would avoid using the word impossible as of yet. With a layer of emulation above RT the thing should "run".
It might be possible to have an app compliant with the app store requirements (as in not require jailbreak) on RT to emulate the WP8 GUI model, but that would imply interpreting the XAML code and emulate it JVM style, but it would be a lot of work.
I wonder if the WP8 emulators would prove to be of any use...
mcosmin222 said:
I would avoid using the word impossible as of yet. With a layer of emulation above RT the thing should "run".
It might be possible to have an app compliant with the app store requirements (as in not require jailbreak) on RT to emulate the WP8 GUI model, but that would imply interpreting the XAML code and emulate it JVM style, but it would be a lot of work.
I wonder if the WP8 emulators would prove to be of any use...
Click to expand...
Click to collapse
My GUI post was in regards to the native GUI. I didn't realize that you were talking about WP8 apps running on Windows RT. I thought you meant the other way around lol.
Couldn't this potentially be pointless? Microsoft Job posting was looking for developers interested on deploying .appx on Windows Phone I believe. So that means they are going to make .appx the universal model for all platforms and not .xap in the future. With that said, they might be stopping .xap development completely in the future.
Who would develop an .xap for Windows Phone when you can develop .appx and have it work on Windows Phone + Windows RT + Windows 8 + Xbox?
Just some thoughts. I think trying to get .XAP running on Windows RT is pointless to pursue right now, since the time researching would be better spent in other areas of development.
Im not sure how they are going to make appx run on WP8. The WinRT model is obviously tuned towards bigger screens. How would you use a charms bar on WP8? In fact, how would you use any of the W8 stuff on WP8?
I think a lot of people would like to run emulated WP8 apps on their tablets, since some apps have not been ported yet.
While I do agree this is kinda pointless, it's a nice way of learning new stuff.
Related
Here we go:
I use a number of Microsoft Access Databases for my work, and each one is intensely coded and designed and basically run like actual programs. What I am looking for is to be able to take these databases with me. Now understanding that Microsoft and Android are two completely different beasts, what I really am looking for is the ability to take the tables (I use all Back-end database so all my tables are in a completely separate file then all my forms, queries, and reports) and the data with me and be able to run them in a program on Android that keeps the relationships and fields and all of that sort of stuff.
Now what would be great is the ability to use forms (even if special forms for android need to be made), run queries, and even be able to run reports and print as PDFs.
now I know how to code in VBA, hence the extensive coding I have done in Access, so anybody willing to WORK WITH in creating an Android Program to basically be an extension of Microsoft Access please contact me. Please not I use the words WORK WITH loosely, while I am trying to learn how to Program for Android, I currently do not have a computer that I can use to develop programs for android on, and well I would be only able to create the "Hello World" starter program and this project seems a slight bit more complicated. But what I can bring to the table is real world experience in testing and using the program day in and day out, a number of already existing Microsoft Access Databases ranging from Complex to Simple that I use every day. Really a program that can run Microsoft Access Tables on Android would be really useful to me and I am willing to do anything to help make this happen.
kronos82 said:
Here we go:
I use a number of Microsoft Access Databases for my work, and each one is intensely coded and designed and basically run like actual programs. What I am looking for is to be able to take these databases with me. Now understanding that Microsoft and Android are two completely different beasts, what I really am looking for is the ability to take the tables (I use all Back-end database so all my tables are in a completely separate file then all my forms, queries, and reports) and the data with me and be able to run them in a program on Android that keeps the relationships and fields and all of that sort of stuff.
Now what would be great is the ability to use forms (even if special forms for android need to be made), run queries, and even be able to run reports and print as PDFs.
now I know how to code in VBA, hence the extensive coding I have done in Access, so anybody willing to WORK WITH in creating an Android Program to basically be an extension of Microsoft Access please contact me. Please not I use the words WORK WITH loosely, while I am trying to learn how to Program for Android, I currently do not have a computer that I can use to develop programs for android on, and well I would be only able to create the "Hello World" starter program and this project seems a slight bit more complicated. But what I can bring to the table is real world experience in testing and using the program day in and day out, a number of already existing Microsoft Access Databases ranging from Complex to Simple that I use every day. Really a program that can run Microsoft Access Tables on Android would be really useful to me and I am willing to do anything to help make this happen.
Click to expand...
Click to collapse
I think we must have the same job
Android utilizes an sqlite database engine and it looks like sqlite already offers a conversion utility HERE. The real question would be how to get the data in and out of the phone. Regarding forms, they definitely would need to be custom built.
Thanks this is deffenetly a start, From what I can tell this This Looks to be the most promising, It looks like all you would have to do is put a MS Access Database file on your SD CARD and have a program access it. That way you copy it back and forth. Unfortunately it doesn't support Access 2003, but I can save down. I also got a lot of learning to do in programing Java programs.
Forms would be as simply as making a program, this is great thanks much
kronos82 said:
Here we go:
I use a number of Microsoft Access Databases for my work, and each one is intensely coded and designed and basically run like actual programs. What I am looking for is to be able to take these databases with me....
Click to expand...
Click to collapse
I would like to say, "yes, please!" to this idea. I currently use Smart List to Go (the descendant of ThinkDB) on my Palm TX. The TX is dying, and I've been shopping for a replacement. HanDBase exists for the iPhone, but I don't want an iPhone. So I've been focused on WinMo - not by choice as much as by necessity.
And android option would be very welcome around my computers.
benmyers2941 said:
I think we must have the same job
Android utilizes an sqlite database engine and it looks like sqlite already offers a conversion utility HERE. The real question would be how to get the data in and out of the phone. Regarding forms, they definitely would need to be custom built.
Click to expand...
Click to collapse
androids sqlite its for applications to access and store data using java code.
try the pocket office app
Freedomcaller said:
androids sqlite its for applications to access and store data using java code.
try the pocket office app
Click to expand...
Click to collapse
Exactly and we're talking about creating an app that would enable manipulation of an sqlite database. Essentially all that would be needed would be to create a ui framework wrapper for the existing api in android. Not the least monumental task I've heard of an individual taking on but not the most either.
The versions of pocket office that I've seen for android do not currently support Access databases as far as I'm aware. If I'm wrong could you post a link and save everyone some trouble?
aaaaaaaaaaaaaaaaaaa
kronos82 said:
Thanks this is deffenetly a start, From what I can tell this looks to be the most promising, It looks like all you would have to do is put a MS Access Database file on your SD CARD and have a program access it. That way you copy it back and forth. Unfortunately it doesn't support Access 2003, but I can save down. I also got a lot of learning to do in programing Java programs.
Click to expand...
Click to collapse
Jackcess library is now patched to support android (will be in 1.2.2 release). Also seems to support 2000, 2003 and 2007 formats now.
Works great for me.
View jackcess site. Couldn't find anything on support for android. I'm using htc desire and would really like to find program to view ms access file. Can you tell me how you do it?
As I remember reading worked as on PC, while writing had some problems.
This forum prevents me from linking directly, but if you click tracker/patches on Jackcess project, check Android Compatibility Fix - ID: 3101578
The changes are in trunk and will be in the 1.2.2 release. I've added some
notes which will eventually make it to the FAQ page on the website
detailing the compatibility steps:
- Set the system property "com.healthmarketscience.jackcess.broken
Nio=true"
- Set the system property "com.healthmarketscience.jackcess.resour
cePath=res/raw/"
- Copy the *.txt, *.mdb, and *.accdb files from the
"com/healthmarketscience/jackcess/" directory in the Jackcess jar to the
"/res/raw" Android application directory.
- Before executing any Jackcess code, set the current Thread's context
classloader, e.g.
"Thread.currentThread().setContextClassLoader(Database.class.getClassLoader())".
Click to expand...
Click to collapse
Until this version (1.2.2) is released you need to build lib yourself.
You also need commons-lang and commons-logging from apache commons.
Before you use Jackcess in Android code, you set
Thread.currentThread().setContextClassLoader(
getClass().getClassLoader());
System.setProperty(
"com.healthmarketscience.jackcess.brokenNio",
"true");
System.setProperty(
"com.healthmarketscience.jackcess.resourcePath",
"res/raw/");
Click to expand...
Click to collapse
and copy those resource files to res/raw
Then you can work as on PC, for example open /sdcard/yourprogram/file.mdb
Jackcess has no GUI, it's a library to read/write access files.
Getting an Access file into Android
I keep a lot of information on a Psion Revo, which has just turned its face to the wall and is giving up the ghost, and have always backed the information up on to my pc as an Access file. It looks easier to get this into a format acceptable to Android by converting the Access .mbx file into an Excel .xls file. This can be searched readily by Column and Values. Maybe this deals with too simple a need for most enquirers to the forum, but if it helps somebody then so much the better.
hi all i have beenlooking for something the same for some time now and just the other day i came accross this site cellica.com
the android app is free and the desktop application has a 5 day trial period or its $50 to buy it works great the only thing you can not do is create a report from the phone
i have emailed support team and they said they will be adding it on in the future.
Any Updates???
I currently build and use databases in MS Access and was wondering if there are any updates on this topic now that Tablets are in use now. Looking to get the Motorola Xoom (2nd version) in the future, but would love to be able to use a program that I would be able to access my MS Access databases while "on-the-go".
Anyone? This would be huge (I believe), since we now have tablets.
Thanks a bunch,
~Kilch~
Access to MS Access by Android
Hi,
I'm also looking to get on-the-go access to my Access databases on my Android HTC Tattoo.
The file is on it, I just need a tool to access it in read-only / search mode, but judging from the previous comments, there doesn't seem to be an oversupply in applications.
The "convert to Excel format" may be OK for me. I want to use a 3 language Access DB (dictionary) on my phone, so I'll try the Excel solution.
It would be nice if we had an ACCESS reader though...
John
Panacea Database
I know XDA frowns upon excessively hawking your own products here, but I do seem to be directly answering more than one of the reply questions, it just happens that the answer is an application my company released.
The Panacea Database application can handle Access from Access 2000 to Access 2007. It has also worked so far on every Access 2010 database we've tested, and we've received no complaints in that department yet. We release updates from time to time as we improve its functionality and features, often guided in our priorities by user e-mail and market comments. Our next update will be focused on improving screen layout for a variety of Android devices - from small QVGA smartphones, to large WXGA tablets. After that we may move onto other functionality.
In the interest of fairness, I'll point out arafa1209's post. He mentions Celicca Database, which is the only other application that I know of that deals with Access databases on Android. It has features Panacea does not have (yet) - ability to work with forms, ability to create and modify databases, ability to connect to your PC etc. Like us, they also send out updates improving their app regularly. So you can compare the apps, and use which one fits your needs better (or use both). If anyone knows of any others they can post here as well, but these are the only two I know of currently.
Just tried Panacea. Although it is more basic and annoyingly doesn't remember the last files you'be opened necessitating finding the file each time you open the app I prefer it for the simple reason you don't have to convert the Access database to another format.
amwebby said:
doesn't remember the last files you'be opened necessitating finding the file each time you open the app
Click to expand...
Click to collapse
If you update the app, this should be fixed, the last version should have this feature.
Got the update last week. Certainly goes a long way to making it more user-friendly. Keep up the great work!
Since the last update it seems to be broken. Although it remembers the last database I cannot open a table within any database.
Edit: It appears the file was corrupted. Loaded a new file and all working again.
Any news in this topic.
I tried panacea Database, works fine. But not very effective. Searching data is a must for me however I didnt manage to find a search option. When I search for tables, it cant even locate the tables by names.
evening gents and lady
i have a query for chefs mainly but anyone with OS knowledge can help.
basically i work for a company that recycles computer equipment, we receive a lot of certain models mostly the dell optiplex gx range. and rebuilding them entails we have to install the OS from the oem discs and then preceed to either download drivers from dell, install from out in house servers or usb pen drives.
i had a thought that maybe the drivers could be installed as packages onto the disc a bit like windows mobile.
ideal situation
One master disc with the operating system on AND all the drivers for the range os systems we build. in this case xp w/ sp2 then after the normal os installation i want a program maybe to detect the model and install the drivers that are on the disc automatically. a bit like the app that installs opera and google maps on coked rom (UC?) also if that goes well i can then include all the apps that we install like ms security essentials. open office etc
is there anyway to do this
have you got a dell oem disc?
I have and it installed the driver auto
flyboy
we have a standard oem disc that does all of our models but thedriver needed differ from machine to machine for instance sometimes the ethernet adapter gets installed by default other times we have to install it after the main os insta;ll
There is a way to do it. Few questions:
1) What Windows O/S
2) Do you have an OEM product key
3) Are you familiar with slipstreaming
* EDIT *
Guess we posted at the same time. You need to slipstream the drivers into the O/S media. It's not usually best practice to included applications but can be done. Depending on the version of Windows, a final post config exists to trigger silent installs of extra applications. It's all part of a SYSPREP deployment process.
we use dell oem disc xp with sp 2, the keys do not have to be written in on the setup and no i dont have a clue what slipstreaming is
-PiLoT- said:
we use dell oem disc xp with sp 2, the keys do not have to be written in on the setup and no i dont have a clue what slipstreaming is
Click to expand...
Click to collapse
In slipstreaming you can place your drivers into the OS so on install everything is done. "including stripping system components integrating service packs"
XP nlite
I just have a library of about 9000 drivers on a CD that always lives in me bag. "and stored as ISO image on computer" These compilations can be found online.
The choice you choose will depend on if you have a quantity the same then you can use nlite as you know the install the same or just bung all drivers onto a disk
The process you're after is a sub-process of imaging.
Here's an abridged version, very abridged, but should give you a sense of what's involved ... having done this a few (aka many many) times.
Media
Generally, the media to use for this type of activity is obtained directly through Microsoft as using another OEM's media is generally problematic as it has been altered for their requirements. Since you're using the DELL OEM CD on DELL OEM systems, you can "get away" using it.
One of the steps you may want to do is slipstream WinXP SP3 to the media. Here's a good site to get you on your way, there are many more out there:
http://www.winsupersite.com/showcase/xpsp3_slipstream.asp
Product Key
The product key embedded in the OEM CD ensures that it is only useable on DELL branded equipment. This permits end-users to rebuild their system and skip the product activation phase - the caveat being that OEM media is used on the OEM system; you can't interchange OEM media/systems as this will trigger activation.
Enterprises usually obtain a Volume License Key (VLK) which allows them to use imaging methodologies to deploy the O/S to workstations.
Note
Before others chime in ... yes, there are "work arounds" but since we're sticking to legitimate usage - we'll avoid that topic.
Pre-Delivery Process
There are two approaches to this process.
The first, traditionally used by OEM's (ex: DELL, HP, etc.) is to inject their drivers into the O/S media and modify some of the setup information files so as to ensure that the drivers are detected during the TEXT & GUI setup portions of Windows.
The second, traditionally used by Enterprises (ex: 20+ workstations) is to build a base image which is: install windows, install drivers, run SYSPREP, capture (seal) image. Knowledgeable IT builders will usually inject the drivers they require and adjust the setup information files prior to running SYSPREP and "sealing" the image.
Note
Large OEM's will also use the second process so that they may build many similar systems at once for shipment purposes. In a nutshell, the customer gets the media but the actual system HDD has been imaged.
Additionally, some OEM's will ship their systems with a hidden partition that is accessible by pressing a combination of keys at boot. The hidden partition contains a copy of the system image which can be restored to the visible partition.
Post-Delivery Process
The are two approaches to this process.
The first, traditionally used by OEM's (ex: DELL, HP, etc.) is to provide the O/S media along with the system. At the factory, an image is copied to the system HDD (see note above) and the system is shipped to the customer. When the customer unpacks and starts the system, the mini-SYSPREP is initiated and the system goes through a mini-GUI setup procedure.
The second, traditionally used by Enterprises (ex: 20+ workstations) is to take the pre-delivery process "sealed" image and upload it to a distribution system such as SMS, Altiris, OnCCM, Symantec GHOST, etc. The BIOS of the workstations are usually configured so that the Network Adapter (NIC) is set for Pre-eXecution (PXE) boot. A Wake-On-LAN is sent to the MAC address of the workstation (which has been recorded during asset receipt/delivery), the workstation turns on, sends a PXE-Boot request, the DHCP server responds to the request and forwards the request to the distribution server, the workstation receives a boot image from the distribution server, which in turn initiates imaging of the workstation HDD. Once completed, the workstation reboots and goes through an automated mini-GUI setup which performs all of the necessary detection and driver installation.
Some Final Points
You can inject drivers to the physical media (ex: Windows XP) and perform individual installs of Windows on a system-by-system basis. This is often referred to as slipstreaming drivers or injecting drivers. This is often required for AHCI controllers on new systems.
Imaging can be "tricky" if you have to deal with multiple variations of hardware abstraction layers (HAL) such as in the case with single/multi processor architecture.
Ensure that customers receive a copy of the media with their systems so as to remain compliant and not violate license agreement terms.
Avoid using NLITE unless your company is planning on providing continuous ongoing support with each system sold. NLITE is an extremely fast method of preparing systems for mass image distribution. Unfortunately, it is not officially endorsed/supported by Microsoft and/or OEM's. Enterprises or individuals can usually "get away" with using NLITE as they typically self-support their systems.
Recommendation
In your situation, it may be easiest to read up on the following methodologies:
Slipstream service pack to cd-rom (media)
Slipstream (inject) drivers to cd-rom (media)
HTH,
wow thx H
very concise. i think even though were technically classed as an enterprise. i think id still prefer to use the oem solution. looks like im going to have to have a disc per model instead of one master disc but cant win em all.
using nlite wont do as we only provide 3 months official warranty on the product
so i think my best bet is to copy the contents of the cd to a computer. then insert my drivers onto it the make a iso out of it then make a bootable cd. the customer wont get a copy of the edited cd. think they might have something to say having the recovery disc on a tdk cd/r
using the oem disc you have got. research on the internet and find out where the drivers are kept on the disc, then copy the disc to your pc and insert the drivers then burn to disc. this way the drivers would be on the disc.
read this as well. i think its a noob sort of guide to slipstreaming:
(cached google page)
http://209.85.229.132/search?q=cachedCEft9ToWQJ:tech.yahoo.com/blog/null/99108+where+are+drivers+on+xp+disc&cd=7&hl=en&ct=clnk&gl=uk
flyboy
( sorry just reaslised i have posted what you said, pilot)
I was just reading an article concerning malware on Windows Phone 8
Google News Search "Windows Phone 8 Malware"
From the article
"A 16-year-old security researcher from India plans to present a malware application for Windows Phone 8 at the upcoming MalCon security conference in New Delhi, India, on Nov. 24.
According to a brief description of the presentation on the MalCon website, it will show approaches and techniques for infecting Windows Phone 8 devices and will demonstrate how the prototype malware can steal contacts, upload pictures, access text messages and more."
Will this affect WP8 sales...it certainly doesn;t look good for this to happen so close to the launch...will we need to install AV software on our phones now too?
"Stealing contacts" is not that hard to do, since your app can read the contacts (you don't need any hacking to do that).
But reading + sending them to your server will make the marketplace instantly reject the app. So i doubt there's a problem.
I also don't see how you can infect a windows phone, given that .Net and Secure Boot make it almost invulnerable to everything.
rob243 said:
I was just reading an article concerning malware on Windows Phone 8
Google News Search "Windows Phone 8 Malware"
From the article
"A 16-year-old security researcher from India plans to present a malware application for Windows Phone 8 at the upcoming MalCon security conference in New Delhi, India, on Nov. 24.
According to a brief description of the presentation on the MalCon website, it will show approaches and techniques for infecting Windows Phone 8 devices and will demonstrate how the prototype malware can steal contacts, upload pictures, access text messages and more."
Will this affect WP8 sales...it certainly doesn;t look good for this to happen so close to the launch...will we need to install AV software on our phones now too?
Click to expand...
Click to collapse
Unless you unlock the device and install that software by yourself, i don't believe it ever gonna pass marketplace check before it get online.
Well I am interested to see how its done, apparently the guy will present the proof of concept on the 24th
There are ways to get past checks run in the Marketplace ingestion. This has been previously demonstrated with PoC malware on iOS, which has similar protections. Don't assume it's impossible, especially if native code use is permitted.
Please note that there is a difference between native and unmanaged code, don't mix them up.
Native code has always run on Windows Phone. Both C++ and C# produce native code. The first is un-managed, whereas the second is managed.
Visual C++, the one we use in Windows Phone is, just like C#, a managed native language. It achieves almost the same performance as the standard C++,due to the more optimized compiler. It is possible to run standard C++ on Windows Phone, but it is very difficult to do so because the marketplace knows which compiler you used to make your app (if visual studio is not there, no no). The marketplace also knows which API you use (no Windows Phone API for C++, again a big NO for the submission).
Now, the difference between native and non-native code...
Native code always ends up as 1 and 0. The very code you write in C# will, at some point, end up as 1s and 0s. Same goes for C++(managed or not). The difference between C# and C++ is that the compiler inserts some failsafes into the code (lots of ifs) to check for exceptions. This does not happen in C++.
So the path for C# is like this:
C# code -> MSIL->Native code which is run on your devices (compilation is either done at install time, or in the clouds).
the C++ code we use in Windows Phone has basically the same path! However, the more mature compiler and the "no-failsafe policy unless instructed to" that all C++ variations enforce make the code faster while less safer.
A non-native language will never, ever get the code a developer writes compiled to 1s and 0s.
Such an example are web programming languages, and Java.
For Java, the process is like this
Java code -> various stages of compilation>byte code -> JVM interprets bytecode and then sends 1s and 0s to the CPU to execute-> CPU sends 1s and 0s results back to JVM which displays the results.
As such, Java is somewhat safer than C#, but also a lot slower.
The advantage of using an interpreted language is that you know the hardware capabilities of the device beforehand, and optimizations can be made on the spot.
Microsoft, however, took the middle road with C#. They gave it all the advantages of an intepreted language (due to the MSIL step, the .Net always knows how hardware it runs on, so the MSIL will always target all the hardware capabilities for your CPU, GPU and RAM), while also running on native code, which makes it very fast. They also decided to push in the same failsafe checks Java inserts in its code. This resulted in a slightly slower code when compared to C++.
As a developer, I think the reason for dropping XNA development by Microsoft wasn't its speed. C# could easily run games, and the thousand XNA games we have on the marketplace bear testimony to that. They brought C++ on board because porting apps from one platform to another would be easier this way, especially for apps coming from android or iOS).
Anyway, having said that, the C++ we use on phones does not have the capabilities to access the hardware or the system the same way it has on desktop. It doesn't have more power than C# already did. It is just used there for other reasons. I don't think it will pose any threat to security. Desktop evolved in a different way. Microsoft learned the lesson of system protection a long time ago. They won't repeat the same mistakes now. It wouldn't surprise me if they actually had some sort of AV software built in, just to be sure.
There are so many factual errors in the above post I don't even know where to begin...
"Native" in this sense refers to apps written in a language which gets built ("compiled" although that technically involves compiling, assembling, and linking) directly into machine code ("0s and 1s" is a silly way to describe it, since *everything* on a computer, from programs to plain text files to MSIL or Java bytecode are all binary). Machine code means a binary sequence that the processor can directly execute. This is also referred to as native code, i.e. code which executes on the processor without needing an intermediary layer.
Although technically "native" and "unmanaged" mean different things, the difference is not what you think it is, and it's not very relevant to this discussion. It's entirely possible to have a native managed language ("D" was supposed to be such a thing; I'm not sure to what degree managed C++ qualifies) and to have intermediate-compiled unmanaged languages (you could, for example, distribute unmanaged programs compiled to LLVM bytecode; some systems might actually be doing so). However, MS themselves typically use "native" to mean "not managed", as evidenced by things like debugger modes.
These days, almost everything gets JIT (Just In Time) compiled to machine code even if the build tool didn't produce native machine code itself. This applies to .NET code (gets built as MSIL), Java (gets built to Java bytecode or Dalvik bytecode if on Android), JavaScript (doesn't go through a build process at all, but modern browsers JIT compile it to native before execution nonetheless), and many other languages. Interpreting is slow and requires a lot of memory overhead as well (you have to run the interpreter in parallel with the program actually being executed).
Although it is possible to invoke managed code from native code (only a little messy) and vice-versa (very common, see P/Invoke or COM interop for .NET, or JNI for Java), this should not be confused with them being the same thing. Yes, by the time they reach the CPU instruction decoder they're the same, but the process of loading the program, and the "runtime" environment that it interacts with, are very different indeed. Managed code uses a memory manager (hence the name), which takes care of things like defragmenting and freeing memory (via the garbage collector). This fundamentally violates a number of assumptions common to unmanaged code, such as that the address of data in memory will never change on its own, and that once allocated, a block of memory on the heap remains reserved until manually freed.
Another important difference is that managed languages must use abstractions of function pointers (for example, .NET delegates). In native languages it is possible (though generally unwise) to specify an absolute address (0x040C7F06 or some such) as a function pointer, and call that "function" (which results in the processor attempting to execute instructions starting from that memory address). In practice, this kind of thing is almost never done in PC software; it's bug-prone, completely un-portable, incompatible with security features like ASLR, very difficult to debug (this is the kind of thing that malware might use to make reverse engineering it harder), and there's typically no reason at all to do so.
However, the fact that it's *possible* is a Big Freaking Deal for somebody looking to work around a runtime security check. Consider this: Sliverlight on WP7 doesn't allow arbitrary LoadLibrary (or Assembly.Load, or similar) calls. The APIs available to your app are the ones included in its DLLs, and the ones in the Silverlight for WP7 runtime libraries. Even though the desired functions exist on the OS, and are even linked into program memory, you can't call them because there's no way to get a delegate for them. Now, compare this to native code, where you can literally just scan the code section of your app's memory until you find the entry point for the function you want, then treat that address as a function pointer and jump right into it.
Now, to be fair, I haven't actually written any official WP8 C++ yet. However, I can tell you that the trick mentioned above works just fine in Windows Runtime C++ on both Win8 and Windows RT, which are also supposed to lack APIs like LoadLibrary, and I therefore suspect it will work fine on WP8. Some experimentation is due, in any case.
GoodDayToDie said:
There are so many factual errors in the above post I don't even know where to begin...
"Native" in this sense refers to apps written in a language which gets built ("compiled" although that technically involves compiling, assembling, and linking) directly into machine code ("0s and 1s" is a silly way to describe it, since *everything* on a computer, from programs to plain text files to MSIL or Java bytecode are all binary). Machine code means a binary sequence that the processor can directly execute. This is also referred to as native code, i.e. code which executes on the processor without needing an intermediary layer.
Although technically "native" and "unmanaged" mean different things, the difference is not what you think it is, and it's not very relevant to this discussion. It's entirely possible to have a native managed language ("D" was supposed to be such a thing; I'm not sure to what degree managed C++ qualifies) and to have intermediate-compiled unmanaged languages (you could, for example, distribute unmanaged programs compiled to LLVM bytecode; some systems might actually be doing so). However, MS themselves typically use "native" to mean "not managed", as evidenced by things like debugger modes.
These days, almost everything gets JIT (Just In Time) compiled to machine code even if the build tool didn't produce native machine code itself. This applies to .NET code (gets built as MSIL), Java (gets built to Java bytecode or Dalvik bytecode if on Android), JavaScript (doesn't go through a build process at all, but modern browsers JIT compile it to native before execution nonetheless), and many other languages. Interpreting is slow and requires a lot of memory overhead as well (you have to run the interpreter in parallel with the program actually being executed).
Although it is possible to invoke managed code from native code (only a little messy) and vice-versa (very common, see P/Invoke or COM interop for .NET, or JNI for Java), this should not be confused with them being the same thing. Yes, by the time they reach the CPU instruction decoder they're the same, but the process of loading the program, and the "runtime" environment that it interacts with, are very different indeed. Managed code uses a memory manager (hence the name), which takes care of things like defragmenting and freeing memory (via the garbage collector). This fundamentally violates a number of assumptions common to unmanaged code, such as that the address of data in memory will never change on its own, and that once allocated, a block of memory on the heap remains reserved until manually freed.
Another important difference is that managed languages must use abstractions of function pointers (for example, .NET delegates). In native languages it is possible (though generally unwise) to specify an absolute address (0x040C7F06 or some such) as a function pointer, and call that "function" (which results in the processor attempting to execute instructions starting from that memory address). In practice, this kind of thing is almost never done in PC software; it's bug-prone, completely un-portable, incompatible with security features like ASLR, very difficult to debug (this is the kind of thing that malware might use to make reverse engineering it harder), and there's typically no reason at all to do so.
However, the fact that it's *possible* is a Big Freaking Deal for somebody looking to work around a runtime security check. Consider this: Sliverlight on WP7 doesn't allow arbitrary LoadLibrary (or Assembly.Load, or similar) calls. The APIs available to your app are the ones included in its DLLs, and the ones in the Silverlight for WP7 runtime libraries. Even though the desired functions exist on the OS, and are even linked into program memory, you can't call them because there's no way to get a delegate for them. Now, compare this to native code, where you can literally just scan the code section of your app's memory until you find the entry point for the function you want, then treat that address as a function pointer and jump right into it.
Now, to be fair, I haven't actually written any official WP8 C++ yet. However, I can tell you that the trick mentioned above works just fine in Windows Runtime C++ on both Win8 and Windows RT, which are also supposed to lack APIs like LoadLibrary, and I therefore suspect it will work fine on WP8. Some experimentation is due, in any case.
Click to expand...
Click to collapse
Well, I was just trying to get a "basic picture" of the thing, but thanks for going into much more details.
As I said, the C++ we use in Windows Phone, just like C# on Windows Phone, functions in a different way compared to Desktop or Tablet version(hell, with C# on desktop you can easily do the memory scan thing and find stuff in the OS, not only in your app, but that is generally not needed, since C# on desktop has a much boarder and less limited API) . Unlike the former two, you can't interact outside your application, because your application is sandboxed. Even if you did find the pointer to a system protected function, you wouldn't be able to do squat with it(the system protects itself). Which is why I said C++ can't do things C# already couldn't. In theory, yes you can do what you said, in fact, i expect it to be possible on rooted rooms, but for the average joe...well...it very unlikely to happen, unless he does something stupid.
As for the JIT story, well, yes, Java does use JIT. However, it does so because it doesn't know before hand on what hardware it will run. The same happens with C# and .Net on desktop, and this is due to hardware variations. Right now, for windows phone, the "JIT" occurs directly in the clouds, or at install time, as all Windows Phones (8) use snapdragon chips.
I didn't say there were no differences between the code C# and C++ create at run time. The abstraction layers inserted by the compiler fall under the "failsafes inserted in code that slow things down", which C++ doesn't have. Also the more mature compiler (C++has like 40 years of xp, C# barely made 10, and only 3 on Windows Phone), the "true native" (happy now?) code it generates (which is very close to assembler language) makes C++ faster than C#, but not fast enough nor safe enough to phase out C# entirely.
In fact, if we still have this board 10 years from now, we might C# eventually take down C++.
We should avoid getting into a technical talk in this thread. As you can see, there are non-developers coming by, and an answer such as yours will completely and utterly confuse them. What I attempted to provide was a very basic image they could understand, like JVM sending 1s and 0s to CPU is the same as JIT.
Let's wait and see what we will be presented with. Currently the only thing a WP8 Managed App can't do that was mentioned was reading the SMS-Storage. Everything else is part of the official APIs. It might be that similarily to several WP7 hacks OEM drivers are being used to gain access.
The only thing that would really worry me was if he was able to provide a way to install his Malware bypassing the Marketplace. It might be interesting though for the Jailbreak community, given that any jailbreak bascially means exploiting a security vulnerability to elevate the rights of the current process to allow for those unlocks.
I've been searching for .XAP decompiler/disAssembler (to do reverse engineer) for phone 8 xap files. I've seen that the new .xap files are not longer simple .zip/.rar files. They have something more.
In short I'm asking something similar to http://forum.xda-developers.com/showthread.php?t=1443692 for phone 8 . Does anyone know any (free) tool which can help me out ?
Could you please attache XAP? I'll investigate it.
Sure
Please see the attachment.
It appears MS have encrypted XAPs now - this has a PlayReady DRM header:
Code:
<WRMHEADER xmlns="http://schemas.microsoft.com/DRM/2007/03/PlayReadyHeader" version="4.0.0.0"><DATA><PROTECTINFO><KEYLEN>16</KEYLEN><ALGID>AESCTR</ALGID></PROTECTINFO><KID>w3i0edJP7EOqQ6aQzdAoSQ==</KID><LA_URL>http://microsoft.com/</LA_URL><CUSTOMATTRIBUTES xmlns=""><S>9FcV5qmfIsMc+X2MVmX3Hw==</S><KGV>0</KGV></CUSTOMATTRIBUTES><CHECKSUM>Hu3+fizBvKU=</CHECKSUM></DATA></WRMHEADER>
So, does it mean I'll never be able to decompile any .xap ?
XAPs downloaded from the Marketplace are encrypted starting sometime in summer last year. That was also the time when devices that had not installed the WP7.5 update lost access to the Marketplace.
So unless you know the decryption key no: you won't be able to decompile XAP files downloaded from the Marketplace. As for XAPs you get from a Dev directly or created yourself - those should still be in the same ZIP-Format as before.
if we get admin access on the phone we can make the phone to decompile it for us and then make an unencrypted version of the .xap
StevieBallz said:
XAPs downloaded from the Marketplace are encrypted starting sometime in summer last year. That was also the time when devices that had not installed the WP7.5 update lost access to the Marketplace.
So unless you know the decryption key no: you won't be able to decompile XAP files downloaded from the Marketplace. As for XAPs you get from a Dev directly or created yourself - those should still be in the same ZIP-Format as before.
Click to expand...
Click to collapse
Does anybody developed some hack to see content of .xap files which are from market place ? if yes, where can I get it ?
ellokomen said:
if we get admin access on the phone we can make the phone to decompile it for us and then make an unencrypted version of the .xap
Click to expand...
Click to collapse
And how can I get admin permission on my phone win 8 phone ? In other words, is it possible to get admin permission on win 8 mobile ?
@shek007
WP8 is much more secure than WP7. So it will take much time or never to hack the OS.
Regarding the xap decompile, it seems you are insisting on 'hacking'. That is a bad behaviour, trying to steal other's logic/data If it's your's or friend's .xap, then you'll get access to the code. Otherwise you have no right to decompile the code if it's not yours or the others didn't provide you access.
Anyway, you got the answer back then: no, it won't work.
shek007 said:
And how can I get admin permission on my phone win 8 phone ? In other words, is it possible to get admin permission on win 8 mobile ?
Click to expand...
Click to collapse
1. No one knows what "win 8 phone" and "win 8 mobile" are. Never heard of those.
2. Go somewhere else to discuss theft.
narrowing the subject to "theft" is not appropriate as when one wants to make out the most of some applications.
Examples are: Decompile the Field Test app from nokia to see the internal API calls to the radio module in order to obtain RF related data, such as cell ID, MCC+MNC, Ec/Lo etc..
using this API calls we can make Apps for RF field engineers to test the network performance and signal levels using the Lumia phone.
This functionality is well known on others smartphones but lacking in Windows Phone platform so far.
Another example will be using multiple whatsapp accounts in the same phone ( another functionality from other mobile platform missing in WP)
As far as I understood the security architecture not just any App would be able to access those APIs even if it knew about them. It requires special permissions and I would guess that at the moment those are not available with a regular Developer Unlock.
As for decrypting the file or gaining access to the phone and extracting the data from there: WP8 security has not yet been broken. There might be people working on it but for now we know of no way to do it.
StevieBallz said:
As far as I understood the security architecture not just any App would be able to access those APIs even if it knew about them. It requires special permissions and I would guess that at the moment those are not available with a regular Developer Unlock.
As for decrypting the file or gaining access to the phone and extracting the data from there: WP8 security has not yet been broken. There might be people working on it but for now we know of no way to do it.
Click to expand...
Click to collapse
Idk if you guys know about this website... [http]://xapapp[dot]blogspot.com/
this guys does exactly what the OP asked. If m wrong then please correct me
I guess I'll have to wait until I can learn about this
Btw, I never had intention to hack/theft others app..
tai4de2 said:
1. No one knows what "win 8 phone" and "win 8 mobile" are. Never heard of those.
2. Go somewhere else to discuss theft.
Click to expand...
Click to collapse
1. Yes. No one knows what win 8 phone is.
That is why YOU are on this forum thread., because is called just like that. "Windows Phone 8" looks similar to windows 8 phone. Or not.
2. " Windows Phone 8 Development and Hacking>> Windows Phone 8 Q&A, Help & Troubleshooting" is the name of this thread. So, where else could discuss hacking windows 8 apps.
You just needed to post something.
I just needed to reply (two years later), so I joined to forum. :laugh:
BTW are there any new tools for decompile xap files?
Please don't necropost!
Posting here rather in a PM in the hopes that others will see and remember...
You just posted in a 22-month-inactive thread. This violates a near-universal guideline (sometimes rule) of online forums: do not post in dead threads (common called "necroposting"). Your post added nothing of value and effectively constitutes spam, as it brings a thoroughly outdated thread to the top of the forum list. It's much better to create a new thread (linking the old one, if you feel that will help) as then people who read earlier posts in the thread but don't notice the datestamps won't be seeing stuff that is years out of date.
While I agree that the person you responded to was being needlessly pedantic, it does seriously annoy some members of the community to have people screw up the name of the OS. Win8 and WP8 have about as much in common as Mac OS X and iOS; that doesn't mean it's reasonable to say an iPhone runs "Phone OS X". The fact that there existed a legacy (and *very* different) OS called Windows Mobile (or WinMo), and that people routinely seem to think that WP is just the continuation of WinMo (it's really, really not), is a large part of why some folks stomp on people who use the wrong name for the OS.
Decompiling apps is easy. Breaking PlayReady DRM is really, really hard. There's no decompiler anywhere I know of that can take a DRMed XAP and decompile it. You'll have to get the app without DRM encryption if you want to decompile it.
PLEASE DO NOT POST ANY MORE IN THIS THREAD!
So after that guy figured out the tethering hack for iOS by just changing a few lines of test, I decided to try to find one for Windows Phone 8. I have no idea how it would get on the phone (besides possibly flashing a new rom?), but I went and looked anyway. I mounted the VHD from the SDK and I think that I found something. If you use something like Visual Studio's Find in Files and search for ICSSVC, you'll find some interesting stuff.
First of all, in Microsoft,Net.NetCore.reg, I found this: puu.sh/3J9yS.png That's how I learned about ICSSVC. So then I searched for that and in Microsoft.Net.NetCore.policy.xml there is a bunch of capability stuff. I have no idea what to do past here, and the emulator doesn't have the Internet Sharing option. So, yeah.
MichaelC97 said:
So after that guy figured out the tethering hack for iOS by just changing a few lines of test, I decided to try to find one for Windows Phone 8. I have no idea how it would get on the phone (besides possibly flashing a new rom?), but I went and looked anyway. I mounted the VHD from the SDK and I think that I found something. If you use something like Visual Studio's Find in Files and search for ICSSVC, you'll find some interesting stuff.
First of all, in Microsoft,Net.NetCore.reg, I found this: puu.sh/3J9yS.png That's how I learned about ICSSVC. So then I searched for that and in Microsoft.Net.NetCore.policy.xml there is a bunch of capability stuff. I have no idea what to do past here, and the emulator doesn't have the Internet Sharing option. So, yeah.
Click to expand...
Click to collapse
Unfortunately, this involves dumping phone ROMs and modifying the policies (We don't know how crazy this process will be). Another set back involves the fact that the bootloaders for WP8 are signed which would require the the ROM to be signed with the correct cert, etc.
Basically, this will be extremely painful due to WP8 running a Windows NT Kernel (WP7 uses Windows CE) and all kinds of other obstacles that we haven't discovered yet.
snickler said:
Unfortunately, this involves dumping phone ROMs and modifying the policies (We don't know how crazy this process will be). Another set back involves the fact that the bootloaders for WP8 are signed which would require the the ROM to be signed with the correct cert, etc.
Basically, this will be extremely painful due to WP8 running a Windows NT Kernel (WP7 uses Windows CE) and all kinds of other obstacles that we haven't discovered yet.
Click to expand...
Click to collapse
Also while I was searching, I found a registry entry for 'DeveloperUnlock'. So when you run the program to dev unlock your phone, the program must modify the registry on the phone. I'm pretty sure that it would be possible to replicate that.
MichaelC97 said:
Also while I was searching, I found a registry entry for 'DeveloperUnlock'. So when you run the program to dev unlock your phone, the program must modify the registry on the phone. I'm pretty sure that it would be possible to replicate that.
Click to expand...
Click to collapse
As of now, we can't execute the native EXEs on the phone so we won't know whether we can replicate that or not. I know with talking with HeathCliff74, modifying the policy on WP7 took quite a long time and effort to figure out. I can almost guarantee the policies on WP8 are implemented completely different from WP7 and even a bigger pain to modify
snickler said:
As of now, we can't execute the native EXEs on the phone so we won't know whether we can replicate that or not. I know with talking with HeathCliff74, modifying the policy on WP7 took quite a long time and effort to figure out. I can almost guarantee the policies on WP8 are implemented completely different from WP7 and even a bigger pain to modify
Click to expand...
Click to collapse
I meant the program on your computer that comes with the SDK. I think that it modifies the phones registry to dev unlock it.
MichaelC97 said:
I meant the program on your computer that comes with the SDK. I think that it modifies the phones registry to dev unlock it.
Click to expand...
Click to collapse
You are correct, it does modify the registry to dev unlock it by connecting to a running service on the phone and executing native DLLs. The main DLL that interacts with the phone within the program's folder is an Win32 compiled .DLL rather than a .NET file which would require some disassembly to get an idea of what's going on. It also doesn't help that it is a signed DLL.