Archive for the ‘Hardware’ Category

iOS Forensic Toolkit: Keychain Decryption, Logical Acquisition, iOS 4.3.4, and Other Goodies

Monday, July 25th, 2011
 
You might have heard about our new product – iOS Forensic Toolkit. In fact, if you are involved in mobile phone and smartphone forensics, you almost certainly have. In case our previous announcements haven’t reached you, iOS Forensic Toolkit is a set of tools designed to perform physical acquisition of iPhone/iPad/iPod Touch devices and decrypt the resulting images. This decryption capability is unique and allows one to obtain a fully usable image of the device’s file system with the contents of each and every file decrypted and available for analysis. And the fact is, with today’s update, iOS Forensic Toolkit is much more than just that.
 
(more…)

Extracting the File System from iPhone/iPad/iPod Touch Devices

Monday, May 23rd, 2011

In our previous blog post we have described how we broke the encryption in iOS devices. One important thing was left out of that article for the sake of readability, and that is how we actually acquire the image of the file system of the device. Indeed, in order to decrypt the file system, we need to extract it from the device first.

(more…)

BlackBerry password cracking: multi-threaded, with hardware-accelerated AES

Thursday, December 9th, 2010

Most modern CPUs are multi-core – it is not easy to find even a laptop with less than two cores these days. And for desktops, 4 cores are usual now.

Password recovery is one of most CPU-intensive tasks, and it fits best into multi-processor architecture. Every CPU (or CPU core) get its own portion of passwords to try (i.e. to check their validness), and they all work in parallel. As simple as that.

So what we’re doing in our software is running multiple threads – as many as the number of CPUs (or cores) available. And the rest is being done by the operating system, that assigns the threads to cores (well, in most cases we don’t care what particular core is going to execute a particular thread, because they are all equal; the only exception is when one or more of the cores is doing something already, I mean something CPU-intensive as well).

(more…)

Canon cannot or mustn’t provide image validation feature?

Tuesday, November 30th, 2010

A true security system cannot be so fragile: Canon Original Data Security broken…

Find 3 differences from original Now if your partner gets a compromising anonymous image where you are enjoying yourself with nice blond with blue eyes or charming young man, don’t panic and don’t get upset, you can easily prove it is just a fake (even if it’s not ;) ).  Seriously, how can we trust photographic evidence in the era of Photoshop and other designer tools? The genuineness of a digital image can only be proven by special digital tools…like OSK-E3?

Unfortunately or maybe fortunately, it turned out that OSK-E3 (Canon Original Data Security Kit) cannot guarantee image authenticity, because now it can recognize even fake images as true and genuine. However, the problem is not in OSK-E3, it is in Canon Original Data Security system implemented in most modern Canon DSLR (Digital Single-Lens Reflex) cameras.

Now it’s possible (well, Dmitry did it recently and who knows if somebody could do it earlier ;) ) to dump camera’s memory, extract secret keys from the camera, and calculate ODD (= Original Decision Data) which answer for any changes done to the image. And thus name the modified image as original one.

What Canon can do? It seems like Canon can nothing do with their models right now, because the fundamental problem lies not in the software. Changing the software could possibly solve the question, until someone again finds its vulnerability. But adding cryptoprocessors that won’t expose the secret key and thus will prevent from any penetrations from outside would close the loophole.

Have a look at some of our fake images that pass verification test by OSK-E3: http://www.elcomsoft.com/canon.html

So, can you now trust Canon’s OSK decision if an image is original or not?

iPhone 4 Performance

Wednesday, September 15th, 2010

Finally, we’ve got our first iPhone 4 in office. And what was the first thing we did with it? Yes, test its performance to complete table in my previous post.

This brand-new iPhone 4 is capable of doing 1.4 millions MD5 iterations per second, about 35% more than iPhone 3GS.

I haven’t found any information on iPhone 4CPU clock frequency, but if we assume that it uses same chip as iPad (which seems to be the case), then exhibited performance corresponds to roughly 775 MHz.

Measuring iPhone Performance

Thursday, August 5th, 2010

I’ve had plans to create some kind of performance measurement app for iPhone/iPod/iPad for quite a bit time of already, and after reading recent reports that iOS 4 is very slow on iPhone 3G I thought that time had finally come.

So I’ve quickly coded an app which computed performance in MD5 hash computations per second, and here are the results:

Device CPU Frequency Thousands MD5 per second
iPhone 3G 412 MHz 350
iPhone 3GS 600 MHz

1050

iPad 1 GHz 1800

The performance scales almost linearly (with respect to CPU frequency) for iPhone 3GS and iPad.

For iPhone 3G this is, however, not the case. Although CPU clock is only 1.5 times slower when compared to iPhone 3GS, overall performance is three times slower.

Puzzled, I did some research and found out that iPhone 3G and iPhone 3GS are using very different CPU cores indeed (link). The key difference is that iPhone 3GS uses dual-issue superscalar CPU which allows executing two instruction per clock. iPhone 3G utilized single-issue scalar core, and is thus limited to executing single instruction per clock. This perfectly explains missing factor of two in performance vs. clock rate difference between iPhone 3G and 3GS.

ATI is at it. Again.

Wednesday, May 12th, 2010

Two months ago I wrote a blog post "ATI and NVIDIA: Making Friends out of Enemies" where (among other things) I wrote:

Developing software for ATI cards is (okay — was) a nightmare. In 2009 ATI quietly introduced two changes in their drivers which made previously perfectly functional and compatible applications to crash (if you are curious: with Catalyst 9.2 or 9.3 they’ve changed names of supporting DLLs bundled with drivers; with Catalyst 9.9 or 9.10 they’ve probably changed format of underlying binary so that anything compiled and linked in with earlier versions caused a driver to crash).

Well, with the release of Catalyst 10.4 drivers ATI is again at it. This time problem only affects users who have display adapters from different vendors in their computer. Applications utilizing ATI Stream will work on such configurations just fine with Catalyst 10.3, but once you upgrade to 10.4, applications will crash with faulting module being aticaldd.dll, a part of ATI Display driver. Kinda embarrassing, I would say. Regression testing is really something one with millions of users should consider.

Users of our software relying on ATI hardware accelerations (as well as any other ATI Stream enabled applications) should not update to 10.4 if ATI Readeon is not the only card in their computer.

ATI and NVIDIA: Making Friends out of Enemies

Friday, March 12th, 2010

There had been a long standing competition between NVIDIA and ATI which has lasted for years now. And there is no winner so far — just like with Windows vs. Linux or PC vs. Mac debate there are ones who prefer the former and others who prefer the latter. Kind of «religious» issue.

(more…)

New password-cracking hardware

Friday, February 19th, 2010

Some time ago we wrote about the smallest password cracking device. Not suitable for you? No problem, here is another one: not as small, but definitely more powerfull: Audi. Yes, it's a car. No, we're not kidding. Just read NVIDIA and Audi Marry Silicon Valley Technology with German Engineering press release from NVIDIA. Or if you need more information, The New MMI Generation from Audi might be also helpful. In brief: Audi A8 luxury sedan is equipped with an entertainment system that uses two GPUs from NVIDIA. We have no idea what are these chips (may be Fermi?) and is it technically possible to load our own code to them, but still funny, isn't it? :)

Now: long-awaited ElcomSoft Password Recovery KIT

Tuesday, October 6th, 2009

Click to see this fat and full of cholesterol image in details

Our it-friends from Ukraine (KARPOLAN and Dmitry) highly optimized our developing processes and helped us finalize long-awaited Password Recovery KIT. We won’t go deep into technical details, just have a look at rough visualization.