Hacker's ramblings

I created a new tool to obsolete the classic B593cmd.pl ping-exploit tool. I wrote that one almost a year ago to run any commands on your B593. That could be used to lift IPtables restrictions or get your sshusers.cfg contents.

Now that Mr. Ronkainen found out that pre-SP100 firmwares have another flaw, which is much more simpler to exploit, I wrote a tool to combine both of them into a single package.

Neither one of these work in SP100+ firmwares, but not to worry! They have SSH-port open for full access anyway. So ... getting a SP100+ firmware into your box should be your target anyway. This tool can help you gain access to your box.

The B593_exploit.pl tool is at http://opensource.hqcodeshop.com/Huawei%20B593/exploit/latest.pl. In the top of the file there is a list of Perl-modules it requires to run. You will get the complaints, if any are missing. Usage:

./B593_exploit.pl --help
Usage: B593_exploit.pl
--help|-h       This help
--run-cmd       Run a command: pre SP-100 ping-exploit
                to run any command via web-console
--telnet-login  Login via telnet: lift IPtables firewall from telnet and login

Ping-exploit -mode

This is the classic. Run example:

./B593_exploit.pl --run-cmd 192.168.1.1 admin "iptables -nL INPUT"

There are couple of bugs fixed, it should be more robust and has --debug -mode in it.

Telnet-exploit -mode

This is the newer one. Run example:

./B593_exploit.pl --telnet-login 192.168.1.1
Attempt 1 telnetting to 192.168.1.1


BusyBox vv1.9.1 (2012-03-01 14:00:34 CST) built-in shell (ash)
Enter 'help' for a list of built-in commands.

# iptables -nL INPUT

Ok. It's not a full telnet-client like you'd a regular telnet to be. This emulates one with Perl's Term::Readline, so your vi won't work or tab-based command-line completion. However, it has enough power in it to allow you to run commands and display contents of the files or fiddle with your IPtables.

In my next post I'm about to release a tool for editing and storing values of your curcfg.xml. This is a prerequisite, getting to the prompt and running stuff on the prompt is a must-have.

The common consensus is that iPhone screen is too small. For example a Finnish journalist wrote (article is in Finnish), that "Soon iPhone will suit me too". As everybody is expecting a bigger screen iPhone to be released. I've had enough and will blog about that.

I'm saying, that the iPhone screen-size is pretty good and doesn't need to grow much bigger. I'm agreeing what Tim Cook says Apple struck on right screen size with iPhone 5. Currently 4S and 5S -sized phones fit into everybody's pocket. Example:

Image courtesy of iClothing.

Or in a Wired review Samsung Galaxy Note - Big Phone, Big Hassle:

Image courtesy of Wired

If that doesn't look ridiculous, then I don't know what does. That's the direction you want to go by crying "too small screen" all the time!

Let's study history a bit. In May 2014 Apple Insider had an article Before Apple's iPhone was too small, it was it was too "monstrously" big. Yeah, that's right! There is evidence, that the screen size was never just the right size. Still a number of studies show, that people are not happy with current screen sizes. Example:
In this article How would you feel if the iPhone 6 didn't have a bigger screen?
"I can say my iPhone usage has decreased over time because it's just too small for me now"
- Chris Parsons

Or example 2:
People want their next phone to have a big-a** screen, survey says

Or example 3, Sales of those ridiculously big phables are way up:
Phablets Will Outnumber Tablet Sales Three To One By 2018

So, pretty much everything is in line with people screaming to have bigger screens for their mobile appliance. How about a reality check. ZDnet has a review of best tablets (Top Android tablets (April 2014 edition)), their list is:

1. Samsung Galaxy Tab PRO 10.1
2. EVGA Tegra Note 7
3. Amazon Kindle Fire HD
4. Amazon Kindle Fire HDX
5. The Google Nexus 7
   

Or Amazon Best Sellers in Tablets:

1. Kindle Fire HD 7", HD
2. Apple iPad Mini 16GB
3. Apple iPad Mini 16GB
4. Apple IPAD AIR WI-FI
5. Cheapest Android KitKat
6. Apple Silver IPAD AIR WI-FI
7. Kindle Fire HD 7"
8. Apple 7.9-inch iPad Mini Retina
9. Apple IPAD AIR WI-FI 32GB
10. Asus Google Nexus 7

Now there is a pattern. People want something that has 7" screen. In ZDnet top-5 has only one 10" tablet, in Amazon #4, #6 and #9 are all iPad Airs with 10" screen. Everything else is 7".

It looks like iPhone has too small screen, because it is not 7". Feel free to say I'm wrong, but I think general consensus has it wrong. They're expecting iPhone to be something that it isn't.

Trend Micro reported that they found a backdoor from Netis/Netcore firmware. It is a quite serious one allowing remote code execution from the Internet side. Sure, the backdoor is "protected" by a password. As you may expect, the password is hard-coded, cannot be changed and is exactly same in each unit. Nice "security", huh!

Why doesn't this surprise me? Mr. Ronkainen, who is a really keen B593 hacker did find the Huawei internal documentation (available from the entire Internet, of course) Log_Capturing_Guide_of_LTE_CPE_B593_V1.2.docx. It describes following "Step 5 Enter admin after Login and press Enter. Then enter the password -removed- and press Enter". Actually, according to Mr. Ronkainen, the same password is the hard-coded password of serial-console. In reality, some soldering is required for serial console to work, but if you do ... there goes your security.

All B593 hacking always reveals hard-coded encryption keys and passwords. My conclusion: that poor security in these produced-as-cheaply-as-possible devices is by design, and it cannot be changed. Not too many samples in my "research", though. I don't mind having fixed default passwords, you can go and change them. These Chinese units, have fixed passwords, which is yet another story.

Again, I thank Mr. Ronkainen for sharing his findings. Even website https://www.sec-consult.com/ crredits him for his findings in SEC Consult Vulnerability Lab Security Advisory < 20140122-0 >.

I tried to upgrade my Supermicro SuperServer 5015A-EHF-D525 IPMI BIOS to have the Heartbleed fixed in it. It failed on me. Badly. When I run:

lUpdate -f SMT_316.bin -i kcs -r y

The not-so-friendly response is:

If the FW update fails,PLEASE TRY AGAIN
update part 0, the size is 0x800000  bytes
Transfer data ................
40K bytes      1%ERROR !! BMC did not in correct state
ERROR:SEND "ReceiveFWData" COMMAND TO BMC FAILED

It looks like Supermicro's Linux upgrade tool is the culprit. It enters BMC upgrade mode, starts pushing bits to FlashROM, and then segfaults. I tried couple of BIOS-versions, but to make things worse, I was going from version 2.x to 3.x and there was no downgrade possibility anymore. The BMC was semi-concious, but it really couldn't do much. For example, it didn't have a proper MAC-address, and its networking was effectively out of play.

The worst part of this failing upgrade is, that to get the BMC upgrade mode disabled, you need to pull the plug. If there is electricity connected to the machine, the BMC will stay on.
Update:
Also the ipmitool bmc reset cold helps.

Luckily, there are couple of options for accessing the BMC directly from OS-side. One of them is IPMItool, but it didn't yield any results. The BMC was stuck somehow. Same story with manufacturer's IPMICFG.

I was almost going to give on on this and was planning to RMA it to Supermicro support in Netherlands. Then a newer version of IPMI BIOS was released and I attempted to upgrade into it. Same story, Linux utility crashes badly causing havoc. As the last move, I USB-booted the hardware into DOS-mode. There is a flash-utility in their ZIP-file for DOS. IT WORKED!! How lucky was that!

The new BIOS-version was sane, it knew its own MAC-address and started operating properly. I was so happy!

Who would have thought, that DOS was abandoned almost 20 years ago, and it once more saves the day.

As promised, here are my presentation slides from Helsinki Security Meetup from August 20th 2014. I did redact my e-mail address to prevent spammers harvesting it. I get enough spam already.

Presentation slides

In PDF-format: 2014HelsinkiSecurityMeetup.pdf

My backdoor C-code

Here it is: backdoor.c

There is no makefile or anything, a simple gcc backdoor.c -o backdoor will do the trick.

Running backdoor

In my demo, there was the insecure directory (run ls -Z to display the file contexts):

-rwxr-xr-x. root root unconfined_u:object_r:httpd_exec_t:s0 backdoor
-rwxr--r--. root root unconfined_u:object_r:admin_home_t:s0 start.backdoor-1.sh
-rwxr--r--. root root unconfined_u:object_r:initrc_exec_t:s0 start.backdoor-2.sh

and one secured directory:

-rwxr-xr-x. root root unconfined_u:object_r:backdoor_exec_t:s0 backdoor.secure
-rwxr--r--. root root unconfined_u:object_r:initrc_exec_t:s0 start.backdoor-3.sh

When running as httpd_t, remember to add the port into Apache allowed ports:

semanage port --add -t http_port_t -p tcp 8282

To (temporarily) change a file context, run a command like:

chcon -t backdoor_t backdoor

To permanantly change the file context,:

semanage fcontext -a -t backdoor_t /a_directory/backdoor

Now, the change will survive a restorecon-call.

What has changed after the presentation

To save system resources with one process, I changed the content of start-backdoor.sh scripts from:

#!/bin/bash

./backdoor.secure

to:

#!/bin/bash

exec ./backdoor.secure

I fixed the bug in fork child code mentioned during the presentation. Now a failing execvp() call does not leak processes. And while at it, I made failing more verbose. It will display the failure both on server and client ends.

During presentation, my backdoor-policy allowed binding the backdoor to any port. I added more security to that, and allow binding only to backdoor_port_t To get the secured backdoor running, you need to remove the TCP/8282 port from Apache, and add it to backdoor:

semanage port --delete -t http_port_t -p tcp 8282
semanage port --add -t backdoor_port_t -p tcp 8282

You can list the allowed ports with a command like:

semanage port -l | fgrep http_port_t

The SElinux backdoor policy files

The package is: backdoor_policy.tar.bz2

Remember to add the package selinux-policy-devel for make to work. Install the newly created policy with following command:

semodule -i backdoor_policy.pp

The new module will survive a system reboot.

What has changed after the presentation

Lot of unnecessary permissions have been dropped. backdoor_t can bind only to backdoor_port_t, not all ports. I also enabled backdoor_t writing to stdout, it helps to see what's going on. It is not typical for daemons to be allowed that, but especially when execvp() fails, it is so much easier to visualize SElinux policy kicking in.

Any comments are welcome!

During the quest of hacking my u-12, Mr. Ronkainen from blog.asiantuntijakaveri.fi insisted, that the certificate files in /etc/ are actually used. My personal belief was, that the purpose of having those would be something not-so-important. It turned out, that I badly misjudged the situation.

My firmware has these files:

# cd /etc/
# ls -l *pem
-rwxrwxrwx    1 0        0             963 privkey.pem
-rwxrwxrwx    1 0        0             963 privkey.b593pem
-rwxrwxrwx    1 0        0            3700 cachain.pem
-rwxrwxrwx    1 0        0            1751 b593cpekey.pem

Please note, that the files are in a Read-Only -partition. They are not unique to my device! Your u-12 should have the exactly same files like I do. Also note, that pre-SP100 firmwares are using different encryptions and may not have those (I didn't bother to check).

The cachain.pem is the trivial one. It contains two CA-certificates issued by Huawei expiring 2040 or so. That is a very common PKI-procedure to have the public certificates in a device to make sure, that the actual certificate being used can be verified to a trusted root-CA. There is very little interesting about that file.

However, the remaining PEM-files are more interesting. The exact purpose of b593cpekey.pem is yet unknown. It is an 3-DES encrypted private key to something. If you want to take a peek into the file, the encryption password is CPE-B593-12 as Mr. Ronkainen dug out of the libraries. A command like this will tell us more:

# openssl rsa -in b593cpekey.pem -noout -text -passin pass:CPE-B593-12
Private-Key: (2048 bit)
...

It is a 2048-bit RSA key. If you know what the key is used for, please tell us.

The remaining files privkey.pem and privkey.b593pem are exactly the same. To me it looks like poor engineering. Libraries seem to be using the latter filename, but my guess is, that somebody is using the first one too. The password for this private key was also recovered by Mr. Ronkainen, it is lteb593. Basic information recovery:

# openssl rsa -in privkey.pem -noout -text -passin pass:lteb593
Private-Key: (1024 bit)
...

Hm. handy, but the really interesting part is where this file is actually used. This information was recovered by Mr. Ronkainen with looking at the GUI admin traffic via Wireshark.

If you go change the admin password at System -> Password change (the frame source would be http://-the-IP-here-/html/management/account.asp), you can see the HTML containing tags for loading a number of JavaScript files, the most interesting ones are /js/account.js and /js/rsa.js. The actual password change code from account.js is:

function AddSubmitParam(SubmitForm,type)
{
  var cfgUsername = ADMIN_USER_NAME;

  SubmitForm.addParameter('cfgUsername',cfgUsername);
  SubmitForm.addParameter('Userpassword',MyRSAEncryptB64(getValue('id_cfmPassword')));
  //SubmitForm.addParameter('Username',ADMIN_USER_NAME);
  SubmitForm.addParameter('OldPassword',MyRSAEncryptB64(getValue('id_oldPassword')));

  SubmitForm.setAction('chgacount.cgi?RequestFile=/html/management/account.asp');

It RSA-encrypts the value from form field with id id_cfmPassword! Wow! They really beefed up their security. The RSA-code is at /js/rsa.js and it contains:

// Return the PKCS#1 RSA encryption of "text" as a Base64-encoded string
function RSAEncryptB64(text) {
  var h = this.encrypt(text);
  if(h) return hex2b64(h); else return null;
}

...

//my encrypt function, using fixed mudulus
var modulus = "BEB90F8AF5D8A7C7DA8CA74AC43E1EE8A48E6860C0D46A5D690BEA082E3A74E1"
             +"571F2C58E94EE339862A49A811A31BB4A48F41B3BCDFD054C3443BB610B5418B"
             +"3CBAFAE7936E1BE2AFD2E0DF865A6E59C2B8DF1E8D5702567D0A9650CB07A43D"
             +"E39020969DF0997FCA587D9A8AE4627CF18477EC06765DF3AA8FB459DD4C9AF3";
var publicExponent = "10001";
function MyRSAEncryptB64(text)
{
    var rsa = new RSAKey();
    rsa.setPublic(modulus, publicExponent);
    return rsa.encrypt_b64(text);
}

It surely is RSA PKCS#1 encryption implemented with JavaScript. That's really cool! A complete PKCS#1 library implemented with a completely wrong language. I didn't realize, that having a fully functional RSA-library with JavaScript was even possible, but there it is.

Next I took the public key modulo and exponent from the above JavaScript-code and used Per Olesen's tool from https://gist.github.com/polesen/2855098 to re-create an actual PEM-file from those ingredients. Mr. Olesen has a nice article Converting RSA public key Modulus and Exponent into PEM file about that.

The resulting PEM-file is:

-----BEGIN PUBLIC KEY-----
MIGeMA0GCSqGSIb3DQEBAQUAA4GMADCBiAKBgQC+uQ+K9dinx9qMp0rEPh7opI5o
YMDUal1pC+oILjp04VcfLFjpTuM5hipJqBGjG7Skj0GzvN/QVMNEO7YQtUGLPLr6
55NuG+Kv0uDfhlpuWcK43x6NVwJWfQqWUMsHpD3jkCCWnfCZf8pYfZqK5GJ88YR3
7AZ2XfOqj7RZ3Uya8wICJxE=
-----END PUBLIC KEY-----

and a simple verify run with OpenSSL for both the private and public keys confirm, that we have a pair:

# openssl rsa -pubin -in privkey.pub.pem -noout -modulus | md5sum
92e88d0b38fe93cd41a000b3c0b1928e  -
# openssl rsa -in privkey.pem -noout -modulus -passin pass:lteb593 | md5sum
92e88d0b38fe93cd41a000b3c0b1928e  -

Both keys have the same modulo in them, thus, they are the private and public parts of the same key. Excellent!

Credits go (as usual) to Mr. Ronkainen for his hard work in hacking the B593. Also Mr. Olesen deserves thanks for his ready-made tool (which btw. builds in my Linux easily) for putting the PEM-parts back together.

Final credits go to Huawei engineers, this time they took data encryption really seriously. However, when you're in a leaking boat, it really doesn't matter if you have the best motor or not, your boat still leaks. In this case the critical information (like encryption keys) are hard-coded, used in every device they manufacture and recoverable in plain-text format. It looks like Huawei is suffering from the weakest-link-in-your-security -syndrom. If your FTP is flakey, you store your SSH-passwords in plain-text format and let people in as they please, they are likely to find this stuff out!

... More to follow about SSH and web-GUI user password encryption. This was a very critical find in the path of full disclosure.

A fellow B593 hacker Mr. Ronkainen from blog.asiantuntijakaveri.fi informed me about his findings regarding /var/curcfg.xml password encryption. This is something I did already spit-ball with him in comments, but this time he had something concrete to show.

This is for decrypting an FTP-password. Since you can set your own, you definitely know what the plaintext password is. His findings are:

exe->Data_DbDecrypt(nil, "llxYjYnY:\021\003\2324\275\241\233Wu\353$Vx;\333#", "", "" <unfinished ...>
exe->strncpy(0x7facddd8, "llxYjYnY", 8)          = 0x7facddd8        (Data_DbDecrypt)
exe->strcpy(0x7facdaf8, "12345678")              = 0x7facdaf8        (Data_getProductInfo)
exe->strncpy(0x7facdb01, "12345678", 9)          = 0x7facdb01        (Data_getKey)
exe->strncat("12345678", "llxYjYnY")             = "12345678llxYjYnY"    (Data_getKey)
<... Data_DbDecrypt resumed> )                   = nil
exe->strcpy(0x4ce009, "BBBB")                    = 0x4ce009

The first call is for the raw input data. It clearly contains 8 characters, a colon (:) and something encrypted after it. Then there is a surprising part, call to a function named Data_getProductInfo() returning hard-coded 12345678 every time. Based on the code, the "product info" is simply concatenated into the Base64-decoded 8 char prefix, forming a 16 byte encryption key.

I've already speculated, that they changed encryption in SP100+ from 3-DES to AES. Based on the function names in firmware libries, combine that with knowledge of block ciphers and give it a go with AES-128 ECB with the above keying. Hey presto! It works!

I wrote a public tool for doing password encryptions/decryptions: http://blog.hqcodeshop.fi/B593/password_recover.php The sources for my web-thing are also there, if you want to use that by yourself.

As you can see from the form, I cannot work with the previous 3-DES stuff. It's simply because I don't know what the key/IV are. There is also another thing with web-GUI and SSH-passwords. They are not using the above keying mechanism. My speculation is, that they are using AES-256 (possibly in ECB-mode) for those, but I have no details about the key.

If you want to test the password recovery, you'll need your /var/curcfg.xml at hand. Pick an encrypted password from that, for example:

<X_FTPServiceInstance InstanceID="1" Username="test" Password="bU50RkQ1T2o6UNkuA7Bdj40/TiNehA6fDw==" FtpUserEnable="1" Privilege="2" Path="usb2_1/../.."/>
or
<WEPKeyInstance InstanceID="4" WEPKey="bU50RkQ1T2o69goRBo2nWOh00YDVCHLGDw=="/>

Select web-form Target as FTP-user, copy/paste the value from XML Password-field into Base64-encoded and klick decrypt. It should give you "test" as Plain-text value. There is another example for Wi-Fi WPA-key, it says WEP in the XML-file, but we can ignore that.

I'll keep investigating the other passwords too. Mr. Ronkainen suggested, that something in the box could be encrypted with PKCS#1, but the block size is off, at least in passwords. Stay tuned for more updates.

All the nerds like me (escpecially me!) love new versions of software.

Backup

I got new toys for my Parallels Plesk Panel box and went for the automated upgrade. I attempted to do the mandatory full backup first:

/usr/local/psa/bin/pleskbackup server \
 --output-file=/Backups/pre-12.0.18.backup.tar -v -v

... just to make sure, that I have something to roll back to if it hits the fan. But it kept failing on me. Any domains having PostgreSQL databases failed to backup properly. I got log entries like:

Failed to execute backup database
Failed to pack files backup_hqcs_blog_1407141359 in /dumps/domains/hqcodeshop.fi/databases/hqcs_blog [ 115057410048 bytes free of 158532106240 bytes total on mount point 0]

Totally puzzling. Didn't make any sense at all! Looking at the detailed XML-log of the backup revealed following:

<?xml version="1.0" encoding="UTF-8"?>

<object name="server" type="server">
    <object name="hqcodeshop.fi" type="domain" uuid="domain#hqcodeshop.fi">
        <object name="hqcs_blog" type="postgresql">
            <message id="e6d718ef-5b52-49af-8c4f-4473393b30bd" severity="error" code="msgtext">
                <description>Failed to execute backup database</description>
            </message>
            <message id="d5e6cfd1-fa94-45d4-89b6-a47a0627134a" severity="warning" code="msgtext">
                <description>sh: AB12: command not found
                    sh: AB12: command not found
                    sh: AB12: command not found
                    sh: AB12: command not found
                    sh: AB12: command not found
                    sh: AB12: command not found
                </description>
            </message>
        </object>
    </object>
</object>

What command not found!? After a few puzzling moments later I realized it, that is the end of my panel admin's password! In the original form the password was [lot of characters here]>AB12. Somebody at the Parallels goofed! What would happen if your password has special characters. What if some of those characters were special in your command prompt? Not very solid backup code, huh!

The next thing was to change the password to one not containing any of these characters £$<>()&;"'`, they have special meaning on *nix command prompt. I always use randomly generated passwords and during my quests I regularily bump into systems that do not sanitize user input properly. I find that the ones from the number keys with shift are especially nasty. During registration process it is very easy to input a proper random passwod, but the system botches something and don't let me log in, or does something nasty like Parallels Plesk did.

Unfortunately changing the admin password didn't make the backup succeed! Apparently PostgreSQL password is stored somewhere else. I did do a:

/usr/local/psa/bin/admin --show-password

... to confirm, that system knows what the new password was. The thing is, that PostgreSQL password needs to be changed manually. I found the knowledge base article about that KB 120262 - How to update password for PostgreSQL admin user in Plesk? Running:

# plesk bin database-server --update-server localhost:5432 \
 -type postgresql \
-passwd `/usr/local/psa/bin/admin --show-password`
SUCCESS: Server localhost:5432 is successfully updated.

... did solve it. Then I managed to get backups.

Upgrade

There were no issues during upgrade. The web-upgrader took a while and then it said everything was done. There really was nothing special about this part.

During my checkings I found a really good knowledge base article about system settings. This is something that Parallels didn't have for previous versions. This is really good stuff: Parallels Plesk Panel for Linux services logs and configuration files. I kept going back to that one a lot.

Testing

When the new version was running, I naturally wanted to see that all my services were running properly. Things I found to be broken were POP3 and IMAP SSL-certificates. Also the Presence Builder didn't upgrade properly.

The funny thing about Courier IMAP/POP3 was, that upgrade reset my certificate settings back to something really stupid. I went to /etc/courier-imap/ to check the imapd-ssl and pop3d-ssl. I changed both of them to contain:

TLS_PROTOCOL=TLS1

That was done to reflect the setting I have in my /etc/postfix/main.cf:

smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3

My policy is, that if you're running something that does not support TLSv1, v1.1 nor v1.2 then you should use somebody else's services. It simply is insane to rely on SSL!

The Web Presence Builder said this on startup:

File: /usr/local/sb/include/Base/ORM/Object.php; Line: 249
Message: Undefined property "controlPanelLink" in object "SB_ORM_TokenAccess".; Code: 0

Luckily, that issue is covered by knowledge base article KB 119875: Cannot open a site in Web Presence Builder: "Undefined property "controlPanelLink" in object "SB_ORM_TokenAccess". A simple SQL-command:

ALTER TABLE `token_access` ADD `control_panel_link` VARCHAR( 255 ) NULL DEFAULT '' AFTER `skin_code`;

did do the fix.

Life after the upgrade

My system has been running as usual. There hasn't been any complaints from the users or I have not encountered anything else that didn't work.

Something funny happened to my Arch Linux, it changed the IPv6 address rather surprisingly. When I failed to SSH into it, I went to the console.

On none of my machines I have the RFC 4941 privacy extensions enabled. The first thing to do was to confirm, that the IP-address was not based on my Ethernet Address:

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 52:54:00:cf:1c:36 brd ff:ff:ff:ff:ff:ff
    inet6 2001::e2:349d:bcc6:c9fc/64 scope global noprefixroute dynamic
       valid_lft 84267sec preferred_lft 12267sec

There is absolutely no reference to the MAC-address 52:54:00:cf:1c:36 of in the EUI-64 address 00e2:349d:bcc6:c9fc. Given the calculator result of 5054:00ff:fecf:1c36. Apparently something modifies the autoconfiguration address.

First culprit could be Linux kernel:

# cat /proc/sys/net/ipv6/conf/all/use_tempaddr
0

I even iterated all the configurations:

find /proc/sys/net/ipv6/conf/ -name use_tempaddr -print -exec cat {} \;

just to make sure, that privacy is off.

That was puzzling. What the heck is going on in the machine!! After all, it used to work ok before. What could be doing that?

Lot of googling around landed me on Arch Linux ArchWiki IPv6 page. It says: "dhcpcd includes in its default configuration file since version 6.4.0 the option slaac private, which enables "Stable Private IPv6 Addresses instead of hardware based ones", implementing RFC 7217". Hum? I've never heard of RFC 7217, nor "A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC)", but there it was.

I confirmed /etc/dhcpcd.conf and yes, it did contain a:

slaac private

in it. Why?! I didn't ask for it. I simply put a comment (#) in front of the line and did a:

systemctl restart dhcpcd@eth0.service

To refresh the situation. No change. A reboot. Yes change!

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 52:54:00:cf:1c:36 brd ff:ff:ff:ff:ff:ff
    inet6 2001::5054:ff:fecf:1c36/64 scope global noprefixroute dynamic
       valid_lft 86399sec preferred_lft 14399sec

Now my IPv6-address was exactly what it used to be. Weird incident, though. There is a perfectly good mechanism for privatizing addressses, if wanted to. But now somebody had created another and some higher power made a choice for me to start using it. Really weird! Well, I'm hoping that my addresses won't change any more.

One day I got an e-mail from Google+ saying: "HQ Code Shop Oy hasn't shared anything on this page with you". I was more than puzzled. Sure I haven't shared anything with myself on Google+.

I clicked the link and got to the page. It had a Manage this page -button at the bottom:

It didn't do much good:

All it said was: "We are sorry, but you do not have access to this service. Please contact your domain administrator for access". Aow come on! Why did you have to create a page for something that you don't own and don't let the owner to control!

I went to my Google Apps administration console:

Yes, I have Google+ enabled for myself. However, that didn't change anything. I still was not able to manage my own company's page.

Many hours of surfing the web, reading many absurd attempts to fix the problem, and nothing. Then I went back to the Other Apps -section and started reading the descriptions:

It says "Add or edit your local business listing on Google Maps" next to Google Places -service, which I hadn't subscribed. I enabled that and hey presto! Suddenly I was able to manage the page. Naturally I had to pass the automated phone call test from Google, but I finally got control of my own property.

This is yet another shame-on-you-Google -thing they do while going towards world domination.

I really don't understand why people complain about iPhone screen size being too small. Personally I'd rather carry a phone, not iPad. Also it happens that iPhone 4S is one of the best phones Apple ever manufactured, it is robust and take mis-handing, it is stable and never crashes on iOS 7. You cannot say that about previous or later phones. And IMHO the best feature about 4S is that it simply has the correct size!

My unit started showing symptoms of aging. Battery charge time was over 3 hours from 20% capacity to full, which felt like much longer time when my phone was new. I'm using Battery Doctor app to monitor the charging to keep my battery in a good shape, but the fact of life is that batteries wear on usage. It was time for me to replace it.

Going to an authorized Apple service was absolutely ouf of the question. I've always wanted to see what's inside my iPhone! The absolutely best thing is to get the new battery and tools for the service from iFixit.com. They even provide a very nice guide for the replacement job iPhone 4S Battery Replacement. As the obligatory warning part I'll simply say, that there are very small parts inside and provide this pic as proof:

That's set of iPhone screws on an euro 1 cent, which is on top of US quarter. The leftmost two screws are Phillips-head battery connector screws and the rightmost screws are original Apple Pentalobes. This should scare you away from ever attempting to do any of this stuff by yourself. If it doesn't, please read forward!

So, I put in my order and in a couple of weeks the box arrived from USA. The box contained:

• The replacement battery
• Phillips-head screwdriver to remove the battery connector and insert the liberator screws for the back lid
• Pentalobe-head screwdriver to remove the back lid
• Plastic tool for prying the battery loose from the sticky stuff it is fitted into
  

The first task is to remove the back lid. It can be done by removing the two Pentalobe-screws next to the bottom dock connector:

After the screws are removed, the back lid will slide bit upwards, that is away from the dock connector:

After that the lid should be loose and can be removed without applying force to it. It has some tricky plastic tabs on the sides, so please be careful with those. They're the ones actually holding the lid in place. Don't break them.

The guts of the phone look like this:

Next step is to remove the battery. This can be done by disconnecting the battery from the phone and then prying the battery loose from the glue. The battery connector looks like this:

It is mechanically not a tight one. First remove the two Phillips-head screws and the try to disconnect the connector pins by sliding the connector towards the battery, like this:

Warning: when the battery connector is loose, it is absolutely certain that you will remove a pressure connector in the process:

iFixit says "Pay attention to the pressure contact underneath the top screw of the battery connector. This may come loose while prying the battery connector from its socket". I already said: It will come loose! Just don't misplace it. Try to figure out how it was, to get it back in place.

Then pry the battery:

It is held in place by reasonable amount of gooey sticky stuff:

Now you have removed the battery! It is another story of getting it all back.

The battery looks like this:

Batteries from left to right: old backside, new backside, old front side, new front

Not much of a difference with the old and the new one. Based on the LMG 08/2013, my new one is manufactured about a year ago. It had 40% charge when I turned my phone back on, I guess that's ok.

Anyway, to put it back together, put the battery in it's slot and try to figure out how the connector cable goes so that it would be possible to put the connector screws back. Before actually placing the battery contactor, concentrate on the loose pressure connector. It should look like this:

Then put the battery connector and try to put the top screw in so, that it would hold both the battery and pressure connectors in place. Then put the bottom screw in. When done correctly it should look like this:

Then the last step is to put the back lid in, slide it to place and liberate your iPhone with the new Phillips-head screws:

After that you're done. Congratulations on your new battery!

When I first turned my phone back on, it didn't find my SIM-card. I don't know what happened, but everything else worked, except it never asked for my SIM PIN-code, nor ever found any telephone operators. I fixed the issue by shutting the phone, going to airplane mode didn't do the trick. On next power on, it did ask for my SIM PIN-code and found my telco quite soon.

My thanks goes to iFixit for their excellent guide. I simply wanted to do my own to fill in the gaps they left.

Since there has been no updates for Mr. Bjørn Grønli's spreadsheet, I chose to continue his work.

The link is https://docs.google.com/a/hqcodeshop.fi/spreadsheets/d/1ZJsy0q-8tmR8m32d1bCHkSv1neGVtA5v5TU4qVczH0Q

I did try out a number of SP104 and SP105 T-mobile (German Telecom) firmwares and found that they are really poor. 3 Italy was a pretty poor firmware, as I had problems logging in! Polkomtel's SP103 was a solid performer, but after a round trip, I went back to Telia's SP102.

Please drop me a comment if something is wrong or new columns should be added, or if I'm missing a firmware in the list. My idea is to try to keep this up to date with firmware information and I will appreciate any help from you.

Something changed in Firefox 30. Once in a while everybody runs into an untrusted certificate while browsing. There is a support article "This Connection is Untrusted" error message appears - What to do at Mozilla's support site. The idea is to click I Understand the Risks and proceed to the site.

Now the latest version chose not to display the button:

If the HTTPS-connection would fail miserably, it wouldn't display the option anyways, as there isn't any possibility to continue to the site. Here is an example:

But since this is not that case, the button should be there. Something changed, since it was there before. Googling gave me an about:config variable of browser.xul.error_pages.expert_bad_cert:

It had been turned into false for some reason. When the setting is true, the error screen changes:

Now there is an option to proceed. While at it, they failed. Adding an exception won't work:

Storing the option permanently or not has no effect. It still won't proceed.

Perhaps they'll fix this into Firefox 31.

Not much has happened here on the blog as I have been busy doing some training and planning abroad.

As the saying goes, "pics or it didn't happen!". Here are the pics:

My hotel is in Nob Hill, but for work I go to SoMa. I didn't have a chance to go to Alcatraz, as the queue is something in the region of 3 months, but I managed to take a nice picture of it from Russian Hill. I don't have the classic Golden Gate picture yet, as it would require renting a car. On the other hand, the Bay Bridge is easily visible throughout the city, including Washington Street where I took the picture of Cable Car Museum. The Also, we had a nice evening get-together and went to see Giants vs. Reds baseball game at AT&T Park. Giants lost 1-3.

Once I get back to home, I'll continue hacking the B593. 

Update 2nd July:
I got back home and here are some more pics:

There are the classic Golden Gate pics you'd expect from anybody who visited San Francisco.

During the last day I had time to do a little pilgrimage:

University of California, Berkeley is the place where BSD Unix was initially written from AT&T's Unix. Nowadays that code runs among other OS X and iOS and most TCP/IP implementations, like the one in your Windows. So, it is a mighty important place. Second pic is a composite from Apple HQ's Apple Store. Every programmer will get the "infinite loop" joke. Since Infinite Loop is a looping street, you can actually take as many loops you want (until security throws you out). Third one is a composite from Google's HQ. There are number of Google bikes for employees to use (not that there wasn't security present when I drove one, typically there are). The last one is from YouTube HQ. It was surprising that it still has an own place and is not embedded into Google Campus.

Btw. In general the pics are of somewhat poor quality. I took them with my iPhone 4S. I didn't want to take my DSLR to a business trip.

Making the choice of a default browser in Windows 7 should be an easy task, right? If you are a fan of 64-bit Firefox browser like I do, then you should consider Cyberfox. The problem is, that ever since Cyberfox stopped using Firefox user profiles, it fails to set itself as the default browser.

Every single time you start your beloved Cyberfox, it will do something like this:

No matter what you try, it will do the same thing every single time. Crap!

The good thing is that this particular issue is a common one. It has been discussed in [Error] Problems Setting As Default Browser and [Solved] Cyberfox 28.0.1 Not the Default Browser bug, which contains enough information to solve the problem. The information is in the cracks of the discussion thread, but I managed to scavenge enough to fix my browser.

Start the fix by setting something else as the default browser:

Confirm, that Cyberfox should be the default browser, but it just doesn't work:

I'm setting IE as the default browser for the time being. Later I'll switch back to Cyberfox, but the fix requires you to change into something else:

Next, go to Cyberfox and go to Options, Advanced, General settings and un-check the Always check to see if Cyberfox is the default browser on startup. Later you need to be able to start Cyberfox without the check:

Download (or copy/paste) a small registry file defaults-64.reg. The entire file will be 7 lines (2 blank ones):

Windows Registry Editor Version 5.00

[-HKEY_LOCAL_MACHINE\SOFTWARE\Clients\StartMenuInternet\CYBERFOX.EXE]
[-HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Clients\StartMenuInternet\CYBERFOX.EXE]

[-HKEY_LOCAL_MACHINE\SOFTWARE\Clients\StartMenuInternet\FIREFOX.EXE]
[-HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Clients\StartMenuInternet\FIREFOX.EXE]

When you have the file in your disc, start File Explorer and right click the file:

Select Merge. It should say something like this (The keys and values successfully added to the registry):

Next thing is to start Cyberfox with administrator permissions. This is very important. If you attempt the fix with regular user permissions, you will fail and need to start over. Example:

Go to Options, Advanced, General settings again:

This time click the Make Cyberfox the default browser (you can check Always check to see if Cyberfox is the default browser on startup, if you want to). This time the button will disappear:

If the button disappears, it means that you succeeded! Cyberfox is the default browser for your Windows and it won't complain about it on startup.

All this trouble pays off. Now your super efficient and well optimizer browser works even better!

The obligatory shame-on-you prize goes out to Mozilla for scrapping their 64-bit Windows browser project. Even Google Chrome is heading towards 64-bit on Windows. Anyway, the 64-bitness is a weird subject, on Linux or Mac OS X 64-bit browsers have existed a very long time. What's with the Windows having only 32-bit versions?