yashsingh1/xdaforums huggingface dataset:
[Nook Color Android Development] jjvcuyler:
I've been giving this quite a bit of thought. Why not use the MAC address instead of the serial? Then it's guaranteed that the number will be unique, and tied to the hardware. Leaving off the first octet, which should be the same for all Nooks anyway, a MAC will translate nicely into a unique 15 digit number.
[Nook Color Android Development] DizzyDen:
Because... even though each and every mac address is unique... the potential for an IMEI based of off it being an actual IMEI becomes more possible.

I can certainly adjust the program to use the least significant digits of the serial number, but I have no intentions of ever adjusting it to use the MAC address for the reason mentioned above.

I also feel the odds of ANY two people who are doing this to their devices having devices manufactured within 10 of each other are minimal.... so IF I opt to change to least significant digits, it will be a user option... for those that have already used it to create an IMEI.

Additionally, as my serial number begins with 2000, I think it would throw up more potential flags having an IMEI starting out "00-000xxx" than having it start out "00-2000xx".
[Nook Color Android Development] martian21:
I was away from my Nook and my main PC when I wrote that post and couldn't remember how many digits the Nook S/N was.

I agree the chances of two Nook's within ten on each other using this is extremely rare but it still would be nice to ensure it doesn't happen. It would certainly be easier to change it now that later and in theory anyone who has used it will continue to use the S/N from their IMEI.fix file or worst case will hopefully read this thread and can manually enter the previously used number. I just fear given those who might not approve of giving the Nook an IMEI in the first place any ammunition to throw darts.

I don't see any issues with a number that starts with 2000, in fact starting with a bunch of zeros seems strange to me but what do I know? (rhetorical question)
[Nook Color Android Development] jjvcuyler:
I'm not sure i follow. Why is one 15 digit number more likely to be an actual IMEI than another?
[Nook Color Android Development] mr_fosi:
Because it won't be a "test" IMEI number (i.e. one that starts with 00).

There are a limited number of test IMEIs that a given company can have and they have to be recycled, which almost guarantees that we won't ever run up against them. Start using other prefixes and all bets are off.
[Nook Color Android Development] DizzyDen:
Actually some real good food for thought being brought in.

The point I was making on my serial number is that by doing it the way I am... I avoid an IMEI starting with all the extra 0's... If I change it to the least significant digits then it would begin with all the extra 0's. However a possible solution would be for me to invert the 15 least significant digits, or use the first most significant digit and then the 14 least significant... Thinking on this now... Thank you all for stirring up both my brain cells ;)

However, after thinking on the mac address situation... If I changed to use that... by creating a test IMEI based off of that... it may be a better situation, IF that information can be read from a file it would be a decent solution... off to look at my nook /rom again... back soon.

OK... done some more looking.... Perhaps I have a very unique NC... don't know... but my serial number begins AND ends with 2000.... so, even if I did the invert... it would begin with 000 unless I did as mentioned and used the MSD (most significant digit) then used the 14 least significant digits in whichever manner I chose.

The MAC address is still a viable option... can read it easy enough no problem... but since it is only 12 digits my program would perform as it does with manual input now... it would use the 12 digits, repeat the first 3 to make it 15 digits and use that for the IMEI generation.
[Nook Color Android Development] BitingChaos:
Using the MAC would be a little hard, as you have 12 hexadecimal characters. Isn't IMEI decimal only?

Using an IMEI that begins with zeros isn't allowed?

Using the first digit of the serial + the last 14 of the serial may be the way to go. There is still the possibility of duplicates, but less likely than using just the first 15 digits of the serial (assuming sequential numbering).

Is it possible some Nooks have a serial that begins with zero?
[Nook Color Android Development] DizzyDen:
It would be simple enough to use MAC address... would just convert hex to decimal and use that... or convert it to a string, then ascii, then decimal... not really that tough... but points out what I said about the MAC address actually increasing potential for becoming one already in use somewhere in the real world.

I can only make some assumptions regarding the Nook serial number database... I would think they would pad them with a meaningful first digit.. to make it easy to determine run number, batch number, manufacture date or location... etc.

I think the odds of one begining with a significant number of 0's would be less likely than one ending with them. I could also work around this by pre-fixing the IMEI with "00-9"... making the IMEI 00-9XXXXX-XXXXXX-XXX where X's are least significant digits of the serial number.

As of now, I am still along the lines of thinking that any two people who would be using this would have a serial number within 10 of another would be miniscual enough for me to continue with my original path.

But, I am also throwing around the idea of saving the IMEI generated to the nook's ROM... thus it will always be available for the program if it has already been ran on that device... NOTE this would be very safe... in that the program would be the only thing at this point that would access it... or write it. One caveat of this would be if you ran the program with your device connected... then ran it again with another connected and used the saved IMEI.fix... then BOTH devices would wind up with the same IMEI. This would still be solvable by regenerating with second device connected an NOT using saved IMEI.fix.

I could in theory have the program generate a totally random TEST IEMI and save the generated IEMI to the devices ROM.

I hope this post isn't as confusing to you reading it as it was for me to try to explain where my brain is going with it.
[Nook Color Android Development] anonim1:
My serial begins with 2010 (and ends with 2005). I now find it very difficult to believe the serials are completely sequential, as that would mean 10 trillion devices would have been manufactured between ours (based on a 16-digit serial: 2,010,000,000,000,000 - 2,000,000,000,000,000 = 10,000,000,000,000).

I like this idea.
[Nook Color Android Development] jjvcuyler:
Each octet translates easily to a three digit number, from 000 to 255. If the first two octets are ignored, we would get a 12 digit number. Prefix that with double zero, and append the proper check digit and you would have a nice, perfectly unique IMEI.

For example, say the MAC is 01:EE:FF:FF:00:FF. Drop the "01:EE" and translate each of the remaining octets to decimal:

255:255:000:255

Next, pre-append double zero:

00255255000255

Next, compute the check digit, as described here, in this example, 2, and append it:

002552550002552

Finally, format it:

00-255255-0002552
[Nook Color Android Development] DizzyDen:
Or use it with a 17 digit IMEI where the last digits represent SW version and you don't even have to calculate the check digit.
[Nook Color Android Development] anonim1:
But what determines that this MAC-to-IMEI number will be universally unique among all the other IMEI-enabled devices out there? Is it the prepended zeros?
[Nook Color Android Development] DizzyDen:
Yes, the prepended 00- indicates it would be a manufacture's TEST IMEI.

At this time I have found nothing to change my methods... however I will always be open to suggestions and if something significant comes up I will evaluate it again.

However, no matter what method I use... by prefixing it with "00-" indicates a TEST IMEI, so it ever being used in a "real world device" other than our's is not a concern.

Additionally, since this can actually be used on ANY device with ADB support, or the ROM for ANY device... I cannot guarantee how all of them store the information to pull from the device... thus, the discussion of Nook specific items may break items on another device.... just more food for thought.
[Nook Color Android Development] martian21:
I believe the leading 2010 in the Nook Serial Number may be the hardware manufacturing year. Could be wrong though. Ofter times serial numbers start with this type of manufacturing information prior to the unique identification numbers.

For example the serial numbers I'm used to all have a product unique three digit prefix which identified what the unit is.
[Nook Color Android Development] anonim1:
This was my guess too, until Dizzy indicated his serial started with 2000.
[Nook Color Android Development] martian21:
Oh yeah, forgot about that...
[Nook Color Android Development] DizzyDen:
Actually that was a typo... however corrected still throws a wrench in the year thing.... which was my initial thought too, until I confirmed my serial number ACTUALLY begins 2004 and ends 2000... now if you can figure out the 8 in the middle you can have my serial number... lol

That is also the S/N on the box it came in....

So... any ways.... back to the coding of the program... some nice things in the near future.
[Nook Color Android Development] DizzyDen:
Thinking on the MAC address situation even more.... TBH I'd rather someone ever get my device S/N as opposed to the MAC address.... MUCH less issues if someone accidentally put their IMEI on another device accidentally and it got discovered...

IF someone accidentally put their IMEI (based on S/N) on somoene's device in the form of an IMEI and they figured out how it was created... they could... theoretically have 10 choices in serial number... no matter which way I went....

But if they put their IMEI (based on MAC address) on someone else's device... and the same happened.... they would have their MAC address... and that could be cloned to other NIC devices... that would be VERY BAD
[Nook Color Android Development] rhester72:
Not to be thick, but why would that be "very bad"? MAC spoofing is only useful on a local LAN/subnet. It's not exactly like a SSN in the US.

I, for one, am very much in favor of the MAC approach. It is (at least by policy) -guaranteed- to be -unique and distinct-, period. The serial #, not so much so. Plus, if you use the longer form (i.e. the full MAC), you've instantly solved the 'artificial IMEI' challenge for -all- tablet Android devices, not just the Nook...it's a universal solution.

Don't let the fact you've got test code running out there dissuade you from the _proper_ approach. "I might break Swype for people using my older code with a poorer algorithm" is _NOT_ good reason not to Do The Right Thing(TM). People running experimental/alpha code should understand what they are getting themselves into - and if they don't, I guarantee they'll learn. We all did at some point in our lives.

Rodney
[Nook Color Android Development] mr_fosi:
It still looks like six in one vs. half-dozen to me.
[Nook Color Android Development] rhester72:
Very well. I suppose your approach is backed up by this most interesting (and likely somewhat inaccurate) quote from Wikipedia's IMEI entry:

"New IMEIs can be programmed into stolen handsets and 10% of IMEIs are not unique." According to a BT Cellnet spokesman quoted by the BBC.

So at least it sticks to your 1-in-10 collision probability. ;)

Rodney
[Nook Color Android Development] mr_fosi:
I haven't seen anything to indicate that Dizzy is using Wikipedia for his info on IMEI probabilities or anything else.

It might well be good for you to take a look at the other recent IMEI thread (the Swype & HBO thread) and see what info has been brought to bear there. Having read through the official IMEI standards myself (thanks to Dizzy's link), I'm sticking with the S/N based test IMEI standard that has been adopted here.

The S/N standard has solid reasoning that has been explained here and discussed elsewhere as well. Frankly, Dizzy has written a nice bit of code conforming to this standard and it seems a bit much for johnny-come-latelies to arrive and start posturing themselves as somehow more expert than the rest of us stooges.

Now that we've all had waved our monkey arms in the air and pounded our chests, perhaps it would be best for the gainsayers to shut up. Help test the prog, go write your own bin based on your personal pet standard, whatever, but shall we leave the rest of the thread to actual productive discussion?

Looking forward to b9. :D
[Nook Color Android Development] mr_fosi:
I'm rather happy that you were finally able to get that off your chest.

Now that you are equally sure, based on your 25 years of professional experience, of the optimal solution, perhaps you'll go on to actually implement it? I, for one, hope you do so that you can save all the unprofessional hacks around here from the mean ol' software companies who use unique device IDs as development metrics.

I'm personally very grateful that you, an uninvested outsider, deigned to descend from Elysium to shine the pure light of knowledge upon, an me, a lowly unprofessional armchair expert. I can only hold out a faint hope of seeing your mine's-better-than-yours solution being released in the near future.

You'll pardon me if I don't flaunt my tail feathers.
[Nook Color Android Development] DizzyDen:
I have no intentions of performing one of my dizassemblies of your post this time... I have wasted far too much time on this S/N v. MAC Address / MSD v. LSD situation. I am providing a solution to a problem... thus far I seem to be the only one who has opted to take early patches to the next level.

Anyone is free to use it, or not.... I don't care... I am only supplying a VIABLE solution.

If you have been following it, and you have all the experience... why didn't YOU provide a solution?

I STILL see no point in throwing my credentials on the table.

Lastly.... I have ALWAYS said, and mean, I will entertain ALL solutions... but the one on what I chose to make unique IMEI off of has been beaten... there has been no evidence to induce me to believe my method is any less solid than any other. If you want unique... I could just cause the software to generate a random IMEI for you... will guarantee you to be unique then... but defeats the purpose of providing a working solution to the devs who opt to check for it.
[Nook Color Android Development] martian21:
Phase 1 - Feature creep is now over.

Phase 2 - Scope redefinition and "Voice of the Customer" feedback (and all the bickering that entails) is in full swing :D

Phase 3 - Schedule slips and budget overruns will be here any minute!

PS. Dizzy - In phase 4 we shoot the engineers and go to market whether it's ready or not then blame you if it breaks!

OK, that was meant to be humor (in hopes to diffuse the recent tension in this thread).

At this point I'm inclined to agree with Dizzy that the present implementation is good enough and certainly better than everyone using the same number.

Keep up the good work Dizzy! Hopefully we will have a shiny new nightly build soon to test it out on. Actually I set up a build server in a VM last night so I'm going to have a build either way.
[Nook Color Android Development] rhester72:
This is the whole thing I have a problem with. Of *course* I want unique. IMEI is *supposed* to be unique! Swype will come down like a ton of bricks if it _isn't_, because it will cause the primary key on their internal database to reject inserts. Random is NOT unique, though it improves the odds beyond 90%. What I suggested _WILL_ be unique, and that's the ENTIRE reason I pushed it...because if you're going to screw around with IMEI, if it isn't unique, why did you bother? Is it just a matter of 'well, let's get some cranky APKs to run, to hell with what I break in the process'?

Forget it. Honestly. As long as this doesn't make it into CM7 mainline, it's fine. If people want to use it and piss all over the Android software community, that's on them.

Rodney
[Nook Color Android Development] rookie1:
Just throwing ideas - how hard would it be to make getDeviceId() read the generated IMEI from a file instead of hardcode into framework.jar? We can generate it once, store in NC's rom partition. Everyone then use the same modified framework.jar to read from that file. Wouldn't that make distributing the hack simpler?
[Nook Color Android Development] mr_fosi:
I guess Rodney's 25 years of experience allow him to solve pressing problems almost immediately since he's already back for more laughs.

Assertion without argument is about equal with a wet fart.

Let's try this again shall we?

You can't guarantee the generation a unique IMEI without actually submitting yourself to the IMEI approval process. This isn't that hard to understand is it?

Any properly formatted number we generate runs the risk of being identical to some other device somewhere in the world. It doesn't matter if it is based off the MAC, the S/N, or a MAC:S/N hash it is still a series of digits that looks rather like an IMEI and may very well match some device in the backwoods of a Tibetan hinterland.

Yes, your hash idea would provide a wonderful way of generating an IMEI that is guaranteed never to match another IMEI generated by the same program, but this isn't the point of the program. The point is to generate an IMEI for a radio-less device based on a straightforward, device-specific metric.

Dizzy's program meets this need and it does it with style. We get a properly formed IMEI-like number that has the test prefix, which should minimize the chance of conflicting with that aforementioned Tibetan device.

I've seen one person say they'd work to get it into the main CM7 stream and it wasn't the author of the prog or any of the testers. Go tell your problems to that guy then get on implementing your optimal solution.
[Nook Color Android Development] rhester72:
Finally, something of value has been said. Who?

Rodney
[Nook Color Android Development] TheMainCat:
My only problem with your solution DD, is that it doesn't run on a 64bit Windows 7 :( Any possibility of getting a 64bit version :D
[Nook Color Android Development] mr_fosi:
Runs on mine. Make sure you run it with admin privileges.

rhester: My initial response is to tell you to go pound salt but... unless I am conflating this with the battery threads I have been following, it was in the other thread of which martian is the OP.
[Nook Color Android Development] rhester72:
Re-read the martian thread from beginning to end and only reference I could find to anyone actually affiliated with CM7 was dalingrin flat-out saying this approach would not fly in mainline.

Rodney
[Nook Color Android Development] mr_fosi:
Then I did conflate the two subjects (not the first mistake I've ever made as you yourself can attest) and you find yourself in agreement with dal, which, again, is fine since no one has suggested working it into the mainline.
[Nook Color Android Development] martian21:
Because I felt it was so important I quoted it at the very top of my thread:

This was written before Swype got upset therefore the status of the "real solution" is probably much less certain at this point.

EDIT: Back on topic

Just tested with a the latest CM7 I built this afternoon and the duplicate file bug is still there (It was detected by your program). Other than that, worked as advertised.
[Nook Color Android Development] TheMainCat:
Nope no dice. I get the "This version is incompatible with this version of Windows" . I wonder if it is because I am running Windows from my Mac (under VMWare). I was wrong about the 64bit (running 32bit, Windows 7 Ultimate N). In my defense I have installed Windows on this Mac a number of times.
[Nook Color Android Development] 12paq:
Wont run for me on sys32, thought it was just me..
[Nook Color Android Development] TheMainCat:
here is the message i get...

This version of C:\Java\bin\!IMEIme.exe is not compatible with the version of W

ndows you're running. Check your computer's system information to see whether y

u need a x86 (32-bit) or x64 (64-bit) version of the program, and then contact

he software publisher.
[Nook Color Android Development] mr_fosi:
Is yours a vm as well?
[Nook Color Android Development] 12paq:
Nope, 32-bit xp, not win7, I need to try it on the win7 at my studio.

I could be mistaken, but I thought the op previously said 64-bit win7.

I do however get the same error as TheMainCat on my xp-32 machine but its xp... so...

like I said, its most likely me.. I need to reread the lastest op carefuly and pick the best machine I have. I just have java loaded on a certain box.. blah blah.. little time .. you know. :)
[Nook Color Android Development] DizzyDen:
NO IT WON'T... there is nothing in the standards to even SUGGEST that an IMEI be generated off of a MAC address... therefore there is NO GUARANTEE it will still be unique.... That is what I have been trying to explain... but yet again.. with all of my explanation... you are STILL coming across as THICK... enough is enough... give me proof OR sufficient reasoning and I will still likely change my mind... YET you have failed in EITHER... enough is enough... get over it... or move on... write your own program and use it... I'm cool with that... but STOP the BS in this thread until you have what I ask for.

Then you can stay with WHATEVER ROM you choose... this is NOT directed at CM7... Froyo.... or ANY OTHER.. it is to address a shortcoming.... give me a solution MORE VIABLE and I am all over it.... the thing is... YOU CAN'T

And I still ask.... why didn't you step up with all of your "credentials"?

ENOUGH SAID on this topic until you can come up with what I ask for... SUFFICIENT REASONING... is that too much to ask for?

Didn't think so ;)
[Nook Color Android Development] DizzyDen:
Actually, unless I am mistaken... another CM7 dev has stated a solution is being looked at.
[Nook Color Android Development] DizzyDen:
Read the part in the OP about java/bin needing to be in your path statement... or copy the exe to your java/bin folder.

N.M... op is not op any more.... discontinued for cause.
[Nook Color Android Development] DizzyDen:
To stop with the "hope it never gets into the dev" situation... DIRECTLY FROM OP.. AT THE TOP....

The intent is to allow each Nook user to have a unique IMEI based on their serial number. It is intended to be a suppliment until IMEI is addressed in dev's ROM's

Damn did I open a can of worms... and that may be a good thing... since we're all fishing for a solution... I intended all along for my solution to be a fill-gap... which I believe it is.

b9 up shortly.... read framework.jar from device or file... we'll see how that goes... then finish up push to device.

I intend to tredge forward... others are welcome to do the same.
[Nook Color Android Development] DizzyDen:
I am doing my dev in 64 bit windows pro... but it absolutely should be Windows os independent.... I will not assure it to work in any other OS... but there is no code in it that is dependent of ANY version of windows. If you have same error as TheMainCat... check OP about java/bin being in path or run program from java/bin folder.
[Nook Color Android Development] DizzyDen:
Unfortunately, without posting my modified CM7 that removes the duplicate... using what I believe to be the most beneficial... I cannot do anything about the duplicate files.... I have asked in CM7 Dev topic a couple of times regarding this... no reply.
[Nook Color Android Development] DizzyDen:
Progress continues....