[IMEI] IMEI Generator

Do you want the method of exiting changed?

  • Leave it as is... exiting automatically

    Votes: 2 50.0%

  • Return to GUI... exit manually

    Votes: 2 50.0%
  • Total voters
    4
  • Poll closed .
Search This thread
By:
Advanced…
P

paleh0rse

Senior Member
Jan 4, 2011
1,942
627
mr_fosi said:
- 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. :D
Click to expand...
Click to collapse

I believe the IMEI.fix is intentionally left behind so that it can be used to modify all future builds without having to gen a new number... correct?
 
M

mr_fosi

Senior Member
May 15, 2010
250
22
Prolly correct, but I don't want to make too many ass-you-me-uptions when reporting results. :D
 
DizzyDen

DizzyDen

Senior Member
Feb 7, 2011
1,301
567
mr_fosi said:
- Dialog contents "Modifying" gave error "Unable to open file", which I OKed.
Click to expand...
Click to collapse
I will have to track this down... maybe add a couple of error handling routines to display exactly where the issue is. Any information as to exactly which modifying is causing it would help track it down in the meantime.

mr_fosi said:
- 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.
Click to expand...
Click to collapse
1) is by intent... that is how the program knows if you have generated it previously. That is the one file I don't have the program clean up behind itself.
2) will be fixed in the next beta. I haven't seen that and wonder if it is related to above error.... in any event I will include routine to kill adb server.

mr_fosi said:
- 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.
Click to expand...
Click to collapse
Again.. wonder if due to above error. Was the one line that was there "getDeviceID()" or "getDeviceID2()"?

The routine for creating the IMEI.fix also includes the code to append the same lines to ".\out\android\telephony\TelephonyManager.smali"

mr_fosi said:
- 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. :D
Click to expand...
Click to collapse

Thank you for your testing and input and information... It is posts like your's that will get the program where it should be.

NOTE: the space in TelephonyManager.smali above is not a typo... it is added by the forum software for some reason. I could code tag it, but didn't see the need.
 
Last edited:
M

mr_fosi

Senior Member
May 15, 2010
250
22
DizzyDen said:
Any information as to exactly which modifying is causing it would help track it down in the meantime.
Click to expand...
Click to collapse

Not sure which one it is, since there are no apparent identifying marks. Seems to be the very first "Modifying" window, but I might have missed one if it open/closed very fast.

DizzyDen said:
2) will be fixed in the next beta. I haven't seen that and wonder if it is related to above error.... in any event I will include routine to kill adb server.
Click to expand...
Click to collapse

Could be, but not sure why it would be.

DizzyDen said:
Again.. wonder if due to above error. Was the one line that was there "getDeviceID()" or "getDeviceID2()"?
Click to expand...
Click to collapse

It was "getDeviceId()" and contained the same code as an unmodded smali.

DizzyDen said:
The routine for creating the IMEI.fix also includes the code to append the same lines to ".\out\android\telephony\TelephonyManager.smali"
Click to expand...
Click to collapse

I figured as much, which is why I think it is the modification of the .smali that isn't going through at the very beginning. That would explain why I still get a nice, packed .zip at the end whose contents haven't been changed.

DizzyDen said:
Thank you for your testing and input and information... It is posts like your's that will get the program where it should be.
Click to expand...
Click to collapse

No probs. I can't do the coding but I can do some of the bug reporting.
 
DizzyDen

DizzyDen

Senior Member
Feb 7, 2011
1,301
567
mr_fosi said:
Not sure which one it is, since there are no apparent identifying marks. Seems to be the very first "Modifying" window, but I might have missed one if it open/closed very fast.
Click to expand...
Click to collapse
I'm pm'ing you a b6-test.... I've added a couple of error check dialogs to help determine where it is failing. I really want to get this isolated and fixed before posting b6

mr_fosi said:
It was "getDeviceId()" and contained the same code as an unmodded smali.
Click to expand...
Click to collapse
That means it never modified the file at all... the error above is most likely that it didn't find .\out\android\telephony\TelephonyManager.smali... we may have some work ahead of us to determine if the baksmali output folder is different if running from java folder.

mr_fosi said:
No probs. I can't do the coding but I can do some of the bug reporting.
Click to expand...
Click to collapse

And that is GREATLY appreciated.
 
DizzyDen

DizzyDen

Senior Member
Feb 7, 2011
1,301
567
Beta 6... OP updated.

Thank you mr_fosi for testing various interbeta tests for me.
 
DizzyDen

DizzyDen

Senior Member
Feb 7, 2011
1,301
567
Beta 7 including ADB(WiFi) for wireless adb to obtain serial number.

OP updated.
 
M

mellopete

Member
Feb 15, 2009
25
2
DizzyDen said:
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.
Click to expand...
Click to collapse

It is b3 that I was using. There is no .zip.tmp. No errors. The TelephonyManager.smali is the same. I used Notepad++ compare, and the hash values match. I will try the latest and let you know.
 
  • Like
Reactions: DizzyDen
DizzyDen

DizzyDen

Senior Member
Feb 7, 2011
1,301
567
mellopete said:
It is b3 that I was using. There is no .zip.tmp. No errors. The TelephonyManager.smali is the same. I used Notepad++ compare, and the hash values match. I will try the latest and let you know.
Click to expand...
Click to collapse

Try beta 7... there's been quite a bit of progress and improvements through the day.
 
N

nolook

Senior Member
Sep 5, 2010
771
63
so is Irvin to just flash this inside generated n87 over the original and keep all settings?,

Sent from my NookColor using Tapatalk
 
DizzyDen

DizzyDen

Senior Member
Feb 7, 2011
1,301
567
nolook said:
so is Irvin to just flash this inside generated n87 over the original and keep all settings?,

Sent from my NookColor using Tapatalk
Click to expand...
Click to collapse

Yes. It is to generate a correctly formed IMEI based on your nook's serial number and used to update the ROM's zip file... Pay attention to the notes regarding duplicate files in recent updates... you may have to manually add the framework.jar to the zip file with winrar. It would go into system/framework folder in the zip.
 
P

paleh0rse

Senior Member
Jan 4, 2011
1,942
627
What's the duplicate files issue all about?

I'm seeing it with b7. Of course I'm able to manually patch, or just transfer the new framework via adb to my existing n87 install, but I'm still not clear on what's causing this duplicate file thing... any idea?
 
DizzyDen

DizzyDen

Senior Member
Feb 7, 2011
1,301
567
The latest nightlies of cm7 have duplicate files... try updating the framework.jar... or even extracting n86, n87 that I know of with 7zip... it will report and show the duplicate files.

I have posted asking about the files twice in CM7 dev thread... still have no reply.

Those files are why we've been seeing the issue of the ROM zip not being updated. And why I had to resort to current method of saving the framework and manually updating the zip.

I forgot about renaming the files in the zip and removing the dup in my n87... so I wasn't seeing the issue in my testing of my program.

You can see that it is CM7 thing by opening the zip in winrar and going to system/lib... you'll see two files as I listed in the thread there.

http://xdaforums.com/showpost.php?p=14126927&postcount=2562
and
http://xdaforums.com/showpost.php?p=14312624&postcount=2755
 
Last edited:
P

paleh0rse

Senior Member
Jan 4, 2011
1,942
627
DizzyDen said:
The latest nightlies of cm7 have duplicate files... try updating the framework.jar... or even extracting n86, n87 that I know of with 7zip... it will report and show the duplicate files.

I have posted asking about the files twice in CM7 dev thread... still have no reply.

Those files are why we've been seeing the issue of the ROM zip not being updated. And why I had to resort to current method of saving the framework and manually updating the zip.

I forgot about renaming the files in the zip and removing the dup in my n87... so I wasn't seeing the issue in my testing of my program.

You can see that it is CM7 thing by opening the zip in winrar and going to system/lib... you'll see two files as I listed in the thread there.

http://xdaforums.com/showpost.php?p=14126927&postcount=2562
and
http://xdaforums.com/showpost.php?p=14312624&postcount=2755
Click to expand...
Click to collapse

Ahh, ok, I'm tracking... saw you post about it both times, but nobody is responding. Have you asked about them over in the CM forums as well?
 
DizzyDen

DizzyDen

Senior Member
Feb 7, 2011
1,301
567
paleh0rse said:
Ahh, ok, I'm tracking... saw you post about it both times, but nobody is responding. Have you asked about them over in the CM forums as well?
Click to expand...
Click to collapse

No, I haven't been over there as of yet. I think as another workaround I will enable the IMEI generator to adb push framework.jar to /system/framework if the user wants.

That won't help the updating install ROM zip's until the dup issue is fixed... but then people could install the update... then run the IMEI generator and place patched rom on their nook.
 
Last edited:
P

paleh0rse

Senior Member
Jan 4, 2011
1,942
627
DizzyDen said:
No, I haven't been over there as of yet. I think as another workaround I will enable the IMEI generator to adb push framework.jar to /system/framework if the user wants.

That won't help the updating install ROM zip's until the dup issue is fixed... but then people could install the update... then run the IMEI generator and place patched rom on their nook.
Click to expand...
Click to collapse

Personally, I would prefer that method. If you pull the in-place framework, mod it, then push it back, that would be perfect! If you do, then please also copy the old version to framework.jar.bak :)
 
martian21

martian21

Senior Member
Sep 12, 2010
308
42
Fort Wayne, IN
Excellent work DizzyDen!!!

Finally got home and had a chance to test out your latest (b7).

My platform is as follows:
Phenom II Quad Core with 8GB DDR2 running Windows 7 Ultimate x64
Android SDK installed

Testing with USB disconnected:
  • Detected cm_encore_full-87.zip just fine and offered to modify it.
  • Extracted files with no issues
  • ADB over USB failed (as expected)
  • Offered to use ADB Wireless - I selected Yes
  • Enabled ADB wireless on my Nook
  • Entered my Nook's IP and port info and ADB wireless worked flawlessly to get my S/N and generate an IMEI number based off that serial number.
  • Notified me of the duplicate file bug in n87 and that I would have to manually add framework.jar
  • Cleanup appears to have worked as only the modified framework.jar, IMEI.fix, telephonyManager.smali and cm_encore_full-87-IMEI.zip files are left
I extracted the framework.jar from cm_encore_full-87-IMEI.zip and backsmali'd it which confirmed it was NOT modified (due to the duplicate file bug)

I then backsmali'd the modified framework.jar and confirmed it had been modified with an IMEI based on my NOOK's S/N - WOOT!

I also confirmed that the TelephonyManager.smali file left behind was modified as well. <=== What is the purpose of leaving this file? It doesn't seem useful in addition to the IMEI.fix file.


Testing with USB connected: (first attempt)
  • Detected cm_encore_full-87.zip just fine and offered to modify it.
  • Extracted files with no issues
  • ADB over USB failed (I did not have USB drivers for the Nook installed!)
  • Offered to use ADB Wireless - I selected No
  • Stated that my IMEI is "12-345678-901234-5" (Obviously not based on my S/N)
  • Notified me of the duplicate file bug in n87 and that I would have to manually add framework.jar
  • Cleanup appears to have worked as only the modified framework.jar, IMEI.fix, telephonyManager.smali and cm_encore_full-87-IMEI.zip files are left

I verified the *bogus* "12-345678-901234-5" IMEI was present in IMEI.fix, framwork.jar, and TelephonyManager.smali

***I personally don't like the fact that it falls back to a clearly bogus IMEI number if ADB fails. I would much prefer you prompt the user to enter their Nook's serial number.***

To remedy my ADB USB failure, I installed NOOK USB drivers from here. I had to go into Device Manage and right click on the Nook and tell it to "update drivers" then point it to the path I extracted the drivers to. I then verified ADB was working over USB with the "adb devices" command which showed my Nook!

Testing with USB connected: (second attempt - with proper USB drivers!)
  • Detected cm_encore_full-87.zip just fine and offered to modify it.
  • Extracted files with no issues
  • ADB over USB succeeded to get my Nook's serial number!
  • Notified me of the duplicate file bug in n87 and that I would have to manually add framework.jar
  • Cleanup appears to have worked as only the modified framework.jar, IMEI.fix, telephonyManager.smali and cm_encore_full-87-IMEI.zip files are left

Confirmed files were properly modified.


Truly amazing work DizzyDen. You have my respect and gratitude!

My only comment would be to ditch the *bogus* "12-345678-901234-5" IMEI if ADB fails, granted it is clearly bogus but I think the only way this mod is going to gain traction and not cause controversy with app developers is if you ensure a unique IMEI number.

If you are dead set on offering a solution that doesn't require a serial number for users who are unable to get their S/N or for whatever reason don't want to use it then I would suggest you request a hash word or phrase (of a certain minimum length) that you can then hash add the two preceding zeros and truncate to the proper length to create a (hopefully unique) IMEI. The goal would be to use an easy to remember word or phase as the seed / hash to generate an IMEI in hopes that the user will remember it even if the IMEI.fix file is lost or unavailable so that the same IMEI number can be generated.


EDIT: Tested with update-cm-7.0.3-encore-signed.zip and everything worked flawlessly. The framework.jar file inside the modded update-cm-7.0.3-encore-signed-IMEI.zip had the IMEI based on my Nook's S/N! Hopefully the "double file" bug will get fixed soon.

Martian21
 
Last edited:
  • Like
Reactions: DizzyDen and gotissues68
DizzyDen

DizzyDen

Senior Member
Feb 7, 2011
1,301
567
Thank you all for the input... I am thinking also about the manual input... but am afraid that may cause us issues with ppl like Swype developers... as I see potential for missuse... but will probably add it anyway ;)

I almost would prefer a random generation of IMEI if adb fails... but will include manual input for now at least.

The method of random I was talking about is simply have the software generate a random 15 digit number and generate an IMEI based off of it. But I like your idea of entering a passphrase and generate a hash... even if simply converting it to ascii hex.... hmmmmmm
 
Last edited:
BitingChaos

BitingChaos

Senior Member
Apr 18, 2011
275
76
St. Louis
So, um... What can this break (or what trouble could it cause down the road)?

I understand that (dumb) programs that assume IMEI are still assuming a factory-assigned number.
What if a Nook Color's serial # just happens to be a real IMEI number already assigned by another factory for a phone?
Is there a chance there still could be a duplicate with someone else?

I believe Cyanogen said they would never put any kind of IMEI spoofing into the default build of the software. What reasoning did he have?
http://twitter.com/#!/cyanogen/status/73496701691895808

Also, in another forum someone said "It is a criminal offence in the UK to tamper with IMEI numbers."

Does using the Nook Color's serial number simply get around all these issues?
 
DizzyDen

DizzyDen

Senior Member
Feb 7, 2011
1,301
567
BitingChaos said:
So, um... What can this break (or what trouble could it cause down the road)?
Click to expand...
Click to collapse
I personally do NOT see any potential "down the road issues" but am certainly welcome to anyone sharing concerns.
In fact, I started this project to try to AVOID "down the road issues" since so many who needed IMEI for software validation were using the same generic IMEI provided in patches instead of creating their own... So I decided to make an easy method for everyone to create their own.

BitingChaos said:
I understand that (dumb) programs that assume IMEI are still assuming a factory-assigned number.
What if a Nook Color's serial # just happens to be a real IMEI number already assigned by another factory for a phone?
Is there a chance there still could be a duplicate with someone else?
Click to expand...
Click to collapse
As I see it.... the possibility is SO REMOTE I would say NO... that is why I chose to utilize "TEST" formed IMEI. I don't think we'll ever have to worry about any hardware manufacturer using a test IMEI that specifically matches one generated from our NookColor Serial Numbers.

The odds are theoretically 1 in 999,999,999,999,999 That's 999 TRILLION with a T or I suppose 1 ZILLION with a Z.

BitingChaos said:
I believe Cyanogen said they would never put any kind of IMEI spoofing into the default build of the software. What reasoning did he have?
http://twitter.com/#!/cyanogen/status/73496701691895808
Click to expand...
Click to collapse
I cannot speak for anyone other than myself... Possibly because no one thought of a way to impliment it to utilize individual IMEI in the packaged framework.jar

BitingChaos said:
Also, in another forum someone said "It is a criminal offence in the UK to tamper with IMEI numbers."

Does using the Nook Color's serial number simply get around all these issues?
Click to expand...
Click to collapse
I am not an attorney, so I only speak from common sense...

Technically speaking, since the NookColor does NOT have an IMEI number, we are not tampering with it. We are providing a unique solution to a problem that exists.

I hope I have addressed all of your concerns adequately... if not, feel free to ask for more specifics.

BTW... beta 8 up soon... manual inputting a seed or serial number for IMEI generation provided... keep eyes out.
 
Last edited:
  • Like
Reactions: BitingChaos
You must log in or register to reply here.

Similar threads

D
Android 3.0 Honeycomb Preview Image v04 - 2/7/2011
Replies
2K
Views
1M
fattire
fattire
V
[ROM][CM7] [v1.3] Size-agnostic SD Card image and CM7 installer for SD Cards.
Replies
2K
Views
1M
A
AdilJ
D
[USER] CM7 General Discussion thread
Replies
6K
Views
1M
gsutton
gsutton
B
[ROM] Customized Nookie Froyo 0.6.8 Image for SDcard Updated (4/29)
Replies
916
Views
300K
Divine_Madcat
Divine_Madcat
racks11479
[ROMS]NEW! Dualboot Mirage CM7 / ICS CM9 Image for SDcard [5/4]
Replies
548
Views
233K
R
Ray2047

Top Liked Posts

24 Hours All time
  • There are no posts matching your filters.
  • 57
    DizzyDen
    DizzyDen
    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
    View
    4
    DizzyDen
    DizzyDen
    WOW.... no reported bugs in Beta 9f.... I am thinking that is a GOOD thing!!!

    Barring bug reports... I will begin implementing the rest of the features I have planned for beta 10... these are primarily:
    1. Use of optional !IMEIme.ini to control settings... initial ini will have the default settings I have the program using right now...
    2. Option to use MAC address in IMEI generation
    3. Option to NOT save IMEI.fix... so you can run it on a friends... and not overwrite your default
    4. Option to create IMEI.fix even if Java fails... so you can manually update TelephonyManager.smali and framework.jar yourself easily... beware of feature 3 listed above.

    I am working on the features... but I don't want to get too deep until I know I have our bugs in Beta 9 series ironed out... No sense in carrying them over to our next feature set.
    View
    3
    DizzyDen
    DizzyDen
    New Beta 9e up... removed previous run check... It should have never worked... and maybe it hasn't... mr_fosi has reported this a few times... I always thought I tracked it to something else... I was WRONG... I know what it is... need time to clear up the issue.

    For now... have NC hooked up adb(usb) or adb(wifi) working... in place should work... but it will need to pull S/N each time for now.
    View
    3
    P
    paleh0rse
    rhester72 said:
    DD, as I stated in my PM, as long as you're willing to help people fix their devices when their IMEI changes without warning in the future and all their software breaks, and you're willing to take responsibility for having Nooks blacklisted with software retailers on the Market because you couldn't wait to be a hero and listen to dalingrin nicely tell you to back off, it's all good. I'm well and truly done with this...I should have expected a gangbang of fervent users attacking me as a 'bad guy' because they are willfully ignorant of the risks they are taking (and that you conveniently forgot to tell them about).

    I *WILL NOT* reply to this thread again. Quit, continue, do whatever you like...but you'd damned well better take responsibility for the outcome in the future.

    Rodney
    Click to expand...
    Click to collapse

    Many if us know the "risks" just as well, or even better, than you... and many of us also believe that this solution mitigates those as well as any other could. AFAIK, the cm team will NEVER allow another IMEI commit for the simple fact that they plan to avoid any/all contraversy dealing with IMEI. For that reason, any possible fix must come from a third party -- like this one.

    I feel that Dizzy's method of IMEI generation provides a test number that is unique enough to avoid the wrath of any vendor. And, even if any dev still decides to take action against our set of numbers, I also feel confident that we can then find a new way around said action if/when that happens.

    You've said your piece, as you're entitled to do... but, I ask that you now let the rest of us decide whether or not the "risk" is worth it.

    Dizzy -- please know that you have no such "responsibility" in the future. As testers and fellow hackers, we know wtf we're messing with. Please continue on and ignore those who might criticise while offering no alternative solution of their own. Rodney might think he "knows better" than the rest of us, but he doesn't.

    PS: nobody from teamdouche, including Dal, has ever stated the serial number solution is a bad one. They certainly didn't recommend the original method of everyone sharing one IMEI, but they've not said word one about this one. Besides, this project has nothing to do with CM specifically... please keep it going! :)
    View
    3
    DizzyDen
    DizzyDen
    OP updated, b9 uploaded....

    I apologize to the community for my short sighted reactions to attacks at my methods, work and efforts. I assure you that will not happen again. I have come to realize the support and appreciation is far greater than I imagined. THANK YOU!!!

    Now.... back to testing ;)

    PLEASE feel free to 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.
    View

New posts