Kindle 3 wifi keeps deleting Developer Keystore every time wifi is turned on.

[fireether]

Hi,

I registered just to post this. I also found a solution (kind of) for the issue. I'm more than happy to post my notes, but first wanted to know if anybody else had this problem. I've searched the forums and couldn't find anything.

First of all, my k3w is jail broken with ver 3.4 installed. My issue is that my Kindle is not registered, yet every time it connects to the internet - it will check to see if the device is registered and then delete the developers keystore (which I installed from KUAL prerequisites) and then leave a nice document in my home titled: "Test Kindle Installation Result".

I've reinstalled the key store, but every time I go online it gets deleted.

Anybody else have this issue? If so, how did you solve it? I'll post my notes once I know for sure that this isn't a duplicate of another post.

[fireether]

Just found this thread that dealt with this problem.
https://www.mobileread.com/forums/sho...d.php?t=194795

My solution was to add a line to the hosts file.

echo "192.168.5.2 firs-g7g.amazon.com" > /etc/hosts

I guess I'll have to try chattr versus the above solution and see which uses the least amount of CPU - i.e. spamming log with "cannot delete" versus trying to connect to the server (and not getting a response).

I also found where in the java file this is done.

[knc1]

Originally Posted by fireether

First of all, my k3w is jail broken with ver 3.4 installed. My issue is that my Kindle is not registered, yet every time it connects to the internet - it will check to see if the device is registered and then delete the developers keystore (which I installed from KUAL prerequisites) and then leave a nice document in my home titled: "Test Kindle Installation Result".

I've reinstalled the key store, but every time I go online it gets deleted.

Anybody else have this issue? If so, how did you solve it? I'll post my notes once I know for sure that this isn't a duplicate of another post.

That is a normal part of the registration process.
Just register the device, **THEN** re-install the key store.

The diverting by domain name is a poor idea - it only takes the address owner a few minutes to change and/or add a new name. Rendering your solution suddenly useless.

Blocking by address range is harder (and much more expensive) for the address owner to avoid.
That is the method used in the BBB (Block Big Brother) filter of the KUAL.firewall, you might want to try that instead of your own solution.

PS: Your command example presumes that **ONLY** your re-direction should be present in /etc/hosts. The removal of the other entries in /etc/hosts will probably break a few things on your machine.
So better to use the append ">>" rather than replace ">" operator.

[fireether]

Originally Posted by knc1

That is a normal part of the registration process.
Just register the device, **THEN** re-install the key store.

The diverting by domain name is a poor idea - it only takes the address owner a few minutes to change and/or add a new name. Rendering your solution suddenly useless.

Blocking by address range is harder (and much more expensive) for the address owner to avoid.
That is the method used in the BBB (Block Big Brother) filter of the KUAL.firewall, you might want to try that instead of your own solution.

PS: Your command example presumes that **ONLY** your re-direction should be present in /etc/hosts. The removal of the other entries in /etc/hosts will probably break a few things on your machine.
So better to use the append ">>" rather than replace ">" operator.

I was going for append, but accidentally did replace. In my defense, that was after two hours of going through java code. I was trying to see if perhaps the java app was checking for a setting before checking the developer keys.

As for diverting by domain name - you have a good point. However, looking at packet captures by wireshark (mirrored my wireless router on my managed switch and captured everything going from/to the kindle) shows that when wireless is turned on, it immediately does DNS look ups for a few names.

dogvgb9ujhybx.cloudfront.net
dns.kindle.com
ntp-g7g.amazon.com
todo-g7g.amazon.com
firs-g7g.amazon.com

No idea what dog is for, but the rest are used. Also looking in other configuration files, it has todo and firs explicitly defined. So doing the redirection works - I should also add todo because it does a https connection ONLY to todo and firs - in case they can update through that route.

My question was, which takes more CPU - simply putting 2 lines into hosts in which the servers for amazon (namely firs and todo, don't want to touch NTP because that keeps my clock correct) - or blocking by ip range? I'd assume the latter. And thank you for referencing me to the KUAL firewall - I didn't know it had a BBB filter.

Originally Posted by knc1

Blocking by address range is harder (and much more expensive) for the address owner to avoid.

What do you mean by this? I understand the "harder" part - i.e. they would have to write code that would be called infrequently to check and modify ipchains/iptables/hosts - but don't understand the expensive part. Mainly because they can easily update their code or write a shell script that runs via cron. MD5 checksums is one way to verify that stuff has been changed, and can revert it back to original.

I did not know that registering stops the checks. I have not investigated the behavior of the java app while the kindle is registered - I assumed it would be like the Xbox - i.e. if you modify it and you login to xbox live, you can be banned.

Last but not least, does anybody have the original /etc/hosts file for a 3.4 k3w? That way if I have to update the OS, the checksum will be correct.

Thanks.

[knc1]

Why expensive ? Because address blocks are sold, not 'free'.

IPv4 address block ranges are hard to get and purchase. The Kindles do not (yet) use IPv6 networking (their Wifi connectivity provider AT&T does not (yet) support IPv6).

Also, you do not have to announce to Amazon whenever you get your clock set - - -
There is a KUAL.ntpdate button for that, using public NTP networks and/or servers - which allows the end-user to change from the defaults that it ships with.

Since these are **NOT** Amazon NTP servers, the ntpdate button works with the KUAL.firewall installed and the BBB filter enabled.

You might also want to checkout the KUAL.backdoor_lock application.
(I did not write that one - but it seems to be well thought out and well tested.)