Related
Current version: !IMEIme 2.2.0.4
Bug Fix
Fixed bug in use previous patch that could result in variable used before declared error.
Changed processing order when custom patches were to be used
The program will now process custom patches prior to editing framework.jar and build.prop edits. With new kernel patches requiring a new build.prop users would lose build.prop edits if the kernel was included in custom patches, the program will now patch any user modifications, then process IMEI generation and build.prop edits.
Updated to work with ROMs that do not include GSMPhone.smali
Recently, many ROMs are not including GSM phone utilities in framework.jar. I have added testing for missing GSMPhone.smali and patching via TelephonyManager.smali if necessary.
UPDATED FILES UPLOADED
MANY of the support files have been updated to the newer versions (smali, baksmali, adb and components).
I encourage you to delete all files in your existing IMEI Generator folder and use the new !IMEIMe.exe to generate the files necessary.
The devices.dat file if you've used the previous version has several issues that prevents the device model from being correctly patched on many of the devices. This has been fixed here and in the device list thread.
There is a known issue with the GUI when your screen settings are set at 125% in Control Panel - Appearance and Personalization - Display... I will work on fixing that in the next release.
Bug reporting thread for !IMEIme
Device list thread
New features:
Will patch GSMPhone.smali if present in framework... patches TelephonyManager.smali otherwise.
I chose this method since more ROMs are coming out for wifi tablets that do not have GSM phone information included in framework.jar. I was playing with CM10.1 and discovered GSMPhone.smali is not present, thus I was getting unable to patch GSMPhone.smali error, and there was no patching for an IMEI. In all honesty... this should be irrelevent, since IMEI is only utilized in cellular communications on GSM phones... however... some applications MAY (xda free does) require an IMEI to work, even on wifi only devices.
ODEX files still in the works
odex file support... I think this solution will work on odex file systems as long as the patching is done on the ROM prior to flashing to device (anyone using odexed system please let us know) and I am working on in place patching on odexed systems... however, I am not completely comfortable since there is a lot of work done by the device itself during odexing of the modified files... I am very hesitant since any mistake could render a bricked device and I don't have a system to test with prior to release.
Previous Important Changes
The new version of the IMEI Generator will no longer overwrite your existing devices.dat file with the current. To use new devices.dat file, delete the old one prior to running the program, or download the new one and unzip it in the IMEI Generator directory.
Device Communications not necessary in certain situations
If you select to Update ROM, using Serial Number based IMEI and do not select Encrypt IMEI, the program will no longer need to communicate with the device when performing its tasks. The framework.jar patch will not hard patch the IMEI in this situation as before. This is useful for patching a ROM for distribution to multiple people, since they will all maintain unique IMEI's. This is accomplished with the following change in the framework.jar
Code:
/com/android/internal/telephony/gsm/GSMPhone.smali
.method public getDeviceId()Ljava/lang/String;
[b]changed[/b] iget-object v0, p0, Lcom/android/internal/telephony/gsm/GSMPhone;->mImei:Ljava/lang/String;
[b]to[/b] sget-object v1, Landroid/os/Build;->SERIAL:Ljava/lang/String;
prior to patching in code to prepend "0"
.method public getDeviceSvn()Ljava/lang/String;
[b]changed[/b] iget-object v0, p0, Lcom/android/internal/telephony/gsm/GSMPhone;->mImeiSv:Ljava/lang/String;
[b]to[/b] sget-object v1, Landroid/os/Build;->SERIAL:Ljava/lang/String;
prior to patching in code to prepend "0"
To try to explain the above a little...
The above is always changed, no matter what IMEI generation method you select...
If you select Serial Number and New Type IMEI and not Encrypt: no other patching is done for the IMEI... this can be implemented on many devices, since each will have a unique serial number.
If you select Serial Number and do not select New Type: additional code is added to format the IMEI to the old standard ("00-" and "-"s)... this can be implemented on many devices for same reason.
If you select MAC Address or Encrypt (or both): additional code is added that results in the IMEI being hard coded, this makes it very much device specific.
If you select MAC Address or Encrypt (or both) and do not select New Type: additional code is added that results in the IMEI being hard coded as well as code to format the IMEI, this makes it very much device specific.
Use Custom Patch NOTE: This is only used when patching a ROM
This is going to take some major explanation, since I ran into so many possible scenarios...
One thing of note... the only additional lines added to updater-script will be for files in the base directory
The order of processing is:
1. Original ROM updater-script and files
2. Custom Patch zip file
3. Custom Patch folder
The program will utilize folders (from Patch zip file or Patch folder itself) named modboot, modsys, or system (not case sensitive in windows) as well as files in the base folder
Any files in modboot will be moved to the root of the **ROM**-IMEI.zip file and lines added to updater-script as needed
Any files in modsys will be moved to the system directory of the **ROM**-IMEI.zip file
If Custom Patch is checked...
/META-INF/com/google/android/updater-script is extracted from the ROM
the program will ask you to select the Custom Patch Folder
If there is a zip file present in the folder the program will ask if you want to use it
You have 3 options, "Yes", "No" or "Cancel"
Yes = Use the zip file
No = Don't use it, select another
Cancel = Don't use a zip file
If you use a zip file, it will extract the zip file and process the updater-script in it for any additional lines needed
After the above, any non-zip files and modboot, modsys and system directories in the Patch Folder will be processed
I chose this order so you can have a "go to" patch zip file, and test other additions by using the file, folder options prior to including them in the zip.
Example here:
I have my custom patches in folder /CM7/UserMods with these contents:
/META-INF
/modboot
/modsys
patch.zip
The program processes patch.zip first, then overwrites any files with the files in modboot and modsys
It also processes /META-INF/com/google/android/updater-script for any lines extracting files to /boot and adds them to the original ROM updater-script if not already there.
It then adds lines for any files originally in /modboot to updater-script to extract them to /boot
"New IMEI Type" of IMEI which no longer has the "-"s in it, but maintain backward compatibility for those who already have IMEI's generated or prefer the old style. When the new type is selected in the GUI:
NOTE: Per the IMEI standards... Using a single 0 prepended to the IMEI indicates a TEST IMEI for a country with 3 digit international code... while it should have no implications to us since we are not on a cell... it may provide potential country validity issues... I will monitor this and resort to 00 prefix in the new type of IMEI if necessary.
ADDITIONAL NOTE: Per the IMEI standards... For devices without an IMEI, they are to provide a unique serial number to be used... This program modifies framework.jar to allow this.
I am now patching framework.jar in the /com/android/internal/telephony/gsm/GSMPhone.smali file instead of /android/telephony/TelephonyManager.smali (this change is what allows the information to display in the about tablet information)
I am renaming and patching 2 functions... getDeviceID() and getDeviceSvn()
By patching the two functions in this file... the IMEI now shows in Settings... About Tablet... Status... no longer have to use external program or dial *#06# to verify the device is patched.
getDeviceID() shows it in IMEI
getDeviceSvn() shows it in IMEI SVN
You can rename or copy !IMEIme.ini to IMEIme.ini and the program will work.... useful for *nix users and probably mac users... since they have issues with special char actors (!)... While I like to use it in windows to keep the executable and ini file at the top of the file list in windows explorer... anyway...
The program looks for IMEIme.ini first and uses it if present... if it is not... it then looks for !IMEIme.ini (which will be there... because the program installs the generic !IMEIme.ini if it isn't ) This also provides a good way to keep your ini.. and see the new settings in the compiled in ini.
GUI selection and related ini setting
GUI: New IMEI Type
INI Setting:
New_Type =
; If 0 then the old type of "00-XXXXXX-YYYYYY-ZZZ" will be used
; If 1 then the new type of "00XXXXXXYYYYYYZZZ" will be used
BUG FIX
No known or reported bugs to work out.
!IMEIme.ini file default settings and explanation:
Code:
;The setting options are 1 (use the option) or 0 (don't use the option)
;WiFi IP Address can be set to your Nook's IP address here to a default to use
;IMEI can be set to a default here... you can also set the seed you use for generation
;Setting Device_Manufacturer to anything will result in an edit to build.prop setting the entered manufacturer
;IF Device_Manufacturer is NOT blank then:
;Setting Manufacturer_Device to anything will result in an edit to build.prop setting the entered device
;
;NOTE: ONLY Device_Manufacturer is necessary for this edit... there have been no software that appears to
; require a device edit
;
;Setting LCD_Density will result in build.prop edit for this setting regardless of Device_Manufacturer setting
;
;Set all options in [Settings] section at the bottom
[Settings_Explained]
Use_In_Place = 1
; If 0 Disable In Place patching... useful for those who always update AOSP ROM files and never patches on device framework.jar
; If 1 Enables In Place patching if ADB is working
Use_Previous_Patch = 0
; If 0 Ignore IMEI.fix
; If 1 AND IMEI.fix exists... use it for patching
Use_Serial_Number = 1
; If 0 then do not base IMEI off of Device Serial Number
; If 1 then base IMEI off of Device Serial Number
; NOTE: This takes priority over Use_MAC_Address
Use_MAC_Address = 0
; If 0 then do not base IMEI off of Device MAC Address
; If 1 then base IMEI off of of DeOvice MAC Address (last 5 hex words) (2 bytes = 1 hex word)
; 0A is converted to 010, FF is converted to 255 etc.
; NOTE: Use_Serial_Number takes priority
Use_Manual_Input = 1
; If 0 then Manual Input disabled
; If 1 then Manual Input enabled
Encrypt_IMEI = 1
; If 0 then uses actual data for IMEI... i.e. Serial Number (last 15 digits) or MAC Address (last 5 hex words) is actual IMEI
; If 1 then program encrypts data for IMEI generation... hiding actual Device data
New_Type = 1
; If 0 then the old type of "00-XXXXXX-YYYYYY-ZZZ" will be used
; If 1 then the new type of "00XXXXXXYYYYYYZZZ" will be used
Use_ADB = 1
; If 0 then ADB is disabled... this will prevent In-Place updating from working all together
; If 1 then ADB is enabled... In-Place will work... IF adb is working on your device
; NOTE: This takes priority over Use_ADB(usb) and Use_ADB(WiFi)
Use_ADB(usb) = 1
; If 0 then ADB via USB connection is disabled... I use this since some ROM's have Debug Mode issues
; If 1 then ADB via USB is enabled and attempted first
; NOTE: Use_ADB takes priority over Use_ADB(usb) and Use_ADB(WiFi)
Use_ADB(WiFi) = 1
; If 0 then ADB via WiFi connection is disabled
; If 1 then ADB via WiFi is enabled... I use this since some ROM's have Debug Mode issues
; NOTE: Use_ADB takes priority over Use_ADB(usb) and Use_ADB(WiFi)
Clean_Up = 1
; If 0 then the program will leave all support files when cleaning up and exiting
; If 1 then the program will delete all support files when cleaning up and exiting if none of them
; existed at program start
Include_Patch = 0
; If 0 then custom patches is disabled
; If 1 then the program will prompt for custom patches to include
Device_Manufacturer =
; If blank then the program will not edit build.prop
; If anything other than blank the program will edit build.prop to include manufacturer
Manufacturer_Device =
; If blank then the program will not include device in build.prop edit
; IF anything other than blank the program will include device in build.prop edit
; NOTE: No build.prop edit will occur if Device_Manufacturer is blank
Device_Model =
; If blank then the program will not include model in build.prop edit
; IF anything other than blank the program will include model in build.prop edit
; NOTE: No build.prop edit will occur if Device_Manufacturer is blank
Build_Fingerprint =
; If blank then the program will not include Build Fingerprint in build.prop edit
; IF anything other than blank the program will include Build Fingerprint in build.prop edit
; NOTE: This edit will occur even if Device_Manufacturer is blank
LCD_Density =
; If blank then the program will not include LCD Density in build.prop edit
; IF anything other than blank the program will include LCD Density in build.prop edit
; NOTE: This edit will occur even if Device_Manufacturer is blank
WiFi_IP_Address =
; You can enter the default Device IP address here... especially useful if you are only using this on one device...
; or if you keep seperate folders for each device you use (!IMEIme.exe and !IMEIme.ini must be in each folder)...
; i.e. folder for "sister" containing the program and ini file at minimum.
; If blank the program will prompt you for the IP address of the device to establish ADB WiFi connection
IMEI =
; Enter a base 10 (integer) and it will be used as the IMEI (duplicated until 15 digits is reached)
; Enter your "seed" and the program will generate an IMEI based off of it
; NOTE: If you try to generate the old GENERIC IMEI the program will not do it
[Settings]
Use_In_Place = 0
Use_Previous_Patch = 0
Use_Serial_Number = 1
Use_MAC_Address = 0
Use_Manual_Input = 1
Encrypt_IMEI = 0
New_Type = 1
Use_IMEI(15) = 0
Use_ADB = 1
Use_ADB(usb) = 1
Use_ADB(WiFi) = 1
Clean_Up = 1
Include_Patch = 1
Device_Manufacturer =
Manufacturer_Device =
Device_Model =
Build_Fingerprint =
LCD_Density =
WiFi_IP_Address =
IMEI =
Credits:
mthe0ry: Credit for the original IMEI patches released for us Nookers(TM). His original thread is here...
martian21: Took mthe0ry's work and maintained it for releases of CM7, upeating it for each nightly that needed a new one. Martian21's thread.
HacDan on irc.freenodes.net #nookcolor for helping me figure out patching GSMphone.smali instead of TelephonyManager.smali
Thank you's:
paleh0rse: I believe was the first to download and test this program... I think the first bug report too... helped many users with suggestions regarding their apps.
mr_fosi: Continues testing and reporting despite no need to. Tested a few private beta builds to help iron out a significant issue. Also providing information regarding Phone App *#06# IMEI test.
martian21: Set the wheels turning. Provides invaluable feedback and suggestions. He is an invaluable tester and Q&A guy. Thanks for dangling that bait
mellopete: Provided the very first bug report... prompted me to include necessary files in the program itself.
TheMainCat, 12paq and frankusb: Provided bug reports leading me to look at why some Windows versions didn't run the program initially.
Nayla1977: Bug report regarding a mistyped EndIf in my source.
jdexheimer: Bug report that lead me to find a problem with folders with spaces in them.
LinuxParadigm: Bug report regarding missmatching If - EndIf's.
BitingChaos: first public post to get me back on target.
dillweed, garrisj and many others: for PM's indicating the importance of this solution.
lemdaddy for reporting the bug that we tracked down to the java version and reporting back that it was the java version causing issues.
adusumilli for reporting the bug where IMEI was generated as "00-cat: c-an't o-pen"
topcaser for being persistent enough with the bug causing In-Place to fail in certain situations.
HacDan on IRC for leading me in the right direction to impliment the patching of GSMphone.smali.
We are all adults, if we break our toys... we only have ourselves to blame and we may have to buy new ones... (this will NOT break your Nook... I PROMISE you that! but it may break some of your apps... more on that later in post)
BUG REPORTING:
This program was initially ineteded to generate a unique IMEI based on your device S/N and update Dev's install zip files... it has become so much more, and as such there are many functions involved in this process.
Due to the complexity the program has taken on... far beyond what I initially intended... to report bugs please try to use the following as a template:
Function attempting: i.e. Updating ROM... In Place Upgrade... Update framwork saved on computer... etc.
Error Messages: any error message you receive... or the last message you saw prior to the issue.
End result: i.e. GSMphone.smali updated, ROM not... GSMphone.smali updated framework.jar not... etc....
Environment: ROM in same folder as IMEIme.exe... ROM on same drive as IMEIme.exe... ROM on different drive... etc. (same for framework if updating framework instead)
!IMEIme.ini settings: you can put your entire ini file if you'd like.
If you could take notes of EXACTLY what which selection in the GUI you have selected and any buttons you click on which prompt it would be EXTREMELY helpful...
As I said, this program has taken on functions I initially had not imagined including... the more features added, the more complex testing and tracking bugs becomes... I don't want to include a bunch of messages just for the sake of letting you know where in the code you are... would not be beneficial to you... more buttons to click for no reason, etc.
The more detailed you can be, the quicker I can see what is happening... otherwise I have to try to duplicate what I think you are doing when you get the error.
mr_fosi and martian21 have been very tedious in reporting bugs... I greatly appreciate their testing despite not needing to, and the manner in which they document what is going on....
Everyone should click "Thanks" on their bug report posts... they have been instrumental in getting the program where it is so far.
Background:
Some developers require a unique number that is supposed to be provided by hardware manufacturers that is unique to every device. This unique number (IMEI) is extremely important in devices utilizing cellular communications.
Since B&N has not registered IMEI numbers for the Nooks, the AOS's we are using do not acquire it as they do in other Android devices.
The developers that require a unique IMEI have been less than receptive of our devices and past methods to provide functionality to utilize their apps.
I decided to provide what I believe to be a viable solution to this problem.
What this program is:
It is a method to provide a unique IMEI (with reasonable certainty) for our Nooks.
It IS intended to be a supplement until IMEI is addressed in dev's ROM's.
It IS viable for Froyo... CM7... CM9... CM10...Honeycomb... MIUI.... AOKP... and others.
I can't think of any reason it will not work with ANY ROM you choose to utilize... if you run across one... just let me know and I'll see if I can't fix that.
What this program is not and does not do:
This is not a perfect solution to our Nook specific issues. Let me make it PERFECTLY CLEAR there is NO PERFECT SOLUTION We are generating an IMEI from something else... I use TEST IMEI patterns based off of our device serial number, to ensure apk devs wouldn't come down on us.
It is not targeting any specific AOS.
It is not guaranteed to be accepted by any other developers.
It is not intended to be the end all, beat all solution.
It is not intended to dissuade other developers from providing what they feel is a better method.
It will not cause any programs to show in the market. That has to be dealt with via APK developers and/or build.prop Manufacturer strings.
Potential issues:
There is NO legitimate solution to the IMEI issue we Nookers (TM) face... unless a group desires to register a block of them for our use... thus I am generating TEST IMEI's... ideal... no, but the only method available to us.
While I feel, with significant certainty, there will be no negative consequences from apk devs in general, I cannot speak for them, or their logic. This can easily be disabled by them again. That is on them, not me or us. By the same token, they can decide to stop providing their service for cause, I still have no control over that.
Above, I emphasize “with reasonable certainty” due to the fact that, in theory, you can wind up with an IMEI that 9 other Nooks that use this software has. That can only happen if the other 9 owners use this program and have a serial number within the same 10 as yours. This is even less likely with the New IMEI Type since it is using the right most 16 digits of a device serial number (and we know they all start with 2)
If everyone who has the same beginning 15 digits utilizes this program to generate an IMEI, you will all wind up with the same IMEI. Given the number of Nooks out there compared to the number of user's hacking them.... I find it extremely difficult to believe, with a reasonable certainty, that any 2 (much less 10) devices would ever wind up with the same IMEI generated by this program. This is prevented when using the New IMEI Type
What this program does/is capable of:
It allows you to extract framework.jar from a developers update zip file.
It will allow you to pull framework.jar from your Nook or use an existing framework.jar already stored on your computer.
It will generate an IMEI based on your Nook's serial number (or MAC Address) if adb is working on your system. If you have issues running adb via USB (ADB(USB)), it provides the opportunity to utilize adb via WiFi (ADB(WiFi)) for any computer-device communications.
It will provide you a method to manually input your serial number if you cannot connect to the device via adb. You can also input a “seed” (easy to remember word or phrase) and generate an IMEI based on the ASCII codes of the text you enter.
It will edit /com/android/internal/telephony/gsm/GSMPhone.smali to rename any existing getDeviceId() and getDeviceSvn() function to getDeviceId2() getDeviceSvn2() and append the patch to end of that file. NOTE: When the program "smali's" the resulting GSMphone.smali... it relocates the appended function to be before the renamed function.
It will save the patch as IMEI.fix, thus allowing you to utilize it for subsequent runs of the program. A caveat to this is... if you run it from the same folder on a friend's Nook... it will overwrite your original one if it is in the same folder or they will have the same IMEI as you do if you use Previous Run.
It will offer to push the patched framework.jar to your Nook... IF you opted to pull framework.jar from your Nook AND adb successfully worked to do that. This facilates in place upgrading.
It will backup the existing developers zip file appending “-IMEI” to it, distinguishing it is one this program has been used on. It will update this file, not the original developers file.
If there are issues with file names that become duplicate in a case insensitive OS such that windows is, it will warn you of this case and not remove the updated framework.jar to facilitate manual updating of the zip file.
Caveats:
This program is known to work on Java version 1.6.0_23 and known NOT to work on version 1.6.0_17 or earlier. If your system seems to work fine... but the nook does not give you an IMEI number... check your java version by typing this in a DOS window (start-run and type in cmd):
java -version
this will tell you the version of java you are running.
Java must be on your system. It must be in your system's path statement, or this program must be in the java/bin folder. It is possible that you must have java 32 bit version, this is being researched.
It will very likely break your swype, or any other app that utilizes IMEI for validation and you have used previous methods to circumvent their validation process.
It will likely break the same software if/when developers include a fix to the Nook IMEI situation in their AOS. Unless you opt to use this method again on their AOS to ensure you maintain the IMEI you used my program to generate.
Since I have opted to utilize test formed IMEI's to prevent duplicating someone's “real device” IMEI, software developers can easily shut us down again. That is their option. I am trying to provide a solution that is acceptable to both sides of the fence.
Closing statement:
As I desire to make this program as beneficial as possible... PLEASE provide any feedback and/or bug reports... just don't continue to push your ideals once it has been discussed... beating dead horses gets tiresome and just wastes precious time.
112 downloads of 2.2.0.3 with bug when pervious fix was selected
1686 downloads of 2.2.0.2 with no bugs reported
141 downloads of 2.2.0.1 with CM10 in place bug that would cause BBSOB and never boot
197 downloads of 2.2.0.0 (that actually appeared to be 2.1.0.4 in the zip) with a few minor bugs... mostly in custom patching
648 downloads of 2.1.0.3 with known GT for GameLoft issues
1123 downloads of 2.1 with no known bugs
182 downloads of 2.0a with a Generic IMEI bug
1919 downloads of 1.9 with no bug reports
3131 downloads of 1.8 with all bug reports being for non-nook devices
80 downloads of 1.7 with no bug reports
600 downloads of 1.6 with a couple of reports of In-Place update bug
880 downloads of 1.5a with 0 bug reports
148 downloads of 1.5 with a bug that could result in IMEI being generated without being properly formed.
36 downloads of 1.4 with a bug that could result in IMEI of "cat: can't open".
258 downloads of 1.3 with 0 bug reports... time to move on with next feature.
1618 downloads of 1.1 and the only bug noted has been tracked to the user's Java version.
12,758 downloads prior to the current version.
Bug reporting thread for !IMEIme
Device list thread
Looks like I have something new to mess with tomorrow night... thanks for working this, we owe ya!
Been looking forward to this! Thanks for your hard work DizzyDen.
Tested it out however it isn't finding 7zip. I've tried both the 64-bit and the 32-bit version (on 64-bit Windows 7). I'm probably doing something wrong if so please feel free to enlighten me
Martian21
martian21 said:
Been looking forward to this! Thanks for your hard work DizzyDen.
Tested it out however it isn't finding 7zip. I've tried both the 64-bit and the 32-bit version (on 64-bit Windows 7). I'm probably doing something wrong if so please feel free to enlighten me
Martian21
Click to expand...
Click to collapse
It wasn't you... there's something weird with the API to the fileopendialog that changes the working directory... a TEMPORARY work around is to copy the zip file to the folder you are running the program from.
Updating to beta 2 to auto extract support files on run.
Beta 2 is up... OP updated... note the bold text... for now the zip file must be in the same folder as IMEIme.exe
That will be fixed shortly.
Updated to beta 3. OP updated.
Fixed file browse for update file.
Improved cleanup behind itself before exiting...
removes helper files
removes framework.jar
removes classes.dex
removes out folder
removes system folder (the one used to add framework.jar to the zip file)
Still debating ability to allow manual input of the IMEI or a serial number... but those that want to do it will probably figure out how to do it manually... its REALLY not that hard.
Will add random IMEI generation as an option. The only purpose I see for this is for those who don't want to use the generic IMEI and cannot get adb working... even with the included adb in this program.
Feedback and bug reports are welcome and will help improve the program.
Thank you for this
I had to copy my AdbWinApi.dll for it to work. It did not put the new framework.jar in the zip though. It made the files, but didn't update the zip. I moved it to the root of my drive and ran it as administrator, but it still didn't update the zip. I am using Windows 7 x64. I used the IMEI.fix file and updated the zip myself. Thanks again for this nice tool.
mellopete said:
I had to copy my AdbWinApi.dll for it to work. It did not put the new framework.jar in the zip though. It made the files, but didn't update the zip. I moved it to the root of my drive and ran it as administrator, but it still didn't update the zip. I am using Windows 7 x64. I used the IMEI.fix file and updated the zip myself. Thanks again for this nice tool.
Click to expand...
Click to collapse
Did you use something prior to b3 ?
There was an issue I discovered that was preventing appending IMEI.fix to TelephoneProvider.smali that was fixed in b3.
I did my development on windows64 so that shouldn't be an issue.
As for the dll... I hadn't experience issues with that... but I can certainly add it to the program.
Both adb dll's will be included in all releases after b3.
Good job!
Can you explain more about how rom is being affected?and what to check?
Sent from my phiremod for Nook using Tapatalk
DizzyDen said:
Did you use something prior to b3 ?
There was an issue I discovered that was preventing appending IMEI.fix to TelephoneProvider.smali that was fixed in b3.
I did my development on windows64 so that shouldn't be an issue.
As for the dll... I hadn't experience issues with that... but I can certainly add it to the program.
Both adb dll's will be included in all releases after b3.
Click to expand...
Click to collapse
b3 is the first one I tried. I didn't look at the classes.dex before it was deleted. I will check.
RASTAVIPER said:
Good job!
Can you explain more about how rom is being affected?and what to check?
Sent from my phiremod for Nook using Tapatalk
Click to expand...
Click to collapse
Read here http://forum.xda-developers.com/showthread.php?t=1004102
TelephonyManager.smali did not change.
mellopete said:
TelephonyManager.smali did not change.
Click to expand...
Click to collapse
Please make sure b3 is the one you are using. When you originally posted... the thread was showing 0 downloads of that file.... or just wait a few minutes... beta 4 is on its way shortly.
To ensure TelephonyManager.smali is not changed you need to look in two places.... the easiest way is to search for getDeviceID
If it worked correctly you should find 2 instances... the first is the original function and my program renames it to getDeviceID2()... the second should be the one !IMEMe adds to the end of TelephonyManager.smali
Additionally... could you check and see if your run is actually overwriting update zip file.... see if there is a update ".zip.tmp" file left over... if it is there... the zipping is running into an issue overwriting the original file... I thought I had that issue worked out... but may need to add a check for that within my program.
I d/l b4, dropped it in a directory with just the .zip for n87 and ran it (win7 pro 64-bit). It errored out and here's the play-by-play of each of the windows which popped up one immediately after the other:
- I was warned about you being an unverified software publisher, which I OKed.
- "Windows cannot find 'java'. Make sure you typed the name correctly, and then try again." I OKed this one as well.
- window titled "DizzyDen's IMEI Generator" containing: "Return Code is:0 and Error Code is: 1"
- window titled "DizzyDen's IMEI Generator" containing: "Java is required on your system. You can download the current version from http://java.com"
I have JRE6 on my machine, though it is not in the system PATH.
Oh, and there were files for 7za, adb, .dll's and .jar files left behind.
mr_fosi said:
I d/l b4, dropped it in a directory with just the .zip for n87 and ran it (win7 pro 64-bit). It errored out and here's the play-by-play of each of the windows which popped up one immediately after the other:
- I was warned about you being an unverified software publisher, which I OKed.
- "Windows cannot find 'java'. Make sure you typed the name correctly, and then try again." I OKed this one as well.
- window titled "DizzyDen's IMEI Generator" containing: "Return Code is:0 and Error Code is: 1"
- window titled "DizzyDen's IMEI Generator" containing: "Java is required on your system. You can download the current version from http://java.com"
I have JRE6 on my machine, though it is not in the system PATH.
Oh, and there were files for 7za, adb, .dll's and .jar files left behind.
Click to expand...
Click to collapse
java will need to be in your path... I have no way of including all possible locations of where it could be installed... and it is way too big to include with my program.
The left over files is due to the program exiting when it did... I will fix that in next beta... should have waited until java was tested to extract them... or have it perform cleanup before exiting on any errors... sorry bout that.... you can leave them... when you have successful run (or run beta 5 or later) it will clean them up.
For now you may have to run as administrator.... I will try to add code to avoid this in the short future.
BTW. Nowhere does getDeviceID does it say that it must be a well formed IMEI.
nemith said:
BTW. Nowhere does getDeviceID does it say that it must be a well formed IMEI.
Click to expand...
Click to collapse
As much as I admire your work... I am honored that you are even checking this out.
I do understand that as of now it is not required... but I figure if I utilize standards (as much as there are anyway) we may avoid future issues if dev's start checking for well formed IMEI's.
I figure if I'm going to make this... I might as well make it right.
As far as I can determine... if a sw dev implemented IMEI checks, the only thing that could cause them to shut down someone using this would be to check that it is a "TEST" IMEI... but I don't see that happening, because hardware manufacturers do use these in testing.
DizzyDen said:
java will need to be in your path... I have no way of including all possible locations of where it could be installed... and it is way too big to include with my program.
Click to expand...
Click to collapse
Roger that. Should the instructions then note either the required change to PATH or that the file must be run in the user's jre#\bin directory?
DizzyDen said:
The left over files is due to the program exiting when it did... I will fix that in next beta...
Click to expand...
Click to collapse
I figured as much, but thought you should know.
DizzyDen said:
For now you may have to run as administrator...
Click to expand...
Click to collapse
I ran it this way and got the same behavior.
I'll keep a lookout for further versions, test them and report.
Beta 5 is up... OP updated to include Java requirements... thank you mr_fosi for pointing this out.
RASTAVIPER said:
Good job!
Can you explain more about how rom is being affected?and what to check?
Sent from my phiremod for Nook using Tapatalk
Click to expand...
Click to collapse
Did you find the information in the thread linked in response to your questions?
TY mellopete for that.
- Plugged NC into USB port.
- Copied new B5 exe and n87 zip to java\jre6\bin directory.
- Ran exe as admin.
- Prompted for .zip check ("is this correct") and it was, so I OKed it. Not OKing it gave me the option to browse for the file, which I cancelled, resulting in a termination of the prog with a few more dialogs. Any extracted files were cleaned up an prog close, except for adb.exe (which I deal with below).
- Re-ran, exe, chose the detected n87 .zip.
- Displayed correct serial.
- Displayed correct generated 17-digit IMEI.
- Dialog contents "Modifying" gave error "Unable to open file", which I OKed.
- Several more dialogs flew by in rapid succession without error, ending with "Updating ROM" overlaid by "Updated ROM file has been saved as: cm_encore_full-87-IMEI.zip".
- Not all ancillary files were cleaned up. Two files remained: 1) IMEI.fix, a plain txt file containing the correct code to insert the generated IMEI and 2)adb.exe which could not be removed because it was still running the devices server. Running "adb kill-server" in the java\jre6\bin directory allowed me to remove adb.exe.
- A check of the modified smali showed only one instance of "getDeviceId" indicating that the smali had not been modified to add the code to spoof the IMEI.
I would also not have been able to eject my NC, had I tried, until I killed the adb server. Looks like one more line of code to add before cleanup.
[SOLVED, see 2011/11/14 update]
Anyone has experience in restore history successfully in Whatsapp?
I have a backup file named "msgstore.db.crypt" in the Whatsapp folder in SD card.
After I reset the phone and install back the WhatsApp, it will prompt me whether I want to restore History.
After I clicked "Yes", there is a loading bar form 0% to 100%. However, nothing was restored except the group name...
I traced back and send the log to my own gmail.
I found the following things...
msgstore/restore/backupfiles msgstore.db.crypt (597008)
msgstore/restore/copy msgstore.db.crypt 597008
msgstore/restore/ioerror java.io.IOException: File.renameTo failed
After discussed with WhatsApp CS, they also have no idea how to solve this.
Their reply is "it's not letting the app write into the internal storage properly."
and the target internal storage location should be "/data/data/com.whatsapp/databases/"
Anyone have same situation ??
Updates: 2011/11/13
Finally figured out one possible reason with the help from Titanium Backup Team, currently /data/data/com.whatsapp/database/ is linked to /firstboot/sqlite/com.whatsapp/.
I try a simple copy of the folder "/data/data/com.whatsapp/" to SDcard , the database folder is not copied, possibly some permission issue..
So even titanium backup also failed to backup the database folder.
But i tried manually copy those db files to SDcard, it succeeds. Strange....
Updates: 2011/11/14
Dxmn i did it!!After two months of contacting WhatsApp support and Titanium Backup Team, and study the ROM structure of Android.
Finally can restore the backup file successfully problems-free!!!!
OK! Time to consolidate what i found in this two months....
Problem:
1. Failed to restore whatsapp history file "msgstore.db.crypt", only in Dell Streak, but succeed in other device (i tried Atrix, IDEOS and Galaxy Tab, they all succeed in restoring this file)
Symptoms:
1.
For a normal procedure:
i. Install whatsapp from market
ii. register my phone no.
iii. receive sms from whatsapp
iv. my number is activated
v. If there is msgstore.db.crypt or msgstore-yyyy-mm-dd.x.db[within 7 days] in \sdcard\WhatsApp\Databases\ , Whatsapp will ask if you want to restore history.
vi. After you say yes, the app will restore all your history.
HOWEVER, in my case, step vi will still prompt but it loads up to 10-15% , it will suddenly become 100%, and... you will see NOTHING in your whatsapp except your joined group name (which store in server).....
2.
In whatsapp, after failed to restore history, "Menu" > "Settings" > "More" > "Report a problem", enter something and click "Next" > select your email app > change to "To:" to your own email.
In the log file inside, you should see a line "msgstore/restore/ioerror java.io.IOException: File.renameTo failed"
3.
By using Root Explorer, look for the \data\data\com.whatsapp, there should be a folder "databases", select the property of this folder. It is linked to \firstboot\sqlite\com.whatsapp\.
Solutions:
If you match the above symptoms, i guess the following steps may help you!~
Suppose you are now using a phone, where whatsapp is not installed.
1. Make sure you have msgstore.db.crypt or msgstore-yyyy-mm-dd.x.db[within 7 days] in \sdcard\WhatsApp\Databases\ and DO A BACKUP OF IT
2. Install Whatsapp from market
3. Just after finished installation, open RootExplorer, go to \data\data\com.whatsapp, you should see "databases" is linked to "\firstboot\sqlite\com.whatsapp\" if you check its property
4. Check the owner of the folder "databases" by select "Owner" of this folder in RootExplorer.It should be something like "App-xx"(xx is app id)
5. rename the "databases" folder to "databases-firstboot"
6. create a folder using Root Explorer named "databases", and set its owner to the previous App-xx
7. Just open whatsapp and follow the normal procedure, the db files will be stored in \data\data\com.whatsapp\databases\
8. [i didnt do this step, but to ensure everything back to original] Finally revert the previous procedure, copy all the files from \data\data\com.whatsapp\databases to \data\data\com.whatsapp\databases-firstboot, and rename databases to databases-old, then rename databases-firstboot to databases.
9. Force Stop Whatsapp and restart it.
Hope this help everyone who have the same problem as me in Dell Streak or other devices.
Good luck
Please use the Q&A Forum for questions Thanks
Moving to Q&A
Same problem with an HTC Desire Z. I don't how to restore msgstore.db.crypt (
I've solved: with Root Manager go in data/data/com.whatsapp/databases and leave only wa.db file deleting msgstore.db file...now go in your mnt/sdcard/whatsapp/databases...here put only the backup file, the msgstorexxxxxx.db.crypt and after this, with app manager close forcing whatsapp if it has activities in background: when you will reopen the program it will say that the file of conversations is broken and if you want restore from the backup. So it's solved
Inviato dal mio HTC Vision usando Tapatalk
Hi,Confucio1986 , thanks for your suggestion.
I have tried what you did, but seems my history still not restored...
The following is the log from WhatsApp, "android.database.sqlite.SQLiteDatabaseCorruptException" is caused by removing the msgstore.db after root. But still have "java.io.IOException: File.renameTo failed" error.
Sigh....
2011-10-13 15:30:57.538 msgstore/checkhealth
2011-10-13 15:30:57.550 msgstore/checkhealth/journal/delete false
2011-10-13 15:30:57.563 msgstore/checkhealth/back/delete false
2011-10-13 15:30:57.574 msgstore/checkdb
2011-10-13 15:30:57.585 msgstore/checkdb/list msgstore.db 2602000
2011-10-13 15:30:57.610 ### begin stack trace 2.6.7814
android.database.sqlite.SQLiteDatabaseCorruptException: error code 11: database disk image is malformed
at android.database.sqlite.SQLiteStatement.native_1x1_long(Native Method)
at android.database.sqlite.SQLiteStatement.simpleQueryForLong(SQLiteStatement.java:107)
at android.database.sqlite.SQLiteDatabase.getVersion(SQLiteDatabase.java:926)
at com.whatsapp.wl.b(wl.java:962)
at com.whatsapp.wl.d(wl.java:816)
at com.whatsapp.t2.onClick(t2.java:15)
at android.view.View.performClick(View.java:2408)
at android.view.View$PerformClick.run(View.java:8816)
at android.os.Handler.handleCallback(Handler.java:587)
at android.os.Handler.dispatchMessage(Handler.java:92)
at android.os.Looper.loop(Looper.java:123)
at android.app.ActivityThread.main(ActivityThread.java:4627)
at java.lang.reflect.Method.invokeNative(Native Method)
at java.lang.reflect.Method.invoke(Method.java:521)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:858)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:616)
at dalvik.system.NativeStart.main(Native Method)
### end stack trace
2011-10-13 15:30:57.626 registername/clicked/sdcardstate mounted
2011-10-13 15:30:57.643 verifymsgstore/usehistoryifexists/backupfilesfound 1
2011-10-13 15:30:57.654 verifymsgstore/dialog/restore
2011-10-13 15:31:00.542 verifymsgstore/dialog/setup
2011-10-13 15:31:00.600 msgstore/initialize
2011-10-13 15:31:00.666 msgstore/restore/backupfiles msgstore.db.crypt (2602000)
2011-10-13 15:31:00.712 msgstore/restore/copy msgstore.db.crypt 2602000
2011-10-13 15:31:05.566 msgstore/restore/ioerror java.io.IOException: File.renameTo failed
2011-10-13 15:31:05.866 msgstore/setup
2011-10-13 15:31:05.887 msgstore/checkdb
2011-10-13 15:31:06.014 msgstore/checkdb/nodb
2011-10-13 15:31:06.024 msgstore/getwritabledb doesn't exist
2011-10-13 15:31:06.040 msgstore/create
2011-10-13 15:31:06.067 msgstore/getwritabledb/done/list msgstore.db 8192
2011-10-13 15:31:06.078 msgstore/preparestatements
2011-10-13 15:31:06.092 msgstore/backup
2011-10-13 15:31:06.504 msgstore/backup/size 8192
2011-10-13 15:31:06.522 msgstore/backup/to msgstore.db.crypt
2011-10-13 15:31:07.445 msgstore/backup | time spent: 1336
2011-10-13 15:31:07.633 msgstore/finish
2011-10-13 15:31:07.644 msgstore/initialize/lastmsgs
2011-10-13 15:31:07.656 msgstore/initialize/lastmsgs 0
2011-10-13 15:31:07.667 msgstore/getAllGroupActionMessages
2011-10-13 15:31:07.680 msgstore/asyncthread/started
2011-10-13 15:31:07.691 verifymsgstore/success
But I found one interesting thing recently, if the backup is too old, you also can't restore history.
I tried in my Atrix before, what i did to resolve this is to change the file creation date and file modified date to be a recent date.
Then the history can be stored.
However, this is not the solution for my Dell Streak...
Updated on 2011/11/13
Emailing chat / thread to ourselves
Good thing I read this thread. Was hoping that the backup work.
I tried emailing the chat to myself but that function only email those part of the thread history that is loaded. I have a chat thread going back half a year and each time I load up a few months, my phone slows and freezes until watsapp finally FCs.
Is there a function that allows me to let watsapp retrieve all the chat history from a single thread and post everything to me without me manually loading them?
Hi akita, i guess your case is not same as mine.
But what i know is the database file "msgstore.db", which store all of your history, is located in \data\data\com.whatsapp\databases\
If you know some SQL commands and have root access to your phone,
Copy the file to your desktop, and use some sqlite editor to open the msgstore.db in PC, and export your conversation as CSV for archive purpose...
Hope this help!~
akita16384 said:
Good thing I read this thread. Was hoping that the backup work.
I tried emailing the chat to myself but that function only email those part of the thread history that is loaded. I have a chat thread going back half a year and each time I load up a few months, my phone slows and freezes until watsapp finally FCs.
Is there a function that allows me to let watsapp retrieve all the chat history from a single thread and post everything to me without me manually loading them?
Click to expand...
Click to collapse
Thanks for the tip, that works!
In addition to this, does your "Email Conversation" function work properly? Does it email the *whole* conversation? Or only those presently loaded?
eg,
If you open up any conversation, some recent ones are loaded while older ones are hidden. Clicking "Load Earlier Messages" loads up a block of them. When you choose "Email Conversation", whatsapp seem to email only those presently loaded and not everything in the conversation.
How do we make it email *all* the messages in the conversation, including those earlier ones that is not loaded yet?
Since my original db doesnt hv much chat, i tried restore my 2.7mb db file and send back the chat log to myself.
The txt inside hv all my half year chat include those not loaded.
Maybe you can try my previous method to send back the log to yourself to see if anything strange during Whatsapp prepare the txt file, or whatsapp stuck in one of your messages.
akita16384 said:
Thanks for the tip, that works!
In addition to this, does your "Email Conversation" function work properly? Does it email the *whole* conversation? Or only those presently loaded?
eg,
If you open up any conversation, some recent ones are loaded while older ones are hidden. Clicking "Load Earlier Messages" loads up a block of them. When you choose "Email Conversation", whatsapp seem to email only those presently loaded and not everything in the conversation.
How do we make it email *all* the messages in the conversation, including those earlier ones that is not loaded yet?
Click to expand...
Click to collapse
Sent from my Dell Streak using XDA App
CharlesCCO said:
[SOLVED, see 2011/11/14 update]
Hope this help everyone who have the same problem as me in Dell Streak or other devices.
Good luck
Click to expand...
Click to collapse
you sir, are my hero!
i had the same issue and managed to get the backup restored thanks to your post.
Workaround
I also faced similar problems after rooting my neo v.
I removed all the msgstore-*.db.crypt and msgstore.db files from /Whatsapp/Databases folder in sd card.
But retained only 1 msgstore-*.db.crypt file which I wanted to restore (ie the latest backup)
Renamed it to msgstore.db.crypt. So now i have only 1 file in the databases folder.
Stopped the whatsapp service.
When I restarted whatsapp, it asked for restore again.
Pressed yes and it got restored with the latest chats history.
Hope it helps...
How to retrieve all whatsapp messages to PC / email
akita16384 said:
Good thing I read this thread. Was hoping that the backup work.
I tried emailing the chat to myself but that function only email those part of the thread history that is loaded. I have a chat thread going back half a year and each time I load up a few months, my phone slows and freezes until watsapp finally FCs.
Is there a function that allows me to let watsapp retrieve all the chat history from a single thread and post everything to me without me manually loading them?
Click to expand...
Click to collapse
This might help you:
[TOOL] Whatsapp Database Analyzer / Messages Extractor / Chat-Backup
http://forum.xda-developers.com/showthread.php?p=24603294
You can copy the whatsapp database to your PC and use the tool to display the chats on your pc as they are displayed by whatsapp.
Then you can delete all messages and have a faster whatsapp again
I tried all the steps in this Thread on my Atrix 4G but nothing works.
My whatsapp starts and creates a new database. I upgraded to ICS.
Before I just installed the App and when I started it, it restores the backup from the SDcard automatically.
Is my backup corrupt or is it an ICS issue?
Hi guys,
I haven't followed this thread in detail but here's something you might want to try when there are symbolic links within the apps' data:
In Titanium Backup, hit MENU -> Preferences -> Troubleshooting -> Enable the "Follow all symbolic links" option.
Then the following backups should properly include the apps' database data.
I got the same problem but only on a certain ROM. When I try to restore my whats app chats only the empty chat groups names are restored. I tried all suggestions on this thread but still no solution.
Please help me to find one.
Sent from my HTC Desire using xda app-developers app
What can you say about this log file?
Code:
[1895] msgstore/initialize
2014-03-21 01:15:11.849 LL_I [1895] msgstore/restore/backupfiles msgstore.db.crypt5 (5492752)
2014-03-21 01:15:11.850 LL_I [1895] msgstore/restore/copy msgstore.db.crypt5 5492752
2014-03-21 01:15:11.884 LL_I [1895] msgstore/restore/key CRYPT5
2014-03-21 01:15:16.817 LL_W [1895] msgstore/restore/error
### begin stack trace 2.11.186
[B][COLOR="Red"]java.io.IOException: Error while finalizing cipher[/COLOR][/B]
at javax.crypto.CipherInputStream.read(CipherInputStream.java:107)
at javax.crypto.CipherInputStream.read(CipherInputStream.java:143)
at java.io.InputStream.read(InputStream.java:162)
at com.whatsapp.util.wc.a(wc.java:82)
at com.whatsapp.ldb.a(ldb.java:2203)
at com.whatsapp.ldb.a(ldb.java:1121)
at com.whatsapp.ldb.a(ldb.java:2242)
at com.whatsapp.rl.a(rl.java:23)
at com.whatsapp.rl.doInBackground(rl.java:14)
at android.os.AsyncTask$2.call(AsyncTask.java:288)
at java.util.concurrent.FutureTask.run(FutureTask.java:237)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1112)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:587)
at java.lang.Thread.run(Thread.java:841)
Caused by: javax.crypto.BadPaddingException: error:06065064:digital envelope routines:EVP_DecryptFinal_ex:bad decrypt
at com.android.org.conscrypt.NativeCrypto.EVP_CipherFinal_ex(Native Method)
at com.android.org.conscrypt.OpenSSLCipher.doFinalInternal(OpenSSLCipher.java:420)
at com.android.org.conscrypt.OpenSSLCipher.engineDoFinal(OpenSSLCipher.java:480)
at javax.crypto.Cipher.doFinal(Cipher.java:1178)
at javax.crypto.CipherInputStream.read(CipherInputStream.java:105)
... 13 more
### end stack trace
2014-03-21 01:15:16.818 LL_I [1895] msgstore/restore/nothing-restored
2014-03-21 01:15:16.824 LL_I [1895]
Its restoring until 50% and then its aborting and nothing is restored. Any solutions for that?
HI Tylonhh, did you renamed your backup ?
The new whatsapp using a new key "crypt5" to decrypt, i am not sure if you are restoring from a very old backup (i.e. msgstore.db.crypt") and hence throw error while decrypting the database.
Tylonhh said:
What can you say about this log file?
Code:
[1895] msgstore/initialize
2014-03-21 01:15:11.849 LL_I [1895] msgstore/restore/backupfiles msgstore.db.crypt5 (5492752)
2014-03-21 01:15:11.850 LL_I [1895] msgstore/restore/copy msgstore.db.crypt5 5492752
2014-03-21 01:15:11.884 LL_I [1895] msgstore/restore/key CRYPT5
2014-03-21 01:15:16.817 LL_W [1895] msgstore/restore/error
### begin stack trace 2.11.186
[B][COLOR="Red"]java.io.IOException: Error while finalizing cipher[/COLOR][/B]
at javax.crypto.CipherInputStream.read(CipherInputStream.java:107)
at javax.crypto.CipherInputStream.read(CipherInputStream.java:143)
at java.io.InputStream.read(InputStream.java:162)
at com.whatsapp.util.wc.a(wc.java:82)
at com.whatsapp.ldb.a(ldb.java:2203)
at com.whatsapp.ldb.a(ldb.java:1121)
at com.whatsapp.ldb.a(ldb.java:2242)
at com.whatsapp.rl.a(rl.java:23)
at com.whatsapp.rl.doInBackground(rl.java:14)
at android.os.AsyncTask$2.call(AsyncTask.java:288)
at java.util.concurrent.FutureTask.run(FutureTask.java:237)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1112)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:587)
at java.lang.Thread.run(Thread.java:841)
Caused by: javax.crypto.BadPaddingException: error:06065064:digital envelope routines:EVP_DecryptFinal_ex:bad decrypt
at com.android.org.conscrypt.NativeCrypto.EVP_CipherFinal_ex(Native Method)
at com.android.org.conscrypt.OpenSSLCipher.doFinalInternal(OpenSSLCipher.java:420)
at com.android.org.conscrypt.OpenSSLCipher.engineDoFinal(OpenSSLCipher.java:480)
at javax.crypto.Cipher.doFinal(Cipher.java:1178)
at javax.crypto.CipherInputStream.read(CipherInputStream.java:105)
... 13 more
### end stack trace
2014-03-21 01:15:16.818 LL_I [1895] msgstore/restore/nothing-restored
2014-03-21 01:15:16.824 LL_I [1895]
Its restoring until 50% and then its aborting and nothing is restored. Any solutions for that?
Click to expand...
Click to collapse
I tried renaming, but that makes no sense because of the decrypting.
I have an back from the 19th this month. So it's just two days old and also from the same WhatsApp version which I use now.
I just got a new phone with a higher Android version. From galaxy S2 to Motorola G (4.4.2).
So normally there should be no errors. Does the log show you something? Does it mean WhatsApp can't decrypt it?
---------------
gesendet vom Barhocker
After a long time search i think i can do a custom rom along with a CWM Recovery for TURBO X HIVE III tablet, but i need ORIGINAL boot.img, kernel.img, misc.img, recovery.img, system.img dump. I will do it myself, but in my Turbo X Hive III tablet i do not have original Andoid OS 4.1.1. I already put it on this nice tablet C.M.10.1 but with some other kernel from another tablet and i screw up the touchscreen drivers. From what i understand some of them are integrated in kernel, but i do not have the original kernel image! For those who wants to help to update this tablet (offcourse must have this device) i will upload a tool that can be easily dump .img for our needs! If more people want to develop something nice for this tablet i will provide more details on what we need to do or what i already did! But for now i will wait and see.....!!!
For the tool dump click HERE
Understanding!
Learning things first (optional).
All this is OPTIONAL for you to learn. If you don’t want to learn it then move on down to the instructions!
Understanding NAND layout:
Your NAND chips is broken into "partitions" or parts if you will call it that.
Each one of these servers a purpose. Here are all the partitions of a RockChip ROM.
Loader.bin - this is low in NAND and special. You can flash it but cannot dump it.
parameter - this file tells the loader how NAND memory is split up into partitions.
misc.img - this is a special area that tells the recovery system what to do on boot.
boot.img - this is the boot section and basically is the ram disk the kernel uses to boot.
kernel.img - this is of course the kernel.
cache.img - this is an area APPs store information like Google Play for instance.
kpanic.img - this is a special area for use by the kernel.
metadata.img - this is a NEW area for KitKat only. It does not exist in pre-kitkat ROMs. It's used for Encryption.
recovery.img - this is like boot.img but boots the recovery menu system.
system.img - this is the system OS.
backup.img - I am not sure what this is. It started showing up with Rockchip ROMs but does not appear to do anything.
But it might be work backing up anyway.
userdata.img - this is where APPs get installed, user accounts are stored, databases, etc. This area if erased losses all your user installed apps, settings, etc. A factory data reset erases this area.
user.img - This is the remaining NAND space and is set aside as the Internal SDcard.
Please note, many APPs like games, etc store stuff here! Erasing this you can lose data! This is also erased on a factory reset.
So based on the above what parts are a stock ROM?
Loader.bin
parameter
boot.img
kernel.img
misc.img
recovery.img
system.img
As you can see a stock ROM is just that! No user data!
Erasing NAND with the flash tool and flashing a stock ROM gives you a empty like new device as if you just bought it.
OK so some basics there. Now let’s look at the parameter file.
It's important because we will be using this to DUMP NAND memory.
I do not need to make you an expert on this but you need to know a few things.
If we look at this area of a parameter file, you will see the partitions I listed above!
Both the ones that hold a stock ROM images as well as ones that are created to be used by the system.
Here is an example of a parameter file for a kitkat ROM.
[email protected](misc),[email protected](kernel),[email protected](boot),[email protected](recovery),[email protected](backup),[email protected](cache),[email protected](userdata),[email protected](metadata),[email protected](kpanic),[email protected](system),[email protected](user)
So what do those number mean in from of each partition name like boot for instance?
First all these numbers are in hex. Second the numbers are blocks of 512 bytes!
let's look at boot..
[email protected](boot)
The first number 0x00006000 is the size of the partition.
The second number 0x0000a000 is the offset into the NAND chip from 0 location (start of the NAND chip).
But remember all these numbers are in 512 blocks.
If you wanted to know the size in bytes then do this math in your PC calculator.
REMEMBER to have the calculator set to HEX!!!
Enter 6000 and now multiply by 200 (fyi 200 hex is 512 decimal).
You will get C00000. Want to see that it decimal? In the calculator just click Dec and it will convert it!
So what we have is 12,582,912 bytes! Basically that is 12 megabytes.
Alright you can do that same math if you wanted to know the offset into NAND in decimal bytes.
Why is all this important? Well if gets you up to speed later when we calculate internal SDcard.
You don't need to know this but it might help you understand if you were to do things on your own.
___________________________________
Instructions for dumping....
Before we begin let’s get familiar with the tool.
In the download run the ROM_Dumper_Tool.exe.
When it opens you will notice 3 tabs at the top.
Download image - this is for flashing ROMs
Upgrade Firmware - this is for lashing single .img ROMs. I won’t be going into this area for as we don’t use it for dumping.
Advanced Function - This is for dumping and doing some NICE stuff! We will be in here all the time for this procedure.
Note: Anytime we dump a partition the tool always makes a file called ExportImage.img in a folder called Ouptut.
So every time we dump a different partition it will overwrite that file unless we rename them first!
Don't forget that please.
OK first lets dump the basic flashable ROM:
To do ANY dumping we need to dump the parameter file of the ROM from NAND.
Why? because we need the start (offset) and count (size) of the partition or we can’t dump anything.
1) Click the advance functions tab.
2) At the bottom is the "export image" button and to empty boxes, Start and Count.
3) To get the parameter file put a 0 in the start box and a 2 in the count.
4) Now press the export image button.
5) Now we need to make this a real parameter file! Rename the file to parameter.txt
6) We need to clean it up a bit. Open in Windows note pad ONLY!!! Do not open in MS word or anything else or it won’t work!
Also you may need to turn on word wrap to see everything (format menu, select word wrap checked).
7) The first line you will see something like this:
PARMi FIRMWARE_VER:4.1.1
Delete all the junk in front of the word FIRMWARE so it looks like this now:
FIRMWARE_VER:4.1.1
8) clean up ending junk. At the end you will see this word:
(user)
After it will be some junk. Delete everything after (user) including any blank space.
When done make sure to hit enter once so there is a new line after (user)
9) Save the cleaned up parameter file but leave it open as we need it to continue.
Now let’s start dumping!
We will do system.img to start with as an example.
1) Look at the parameter file and find (system) and the numbers before it. Example:
[email protected](system)
REMEMBER the number before @ is the COUNT and the number after the @ is the START!
2) Copy the number after the @ example: 0x00484000 into the start box of the advanced tab in the tool.
3) Copy the number before the @ example: 0x00180000 into the count box of the advanced tab in the tool.
4) Press the export image button and wait for it to complete.
5) Go into the Output folder and rename the file ExportImage.ing to system.img
Now we just repeat the steps 1-5 above for
misc.img
kernel.img
boot.img
recovery.img
backup.img (This can be optional but do it anyway especially if this is a first REAL stock ROM dump as we may need it).
Remember to always use the numbers in front of each name! Don't forget to change those or you won’t have a good dump.
Also remember after each dump, to rename ExportImage.img to the proper name of the image you dumped!
Each time you press Export Image, it will overwrite the existing ExportImage file unless you rename it!
When you’re done you should have the basic ROM dump.
misc.img, kernel.img, boot.img, recovery.img, system.img, and backup.img.
You can now use the flash tool 2.1 or the flash tool 1.37 to flash these.
_________________________________
Dumping userdata, cache, metadata, kpanic:
For a user backup the above 4 should be dumped.
We will start with userdata
This is basically the same as above except can take longer depending on how big your user data partition is.
This will be larger than any other partition so far as most devices have at least 1GB or more!
1) Again look at the parameter file and find (userdata) and the numbers before it. Example:
[email protected](userdata)
REMEMBER the number before @ is the COUNT and the number after the @ is the START!
2) Copy the number after the @ example: 0x00080000 into the start box of the advanced tab in the tool.
3) Copy the number before the @ example: 0x00400000 into the count box of the advanced tab in the tool.
4) Press the export image button and wait for it to complete.
5) Go into the Output folder and rename the file ExportImage.ing to userdata.img
Again repeat above for cache, kpanic, metadata.
if your parameter file does not have metadata then no need to dump this as it does not exist.
Remember only KitKat ROMs have this so do not worry if you don’t have it.
_________________________________
Finally to the hardest part but it is not really that hard. Dumping "user" which is internal SDcard.
Note: if you have a 32GB NAND or something large like that, this might not be worth your time!
Just back up internal SDcard another way (file copy) as it will probably be faster.
One way I like to do it is turn on MASS Storage in settings and enable USB to the PC.
Then I just copy the files to the PC.
For restore after flashing a ROM and userdata, I do the same thing and copy the files back to internal sd BEFORE running any apps that need that data on internal SDcard!
Dumping 32GB and flashing a large internal SDcard takes a LONG TIME! If most of your internal SDcard is empty,
dumping and flashing still writes ALL 32GB anyway so it's a waste of time to do this unless you have a LOT on internal SD.
So there is a trade-off... YOU decide which best works for you!
*********
So to back this area up we have to work some things out.
You will notice the parameter file for (user) has no SIZE number just the offset!
Example: [email protected](user)
the [email protected] simply says to use the remaining NAND as all of user (internal SDcard).
Thus to dump it we must calculate the size! To do this we must know how big our NAND chip is.
First put the number after the @ into the start box so we don't forget example: 0x00604000
This is just like the other parts we did above. We need the start point for user (internal SDcard).
Now let’s find out the size of the NAND chip.
In the advanced tab click the Read Flash Info button.
On the right it will display information but we are interested in this:
Flash Size: XXXXX MB
Where XXXXX is the size of your flash chip "page" size.
For instance my "other androidrk3066 device" says 8192 MB.
BUT WAIT! We also have to see how many pages of NAND we have.
Look at the line Flash CS:
If yours has a 0 then that is all you have 8GB
If CS says something like 0 1 2 3 (That’s 4 pages)
Then you have 4 pages of 8GB or 32GB NAND. If it says 0 1 then you have 2 pages or 16GB NAND and so on.
So whatever your size is multiple that by number of pages!
Example my "other rk3066 android device" stick says:
Flash Size 8528 MB
Flash CS: 0
Thus my full NAND size is 8528 as there is only 1 page
(yes the 0 is a page! The first page starts at 0 and a 1 is the 2nd page).
My "other rk3066 android device" says this:
Flash Size 8192 MB
Flash CS: 0 1 2 3
Thus I would take 8192 and multiply by 4 pages = 32768 MB NAND size.
So we now have our total NAND size!
Now a little more math but easy if you follow my instructions.
First we must make the size in MB a REAL GB number (not a MB number in 1000's).
I am going to use 8192 MB (8GB) NAND as an example. (It only had 1 page e.g. Flash CS: 0)
1) Open your PC calculator and again make sure it is set to programmer mode!
2) Make sure your set to Dec (decimal) not Hex mode!!!
2) Type in your NAND size you read or calculated with pages from the tool. My example 8192.
3) Multiply that by 1024. My example 8192 x 1024 = 8388608
4) Now do that one more time and multiply 8388608 by 1024. My example 8388608 x 1024 = 8589934592
5) Now divide this number by 512. My example 8589934592 / 512 = 16777216
So you know what all this math did was take the proper number of bytes and divide them into 512 blocks.
This is what is needed by the flash tool and parameter file!
6) Now press the Hex button on the left of the calculator to convert this to a hex number. My example came to 1000000 Hex.
7) OK now we know the total size of our NAND chip in 512 byte blocks in Hex format!
8) Now take this number and subtract the "start" that what was shown in the parameter file.
In my example parameter file I had [email protected](user) so my start is 604000 (we don’t use the beginning 0's).
So again my example 1000000 - 604000 = 9FC000
We now have our user (internal SDcard) size! It is 9FC000 in hex!!!
9) Enter this number into the count box of the tool. Again my example is 9FC000
BUT we need to enter it in the format the tool needs and that is hex!
Just add the 0x at beginning of the number so the tool knows it's hex. Again my example is now 0x9FC000
Just a note: 0's in front of any hex number are ignored. So 0x009fc000 is the same as 0x9fc000.
10) Make sure as I said above, you also entered the start number! Again in my example 0x00604000
11) Press the export image button and wait for it to finish. Depending on size this could be a long time!
12) Done forget to rename the ExpoertImage.img to user.img!
We are DONE! We now have a flashable FULL backup of the entire NAND chip!
What you should have in the output folder, if you did everything above dumping EVERYTHING is:
parameter.txt
backup.img
boot.img
cache.img
kernel.img
kpanic.img
metadata.img (optional if you had that and were on KitKat)
misc.img
recovery.img
system.img
user.img (internal SDcard)
userdata.img
__________________________________
Flashing your dump:
OK so now you have dumped the ROM and other items and you want to flash them back.
Well we can’t use the 2.1 RK tool! Why? Because it has 2 bugs in it.
1) Flashing userdata. It works but will error at 50% every time.
It actually does flash 100% but due to a math bug in the program it counts to 50% instead of 100%.
2) It won’t flash user (internal SD). If you try it says it did it but it doesn’t.
It returns success instantly so obviously it doesn’t flash anything.
If you did not backup user (Internal SD) then feel free to flash with the 2.1 tool and you will be OK even with the error at 50%.
However I setup the old 1.37 flash tool for you. All of the lines for each image is there.
I even have them checked by default for you.
In the download there is a flasher tool folder. Just run the flash tool from there.
Uncheck anything you didn’t backup or items you don’t want to flash.
Note: if you leave something checked you did not backup or the .img is not in the Output folder, you will get an error.
I left boot loader unchecked as there is no reason to flash that!
OK so that’s it!
Specs!
In case somebody not know what device is about: Turbo-X, 10.1", 1280 x 800 pixels resolution, IPS panel, Front Camera 0.3 Mp, Back Camera 2.0, Android 4.1 Jelly Bean, CPU - Dual Core ARM Cortex A9 at 1.5 GHz, Internal Storage 16 GB, RAM -1 GB, WiFi, Bluetooth, Mini HDMI, Micro usb 2.0 host, microSD card slot, Li-Ion 6600 mah with Android 4.1.1, 3.0.8+ Kernel !
Battery
Also for those who have some problem with battery i found this one that is even better then original HERE
Some other toolkit that i find!
Special thanks to Zeus and Faheem! With their tools you can Check Device, Wipe data, fastboot wipe, Reset user lock, Reset gmail, Reboot device, Fix camera, install usb driver and many other cool stuff!
HERE
My dear friend Seby, i can help you without any problem and maybe we can open a new development thread for this old tablet because i already did a custom rom with a great help from a greek friend Panagiotis! So we will talk in PM about that!
Hello,can i have more information about this rom?
I must fix my brother's tablet ,stuck on bootloader.
It's exactly the same model as the author's of the current thread.
does anybody know how to enter fastboot mode in a turbox hive iii tablet it stuck in boot logo screen and i cannot do anything. If there is something I can do please tell me.
thanks
Hi,
Since Whatsapp didn't want to perform a backup on my old phone (http://forum.xda-developers.com/galaxy-s4/themes-apps/cyanogenmod-whatsapp-backup-t3383454), i am stuck when trying to get my chat history from the old to the new phone (Samsung S7 with Android 6.0.1) which i cannot root and put the file into com.whatsapp due to warranty.
The uncrypted msgstore.db from the old phone's com.whatsapp is not recognized as a backup file on the new phone.
I have got my msgstore.db with the corresponding key file but I can't create any *.crypt8 file with Omni-Crypt or Whatcrypt. I can only create a *.crypt file, which Whatsapp ignores as well.
Result of Whatscrypt online (key file uploaded): "Encryption failed / Incorrect account?"
Result of Whatcrypt app: "msgstore.crypt" -> copied to Databases on S7: "searching for Backups" with waiting triangle for hours
Result of Omni-Crypt app: "msgstore.crypt" -> copied to Databases on S7: "searching for Backups" with waiting triangle for hours
Any tips are greatly appreciated
Checked posts / searched for an existing answer... didn't see anything (please move this post if it is in the wrong section)
So I have a app, when I open it asks me what Google ID to uses (preferred ID) but after selecting a Google ID I can not change to a different ID
- If I clear the App Cache the selected ID persists
- If I clear the App Data the selected ID clears and the app returns to the select ID option
- I keyword searched for the App name on my device (Nexus 5x)with Root Explorer (12 different file locations, with subfolders and a bunch of empty folders)
Clearing App Data is a working interim solution, the downside is that every time I clear the App Data the app "downloads assets" (40mb+ ~40 times per day - 1.6Gb!)
What I am hoping to find is a app / script / terminal / log solution that will tell me what file is being modified when I select the Google ID, so I can delete that file re-open the app and change Google Logon
(I contacted the app developer, they said they may be able to fix the problem on the next patch eta 12-24 months)
So I have tried these apps:
https://play.google.com/store/apps/details?id=file.observer
https://play.google.com/store/apps/details?id=scd.lcex
https://play.google.com/store/apps/details?id=eu.thedarken.sdm
But I didn't see system changes (root level) or I didn't know what to look for in LogCat
Any help or suggestions are appreciate!
- I do not have a computer with me (ADB) will be about 7 days before I can try that
- I have been experimenting with deleting files / folders and testing to see if I get lucky (probably not the best method)
- I am not a developer
My current process (as of today) - I clear the app data, then restore the app data with TB (just restoring doesn't clear the sign in status)
As long as my TB backup is "always" in the signed out state, then the "app assets" restore with no issues (and I don't have to keep downloading them)
I am looking for a way to get these (2) operations into a single script / file / shortcut, but it is working for now
I did try the terminal with cp -a (copy the assets - app had a error on library permissions when the files were restored) chmod, chown, and find (try and locate the file) but had minimal success