Hardware - 7

The original post about curcfg_tool.

So I decided to add couple of new features to my tool. However, neither of of them work.

Asiantuntijakaveri-blog introduced hack to run commands on boot: Persistent customizations to Huawei B593u with stock firmware. I added a feature to do that:

./curcfg_tool -rc "update-westerneurope.huaweidevice.com ; /upgflash/init.d/rc.local" -w

The flaw is in the httpupg-command startup. It takes the server address from curcfg.xml, but it doesn't escape it properly. This makes it possible to piggy-back any command on it. The thing is, that in my B593, the automatic firmware upgrade does not run automatically. I can go trigger it manually. At that point it runs my script I created at /upgflash/init.d/rc.local. My hope was, that system would run it automatically on bootup, but it doesn't.

Another thing I added was NTP-server change. I don't know where the list comes from, in my case it is completely ridiculous. However, the source for information is not from curcfg.xml. For example:

./curcfg_tool -ntp1 ntp.dnainternet.fi -ntp2 fi.pool.ntp.org -w

... doesn't change anything. The new servers don't appear at the list in GUI, nor the system doesn't update time from them.

Crap! Both attempts failed miserably. Please drop me a comment if you have anything to add to those ones. 

Being an old geezer, I typically upgrade my iPhone firmware via USB-cable. Wireless users need to wait for the upgrade to happen, USB-people simply plug the cable and go. Also it is a very robust method and less things will go wrong than doing it wireless. Yeah, right!

So I plugged my phone in. Made sure, that I had latest iTunes version running and that a recent backup was made. Then, DÄNG!

Yeah. Crap! The iPhone could not be updated. An unknown error occurred. Really? Is it possible to be more vague? Next to frustration, the next thought that goes through my mind is: "Did I brick it!!! Is it still salvageable?".

Quite soon I had a positive signal:

Phew! iTunes announced, that the device is in recovery mode. Somewhere before it actually started the process, there was a question "Do you want to upgrade software and restore backup?" In reality it was a non-question, pretty much the only choice was "Ok". Looks like I didn't manage to get a screenshot of that.

The actual recovery process took a very long time. At the time I didn't realize, that it wasn't a "recovery" by definition. It was a simple iOS install. The next iTunes said was:

I'm not sure if this is part of the iOS 8 kill-switch -procedure or is that a regular thing to gain Internet access via 3G, but the installation refused to continue before I had successfully entered the PIN-code for my SIM-card. Then iTunes was ready to start restoring my precious data to the device:

At Apple there is a known reality distortion field, making a nice guestimate of 3 minutes for the restore time. After 15 minutes, the best guestimate was less than 1 minute. Nevertheless, I really had nothing else to but to wait for the restore to complete. Finally it said:

Oh yes!! I didn't brick it after all. I simply took the long route to the end.

It really wasn't worth the update. The only really noticeable thing is the voice button in messaging and the fact, that it drains my battery much faster than my previous iOS 7 did. But who would have guessed that would happen, or ... iOS 7.1 makes everything faster — including your battery drain @ 9to5mac.com. So, does that really happen every time they release an upgraded iOS-version?

As I have promised a number of times to number of people. Here it finally is! The first version of my tool to alter your B593 configuration. With this tool you can change admin passwords for web GUI and SSH to something of your liking. It does not (yet) convert plaintext passwords into encrypted ones, but it successfully writes the changes to flash, thus making them permanent.

Prerequisites

• Huawei B593 u-12
• Access to your box for running commands, telnet/SSH are really good options for this
• While at Busybox sh prompt, internet connectivity via the mobile interface (4G/3G/2G)
  

Getting the tool

The MIPS32 binary version suitable for running at your B593 is at http://opensource.hqcodeshop.com/Huawei%20B593/curcfg/latest. The C source code is also available at: http://opensource.hqcodeshop.com/Huawei%20B593/curcfg/

1. Log into your box
2. (recommended) Change into directory /upgflash/
3. Download the binary into your box:
   wget -g -v -l curcfg_tool -r "/Huawei%20B593/curcfg/latest" opensource.hqcodeshop.com
   
• As you can see, Busybox has a mighty quirky wget!
• Anyway, that command will download the tool from the above URL and place it to the current directory with local name curcfg_tool.
• Also note, that your box must have a functioning Internet access for download. The only other viable option is via FTP-hack. The environment is very limited and file transfers are restricted heavily.
  
4. Make sure, that the file is executable:
   chmod a+x curcfg_tool
   

Running the tool

Now that you have the thing sitting there, run it:

# ./curcfg_tool
Usage:
-V                     - Print version information
-cw <base64 encoded web gui password>  - set password
-cs <base64 encoded SSH password>      - set password
-w                     - write changes to flash (default: don't write)
-fi <file name>        - input file (default: read from flash)
-fo <file name>        - write changes (default: /tmp/flashinfo.bin)

An example of resetting the web-GUI password would be:

# ./curcfg_tool -cw f5338SA1kb4= -w
Read data: addr = 0xe00000, len = 0x4 ...
Begin write to file
Export done
Reading 25785 bytes of config
Read data: addr = 0xe00000, len = 0x64bd ...
Begin write to file
Export done
Writing 25785 bytes of config
/tmp/flashinfo.bin size = 25790 Bytes
Read file done
Begin write to flash
Load file done

The magicical Base64 encoded 3-DES encrypted string f5338SA1kb4= is "admin" in plain text. After a reboot (just say reboot at prompt), you can login into your web-GUI and change the password into something of your liking.

What next?

That's pretty much it as of now. If you don't like your operator designated passwords, you can change them.

How do I ...

• ... see what my current password is:
  You cannot. Encryption key is not known for pre-SP100 firmware and SP100+ firmware is using double encryption with 3-DES and AES and entire flow of information is not yet known.
• ... access the prompt of my box:
  See B593_exploit.pl for details.
  
• ... access the prompt of my box, but I have SP100+ firmware and don't know any of my passwords:
  You cannot. Yet. Currently known exploits have been fixed preventing access.
  However, in this case the real question seems to be: "How did you get your box running in the first place?"
  
• ... run the B593_exploit.pl -tool, my Perl isn't working:
  You may want to install all CPAN-modules the script requires. Also skip the Windows and use a proper computer.

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.

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.

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.

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.

This is something I've wanted to do for a long time. Ever since I got my B593. Jevgenij has been hacking his B593 and dropped me a comment that he found command /bin/lteat from his box. Obviously I had to SSH into mine to confirm this:

# ssh admin@192.168.1.1 /bin/sh
admin@192.168.1.1's password:
-------------------------------
-----Welcome to ATP Cli------
-------------------------------
ATP>shell

BusyBox vv1.9.1 (2013-07-25 14:10:15 CST) built-in shell (ash)
Enter 'help' for a list of built-in commands.

# ls -l /bin/lteat
-rwxrwxrwx    1 0        0           34604 /bin/lteat

... and oh yes! Such a command is there. It is an interactive AT-command shell!

Warning!
Running these AT-commands will mess up with your box. The modem does not like to be messed up and my box didn't connect to internet after doing this. There is a simple fix to just reboot the router.

Let's explore some possibilities.

Manufacturer information

Running the AT-command shell:

# lteat
AT>

This is something that worked already in the 80s modems. The classic modem information:

AT>ati
Manufacturer: Huawei Technologies Co., Ltd.
Model: EM920
Revision: 11.433.61.00.07
IMEI: 868031008680310
+GCAP: +CGSM,+DS,+ES
OK

The 15-digit IMEI is broken into two pieces. First 8 numbers are the Type Allocation Code (or TAC). The second part is the 7 number unique id of my unit. That's why I'm not revealing it here.

If we punch the TAC into a http://www.nobbi.com/tacquery.php it will yield a result of:
86803100
Manufacturer = Huawei
Model = B593
Hints = LTE/UMTS Router

Which is not very surprising. That is something we already know.

Telco information

Let's see what we can get from my telco. I found a nice reference List of AT commands to be very helpful. Running command:

AT>AT+COPS=3,2
AT+COPS=3,2
OK
AT>AT+COPS?
AT+COPS?
+COPS: 0,2,"24405",2
OK

The 24405 is my PLMN code (note: this can be found from web GUI's diagnostics wireless status also). According to article Mobile country code, it breaks down to two parts:
Mobile Country Code = MCC = 244
Mobile Network Code = MNC = 05

According to the table:
MCC = 244 = Finland
MNC = 05 = Elisa

Again, something that I already know.

Location information

To dig a bit deeper ... Every cell tower has unique code. I found information about that from a discussion forum with topic Huawei USB LTE Modem, E3276 K5150 E398 (Modems). The forum says that:

AT+CREG?
+CREG: 2,1, YYYY, XXXXX, 2
OK

Y = LAC
X = Cell ID
Added: Note that both are in hex so need to convert it

Let's try that one out:

AT>AT+CREG=2
AT+CREG=2
OK
AT>AT+CREG?
AT+CREG?
+CREG: 2,1, 620C, 123ABC, 2
OK

Now we have:
LAC = 620C (hex) = 25100 (decimal)
Cell ID = 123ABC (hex) = 1194684 (decimal)

Again, I'm not going to reveal my exact location here! The cell-ID published here is something I made up.

I tested all the gathered information of:
MCC = 244
MNC = 05
LAC = 25100
cell-ID = 1194684
in OpenCellID's search engine, but they don't seem to have my coordinates in it. Maybe I should add them. Your's may very well be there.

According to Wikipedia article, there are a number of databases for cell-IDs, but most of them are commercial and I don't have a license to use them. In general they simply have exact GPS-coordinates of cell towers and they can be used to get a rough estimate of your location.

Signal quality

The last one I did was to get exact signal quality. A B593 has 5 bars in it, which is accurate enough for most users. The hardware has the quality info in much more detailed level. The AT-command list says:

Signal quality

Command: AT+CSQ
Response: +CSQ: <rssi>,<ber>

Let's try that out:

Query for the ranges:
AT>AT+CSQ=?
AT+CSQ=?
+CSQ: (0-31,99),(0-7,99)
OK

Query for the signal quality:
AT>AT+CSQ
AT+CSQ
+CREG: 1, 620C, 123AC1, 2
AT+CSQ
+CSQ: 23,99
OK

Whoa! It also returned a LAC and another cell-ID. The cell-ID is pretty close to the original one, but not exactly the same. Anyway, the Received signal strength indication (RSSI) is 23 and Bit Error Rate (BER) is 99.

By Googling I found out following information about RSSI:
RSSI (dBm) = RSRP + 10*log10(RB) + | RSRQ | + other noice, temperature noice etc.

You may also see the RSSI vs RSRP: A Brief LTE Signal Strength Primer for details about the signal math.

To put all the logarithms and four-letter-acronyms into layman terms. This table was published in the discussion forum in Finnish by user with nickname timtomi. Signal levels are from poor to excellent:

The BER is typically 99 which means that none could be measured. In general there shouldn't be any errors in the transmission, so 99 is likely what you'll get also.

This is a HOWTO instruction for replacing a spinning platter hard drive with a modern faster solid-state drive. Since Compaq 615 has Windows 7 Home Premium OEM installed, I'll blog about the Windows Activation in more detail on my next post.

This kind of Compaq laptop is quite generic PC. Majority of this information applies to almost any laptops I've disassembled. It's about the location of the drive, location and number of screws, but the information in general covers the operation of replacing a drive with another one.

I started this project with checking for Manuals for Compaq 615 Notebook PC @ HP. The good stuff is at PDF-document with title Compaq 615 Notebook PC and Compaq 610 Notebook PC - Maintenance and Service Guide.

It will contain all the information a service technician would need to successfully operate on this kind of hardware. On page 4-8 it has the hard drive replacement procedure documented.

Anyway, this is something I've done a lot. I briefly checked out the location of the drive and the screws that needed un-screwing. Here is a pic from the flipside of the laptop:

Those two screws hold a HDD-cover in place. The screws even have a HDD-symbol next to them. Un-screw both of them with a small Phillips head screwdriver:

Remove the HDD-cover by pulling up from the side you removed the screws from. The drive is visible:

The drive is held in place by a single Phillips head screw. Remove that too. Pull up from the drive screw bracket and the drive will slide left and reveal a standard S-ATA -connector:

Now you have the drive completely detached from the laptop. The actual hard drive is connected to a metal cradle with 4 Phillips head screws. Un-screw them:

As you can see, the screws are really small. The screws are quite tight, see the blue substance in the screws. It is threadlocker and its purpose is to make sure a screw is tightly attached. If you don't have the proper sized screwdriver, you will destroy the notches of these screws making removal really difficult. This is the only part of disassembly, where I needed to apply some force just to make sure that the screwdriver wouldn't slip.

The next step is to attach the new SSD-drive to the cradle:

Think really carefully which way the drive needs to be attached to the cradle. There are four possible options, but only one of them will yield success. You will see quite soon the position the cradle needs to be in the laptop. The hard part is to figure out which way the drive needs to be to succesfully connect to the S-ATA -connector of the laptop.

When the hard part is done, all you need to do is slide the cradle back to S-ATA connector and secure the screw holding the cradle at place. Then put the HDD-cover back and secure the two screws for the cover.

All this will take around 10 minutes on experienced hands. If this is your first laptop maintenance work, reserve a hour. Nothing here requires much force to be applied. If you are applying much force, you're doing something wrong.

Good luck on your project!

Jevgenij dropped me a comment about new firmware. It is from Telia Sweden and you can get it from here http://www.telia.se/privat/support/mobiltbredband/uppdaterausbmodemorouter#huaweib593formac=&tabMenu_0=huaweib593formac The direct download link is https://www.telia.se/dms/mgnl-ext-dms/www-telia-se-ui/installation-files/se_telia_r-m-h-s.tar/se_telia_r-m-h-s.tar.bz2 The firmware seems to have nice features, SMS and even to force for 2G-operation. He highly recommends this one. This looks very promising, perhaps I'll try this myself.

I upgraded my B593 with this one and can confirm that it works well. GUI-languages are: Svenska, Suomi, Pусский, Norsk, Dansk, Eesti, Lietuviu and Latviešu. No setup wizard. Has external antenna support. No VoIP. No DDNS. Mode selector has 5 options: auto, auto 3G/4g, 2G only, 3G only and 4G only. SMS in/out. No DLNA. So it is little bit light on features, but is fully exploitable and SP102!

The file will contain a SP102 for u-12. Altough The Exploit does not work, it seems to have a nice bug in it. When you're FTPing into it, it will open also SSH-port! Whaat!

Warning:
SSH passwords are reset to something the telco set. However, USB/FTP-hack will work and you can get the /var/sshusers.cfg and look at the plaintext password from there.

John do, a reader of this blog made a serious break-trough! Via SSH on B593 prompt, he found the flashtest-command. Before this I had no knowledge about such command, but see what I can do with this new information:

# flashtest
Usage: flashtest {info|read|write|erase|export|load} {addr} {len} [data]
Format:
flashtest    help
flashtest    info
flashtest    read      addr    len
flashtest    write     addr    len    {data}
flashtest    erase     addr    len
flashtest    export    addr    len

Well ... the info sound interesting. Let's see:

# flashtest info
 flash  block  size  :  0x40000 (256k Bytes)
  flash  block  num   :  0x40 (64 Blocks)
  flash  total  size  :  0x1000000 (16M Bytes)
  flash  partation  info :
  ---------------------------------------------------------------
  Name                  Address                    Usage
 ---------------------------------------------------------------
  Boot                  0x0---0x40000            Bootloader
  Image             0x40000---0xA40000           Main  image
  Image            0xA40000---0xE00000           Subject  image
  Curcfg           0xE00000---0xE40000           Curcent  config
  Faccfg           0xE40000---0xE80000           Factury  config
  Tmpcfg           0xE80000---0xF00000           Temp  config
  Fixcfg           0xF00000---0xF40000           Fixed  config
  Logcfg           0xF40000---0xF80000           Log  config
  TR069            0xF80000---0xFC0000           TR069  cert
  Nvram            0xFC0000---0xFFFFFF           Nvram

Current config! Really!? (Mis-typed as Curcent config). The run-time -only /var/curcfg.xml's real storage has eluded me this far. Let's explore that further:

# flashtest export 0xE00000 65536
Read data: addr = 0xe00000, len = 0x10000 ...
Begin write to file
Export done

What did it do? Where it wrote to? Some poking around reveals:

# cd /tmp/
# ls -l
----------    1 0        0           65536 flashinfo.bin

Oh yes! The next thing is to get my hands on to the file. In the B593 firmware's Busybox there is only a limited set of tools.

Let's use the USB/FTP-hack for transferring the file. The idea is to plug an USB-stick into B593. Any FAT32-formatted stick will do, it is totally irrelevant if there are files or not. Early firmwares are known to have a flaw in them. You can mount the entire filesystem into FTP-server and transfer file to/from the box. Setup goes like this:

Make sure you have the FTP-server running, add a user to the new mount and set the directory as ../.. It is really important to do that! That effectively breaks out of /mnt/usb2_1 into /. See this pic:

I added user with name test. Now let's see if the FTP-connection works from an external machine:

# ftp 192.168.1.1
Connected to 192.168.1.1 (192.168.1.1).
220 bftpd %v at 192.168.1.1 ready.
Name (192.168.1.1:user): test
331 Password please.
Password:
230 User logged in.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> cd /tmp
250 OK
ftp> dir
227 Entering Passive Mode (192,168,1,1,166,124)
150 BINARY data connection established.
----------   1 0        0        65536 May 21 19:26 flashinfo.bin
226 Directory list has been submitted.
ftp>

Oh yes! The extracted NVRAM-binary is there. Let's download it:

ftp> get flashinfo.bin
local: flashinfo.bin remote: flashinfo.bin
227 Entering Passive Mode (192,168,1,1,144,190)
150 BINARY data connection established.
226 File transmission successful.
65536 bytes received in 0.06 secs (1092.41 Kbytes/sec)

A brief analysis of the file reveals:

# hexdump -C flashinfo.bin | head -3
00000000  3e 00 64 fe 3c 3f 78 6d  6c 20 76 65 72 73 69 6f  |>.d.<?xml versio|
00000010  6e 3d 22 31 2e 30 22 20  3f 3e 0a 3c 49 6e 74 65  |n="1.0" ?>.<Inte|
00000020  72 6e 65 74 47 61 74 65  77 61 79 44 65 76 69 63  |rnetGatewayDevic|

# hexdump -C flashinfo.bin | tail -5
000064f0  65 77 61 79 44 65 76 69  63 65 43 6f 6e 66 69 67  |ewayDeviceConfig|
00006500  3e 0a 00 ff ff ff ff ff  ff ff ff ff ff ff ff ff  |>...............|
00006510  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
*
00010000

The first 4 bytes of 3e 00 64 fe are bit of a mystery. I don't know what the 3e 00 is for, but the 64 fe is obvious! It is the length of the XML-file following the header bytes. I can confirm that the entire /var/curcfg.xml is there. Unchanged. Intact!

My next move is to try altering the curcfg.xml and write it back. There is a chance of locking myself out of my own B593, so ... I need to be really careful with this. If everything works as I expect, my next move is to write tools for allowing people to access their devices as they want to.

I'd like to extend my gratitude to Mr. John do. This really is ground-breaking stuff allowing us to new lengths with Huawei B593 hacking. Thank you, sir!

This is something that has been bugging me since November. In my post about different models, I stated that I have a u-12 (and still do). Last year I did setup a s-22 to a friend and got to see that it is pretty much the same. However, "pretty much the same" is not exactly the same.

The s-22 is a newer model and it has been well established, that it has a TDD 2600 MHz added into it. All the FDD frequencies are exactly the same than in u-12.

In the comments of my post, a user suggested that s-22 differs from u-12 by having only one USB-connector. At the time I was unable to find proof of that, all the pictures I could found of alleged s-22 units had no difference for a u-12 unit.

Now the situation has changed. In my ventures of the wonderful Internet I found an article What's the difference between HUAWEI B593s-22 and B593u-12? and it has a picture of both units side by side in it. Nice! But which one is which?

Just to make sure that s-22 is in the left and u-12 is in the right, I'll post a fresh picture of my own u-12 unit:

Also to close the case I also found a vendor page with a nice picture of s-22 in it, see HUAWEI B593s-22 4G LTE CPE [B593s-22]. It has a picture of the unit in the page, and their s-22 looks exactly the same than the left unit in the picture, and exactly NOT the same than my u-12. Apparently s-22 does not have a power switch, it lacks the side USB-connector and SIM-card -slot has been changed into a tray. Lot of differences to spot, actually.

So I'm confident that s-22 is very much re-designed both in hardware and firmware. The hardware side is surely changed because of the new(ish) 4G TDD radio interface. And while Huawei engineers were at it, they changed also the firmware in number of ways, one of them being to resist hacking attempts better than their 1st gen version did. This is also a well established fact, s-22 firmware has a completely different structure than u-12 firmware.

Now me and everybody else should be able to identify the units by a simple visual inspection.