aVanityGen Alpha v0.2: Vanity address generator for Android. [UPDATED 1/11/12]

[Remember remember the 5th of November]

Not sure if any similar apps exist, but I made one anyway. Realistically you'd never want to generate a vanity address on a phone since it is slow, considering phones are not fast as PCs, but now at least if someone asks if there is a vanity address generator for Android, we can say yes.

I suppose now you are wondering if this app is safe. I can say it is, but just to assure you guys, most of you Litecoin miners used to use my binaries of pooler's litecoin miner and I could've put malicious code anytime I wanted, but did not(there was once a false positive warning of a trojan in the libcurl library, precompiled, which I had downloaded from a website I found in the official links on the curl website, but that was it).

In case you are still paranoid, use a traffic minitor to see that it does not make any outgoing connections OR simply do not use the app .
Also, while the app does not require any permissions some are forced on the apk by default.

The application is still Alpha but is in a working state, however I do not encourage you to use the addresses untill I am sure that the OpenSSL library I am using does not have any security flaws. Speaking of OpenSSL I am providing my own, but the phone might use the ones that come with Android by default, hence why it might not work on 2.3 and lower. I can confirm it works on my Samsung Galaxy SII running Ice Cream Sandwich 4.0.3. Post on which it does not.

Update September 1st, 2012.

Ok, I have added a new feature. I have added the ability to select between 3 chains, Bitcoin,Namecoin and Litecoin as well as two themes, Dark Holo and Light Holo which were introduced in Honeycomb 3.0.
This is why this time I am providing 4(four) different versions:

• Compatability version <- For Android platforms <3.0 as well as statically linked OpenSSL 1.0.0a.
• Normal version <- Uses UI elements that are standard for the platform(noticeable difference from first version if ran on a >3.0 device), comes with shared libraries, but they are never actually used, since the phone uses the more recent ones that come with Android, on ICS 4.0.3 that would be OpenSSL 1.0.0e.
• Holo Light version <- same as Normal version, except that the theme is Holo Light.
• Holo Dark <- same as Normal version, except that it is a darker theme.

But, with new features come new bugs. The new bugs are:

• Navigating away from the application while it is looking for a Regex match will not continue to search for a vanity address thus resuming the application you will find out it had stopped and was reset. Same thing happens when screen goes off or the user locks the phone.
• For the same reason, if you try to copy either the private key or bitcoin address and navigate away to paste it into another app, after resuming a new address will be generated thus you will not have the ability to copy the private key or bitcoin address associated with the address/private key you had previously copied. There is a workaround though. Android has a clipboard, so just copy the private key, then the bitcoin address and use the clipboard to fetch the data. I think this is only available in ICS.
• The dialog that appears when clicking 'About OpenSSL' has a button which at the moment does not do anything.
• Elapsed time is only shown when a match is found

The reason I have not fixed these bugs, is that I only found out about them last night, and I don't have time to fix them since I will probably be away for a week or two, if not more.

I know this sounds like more of a regression due to all the bugs, but it is Alpha, a stage where new features and bugs that come with them are expected.

Normal -> http://www34.zippyshare.com/v/31630959/file.html
Compatability version -> http://www34.zippyshare.com/v/86928096/file.html
Dark Holo -> http://www34.zippyshare.com/v/87173194/file.html
Light Holo -> http://www34.zippyshare.com/v/53924730/file.html

For Technical users:
Bitcoin: address type: 0, privkey type 128.
Litecoin: address type 48, privkey 128 + 48;
Namecoin: address type 52, privkey 180(starts with 7??).

And remember, while in Alpha stage, I do not recommend using the addresses untill I implement a verification feature to ensure Privkey matches the Address displayed.



Planned features:
*Support for alt-chain addresses.[Semi-complete, more to be added]
*Creating wallet with X keys.
*Show elapsed time as well as estimated remaining time.[Semi-complete, more to be added]
*Built-in check to verify addresses [Semi-complete; Addresses are generated on the native side, but will be verified on the Java side]
*Support for Mini private key format [Done, but a more secure entropy for random strings must be added]
*Display address/private key as QR code
*Display public/private key in other ways, such as Hex instead of Base58.

If possible, please post your speeds(keys per second) as well as phone models and firmware version.

SGS2: 140 keys on avg going from 140 to 145 using v0.2. Wrong calculation, so the numbers were wrong.

Oh, and if you like this app you can also donate to 12jujMxZodCde2o4LvLRpsXK5tF1WQ9YC9

[1713927386]

1713927386

[1713927386]

1713927386

[1713927386]

1713927386

[1713927386]

1713927386

[scintill]

Do you have any plans for releasing the source?

Nexus One, 24 keys/s, CyanogenMod 7.1.0

[scintill]

Feedback on the app: I generated a few keypairs, they seem to be correct, but I haven't sent funds.

Took me a while to figure out "multi generate" has to be checked to actually do the vanitygen, otherwise it just seems to generate random keypairs (may be useful in itself.)

A case-insensitive option for the regex might be useful, if a user just wants a word in the address but doesn't care what case it is.  Also, a prefix option that checks the viability of the prefix (no capital i's for example) could be useful.

I also don't know if anyone would really use this, "but now at least if someone ask if there is a vanity address generator for Android, we can say yes."

[Remember remember the 5th of November]

I think I have a plan on how to squeeze more keys on the C side.
Right now the biggest bottleneck is function call overhead. In order for one address to be generated, I must call the jni wrapper which allocates memory for the private key and bitcoin address and then call the actual function where the address is generated which in turn allocates memory for the bignum variables and frees them when it is finished.
Obviously allocating and freeing memory is expensive so what I plan to do is setup an event handler in the aformentioned function and if a key is requested at least a few allocations will be avoided.

And after that I will try to optimize in assembly, while ironically, I do not know any.

Also, noted on the case-insensitive search. But you also must remember that enabling such an option would disable regex.

[exotime]

Cool project

If you don't release the source for the project, you'll find it'll be hard to convince people to generate addresses that they'll use - it's too hard to prove you aren't sending the private keys to yourself.

[nhodges]

Cool project

If you don't release the source for the project, you'll find it'll be hard to convince people to generate addresses that they'll use - it's too hard to prove you aren't sending the private keys to yourself.

Not really, just hook your phone up to your computer, open Eclipse (make sure you have ADT plugins installed) and watch the ADB logs for anything outgoing. But for non-Android developers, I guess.

What permissions does the app ask for? Sorry, re-read OP, what are the permissions that are "forced" from the APK.

Decompiled his APK, definitely doesn't seem nefarious from first glance, and he's definitely not lying about what permissions the app actually asks for. (Meaning, since it doesn't request network permissions, it can't send your addresses anywhere.) Please feel free to correct me if I am wrong.

His AndroidManifest.xml file:

Code:

<?xml version="1.0" encoding="utf-8"?>
<manifest android:versionCode="1" android:versionName="1.0" android:installLocation="preferExternal" package="com.firstapp.firstapp"
  xmlns:android="http://schemas.android.com/apk/res/android">
    <uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE" />
    <application android:label="@string/app_name" android:debuggable="true">
        <activity android:label="@string/app_name" android:name="MainActivity">
            <intent-filter>
                <action android:name="android.intent.action.MAIN" />
                <category android:name="android.intent.category.LAUNCHER" />
            </intent-filter>
        </activity>
    </application>
</manifest>

[Remember remember the 5th of November]

I was actually going to suggest using a traffic monitor to check the app, but I suppose that works as well.

Anyway, I went in and applied a few optimisations I thought would work, but somehow the JVM deattaches the thread now, so I scrapped it all and I am going to redo it.

(while at the same time trying to cross-compile a toolchain for android)

[Remember remember the 5th of November]

Alright, achieved an almost 200-300%(varies a lot) increase in key generation by moving code a bit.
UI elements will now correspond to the correct API Level.
Added an About OpenSSL dialog which will tell you the OpenSSL version used, should be the one that comes with the phone, or if it is an older device, then use the static libraries in the Compatability version.
Added Elapsed time and planning to add Estimated time.

Update September 1st, 2012.

Ok, I have added a new feature. I have added the ability to select between 3 chains, Bitcoin,Namecoin and Litecoin as well as two themes, Dark Holo and Light Holo which were introduced in Honeycomb 3.0.
This is why this time I am providing 4(four) different versions:

• Compatability version <- For Android platforms <3.0 as well as statically linked OpenSSL 1.0.0a.
• Normal version <- Uses UI elements that are standard for the platform(noticeable difference from first version if ran on a >3.0 device), comes with shared libraries, but they are never actually used, since the phone uses the more recent ones that come with Android, on ICS 4.0.3 that would be OpenSSL 1.0.0e.
• Holo Light version <- same as Normal version, except that the theme is Holo Light.
• Holo Dark <- same as Normal version, except that it is a darker theme.

But, with new features come new bugs. The new bugs are:

• Navigating away from the application while it is looking for a Regex match will not continue to search for a vanity address thus resuming the application you will find out it had stopped and was reset. Same thing happens when screen goes off or the user locks the phone. Should be resolved in v0.2b
• For the same reason, if you try to copy either the private key or bitcoin address and navigate away to paste it into another app, after resuming a new address will be generated thus you will not have the ability to copy the private key or bitcoin address associated with the address/private key you had previously copied. There is a workaround though. Android has a clipboard, so just copy the private key, then the bitcoin address and use the clipboard to fetch the data. I think this is only available in ICS. Fixed in v0.2b
• The dialog that appears when clicking 'About OpenSSL' has a button which at the moment does not do anything.

• Elapsed time is only shown when a match is found

The reason I have not fixed these bugs, is that I only found out about them last night, and I don't have time to fix them since I will probably be away for a week or two, if not more.

I know this sounds like more of a regression due to all the bugs, but it is Alpha, a stage where new features and bugs that come with them are expected.

Normal -> http://www34.zippyshare.com/v/31630959/file.html
Compatability version -> http://www34.zippyshare.com/v/86928096/file.html
Dark Holo -> http://www34.zippyshare.com/v/87173194/file.html
Light Holo -> http://www34.zippyshare.com/v/53924730/file.html

File size is larger due to added support for SpongyCastle crypto functions. They are not used, but will be.

For Technical users:
Bitcoin: address type: 0, privkey type 128.
Litecoin: address type 48, privkey 128 + 48;
Namecoin: address type 52, privkey 180(starts with 7??).

And remember, while in Alpha stage, I do not recommend using the addresses untill I implement a verification feature to ensure Privkey matches the Address displayed.[/list]

[Remember remember the 5th of November]

Hi all. Been a rather long time, but honestly I kinda wanted to rest since even though aVanityGen is incomplete, I poured a lot of precious time into it.

I've decided to pick it up again, but this time I need help from the community. One problem I am facing is the connection between Java and JNI. You see, the way I display the private and public key in the UI is by having two global variables in my main class/activity on the Java side, when a key is requested JNI takes over and generates a keypair and sets the Java global variables(privkey and pubkey;both are of type String but with no access modifiers) but nothing guarantees they are set(could happen if something went wrong with JNI). Then on the Java side is where I do the regular expression matching. Here lies the problem, in order to actually match them, I must return from JNI to Java, thereby exiting the generating function. Samr7 discovered that it's possible to batch up EC points and do batched modular inversion which is why he achieved such great speeds.

Code:

	EC_POINTs_make_affine(pgroup, nbatch, ppnt, vxc_bnctx);
	for (i = 0; i < nbatch; i++, vxc_delta++) {
		// Hash the public key
		len = EC_POINT_point2oct(pgroup, ppnt[i], POINT_CONVERSION_UNCOMPRESSED, eckey_buf, sizeof(eckey_buf), vxc_bnctx);

		SHA256(eckey_buf, len, hash1);
		RIPEMD160(hash1, sizeof(hash1), &vxc_binres[1]);
                // Debug
		char address[64];
		Base58Encode(vxc_binres,21, address); //Funny, but I do not remember why I skip the 4 byte check code. Duh, for debug purposes :P
		__android_log_print(ANDROID_LOG_INFO, "aVanityGen", "%s=%s", bin2hex(vxc_binres,21), address);
		npoints = 0;
		rekey_at = 0;
		i = nbatch;
                break; //No point in continuing further.
	}

This is the relevant C code. I am still using it in my code despite the fact that it does NOTHING at this point. The problem is, I have no way to return to Java on every loop and check it before the next loop begins. Doing the actual checking in there sounds like a plan, but how? Using PCRE sounded like a nice idea, but it would add a lot of size to the program.

I offer an 100PPcoin bounty for real ideas on how to overcome this. I know 100 ppcoins is not nearly enough, but hey, I didn't see 100 litecoins being a lot at the time as well.

[Michael_S]

feedback to the app (honeycomb 3.0.1)
1) It takes too long because it misses many hits! Example: I search for "^1a.*" --> I should expect that 1 in 58 addresses matches this pattern (because of base58 alphabet there are only 58 possibilities for the first character after the leading "1"), but it takes many 100s (sometimes 1000) tries before the search algo stops. Hence there is something fundamentally wrong.
2) false positives: sometimes it stops without having found a match. E.g. I search for "abc", and it stops at an address that has abc nowhere inside the string. Hence there is something else fundamentally wrong.
3) printing the number of searches continuously is a nice GUI feature but slows down the search process a lot. there should be the possibility to switch it off, or it should only print that number once every full 100 searches or so!

moreover: What i do not understand: Why do people here worry about that the app may send the priv key to a server when the app does not have any android permissions at all (neither internet permission, nor permission to write to sd card...)?

[scintill]

moreover: What i do not understand: Why do people here worry about that the app may send the priv key to a server when the app does not have any android permissions at all (neither internet permission, nor permission to write to sd card...)?

Tinfoil hat on:  It could instead have a rigged "random" number generator so that the creator can re-generate (or pre-generate) the same sequences of keys.  No network access involved.

[Remember remember the 5th of November]

Err, no. I indeed got the calculation wrong... I since rewrote some of the code and got some real speed/s figures this time. I also added Java-side verification of Privkey->Address. Slows down Single address generation, but well worth to ensure that what you see is what you get. The main change is that I use the PCRE library which further increased the size, however it's also native code so should be faster than Java side.

And no, address generation is DEFINITELY not rigged. The only problem I saw however was that Android might not have /dev/random or /dev/urandom sources of entropy where OpenSSL got it's seed from on Desktop Unix/Unix-like systems, but I've asked on Stackoverflow and they've assured me it exists and is being used(no real way to verify other than to use the cryptographically strong entropy from Java side and pass it onto JNI).

Anyway, I haven't had much time to work on it seeing as it was barely "popular". My goal was to add apart from Multi-chain setups,but also Mini private keys(I already wrote the java implementation myself) and other features you'd see today in Desktop applications. I plan to release the source code when I am confident it doesn't suck as much .
Looking at the casascius client, there are very good features concerning encrypted private keys(passphrases) and whatnot.

Ah yes, trust me or not..it's using ludicrous amounts of RAM. The per-process limit is 16-24 megabytes, and mine is already using well over 11. I cannot find the problem, the emulator is fine though... My only guess is the UI elements.

EDIT:Currently, on my SGSII I get about ~7500 keys per second. The pattern 1abc(anywhere in the address) took about 45 seconds. Give or take a few since I had to count myself. Another took around 20 seconds(lucky). Timer needs to be fixed..fffuuu.

And if you have time, do analyze the memory dump http://www.filedropper.com/work_3...I am dying to know what's causing the insane amount of RAM usage.

[Remember remember the 5th of November]

OK, been a long time, sorry for the delay. I have not worked on the application for a very long time.

Here are the sources https://mega.co.nz/#!SMlxlZDA!bqrtjn5ofRJ1Y16ePrLGvWFDolwuBm_iMTPB2lF81zc they depend on PCRE and OpenSSL(the SO bundled are OpenSSL 1.0.1c and pcre)

Meanwhile, I'd like you all to know that this was my first Android application, and first involvement with Java. Most of the initial code I wrote on my phone. Overall, as a programmer, I am not very good, my understanding of Bitcoin is that of any new person who has never heard of it, but I still attempted this project.
If you feel like the code is written horribly, which I am sure it is, feel free to fork it.

And if you find ANY problems with the code which might make the application produce insecure keys, please do patch it, and I will update my post with the changed application. I was told that by default OpenSSL uses /dev/random for getting it's entropy, but I've heard in a lot of places that /dev/random might not exist under Android, so this should be looked into.

If by chance it does produce insecure keys, do remember I've said it's in Alpha stage and you shouldn't really use the private keys produced.

[jasinlee]

Any updates to this yet?

[bitpop]

Updates?

[gadman2]

Links are broken.

[Remember remember the 5th of November]

Link to sources work, plus, always better to build from source. As for updates, well I was pretty clear that there was no interest in the project so I have not worked on it at all.

[jasinlee]

Link to sources work, plus, always better to build from source. As for updates, well I was pretty clear that there was no interest in the project so I have not worked on it at all.

If you were to add a windows gui for it with all the different coins then I would kick in 1 btc. I want a faster way to get a ltc vanity address.

[Remember remember the 5th of November]

Link to sources work, plus, always better to build from source. As for updates, well I was pretty clear that there was no interest in the project so I have not worked on it at all.

If you were to add a windows gui for it with all the different coins then I would kick in 1 btc. I want a faster way to get a ltc vanity address.

Erm, this is for Android, so I am not sure how a Windows(Microsoft?) GUI would help here.

[bitpop]

Lol

[jasinlee]

I assumed you would understand I would be looking for a version for windows based on what I said.

[bitpop]

But there's already a Windows one of which this one was BASED on

[Remember remember the 5th of November]

But there's already a Windows one of which this one was BASED on

Exactly! In fact, I've borrowed the main loop from VanityGen by samr7, and glued the code to Android via JNI, I've also borrowed from BitcoinJ, but most of the Java code is mine. It isn't explicitly mentioned, but I am not much of a copyright person, anyway, it's open source so...

[jasinlee]

But there's already a Windows one of which this one was BASED on

Exactly! In fact, I've borrowed the main loop from VanityGen by samr7, and glued the code to Android via JNI, I've also borrowed from BitcoinJ, but most of the Java code is mine. It isn't explicitly mentioned, but I am not much of a copyright person, anyway, it's open source so...

I hadnt seen a ltc one just btc.

[Remember remember the 5th of November]

But there's already a Windows one of which this one was BASED on

Exactly! In fact, I've borrowed the main loop from VanityGen by samr7, and glued the code to Android via JNI, I've also borrowed from BitcoinJ, but most of the Java code is mine. It isn't explicitly mentioned, but I am not much of a copyright person, anyway, it's open source so...

I hadnt seen a ltc one just btc.

The program has had LTC support for some time now. Just look at the screenshot on the first page what it says https://bitcointalk.org/index.php?topic=101612.0

[jasinlee]

So I can run a vanity gen on windows for ltc your saying?

[bitpop]

of course use
vanitygen -X 48

[mogrith]

Link to sources work, plus, always better to build from source. As for updates, well I was pretty clear that there was no interest in the project so I have not worked on it at all.

Well almost no interest. Is this also affected but the now corrected random number bug in android?

[forumaster]

Links are broken, i can't download it, my personal computer is broken, so i need to generate my addresses with my smartphone, please op, can you re-upload the normal version?