Related
I'm assuming this is associated with the recent phenomenon of hardware ID's changing everytime a new ROM is installed. Apparently MS uses the same hardware ID when it encrypts files on SD cards. What this means is you will lose all of your files on the SD card (including backup files) if you have encryption turned on, the files get encrypted, and then you switch ROM's.
So.. uh.. this is just a little warning, and it might be obvious to everyone but me... don't use SD encryption unless you know you're going to stick with a ROM.
I have no idea why MS doesn't just use the IMEI, but... they don't.
From what I read about the encryption, the key is generated after a hard reset, so basically you can't hard reset the device once data is encrypted.
Do you know wether there is an option to backup ones key to a file, save it to ones PC, and then reimport it once one has finished hardresetting the device?
If I were MS I'd see the vast usefullness of such an option and integrate it at once
the encryption key is created when you turn the Setting on...
and when flashing a new ROM or a HardReset the key is desteroid...
i am still yet to find the location... still looking...
Providing you remember, can't you just turn off the setting before a flash or hard reset and restore all the files to there unencrypted state?
Once the ROM has been flash and everything hard-reset you can just encrypt them again?
Percz said:
Providing you remember, can't you just turn off the setting before a flash or hard reset and restore all the files to there unencrypted state?
Once the ROM has been flash and everything hard-reset you can just encrypt them again?
Click to expand...
Click to collapse
No, because turning it off doesn't decrypt existing encrypted files. Just like turning it on doesn't encrypt the normal files. It will decrypt them as you open and resave them.
:-\
walshieau said:
the encryption key is created when you turn the Setting on...
and when flashing a new ROM or a HardReset the key is desteroid...
i am still yet to find the location... still looking...
Click to expand...
Click to collapse
OK; that makes sense. I just realized that after I hard-reset I restored most of my settings with the data from a backup (Sprite Backup). I wasn't seeing the encoded files problem because I was restoring from a non-encrypted file.
ugh.
y2whisper said:
From what I read about the encryption, the key is generated after a hard reset, so basically you can't hard reset the device once data is encrypted.
Click to expand...
Click to collapse
That makes perfect sense, actually. That way someone can't hard reset your phone to get at the data.
Too bad it also means the real owner can't get to his own data..
Some FAQs from the horse's mouth: http://blogs.msdn.com/windowsmobile...ows-mobile-6-storage-card-encryption-faq.aspx
What you can do is ActiveSync your Device and then drag and drop all the files you want to keep before the hardreset. And then when you finish installing your ROM and Hardresetting your device, just transfer back the files via activesync. I know its tedious and long if you have like 1 gig of **** in the SD card, but thats the only way i've found.
just lost files to encryption
Been reflashing my 8525 with new versions of custels and vanilla and have never lost files to encyption. However just flashed to Black 3.01 and lost all my stuff. If i flash back to my previous ROM is it conceivable that the same key will be created and i will regain access to my files?
Unfortunately, I was also unaware of this. I presumed MS would use a key based on the hardware or something like that.
Anyway, is there any way of breaking the encryption and get back the files?
Thanks!
Keshen
As the DataProtection API as in WinXP and Win2003 is used, it is AES-128 by default.
"The design and strength of all key lengths of the AES algorithm (i.e., 128, 192 and 256) are sufficient to protect classified information up to the SECRET level. TOP SECRET information will require use of either the 192 or 256 key lengths."
So brute force attack is not really an option….
As the key is stored somewhere in the flash I think this will be the only feasible way to decrypt the files.
But as the key is lost because of the hard-reset during upgrade, there is not much hope...
Only if we can get more information on how the keys are generated, maybe this will reduce
the complexity of an attack.
You won't have good luck trying to crack the encryption. Which, is actually a good thing since the purpose is to keep your data safe in the wrong hands. I prefer to use a 3rd party encryption solution as it allows more choices and control.
MrGAN said:
As the DataProtection API as in WinXP and Win2003 is used, it is AES-128 by default.
"The design and strength of all key lengths of the AES algorithm (i.e., 128, 192 and 256) are sufficient to protect classified information up to the SECRET level. TOP SECRET information will require use of either the 192 or 256 key lengths."
So brute force attack is not really an option….
As the key is stored somewhere in the flash I think this will be the only feasible way to decrypt the files.
But as the key is lost because of the hard-reset during upgrade, there is not much hope...
Only if we can get more information on how the keys are generated, maybe this will reduce
the complexity of an attack.
Click to expand...
Click to collapse
Breaking AES is pretty hopeless unless you have access to the NSA's computer systems.
The big problem, in my opinion, is MS doesn't give you an easy way to back up the key and restore it. Now that I've given it more thought, it makes perfect sense that the key gets nuked on a hard-reset: otherwise someone could just hard-reset your phone and have access to your data. In most cases, it's better to permanently lose the data than to allow someone else to have access to it.
Another thing that MS would be wise to offer is a "mass decrypt" function that would go through the entire SD and decrypt all of the encrypted files.
Other than that -- the way I've been dealing with it is by using SpriteBackup (I'm sure SBP does this too) and back up the SD card along with the main memory. Since the encoding happens in the OS level, the backup software sees the normal unencrypted files. So this way I can restore the SD backup after a rebuild (I don't recommend restoring the main ROM image, since so much changes between each release).
j
keshen said:
Unfortunately, I was also unaware of this. I presumed MS would use a key based on the hardware or something like that.
Anyway, is there any way of breaking the encryption and get back the files?
Click to expand...
Click to collapse
Once you hard-reset your device and lose that key, your files are gone, unless you somehow have access to some very very high powered computer systems that can break AES -- and even then it would take several years.
I think the NSA in the US has managed to break AES (that's the rumor I've heard), but it takes quite some time.
j
AES-128 offers a sufficiently large number of possible keys, making an exhaustive search impractical for many decades.Correctly implemented AES-128 is likely to protect against a million dollar budget for at least 50 – 60 years and against individual budgets for at least another 10 years.
But as there are many pitfalls to avoid when encryption is implemented, and keys are generated.
So if the key is easy to guess it doesn’t matter if AES is secure ot not.
Creating good and strong keys is a surprisingly difficult problem and requires careful design when done with a computer. The challenge is that computers are notoriously deterministic, but what is required of a good and strong key is the opposite – unpredictability and randomness.
Provided that the implementation is correct, the security provided reduces to a relatively simple question about how many bits the chosen key, password or pass phrase really corresponds to. Unfortunately this estimate is somewhat difficult to calculate, when the key is not generated by a true random generator.
To make a long story short: if at all then the key generation might be the weak spot...
So i've to realyze that i've lost all the data of mi SD card. That sounds incredible!!, i don't know if i will be able to recover all the changes made.
I installed Mobsync, wich makes me backups of the SD data to avoid SD corruption, but the files are also encrypted on my PC.
WM5torage
I'm curious if anybody has tried turning encryption on, and using WM5torage to transfer files to/from the Hermes. Does it properly encrypt/decrypt the files, or does that work only when using ActiveSync?
-- Joe
My problem is making the device as it was before a firmware upgrade, without being forced to reinstall everything.
Supposedly there are now backup options (from Sprite and SPB) that allow you to restore to a firmware updated device (or even a new device!).
I don't trust those. They vaguely claim that they do that, but we have to wonder how.
Also there are a few programs (a couple of them in here - even one with subscription) that "re-provision" the device. To be honest I find them VERY complex. I think it takes more time to set those up properly than re-install everything (if we talk about 20-30 apps and a normal "firmware update" cycle... I am not talking about people with 400 apps and testing all the custom ROMs 3-4 a week). Even if you set those up properly, they take long time to re-install everything.
I thought about this and the problem is in fact simple:
What possibly changes between firmware updates?
- ROM software
- Auto-installed from ROM software
- Some registry entries (also possibly some removed and some added)
Is that true?
So. The solution I propose is not as "stupid proof" as commercial backup/restore solutions, but I think it is also WAY safer than them. It is also much faster than "re-provisioning" programs.
What is the process to follow:
- Install the program I propose (let's call it "Smarter Upgrader") FIRST before anything else installed on the device (maybe only after the forced provisioning that happens anyway).
- You tell the program to take a "fresh system backup".
- Program makes a nice image of the whole registry.
- Program makes a nice backup of everything without "ROM" attribute from main memory.
- You forget about the program.
- You install everything you need and work with your device normally.
- A new ROM comes up and you want it badly.
- You run the program and command it to take a "pre-upgrade backup".
- Program takes a full registry backup or if it is smart enough, already makes a comparison with first backup and just stores the changes (also detects possible eliminated keys - although this is rare from factory to used non-upgraded device).
- Same for main memory software. Backs up only what shows different (or new) from the time of "fresh system backup". If some ROM software is replaced (as is the case of hotfixes), then it is detected as new (as in "fresh system backup" ROM files were ignored anyway).
- User does the upgrade.
- After the upgrade (and forced provisioning), installs this program first.
- Program is run in mode "post-upgrade, new fresh device" backup ("new fresh device" as this mode will also replace the original "fresh device backup" with a new one).
- This mode will take the full image of the registry.
- Compare this registry with the ORIGINAL "fresh device" registry and the differences it detects are the new or changed keys of the new firmware (correct?).
- Will then compare those "differences" to the "pre-upgrade backup". The program here has many many new keys (from the installs of apps before the upgrade), that will normally RE-ENTER back to the registry and possibly a few keys that are different between ALL THREE: the original registry, the upgraded registry, the pre-upgrade registry. These are normally system related keys that the user (willingly or without knowing) has tweaked while using the device (before upgrade). Here the program should ASK the user what to do (this is why the program I propose is not for the "WM freshman"). For example there is a possibility that a key in 1.43 Leo ROM, sets the screen sensitivity to something, then a tweak program sets this to something else. Then new ROM has a different default value. Here the user will decide if he wants to follow the new ROM default or his tweak. I don't think this will be for 100 keys. It will be a much smaller job.
- Next the program will do almost the same for main memory software. Will compare "fresh device" with "post-upgrade". If there is anything (non-ROM attribute) different, it is marked as "new ROM default".
- Then system compares this with the "pre-upgrade" backed up main memory software. What is not "new ROM default" and is not already in the device, it is written back on the device.
- For the programs that ARE in "fresh install", ARE marked "new ROM default" (so the new ROM has a new version) AND are in the "pre-upgrade backup" (so user has installed some version manually), system asks. For example (again Leo) has Google Maps, user finds a new version in Google (well this is real example) and new ROM has yet a different one. System asks which to keep. Later if program becomes smarter, it could detect version strings and automatically use the newer one.
- Program performs a general clean up (for example make sure the Start Menu is as the user had it configured before upgrade, or as close as possible - I for one like to make folders and move everything in them) and soft resets.
...after this procedure (that seems long but I doubt is longer than "re-provisioning" and is surely shorter than reinstalling and WAY safer than "ROM upgrade" backup software modes), the device should have the new ROM and the software that was installed before.
Three steps:
- Backup clean device (this is what commercial backup solutions lack so I don't trust them)
- Backup device before upgrade
(upgrade)
- Post-upgrade Process (which also serves as the NEW backup clean device file for further upgrades)
...allow the system to do it's magic during the third step.
BTW as an idea for the concept I propose, SKTracker is a program that half-way goes where I want.
What do you people think?
Hi
I think is a nice idea. I cant understand why other programs dont include it right now. Is a very interesting and useful project. For sure most of us would use it. This days I am very busy but if no one do it I will develop it as soon as I ve time....
Dani
I hope someone can handle this.
I didn't include databases in my analysis, but I am sure we can stuff them somewhere in between...
BTW I also pointed this thread to the SK Software guys... Maybe they could make something (since their software is already halfway there)...
Here is SKKV reply:
Hallo, Nick.
We have quite a long time thinking about it. At this time exist many not solved problems which not allow create high-quality product with this feature.
I hope ever been we will release it.
Click to expand...
Click to collapse
So if someone is up to the task, all yours.
Just thought this might be useful to some of the newer users, a list of what I see as the most commonly asked questions, and some misunderstood terms.
What is the difference between Nand, Haret and SD:
Nand; refers to the devices internal memory, which is NAND Flash memory, and is used to hold what is commonly called 'a ROM'. It is this memory which holds the Operating System, and can be 'Flashed' to change the data on it, once flashed it is persistent in memory, meaning that if you remove all power sources it will not lose this data, this is also known as 'Non-volatile Memory'. Nand Flash refers to a specific type of Flash memory, and gets it's name from the way the memory cells are constructed.
SD; Refers to the MicroSD cards we use in our devices, these are also Nand Flash but typically have slower transfer rates than the Nand Flash we have inside the device. typically used to store data, they can also be used to store the Android OS when used with Haret installs.
Haret; often confused with SD. It actually refers to Haret.exe, which is a program used to launch Linux systems from within another OS, such as Windows Mobile, think of it as a Virtual machine system, which allows users to run another OS. In our case, Haret refers to running Android within WM, it does not replace WM in Nand ROM, it does replace it in RAM however, but only until powered down, after that WM will boot from Nand next time the device is powered on.
What is my Panel Type?:
Panel; This refers to the actual LCD panel hardware, there are 3 types in use on Kaiser, and although Type2 seems most common, there are also Types 1 and 3. When running WM the panel type is autodetected and the correct settings are used for the display, however Android has no autodetect, so we must tell the OS which type we are using at boot, in Haret installs this is done with a line in Default.txt, in Nand it is set in the NBH we use to flash the kernel and other boot files needed to run Android. Display issues such as odd pixel colouration, streaks or lines on the display, white screen when exiting sleep, and other noticeable display issues can usually be cured by changing the panel type.
Other useful terms:
NBH; This is the file extension of a file intended for flashing to Nand, most commonly used to flash WM or Android, it can also be used to flash radio or splash screen.
Bootloader/tricolour screen; Both are the same, it refers to the screen display you get if you hold the camera button, and press power, on this screen are a few useful pieces of information, device type, (e.g KAIS130), SPL version, (e.g SPL-3.29.Hard), in the bottom white area it will say 'serial' or if connected to a PC, 'usb'. Remember to remove the SD card before entering Bootloader mode, as the bootloader also scans the SD for a file called KASIimg.nbh, and will run the updater utility if one is found.
HardSPL; This is a specially designed SPL that allows us to flash the Nand with an NBH file that was not signed by HTC, it also prevents itself from being overwritten, so that it is usually possible to reflash as long as we can get into Bootloader mode, this means we can, ( usually ), recover from a bad/corrupt flash.
Build and ROM; In WM terms, a ROM usually refers to a complete, ready to install, single file NBH, custom version of WM. However with Android we do not use the single file approach, and therefore we do not usually use the term ROM. Build is what we usually call a custom Android install. This is roughly equivalent to the WM 'cooked ROM', since each build is designed and built in a particular way, and may be any of the different android 'flavours'.
Flavours; Mostly used to describe the versions of android, these are, in historical order
1.1 - un-named, released feb 2009
1.5 - Cupcake, released april 2009
1.6 - Donut, released sept 2009
2.0/2.1 - Eclair, released as 2.0, oct 2009, and as 2.1, Jan 2010
2.2 - Froyo, released may 2010
3.0 - Gingerbread, scheduled release date, sep-dec 2010.
Odex'ed: As stock, android builds are odex'ed. Odexing involves generating an odex file for each app, which slightly lowers the memory used by the system, and may also speed up execution of apps, the downside is that it is difficult to modify odexed builds in order to tweak or theme them.
DeOdex'ed: a deodexed build is one in which the odex files are moved into the apk's, which slightly increases the memory used by /system, but allows modifications and tweaks to be used.
Deodex Vs Odex: Odex uses less space in /system, boots quicker, especially the initial boot after installation, however themeing is impossible, and various tweaks and modifications probably won't work. Deodexed uses more space in /system, has a slower initial boot, subsequent boots are much quicker, but may be a little slower than odexed, theming is a lot easier, as are modifications and tweaking of the build. ( most custom builds are deodexed due to the ease of theming and modifying ).
Bootsplash/Bootanimation:
The bootsplash is the static picture that appears as soon as you boot the device, usually is stays for 20 seconds or so before being replaced by the scrolling text showing Linux is booting.
The Bootanimation is the animated screen you see after Linux has booted, and usually loops until Android is loaded.
Sim Pin/SIM lock:
SIM Pin is often confused with the SIM lock, the SIM pin is the code you have to enter before using the phone when you start it up, this code is stored on the SIM card itself, and until recently caused a lot of problems, since Android could not decode it properly, this has been fixed in some flavours, Eclair and Froyo, but is still an issue in older flavours, such as Donut.
Sim lock also known as provider lock is a method used my phone service providers to ensure that you only use their service by locking the phone so that it only accepts that providers SIM cards, this lock code is stored on the phone, and may be unlocked by entering a code, or by bypassing it using unlocking software, once unlocked the phone will accept any other providers SIM card.
PUK the PUK is the Personal Unlock Code, and is a code that unblocks a SIM that has been blocked by too many unsuccessful attempts to enter the Sim Pin code, ( usually 3 attempts), this code must be entered to unblock the SIM card, usually the PUK is provided with the SIM Card, however if it is lost then some providers may give you the code, if the SIM has been registered by you.
Please feel free to add to this
Back to Windows Mobile:
If you need to reflash Windows Mobile, for whatever reason, these are my preferred methods:
I recommend using a Card Reader and MicroSD adaptor for working with SD cards, it makes life so much easier than relying on the kaiser to transfer and rename files, since most of us are used to handling files in Windows.
Method 1
1. Download a Stock shipped ROM, do not go crazy getting the latest custom 6.5 ROM, in my experience these often cause problems, if you want to go to Custom ROM's then flash stock first.
2. Extract the RUU_Signed.NBH file from the .exe, ( I use 7zip for this, but other archive utilities my work, winzip, winrar etc), rename the file to KAISimg.nbh and copy to the root of a freshly formatted SD card.
3. Insert the SD card in your Kaiser, pres and hold camera button while pressing power, ( you only need to press power briefly, but keep the camera button pressed until you see the tricoloured screen).
4. Once you get the tricolour screen, ( bootloader ), it should change to a grey screen with blue instructions, basically, press the power button and let it flash.
5. Once flashed, simply pull the battery/press reset and let it go through the first boot process.
Troubleshooting
Common problems with this method are that it will just not recognise the flash file, leaving you at the bootloader screen, this is usually caused by wrongly formatted sd cards, the card must be formatted FAT32. Other reasons are file name issues, make sure you have not accidentally mistyped the filename, or renamed it as kaisimg.nbh.nbh.
Method 2:
If Method 1 fails then the alternative method is USB flashing:
1. Disable Activesync, by unchecking the 'USB' option in Connection settings.
2. Remove the SD and SIM cards from the Kaiser.
3. Press Camera+Power to enter Bootloader.
4 Connect the usb cable, ensure that is says 'USB' at the bottom of the screen.
5. Flash the Stock ROM, usually by double clicking the downloaded stock ROM exe file, allow it to flash, and wait until it is finished before removing the USB Cable.
Troubleshooting
There are a few potential issues with this method also, if this method fails try another stock rom, the last shipped ROM from HTC was Kaiser_HTC_ASIA_HK_WWE_3.34.721.2, this is a generic stock 6.1 rom and should be compatible with most if not all kaiser variants.
Useful Links:
ThoughtlessKyle's Why my Wifi doesn't Work Invaluable Information on recent WiFi Issues, A 'Must Read'......
LCD Panel Information
Tinboot thread ( the thread that launched Nand flashing on kaiser ).
SuperJMN's Android Issues roundup thread ( common problems, as yet unsolved )
Adding language support
Miscellaneous Notes.
Radio Version
Just as in Windows Mobile, Radio Version seems to play as vital a role on Android.
There are a number of problems that may be related to radio version, and just as in WM, the effects are sometimes surprising.
Audio: yes, just like WM the wrong radio version can cause audio issues, ranging from no audio, to more subtle issues such as call audio not working, even though all other audio events work fine.
Wifi: no surprise really, the radio stack controls wifi as well as the more common phone/network activities.
Data/Network: Obvious one, but there are a number of complicating factors here too, geographical location seems to affect radio version, for instance, in the USA, 1.71 radios may offer the best signal, and data rates, while in Europe, using 1.71 may cause a lot of 'No Signal' issues, where the phone seems to drop off the network, the solution is usually an older radio version, in the UK 1.65 seems the best choice for most users, I have also had reports of 1.65 being the best for South Africa, Asis, while Australia seems to do better on 1.70 or 1.71. This may be due to the technology in use in those countries.
GPS Maybe, not sure about this one, had at least one report that a radio downgrade from 1.71 to 1.65 seemed to help with GPS, as far as I am aware the GPS and the Radio stack are not related, but who knows for sure?
Great guide! I was thinking about making similar one myself, but couldn't find free time
I'll maybe try to add something this weekend
hello maybe a stupid question
what is the differents between odex and unodex
sorry for my bad english
kisses
Rose
Not sure if this is a general dumb newbie question but I'm having it across different Android builds. Occasionally I have to reset the phone without shutting Android down. When I restart, any apps that were running at the time have to be uninstalled and re-installed because they now crash on startup (with a "program has stopped working" error.) Is there anything I can do about this?
CassandraN said:
Not sure if this is a general dumb newbie question but I'm having it across different Android builds. Occasionally I have to reset the phone without shutting Android down. When I restart, any apps that were running at the time have to be uninstalled and re-installed because they now crash on startup (with a "program has stopped working" error.) Is there anything I can do about this?
Click to expand...
Click to collapse
Not really a dumb question, however it depends how you are resetting, the reset button is a bad idea, Battery Pull is the preferred method, ( say it with me class, 'Battery Pull Good, Reset Button Bad' ).
However, why do you have to reset without shutdown? This often leads to data corruption, since the OS does not get a chance to synchronise properly before it closes, ( not that a battery pull should be any better, but for some reason it seems to cause fewer problems than resets).
Thanks for the FAQ, it is extremely useful to noob or semi-noob like I am.
Thanks, that's why I decided to start it, and if one person finds it useful, it was worth it
say it with me class
Click to expand...
Click to collapse
This is just hilarious
BTW, I tried some of the reboot apps in the market, non of them seemed to work (on 2.1)
the original reboot menu that you get when you hold the power button did not work at all. it just hangs on the loading circle.
In Froyo however, things are a bit different. the reboot option shuts downs the device instead, I did not try any reboot app yet
Any ideas about this zenity?
zenity said:
Not really a dumb question, however it depends how you are resetting, the reset button is a bad idea, Battery Pull is the preferred method, ( say it with me class, 'Battery Pull Good, Reset Button Bad' ).
However, why do you have to reset without shutdown? This often leads to data corruption, since the OS does not get a chance to synchronise properly before it closes, ( not that a battery pull should be any better, but for some reason it seems to cause fewer problems than resets).
Click to expand...
Click to collapse
I usually battery pull (I lost my stylus and the cheap replacement won't fit in the reset hole ), but I still seem to have problems.
I think my problems are due to a rogue app eating all the CPU. My suspicions are Twitter or Swiftkey. The phone becomes so unresponsive that sometimes a hard reset is the only way to make it useable again. I'll try to avoid it in future if I possibly can.
Tried taskiller? Useful for watching your memory, and killing tasks if needed, osmonitor is also useful for, well monitoring the os
I have noticed that the system does get very unresponsive at times, and it usually means low memory, try an eclair build if you are using a CM6 based one, I usually get about 30+Mb free in normal conditions, and if things start to get too slow, well a tap on the taskiller widget sorts that out
@Duke911:
As far as I am aware there is no real reboot option, in any build, I think it's a kernel issue, or perhaps just not implemented correctly, the safest option is a power off, which performs a proper shutdown, I do know there have been a few issues with data corruption that may be associated with using reboot, or the reset button, since these may cause the system to shutdown to rapidly to sync any data that may be cached, it's similar to pulling an SD card out of the computer, there may be data left unwritten in cache, which is why there is a nice safe removal option
This is a cool wiki for Kaiser Android users! Thank you!
By OP request, I am making this thread a sticky and making some adjustments to the forum. Please PM me if you have any requests. Thanks.
Precious work, Zenity!!!
video call anyone?
Is there any chance of getting a build to support video calling?
Video calling will need working front camera driver at least, which is not supported yet, I do not know if anyone is actively working on this, however, at some time, someone will take up this challenge, just as they have with other things which did not work previously
Sent from my HTC Dream using Tapatalk
hello..
I just want to ask about polymod and cyanogenmod.
what is the function, are they different from eclair or froyo?
thanks ^^
CyanogenMod builds are all Modifications of base android releases, these are complete rebuilds of the system, and include many improvements over the original release.
Polymod is an Eclair Mod based on OpenEclair 1.3 and is modded in a different way to Cyanogen's methods and style.
Most Eclair and Froyo builds are ports and modifications of Cyanogen bases, ( in fact I don't think there are any Froyo builds that are not CM6 based).
For Donut things are different, most builds are modifications and ports of official releases, such as Myn's Warm Donut.
Hi there,
I'm programming something for Windows Mobile 2003. It basically removes and creates files around. One of the files it deletes is special file.reg, which is normally picked up during the hard-reset.
The file gets deleted using "DeleteFile" and very soon after, I force a hard-reset.
The problem is, the special file.reg is deleted from the file system tree, but it is apparently still available from the hard-reset.
I was wondering if there was another function I had to call to "flush" the file system? If not, I need to find a good trick to 1) enforce the file deletion (like rename first, then delete) and to 2) flush current ghost files left around.
The file system on those persistent drives are fat12 and/or fat16.
Thanks in advance for any input,
Simon
The hard reset returns the machine to its first power up state. If 'file.reg' was part of the original build, then the hard reset will restore it from ROM.
Also any programs you have installed to run on startup, will also be lost, so it is going to be a little difficult, if not impossible, to get rid of this file programatically.
Right, but I'm not talking about the ROM.
I'm talking about the persistent memory which are mounted as \Platform and \Application on this device. Those are FAT12 and/or FAT16, and files deleted (normally) do not come back.
In this case, the files are not coming back, they are not hidden either, but the hardreset process is able to pick them up somehow.
I mean, I call it the problem of the "Ghost files", because they are supposed to be nowhere, but they are found during during the hardreset.
(The files are not recreated, they are still not there, but their contents gets loaded. The info in them cannot be placed in ROM as it contains stuff that changes often)
They come back after a hard reset because during cold boot, they're being copied there from the rom or being created by the system. You may be able to delete them afterwards, but the only way to prevent them from being formed will be to re-cook the rom and stop them from being copied/created during boot-up.
The files DO NOT come back, it's gone, I cannot re-delete it. But somehow it is "read" by a program during the hard-reset.
This file is not part of the ROM, it's part of the persistent memory that doesn't get wiped out upon hardreset but is read-write.
I need to wipe out the ghost file that is stuck on the read/write partition... and I need a way to avoid these being created!
I understand that, but clearly the file is being created (or copied from rom) during cold re-boot, otherwise you wouldn't see it coming back. There isn't going to be any easy way to prevent that, unless you can re-cook the rom, or include some sort of user customization that would delete the files prior to using the device. There are lots of ways that the rom could create the files and put them onto persistant storage.
Hi Farmer Ted,
this is not a ROM issue, recooking the ROM will not help. The problem is a FAT12 or FAT16 filesystem that has bogus data in it.
The problem is most likely a bug in the program that reads the persistent folders... It probably reads it in a way that goes around the change made by DeleteFile()...
Changing that program is not possible (in ROM and I don't have the source, it's also necessary). I just need to make sure it can't find the file I've deleted on the persistent directory (not in ROM).
I haven't found anything on the forums about this (I have searched) so forgive me if it's a basic question. Is it possible to either:
1) Dump all data on a mango phone (in my case, a Samsung Focus, no interop-unlock) to a file on my computer, or alternatively
2) Access the data stored in the umpteen files created during a WP7 backup.
If anyone knows how to do either of these things (without interop unlocking -- I have data I need to pull off, but my firmware is too old to get interop unlocked, and I get error messages when I try to manually update the firmware), it would be greatly appreciated.
Thanks,
Beakin
Note: edited to clarify
I doubt it's even possible *with* interop-unlock.
1) A native app could map a large region of memory, but the WinCE kernel uses process isolation (same as every other modern OS) so there's no way for one app to access the full physical memory.
2) They're encrypted with a key that appears to be stored in the device itself. Nobody has yet figured out how to reverse this encryption.
GoodDayToDie said:
I doubt it's even possible *with* interop-unlock.
1) A native app could map a large region of memory, but the WinCE kernel uses process isolation (same as every other modern OS) so there's no way for one app to access the full physical memory.
2) They're encrypted with a key that appears to be stored in the device itself. Nobody has yet figured out how to reverse this encryption.
Click to expand...
Click to collapse
On #1, I should have been more specific -- I meant dump the phone's storage; what's in non-volatile memory, not RAM.
Still no without interop-unlock, then - standard apps don't have the privileges to access the filesystem (aside from a few very specific locations, like their isolated storage folder). That probalby means no access to the storage device itself either, although I admit to not knowing how that works on CE (NT or Linux, but that's it). If the app was initially sideloaded you can use the Isolated Storage Explorer to pull files from that app specifically, but if it's a marketplace app or something built-in like the SMS store, no such luck.
Of course, you can get more permissions if you can call into a driver - which is what ID_CAP_INTEROPSERVICES allows you to do, and ID_CAP_INTEROPSERVICES is why you need interop-unlock. I'd suggest you focus on figuring out why you can't interop-unlock and fixing that. Unfortunately I can't really help you there; I don't have a Samsung phone and the steps to IU an HTC phone are very different.
GoodDayToDie said:
Still no without interop-unlock, then - standard apps don't have the privileges to access the filesystem (aside from a few very specific locations, like their isolated storage folder). That probalby means no access to the storage device itself either, although I admit to not knowing how that works on CE (NT or Linux, but that's it). If the app was initially sideloaded you can use the Isolated Storage Explorer to pull files from that app specifically, but if it's a marketplace app or something built-in like the SMS store, no such luck.
Of course, you can get more permissions if you can call into a driver - which is what ID_CAP_INTEROPSERVICES allows you to do, and ID_CAP_INTEROPSERVICES is why you need interop-unlock. I'd suggest you focus on figuring out why you can't interop-unlock and fixing that. Unfortunately I can't really help you there; I don't have a Samsung phone and the steps to IU an HTC phone are very different.
Click to expand...
Click to collapse
Thanks for the clarification. I've spent the last month trying to figure out how to get the interop unlock working on my phone to no avail, which is why I was changing tact by asking this. Oh well, back to the old drawing board.
BTW if you or anyone know how to take a windows phone firmware CAB file and alter it (removing items) I'd appreciate it. My problem with updating the firmware is that I get a "file name conflict" error pointing to specific items in the CAB. At the risk of bricking my phone, at this point I'd try removing those items and installing it anyway.
Editing a CAB is easy; Win7 Explorer can open them natively and many third-party tools also exist. Editing a CAB so that it can still be isntalled may take a little bit more effort, but the important point is that as soon as you edit it, you'll invalidate the signature on the CAB. That means it will no longer install through the default update-OS at all. On HTC phones, you can use RSPL (or HSPL) to install custom updates, but on a phone with a retail bootloader (such as a Samsung), you can only install official updates.