Adventures in Arch: Part 1 - Goodbyee Ubuntu!

Introduction

Well, this is it… This is the moment every Linux user dreads: It's time… to install Arch Linux.

Why am I doing this? How has the moment come so soon?? I thought I had more time!! Well in a nutshell, it's because (as my good friend Nick would say) ‘HP sucks’. The reason being, I have a HP laptop which comes with some kind of funky Intel/AMD hybrid graphics setup that doesn't work with the open-source drivers. Now, under normal circumstances, that would be fine. Just grab the proprietary Linux drivers and off you go. Unfortunately, doing this has a number of problems.

Oh AMD…

The Linux drivers for AMD graphics cards suck. Well, perhaps not all of them, but certainly for my setup. Not only did it take an hour of Googling to find how to get the thing to run, the card runs incredibly hot when using the discrete (high-power) card, so I can't keep my laptop on the high-power card. But if I use the power-saving card, I can't play any games because then I'd get 10 FPS.

On Windows, this wouldn't be a problem: I'd just use the power-saving card for my day-to-day activities, and whenever I feel like a game of Dota 2, switch to my high-power card. Unfortunately, this is a pain in the arse on Linux. There is no way to, on Ubuntu at least, easily switch between graphics cards without logging out and back in again (thereby closing all your programs). As someone who likes to keep a million applications open in the background to save time, this was a big psychological barrier to playing games.

I did try, of course. amdconfig --px-igpu, log in, amdconfig --px-dgpu, switch user should work. In theory. Of course, this is proprietary software we're talking about, so of course it doesn't. OpenGL error. GLX error. Segmentation fault. And so on.

Hope at the End of the Tunnel

Enter the Arch Linux wiki. Wait, what? You're saying that I can do exactly what I want to do on Arch Linux? That's brilliant news! Except it's Arch Linux. You know, the one where you have to do everything yourself. I mean, I'm all for Linux, but… Arch Linux?

At the end, I just couldn't stand Ubuntu any more. I upgraded my Mesa and it  thoroughly broke rendering on both my graphics cards. I tried reinstalling my drivers, but no. It was completely screwed.

It's Time… For Arch Linux

So, I decide it's time. I go to the Arch Linux website and download the ISO. I put it on my multi-ISO GRUB USB. The one that works on VirtualBox, QEMU, the s**tty computers at my school and my five-year-old piece of junk. Surely it should work on my brand-spanking-new laptop? Aah, but you make a fatal mistake. You forget that this is a HP laptop, so firstly it hides the USB in the boot menu. It looks like there are two boot options, Notebook Hard Drive and DVD Drive, but there is actually a third option, set to ‘display:none’, sandwiched in between the two – the USB boot option. And of course, being a HP laptop, selecting that option makes the USB light blink… Then it makes the screen go black and the fan go crazy.

Thus, I was forced to make an image of my USB and dd the ISO file to it like an IT noob. This, of course, for some unknown reason, works with the HP BIOS, and so began the long process of installing Arch.

Installation

The installation process itself was surprisingly straightforward, though perhaps somewhat involved. Unlike Debian, which complained about missing WiFi firmware then refused to read said firmware off a USB, my WiFi card actually worked! Everything was going swimmingly, until I realized, too late, that my HP laptop had decided it was going to put my USB drive as the first hard disk. This, of course, completely screwed up the drive numbering (lettering?).

Perhaps it had something to do with using USB 2.0 or 3.0 ports. I switched to a different USB port, rebooted, and voila! The drive numbering was correct! Now, at this point, it is necessary to note the strange nature of my laptop. Despite being advertised as having a 1.5TB hard disk, it actually has two 750GB hard disks. The HP BIOS, however, refuses to recognize the second, and treats both as a single ‘Notebook Hard Drive’, meaning that I had to install GRUB to my first hard disk, despite Arch being installed to the second. This had cost me a large amount of time earlier, when I installed Ubuntu.

Unfortunately, I had forgotten this, and absentmindedly ran grub-install /dev/sdb. I then rebooted and was surprised when what I believed to be my newly installed GRUB complained that it couldn't find the root partition, giving its UUID.

I rebooted into my live USB and discovered that, indeed, no partition with this UUID existed, however I was at a loss to explain why GRUB was searching for this. Perhaps I should try and reinstall GRUB again. However, HP was back again, ruining my day, as I discovered that the drive numbering had again screwed up. I, however, decided to try my luck.

Then it hit me: Of course, GRUB needs to be installed to my first hard drive because of the BIOS! Thinking that I was so clever for having worked this out, I ran grub-install /dev/sda. Notice any problems? I certainly didn't, and was surprised when GRUB complained about some kind of partition label problem.

It took quite a bit of sleuthing before I realized what I, or rather, my laptop, had done wrong. Thankful that GRUB had not overwritten my live USB, I executed the correct command and finally got GRUB working.

Enter AMD. Again.

Yes! I'd finally got Arch Linux booted! Now why is the fan so loud? And why is the laptop so hot?

Google…

Google…

Google…

*sigh*. A-M-D!!! Evidently, the problem was that both of my graphics cards were running, despite the fact that I hadn't even installed X yet. One fstab modification, one reboot and one vgaswitcheroo command later, everything was working perfectly.

The End, For Now

Finally, after several hours of work, I'd gotten Arch Linux to the point where it sort of vaguely worked. Now, to tackling the real problem: hybrid graphics.

GUIDE: Exporting Encrypted bitcoin-qt Wallets into MultiBit

Introduction

Bitcoin is awesome. Unfortunately, migrating between Bitcoin clients is not. It's especially annoying when the recommended method of exporting with pywallet, importing into BlockChain.info, exporting as an aes.json and importing into MultiBit is 1) incredibly confusing and 2) doesn't actually work.

So, here is how to export your (encrypted) wallet from bitcoin-qt into MultiBit.

Process

1. Open up bitcoin-qt and go to the Receive page.
2. Go to Help/Debug window from the menubar.
   
   
3. Switch to the Console tab and enter walletpassphrase <your passphrase> 600. This will ‘unlock’ your wallet for 10 minutes.
   
   
4. For each of the keys you want to export, enter dumpprivkey <your 34-character bitcoin address>. Copy the resulting 52-character private key into a text document.
   
   
5. At this point, you should have a list of 34-character Bitcoin addresses and their corresponding 52-character private keys.
   
   
6. Now, go to a site like BlockChain.info and look up each of your Bitcoin addresses to find out and copy down the oldest transaction on each.
   
   
7. You now need to convert your data into the correct format, as shown below. The format is <private key> [space] <date>, where <date> is in the format 2013-11-24T15:04Z. Note that I have moved my dates one day backward, just to be safe.
   
   
8. Save your data file as filename.key and import it in MultiBit through Tools/Import Private Keys.

Hand-Crafting a Linux Computer Virus… in Java!

It's a computer virus… for Linux… in Java. That's right, I've broken the Internet.

(app.exec is a shell script, hello.exec and hello2.exec are compiled C programs)

Disclaimer

There won't be any code in this post, nor will there be detailed plans for how to implement the theory. Do it yourself (or just don't do it at all—that's probably a good idea too). Bloody script kiddies.

Why Java?

Just cuz.

The General Idea

So how exactly does the virus work? Essentially, it creates an executable JAR file, with a hashbang at the beginning to make it executable. (ZIP files seem to be quite good at letting people shove random data at the beginning of them) The JAR file contains a copy of the virus, as well as a copy of the original uninfected program.

When the file is run, it searches for all exec files in the current directory (safety first!) and checks if they're already infected. If not, it applies the patch to them: compressing them inside an executable JAR file along with a copy of the virus.

Then, it uncompresses the copy of the original program into the temporary directory and executes it.

Interestingly, a side effect of this virus is that it makes the programs it infects smaller!

Notable Issues

• Attempting to double-infect a program will cause it to massively screw up.
• Programs that attempt to read themselves may unexpectedly find themselves to be corrupt.

Conclusion

It just goes to show, even if you run Linux, you still need to be vigilant around strange programs and email attachments, and you should probably get some sort of antivirus program too!