Archive for the ‘How To’ Category
I want to start this off by admitting I have an iPhone 3G. It’s true. Working at a tech company, I feel like admitting I have this version is like carrying around a Zach Morris phone. Truth is, I hardly ever plug my iPhone into my computer and when I do, it is just to upload music. But sometimes, you are forced to update.
Recently, I headed to the gym and started my Netflix app, only to find out it wasn’t working. When I tried to download my new update, a tiny box popped up saying, “requires iOS 5 or later.” I knew it was time. I had seen the nightmares on Facebook of people losing contacts, pictures, and even their email set-ups. I couldn’t stand to part with my pictures of my beloved beagle or lose the phone numbers of friends I plan on calling (sometimes). In order to avoid losing your precious memories, here are some quick tips to remember when running updates.
- Make sure you are running the most recent version of iTunes. Ensure that you have the most recent version of iTunes for compatability. The most current version to date is 11.0.2. If you are not sure which version you have, go to the top bar in iTunes, click “help,” and then select, “Check for Updates.” If there is an update available, iTunes will locate it here.
2) Make sure to back-up your phone. If you are in more recent versions, you will be able to do this in the cloud. I did mine manually by plugging my phone into a computer. Once you’ve plugged your phone in hit “File,” then “Devices,” then choose “Back-Up.” Backing up is different than syncing, so be sure to hit the right tab.
3) Check to make sure your applications and music are synced. From what I understand, there is really no way to see if your contacts, messages, and photos are synced, but you can see what time it was when you last backed up on your “Summary” page in iTunes.
4) Use a solid wifi or internet connection. When I tried to update my phone on my computer at home, I kept getting errors regarding my network connection. Despite my numerous troubleshooting attempts, I was unable to get the connection strong enough to download. Wherever you choose to download, you should have a strong enough connection to fully finish the download.
5) Make sure your phone is fully charged. If you choose to download your update through the cloud, be sure to charge your phone. Having the phone die in the middle of an update could mean big trouble. If you really want to be on the safe side, plug your phone into a charger.
6) Read any and all pop-ups before you update. iTunes is pretty good about telling you the possibilities of what could happen if you haven’t backed up your phone or transferred your purchases. Make sure to read all of your pop-up messages before you update to avoid any mishaps.
7) Do not unplug your phone or disconnect. The time it takes to download a software update can vary. Make sure that you allow plenty of time for your phone to update. Depending on the amount of files you have and network speed, it can take up to a few hours. From what I’ve read in other forums, it usually takes about an hour on average.
8) The software update will only download your most important applications. In order to get the rest of your music and applications you will need to sync with your computer. If you backed up before you did your update then you should have no problems. In order to sync your music, apps and movies, just scroll through the summary bar and select.
Now, I’m sure that we can have tips for days, but these are just a few of the most common mistakes people make. If you have any helpful tips for updating your iPhone, please feel free to comment below!
We use some utility encryption routines in C for various purposes. When I first tried to migrate these routines from HP-UX to Red Hat Linux, I ran into a problem right away: the linker couldn’t find the libcl.a library.
There is no library by that name in Linux, and I had no idea what the linker wanted to find there. As an experiment, I edited the make file to remove the reference to –lcl. Now the linker complained that it couldn’t find the functions setkey() and encrypt().
A little research showed that, in Linux, those functions reside in the library libcrypt.a. I edited the make file again, replacing the reference to –lcl with a reference to –lcrypt.
(Under HP-UX, the libcl.a library includes not only the encryption functions but also a bunch of math functions. Under Linux, the math functions presumably reside in the library libmath.a. However I haven’t needed any of them so far, so I’m guessing.)
Now the linker was happy, but I wasn’t. Whenever I tried to encrypt anything, all I got was a string of zeros. Um, that’s not encryption. At best, it’s a really, really, really bad hash function.
At that point I fell down the rabbit hole of debugging – grepping the source, studying the code, inserting displays, Googling for clues, and trying experiments. Here’s what I found out.
The setkey() and encrypt() functions apply DES encryption to blocks of 64 bits at a time. That’s bits, not bytes. However, you don’t pass the bits as 8-character arrays. You pass them as 64-character arrays, one character for each bit. It’s the job of your application to translate back and forth between these bit arrays and whatever the data should really look like.
One reason for this arrangement is probably that not all machines use 8-bit bytes. The C language requires that a byte contain at least eight bits, but it can have more. I’ve heard of CPUs that use 9-bit bytes, and others that use 64-bit bytes. If you really want to be perverse, you could build a machine with 37-bit bytes. It may be easier for an encryption standard to support exotic architectures if it breaks everything down to the bit level.
In the HP-UX version of these functions, the bits in these arrays can be encoded as the ASCII characters ‘1’ and ‘0’. I haven’t found any documentation of that fact, but that’s how our programs were coded, and they seem to work okay.
In the Linux version of these functions, the bits in these bit arrays evidently must be encoded as the binary values 0x00 and 0x01. I haven’t found any documentation of that fact either. The man pages on both systems are ambiguous.
The best evidence is that, after I rewrote our code to pass the bit arrays with binary values instead of ASCII characters, the encryption started working on Linux. I can encrypt something and then decrypt it, and get the same thing I started with. Furthermore I can encrypt something on HP-UX, decrypt it on Linux, and get the right answer.
Out of curiosity, I tried the Linux version on HP-UX – and it worked! Evidently the HP-UX implementation of setkey() and encrypt() can accept either character values or binary values in their bit arrays, but the Linux version only accepts binary values. Once I converted the code to use binary values, I could use it on both platforms without a bunch of ugly #ifdefs cluttering up the code.
The C and C++ languages don’t try to define the results of every syntactically correct program. For example, if you dynamically allocate some memory, and then free it, and then try to access the memory you freed, you invoke undefined behavior. The C and C++ standards don’t specify how the program will respond.
Undefined behavior means that anything can happen, because the compiler is under no constraints. The traditional formulation is that undefined behavior can make demons fly out your nose. In practice the consequences are usually less dramatic.
If demons ever fly out your nose, you’ll know you have a bug. You can track it down and fix it. More insidious is undefined behavior that happens to be exactly what you want.
I ran across an example as I was preparing to port some code from HP-UX to Linux. The program was freeing a linked list, using code similar to the following:
Node * curr_node = first_node;
while( curr_node )
free( curr_node );
curr_node = curr_node->next;
To a long-time C coder, this code immediately looks fishy, because the loop has only two statements in it. Look a little closer. The second statement in the loop tries to access memory through a pointer that has already been freed. It invokes undefined behavior.
This program has been running for years with no obvious ill effects from this bug. Apparently HP-UX isn’t very persnickety about accessing previously freed memory. That’s legal. “Anything can happen” includes “what you want.”
When I first saw this code, I wasn’t ready to port the entire program to Linux yet, but I could experiment. I dashed off a little test program that built a linked list and then freed it, using the logic shown above. Under HP-UX this program ran to completion without incident. Under Linux, the same program stopped abruptly in the first iteration. It didn’t issue any messages, dump core, or even leave a non-zero condition code; it just stopped cold. That’s legal too. Anything can happen.
I don’t know whether this difference is attributable to the operating systems, the compilers, the libraries, or the machine architectures. I don’t care. What matters is that I can’t run this program under Linux without fixing the loop:
Node * curr_node = first_node;
while( curr_node )
Node * temp = curr_node->next;
free( curr_node );
curr_node = temp;
A few days later, another example of undefined behavior popped up, in the form of a buffer overflow. Under HP-UX the overflow had no visible effect, at least not until I started poking around with printf statements. Under Linux the code just didn’t work. Probably the variables are arranged differently in memory. In HP-UX the overflow didn’t damage anything that mattered, and in Linux it did.
These examples are just things that I stumbled across. There will be more, and I won’t catch them all so painlessly. Fancy code analyzers may help catch things in advance, but there is no substitute for vigilance.
It’s tempting to conclude that HP-UX is more forgiving of blunders than Linux is, since some things work in HP-UX but don’t work in Linux. That conclusion is premature. Maybe the two platforms are just forgiving about different things. If the bugs had done obvious damage under HP-UX they would have been fixed already.
There’s a Darwinian process at work here. Bugs survive when they’re well adapted to the environment. When the environment changes, some of those bugs will go extinct. Unfortunately, new species will probably replace them.
You might think that migrating from HP-UX to Linux would be a piece of cake. Hey, they’re both UNIX, right? Sort of?
Naturally, it’s not that simple. Even among two UNIX-like environments, there are all sorts of pesky little differences to trip over. Typically the resulting problems are not hard to fix, but they can be hard to anticipate.
Lately we’ve been migrating an application from HP-UX to Red Hat Linux, and stumbling over a series of little gotchas. I plan to report some of them on this blog, and maybe save somebody else some hair-pulling.
For example: take the echo command.
Under HP-UX, echo recognizes escape sequences such as “\t” for horizonal tab, “\n” for newline, and so forth. Under Linux, it doesn’t, at least not by default. However the -e option tells the Linux version to recognize escape sequences.
One solution would be to look through all our shell scripts for ones that use echo with escape sequences, and fix them. Ideally, I should do that. However, the search would be tedious and time-consuming.
Instead, I defined the following alias in a logon script that everybody goes through:
alias echo=”echo -e”
If you really want echo not to recognize escape sequences, use the -E option, which works even with the alias in place. When the -e and -E options are both present, the last one wins.
Under HP-UX, the echo command is built into the shell, i.e. ksh and there is also a separate executable /usr/bin/echo. Both versions recognize escape sequences.
Likewise under Linux: the echo command is built into bash, and there is also a separate executable /bin/echo. Neither version recognizes escape sequences unless you include the -e option.
When a website’s database has been compromised with a SQL injection attack, it is important to clean it up as soon as possible. An attack of this nature passes SQL commands through a web site into a database. In the following case, many different HTML code statements were spread throughout multiple tables and columns. In short, the way to clean this type of attack is to identify the kind of injection, search for the offensive code, and then remove it.
Recently a company contacted us when they noticed a problem with their page titles. There was unknown HTML code, a script tag, showing up in the titles linking to ur.php, an obvious problem, so I began my investigation.
The first task was to find information about other sites which had also been attacked with the same HTML injection. A quick web search turned up the so-called LizaMoon attack which has been showing itself around the internet since at least autumn of 2010. LizaMoon has impacted well over 1 million different websites by inserting malicious code.
The next task was to determine a way to find all variances of the injected code. Besides looking for the URLs that had been known to be inserted (listed on many websites), I wanted to determine what other variants might be hidden in the good data of the database. To do this I compiled a list of strings that are not likely to be widespread in that database, including:
.js, php, script, .pl, .info, cfm, .inc
In order to search through all the tables and columns, I used the SQL script found here:
I modified it to include text and ntext columns and then started searching.
Even though the SQL script was finding what I wanted, it still took time to look at some data by hand to determine exactly what to remove. I made a backup of the database before I updated anything, always a good idea before a mass update, and then started removing the injected code. Here are the strings I ended up removing:
<a style=”display: none;” href=”hXXp://bookavio.cXm”>book</a>
(“http” replaced with “hXXP” and “.com” replaced with “.cXm” for purposes of this posting only.)
There were ten variations of bookXXXX.com that I found in the data (where XXXX was always a set of 4 other letters). As you can see, besides the script tag, all of the links contained the word “book” and the “display:none” CSS. So that knowledge helped me find additional variants.
Once I started seeing the injected code snippets, I needed to get rid of them. I found a great global search and replace that I also modified for my needs to use text and ntext columns.
Here is a list of additional strings I searched for based on what I had found from the known injections:
Since injection code viruses like LizaMoon, and others like it are not likely to disappear anytime soon, it is important to know how to walk through the steps of deleting such code from databases. There is no need to panic if you are faced with one of these SQL injections. With the right information it can be no more than an irritation.