Thread: NAVIGON Europe v5.9.0 patched

I do know the German discussions about this message; in fact some of my solution attempts were based on their recommendations.
By chance I discovered a potential root cause, but am currently unable to 'repair' it:
not the IMEI may be the rejection reason, but the hardware SERIAL number, which is '123..EF'. Assuming that even the cracked versions do a SN match check, this may cause the decline of service and 'an error has occurred'. Most likely MANY devices report this common serial number and few apps seem to care for it.
Unfortunately I am too stupid to manage XPrivacy, as I have not found a way to inject a different or even random SN at that moment (I can block it, but that is of no help).
And the alternative and promising app 'DonkeyGuard' is not working at all, crashing right after every attempt to run it in the XPosed shell. There may be other tools to replace serial numbers on the fly.
I will pursue this attempt, still fighting for a solution and to boost of my ego... never give up!

I just installed both cracked versions, the one from this thread and the latest Amazon one, on my new Samsung Galaxy J5 dual-SIM, and as expected and stated by others, no IMEI issue. Only the Telekom Select Edition is IMEI sensitive.

If you think you're on the right track w/ faking a different serial number; good luck with that.

Also you might want to try and install the [Only registered and activated users can see links. ] just to see how that one behaves.

This is getting ridiculous:
- even the (hopefully functional) injection of a new IMEI and Serial Number with XPrivacy has not solved the issue
- installation of the free version worked, and it would start correctly multiple times, for ONE day. The following day I got the same 'An error has occurred' message...WTF?

I am now considering the cumbersome 'carefree package' method offered elsewhere. It is so complex and error prone that I really wanted to avoid it, yet what else could I possibly try? If even the official version downloaded from the Playstore is failing on day #2, this hack will probably fail as well.

The very last attempt is to use a brandnew SIM card, create a new Google identity with it, and then install the app once more.
I have no clue what this weird app is trying to verify and why it fails utterly for me, regardless what version I am trying to run.

My final verdict, after examining all my findings so far:
- the root cause of my (and apparantly just MY) problem is a fatal combination of two issues: Navigon relying on specific system IDs and my tablet unwilling to 'alter' its generic SN data.
- The S/N change app I tried reported 'success', but showed the old and wrong one ("123456789ABCDEF") after each restart anyway, a first suspicious hint
- the permission controller tool DonkeyGuard does install, but crashes whenever started without even showing a splash screen, apparently losing the battle against my Android 5.1; another suspicious hint that matches the first one.
- the XPrivacy tool allows to block these IDs (useless); when trying to alter and save the critical ones it will show the randomly generated fake numbers but will not store them. As soon as I peek into the 'Settings' after saving, IMEI and SN are shown as '0000' and 'DEFACE' again. So it most likely feeds the original IDs to Navigon each time it starts, causing the 'an error has occurred' reaction.
- even the installation of the free trial version of Navigon exposes the same issue, on day #2, after working fine on day #1 (so they seem to check the ID not right away)
That solidifies my assumption that all these tools basically fail for a similar reason; with different reactions.

Quintessentially this means that my rooted China tablet, despite running on stock API 22 (Lollipop_MR1), uses internal trickery to prevent any attempt of altering the system IDs, for whatever reason.
Maybe the flashing of a new image or other Android version could solve the problem? But I am not willing to take chances just for the installation of this f.cking navi app.

What appears to be really needed is a version of Navigon that either circumvents these ID checks at startup entirely. Or that creates a random S/N value at installation time, that will be used inside this app whenever it is started later. Only needed for folks with a generic SN '1234..DEF' AND a locked down system that does not allow for the faking of real numbers. A miniscule number of users would benefit, no modder will ever go that route - bummer..

So Navigon DID win this battle against me after all - I lost the war.
Yet they did not squeeze a dime out of me either; so I will leave the arena 'heads up' anyways!
I wonder if they would refund me in such a case, if I had purched this frigging application that cannot work due to stupid verification checks?!


Most likely the modded version offered here in this thread is OK for most other users, just not me.
Sorry for the intrusion.

wow - what an ordeal - I feel for you. Had gone through similar digital warfare at some point, just not with Navigon. I doubt you are or will be the only one, so you can at least feel good about sharing your insights.

But before you give up completely.. have you tried [Only registered and activated users can see links. ] yet (the Google Docs page might need 30 secs or so to generate)? It's fairly recent and does accept the most recent new maps, too.

Before you install it, make sure you remove all other Navigon completely (force stop, delete cache, delete data, uninstall).

Let us know hot it goes. Good news hopefully, finally. Fingers crossed, thumbs up.

Thanks, but this file version is in my archive already; so I am quite sure I have tried it as well, with no luck.

Since my real dilemma is with the generic serial number (and all tested tools failing to 'fix' it) I am now pursuing methods to alter it manually.
I am aware that this is totally OFF TOPIC here; yet I want to share my current findings, for those few who have this damn '123456789ABCDEF' issue.
The most promising approach appears to be an ADB command sequence that I dug up somewhere.
Albeit I do not understand its rather cryptic 'presentation'. A clean step-by-step command sequence would sure help.
If anyone can point me in the proper direction (best site to ask, or a complete script to use), please let me know, thanks!

This is what is supposed to create a different Android device S/N in any case:

"
adb shell
su
mount -o remount,rw /system
vi /system/etc/install-recovery.sh
# edit, save and exit
mount -o reount, ro /system
And here comes the line to add to /system/etc/install-recovery.sh to make the magic happen:
echo -n NEWSERIAL123 > /sys/class/android_usb/android0/iSerial
"

I assume that the 'edit' means to enter the special "echo" line in the install-recovery.sh file?
I may need to swallow more "Tongkat Ali" pills to develop the balls for hacking into the recovery area...

LOL right on, Tongkat Ali wll do ..

If I were you, before more hacking, I'd do a full backup via TWRP or alike, wipe all, restore stock firmware ROM, and see if either the cra**ed Amazon or this one works steadily. If so then it might make sense to apply a more compatible custom ROM.

One of the various 'changer' tools allowed for a successful change of the Android_ID (not S/N, mind you). Of course with no impact on the Navigon app, as it really relies on the S/N, which is oddly frozen on my device.
I do have the TWRP backup, and besides the root everything else is 'stock' as there is very little activity around this fake tablet from Voyo (sold as 6.0 with 1.5GHz and 5Ah, in reality a crappy API 22 device with 1.3GHz and 4Ah battery). Russians hacked it somehow and even tinker with a Android 7.0 update, but I really do not want to mess with it that much. 250 apps are running just fine, just no Navigon at all.

Maybe I can find some help at XDA where I will officially ask for a method to fix a "frozen" serial number for good, if on the fly each time I boot this thing, whatever.
It is my utter belief that a unique S/N will cure my problem, and most likely future similar issues as well.
Until then I am swallowing pills...
Thanks for the continued support and ideas.