Verizon Fios Tech Support

  • Subscribe to our RSS feed.
  • Twitter
  • StumbleUpon
  • Reddit
  • Facebook
  • Digg

Sunday, 10 March 2013

Security and Trust when Everything has a Computer In It

Posted on 20:09 by Unknown

Security and Trust when Everything has a Computer In It

Recently, Panic Software announced that they had opened up an HDMI display adapter cable for the latest family of Apple iOS devices, which use a proprietary I/O port named Lightning. Inside the HDMI adapter, the engineers at Panic Software found an ARM system on a chip (SoC), that apparently accepts a compressed video signal from the iOS device and decompresses it to HDMI for the display side. 

Many were surprised to see that microprocessors have become so commonplace that even the cable that connects our devices would itself contain its own CPU. Perhaps we shouldn't have been surprised. Intel introduced the Thunderbolt interface in 2011, and it also uses a chip within its cables, also known as active cables.

Your IO cable could be a man-in-the-middle

Purchasers of the iOS HDMI display adapter expected it to perform like any other HDMI display cable, which is as a "dumb" carrier of a signal. But at this point we can no longer make such assumptions – advances in processor miniaturization have enabled every device, even a cable connector, to incorporate its own CPU. As chips have become smaller and more cost & power efficient, more hardware devices have begun to incorporate them in order to implement internal functionality. The user is often unaware that what seems like a commodity dumb device is actually, effectively, a small computer on the inside, running its own code in firmware. Security researchers ought to be thinking about the implications of this.

We can no longer treat a storage device read operation as forensic evidence 

Security researcher Travis Goodspeed presented at Chaos Communications Congress 29C3 late last year, introducing work he had done to demonstrate that a USB-attached mass storage device with custom firmware can be made to detect its environment and host, and even detect and deny attempts to forensically image it. His presentation invalidated the widely-held (but naive) assumption that a block storage device is just a dumb device, and that it would always simply obey the commands from the host. Travis showed that a drive can actually be aware of its environment, aware of the data it is storing, and actively subvert attempts to access its true stored data.

All devices that access an interface of your computer, no matter how small, ought to be treated like computers

Researcher and Dartmouth College professor Sergey Bratus reportedly exclaims "It's not a bus; it's a network!" with regard to the attack surface of computing devices. He and his colleagues published a paper last year which enumerated the ways in which device interconnect buses (e.g., USB) are just as much attack surfaces as the network interface. This is not the first paper to discuss the potential of attacks against USB hosts, drivers, or device firmware, but Sergey's paper does represent a shift that is happening with regard to recognizing the importance of securing these vectors, and the need for tools and devices to properly research them.

New device interconnect exploration tools are needed

Along those lines, at Recon 2012, Travis Goodspeed released a rapid prototyping device to be used to explore USB endpoint security, called the Facedancer. He generously donated a Facedancer to Digital Operatives, and we hope to do something interesting with it and write more soon here about our experience with implementing subversive USB devices. 

Conclusions

It is 2013 and our storage devices have internal processors and firmware; our input devices have internal processors and firmware; our high speed IO cables have internal processors and firmware; our laptop batteries have internal processors and firmware. Nearly all of these have been basically overlooked by the security research community, mostly because of proprietary and undocumented implementations and because the firmware is difficult to access. New tools are needed, and there is a clear opportunity here for exciting new research. This is a problem we hope to work on ourselves. We'll be back to share more here soon.
Read More
Posted in | No comments

Saturday, 9 March 2013

Codegate 2013 Quals

Posted on 21:42 by Unknown

The Codegate 2013 YUT Preliminary capture-the-flag event wrapped up last week on March 3, 2013. Congratulations to the European NOPSled Team for winning the challenge and congratulations to all who qualified to participate in the final challenge in Korea on April 3rd.

A contingent from Digital Operatives participated with a small team including friends. We enjoyed attempting to solve the many interesting challenges in this CTF. One in particular, solved by Joshua Dugie, was a great little problem. Below is his writeup of the challenge.


Spoiler alert!


Misc 300-2 Writeup:

We are given a file, 396c983d4290901e4060ffe25e7c0eb3, with the instructions, "Find the key".
The file is a 7-Zip archive with a single file inside, DNA.png.  DNA.png is a 1x992 PNG image with single color pixels in a column, separated by two black pixels.

DNA.png

To extract the information from this image, you can use the Python Imaging Library.



#!/usr/bin/python

import PIL.Image

# get DNA.png pixels
pixels  = []
f       = open('DNA.png', 'rb')
im      = PIL.Image.open(f)
vpixels = im.getbbox()[3] + 1
for i in range(0, vpixels, 3):
   pixels.append(im.getpixel((0,i)))
f.close()

# convert pixel tuples to data
data = ''
for pixel in pixels:
   for x in pixel:
       data += chr(x)

# write out the data
f = open('dna.bin', 'wb')
f.write(data)
f.close()
Running file on the resulting data gives "dna.bin: x86 boot sector, code offset 0x5" and xxd can confirm (see the bytes 55aa at offset 0x1fe):

jdugie@machine:~$ xxd dna.bin
0000000: ea05 00c0 078c c88e d8b8 00b8 8ec0 b9ff  ................
0000010: 07be 4700 bf00 008a 0426 8805 4726 c605  ..G......&..G&..
0000020: 073c 0074 0547 46e9 edff b800 108e c0bb  .<.t.GF.........
0000030: 0000 b402 b001 b500 b102 b600 b200 cd13  ................
0000040: 72e8 ea00 0000 1052 6564 5374 6172 4f53  r......RedStarOS
0000050: 2042 6f6f 7469 6e67 2e2e 2e00 0000 0000   Booting........
0000060: 0000 0000 0000 0000 0000 0000 0000 0000  ................
...
00001d0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00001e0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00001f0: 0000 0000 0000 0000 0000 0000 0000 55aa  ..............U.
Let's analyze the code in IDA.

IDA Analysis

IDA Analysis


From the code analysis, we can easily see that the OS (a play on the North Korean Red Star Linux distribution) starts up and prompts for a username and password, expecting "Kim jong-eun" and "Boot the DNA", respectively. If the user gets it wrong, the OS reboots; if the user is right, the key is printed.

The username and password are stored and compared in reverse. The key string is also stored in reverse, but the developer of the challenge doesn't print it in reverse. To get this code to run in VirtualBox, you can dd the code to /dev/sda from a LiveCD of your choice after modifying the given sector 2 copy code to pull from the hard disk instead of the floppy (change the byte at offset 0x3d from 0x00 to 0x80).

Success!

Key: lower(md5(xor(hex(id),hex(password))))
Read More
Posted in | No comments

Wednesday, 20 February 2013

How to compile busybox with Android NDK for both ARM and x86 architectures

Posted on 19:56 by Unknown
I was looking for a way to run busybox on a Motorola RAZRi with an x86 Intel Atom processor but I couldn't find any Android app from the Google play market that was running on the phone (when running any busybox command nothing happened and I was immediately getting the prompt back).
So I decided to cross-compile busybox for Android myself. Now you will find other posts claiming to have done so by downloading an ARM-cross compiler from codesourcery.com but I had two problems with that approach:

  1. I needed an x86 cross-compiler and,
  2. I read various complaints of people not being able to run various busybox commands with this method.

Cross-compiling busybox with the Android NDK

My only option was to use the Android NDK itself, since it comes with full support of the ARM, x86, and MIPS architectures. I ended up manually configuring busybox by eliminating any module that would not cross-compile due to missing header files and/or libraries in the Android NDK.
To cut the story short, I managed to cross-compile busybox using the Android NDK compilers for both ARM and x86 architectures (I didn't try MIPS since I don't have a device with a MIPS processor to test the resulting binaries).
To build busybox yourself, download the busybox-android.patch, busybox-android.config, and build.sh script and run the latter with the following options:

$ build.sh <android NDK dir> <NDK toolchain> <Android ABI> <Toolchain compiler version> <Android Native API Level> <Install prefix>

The script will download the busybox version 1.21.0 source code, apply the busybox-android.patch and configure busybox for the right architecture.
For example if you have your Android NDK installed under /home/android/android-ndk-r8d, to build busybox for the Intel x86 architecture call the build.sh script like the following:

$ build.sh /home/android/android-ndk-r8d x86-4.7 x86 4.7 android-14 /home/android/busybox-x86

and the cross-compiled busybox binaries will be installed under  the  /home/android/busybox-x86 directory. Similarly if you want to build busybox for the ARM processor, run the following:

$ build.sh /home/android/android-ndk-r8d arm-linux-androideabi-4.7 armeabi-v7a  4.7 android-14 /home/android/busybox-arm

Download busybox binaries

The busybox binaries for x86 (compiled using the above procedure), can be found here.

Installing busybox

The above procedure was tested with release r8d of the Android NDK and for both ARM and x86 devices.

Pre-requisites

  1. Your phone must be rooted (for example check out my blog How to root Motorola RAZRi XT890 running Android 4.0.4)
  2. You must activate USB debugging mode on your device by going to Settings -> Developer Options -> USB Debugging and selecting the corresponding check box.

Installation Procedure

To install busybox on an x86 Android (rooted) device, I run the following commands with the phone connected to the computer via USB:

# logon to the phone and become root to mount the /system file system read/write
$ adb shell
shell@android:/ $ su -
shell@android:/ # mount -o rw,remount -t ext4 /dev/block/system /system
shell@android:/ # chmod 0777 /system/xbin
shell@android:/ # exit
shell@android:/ $ exit
$

then change directory to the location of the busybox binary file and push it to the phone:

$ adb push busybox /system/xbin/

log back on as root and change permissions appropriately:

$ adb shell
shell@android:/ $ su -
shell@android:/ # chmod 755 /system/xbin/busybox
shell@android:/ # chmod 0755 /system/xbin
shell@android:/ # exit
shell@android:/ $ exit
$

Installing busybox on an ARM Android device is very similar, only the mounting instruction line changes:

$ adb shell
shell@android:/ $ su -
shell@android:/ # mount -o rw,remount -t yaffs2 /dev/block/mtdblock3 /system
shell@android:/ # chmod 0777 /system/xbin
shell@android:/ # exit
shell@android:/ $ exit
$
$ adb push busybox /system/xbin/
$ adb shell
shell@android:/ $ su -
shell@android:/ # chmod 755 /system/xbin/busybox
shell@android:/ # chmod 0755 /system/xbin
shell@android:/ # exit
shell@android:/ $ exit
$
Read More
Posted in Android, ARM, busybox, Mips, x86 | No comments

Security News: Adobe Reader/Acrobat 0-Day with Sandbox Bypass

Posted on 17:05 by Unknown
Some of you have undoubtedly heard the big news in the exploit world this week. There is a new Adobe Reader/Acrobat exploit in the wild that bypasses ASLR (Address Space Layout Randomization), DEP (Data Execution Prevention), and, most importantly, the sandbox ("Protected Mode") that was introduced in Adobe Reader X. Adobe confirmed the critical-rated vulnerabilities as CVE-2013-0640, and CVE-2013-0641 on Wednesday night, February 13, 2013.  The vulnerability applies to versions 11.0.01 and earlier (XI), 10.1.5 and earlier (X), and 9.5.3 (9) and earlier. There is no fix available as of the time of this writing.

The exploit does not defeat "Protected View" that was introduced in Adobe Reader XI. However, it does not need to because Protected View is disabled by default. It is highly recommended to all Adobe users to enable Protected View as described in the Adobe link below. The exploit uses ROP (Return Oriented Programming) as one would expect to get around the standard defenses, and employs several anti-analysis mechanisms such as TLS (Thread Local Storage) callbacks and fake Export Table entries.

This news is particularly important because there have been no confirmed Adobe sandbox bypasses ever published, until now. Some readers may note that "Group IB" (a group based out of Russia) claimed to have a sandbox escape in November, 2012 when they posted a tantalizing video of Adobe Reader XI being exploited http://www.youtube.com/watch?v=uGF8VDBkK0M.  However, that particular end-to-end exploit is seeming more like vaporware every month that passes without independent confirmation.

Adobe CVE Report:
https://www.adobe.com/support/security/advisories/apsa13-02.html

FireEye has published a partial technical description of some of the shellcode from the in-the-wild exploit.  FireEye has withheld full details for now at Adobe's request.
http://blog.fireeye.com/research/2013/02/the-number-of-the-beast.html

UPDATE: Adobe has released a patch for CVE-2013-0640 and CVE-2013-0641 as of Wednesday, February 20, 2013.  You can find the security bulletin here: http://www.adobe.com/support/security/bulletins/apsb13-07.html
Read More
Posted in | No comments

Tuesday, 12 February 2013

Verizon Fios Home Monitoring Review

Posted on 15:24 by Unknown

 We want to start off by saying we love Verizon Fios. We have our cable and internet through them and don't plan on switching anytime soon.
   
   A few months ago when we went into a Verizon store we noticed their new Home Monitoring System, $89.99 for the starter kit then $9.99 a month after that.  With the starter kit you get a gateway device (which is basically a router), an indoor camera, and an indoor light module.  There are also many add-ons you can get.  We got the deadbolt keypad lock for $159.99.  The thing that got us was that we didn't have to pay anything then, they could spread out the payments for the next three months of our Verizon bill.  If we had to pay right then we wouldn't have done it. We thought this would be a cheaper security system, no contracts and we do all the monitoring.
This sounds way more awesome then it is, let's not waste any time and get to  why we say such things. We are very handy and tech savvy people, Cody would even go so far as to call himself a handy man. So the physical installation was not a problem (Cody did most of it, lol) but when we got to the tech set up the website wasn't running right and we had to call the tech support team three different times. 2 out of 3 where helpful but one of them Cody wanted to smack them through the phone. No one is a fan of rude tech support people. Just because you know what you are doing doesn't mean that everyone does, especially  when your website is not working correctly.
   
   Anyway lets go for its function. It works but not the way it was explained to us. We were told that if the motion detector camera went off we would be sent a picture text message of what set it off. That is not the case. The couple times it was set off by our dog we didn't receive a picture of him jumping around being awesome and doing awesome things  just a text to a link. The link takes you to the website where you have to sign in and there is still no picture just a message saying that the motion sensor was set off at this time, on this date. They have a smart phone app, which is great for monitoring. Downside, you can only have one user monitoring  on the app at a time. So it's kind of a pain to try to sign in and not be able to. Then you text the the other person to ask if they are on, and sometimes no one was on but it wouldn't let you in. We got the Home Monitoring System to take some stress off Cody's mind but it just added more to it.
   
   All this being said we sent it back. We're not willing to pay for something that only works 50% of the time. This could be a great product but right now we feel that Verizon Home Monitoring is not worth the trouble. We have been trying to get our money back and our bill straightened out for the last 4 months. As of now we are still waiting for the refund, we haven't payed it but its still on the bill. They say its coming so we'll see what happens.
   
   This product was not for our family, but it might work for someone else's, that up for you to decide. This has been our honest opinion.



Read More
Posted in blogging, Blogging with The Tate's, Florida, Husband and Wife perspective, man and women perspective, product reviews, products, security system, verizon, verizon fios | No comments

How to build the gcc Fortran cross-compiler for Android (ARM and x86)

Posted on 07:09 by Unknown
If you need to cross-compile for Android a program written in Fortran, you know already that the official Android NDK does not come with the gfortran compiler, and if like me you need to port to Android code that depends on Fortran (such as the lapack libraries), you are out of luck.
Fortunately I managed to compile the gcc Fortran cross-compiler with the help of  Mike Long's blog. As an added bonus, I managed to build gfortran 4.8.0 not only for the ARM but also for the x86 toolchain, as well as update the script to the latest Android NDK (currently r8d).
What you need to do is the following:
  1. download the fortran4android shell script.
  2. download the ndk-r8d fortran patch.
  3. run the script in your directory:

    $ fortran4android
  4. wait, wait, wait, ... and you will see in the android-ndk-r8d/toolchains directory two new toolchains called arm-linux-androideabi-4.8.0 and x86-4.8.0
  5. Enjoy your new gfortran compiler.

Note that I've successfully tested the script only on Ubuntu 12.04.

Addendum of August 30, 2013

I now have available a patch for the newer android-ndk-r9. To use this instead of the patch above:
  1. download the ndk-r9-fortran-patch
  2. change the fortran4android script by replacing "r8d" with "r9" everywhere
  3. run the fortran4android script in your directory.
 Note that r9 of the NDK already comes with a 4.8 gcc toolchain and to keep it separated, the fortran4android script will still generate in output a "4.8.0" toolchain.
Read More
Posted in Android, ARM, Fortran, Linux, x86 | No comments

Monday, 11 February 2013

How to root Motorola RAZRi XT890 running Android 4.0.4

Posted on 12:47 by Unknown
This procedure is only valid for Motorola RAZRi model XT890 (Intel inside) running Android 4.0.4 (system version 81.5.39001.XT890.Retail.en.GB). The following instructions refer to rooting the RAZRi from a Windows 7 PC.

You need to download the Android SDK 

Go to the Android Developer web site and download the Android SDK for Windows.
Make sure you then set the PATH environment variable to the <sdk>\platform-tools directory where all the tools can be found from the command line.

Install the latest Motorola USB drivers for you phone

Install the latest Motorola USB Drivers. Get them here.

Your phone should be factory unlocked

This is a must or else rooting the device will fail with the phone stuck on the bootloader. Go to the Motorola Web site and follow the step by step instructions. Basically open a Command Prompt window and get your Device ID by running the fastboot command. The instructions from Motorola are the following:


  1. Put your device in fastboot mode (press the power button and volume down button at the same time and connect your device to your computer with a USB cable).
  2. On your computer, open a command prompt or Terminal session.
  3. Go to the Directory where you installed the Android SDK tools, and type:$ fastboot oem get_unlock_data
  4. This fastboot command will return a character string. This is the Device ID which you will be using to generate your unique unlock key.

    Example Device ID (PC User)$ fastboot oem get_unlock_data
    (bootloader) 0A40040192024205#4C4D3556313230
    (bootloader) 30373731363031303332323239#BD00
    (bootloader) 8A672BA4746C2CE02328A2AC0C39F95
    (bootloader) 1A3E5#1F53280002000000000000000
    (bootloader) 0000000

At this point if you submit the device ID to the web form, Motorola will send you the unlock code via e-mail (after warning you that the warranty will be void if you do so).
To unlock the device:


  1. Turn off your device.
  2. Start your device in fastboot mode. To do this on most Motorola devices, push and hold the power and volume down at the same time, release the power button then release volume down. The device will power up in fastboot mode
  3. Connect the device to the computer with a USB cable. You'll get a confirmation message on the device will indicate that it's connected.
  4. Open a command window or terminal on your computer.
  5. Change field to show the path to the tools folder within the Android SDK folder.
  6. Verify that the desktop and device are connected by entering the following in the command field:$ fastboot devicesYou should see that your device is connected.
  7. Now you will unlock the bootloader. Simply enter the following in the command line:$ fastboot oem unlock UNIQUE_KEYThe UNIQUE_KEY is the code you received in the email. It is case-sensitive.
  8. If the line was entered correctly, your device's screen will confirm that your device is unlocked. You have just unlocked your device's bootloader.


Root the device

Get the RAZRi rooting utility for Windows. Get it here.
Extract the zipped files and from a Command Prompt or terminal window, change directory to the location of the utility. Make sure your RAZRi is connected to your Windows PC via the USB cable. Finally run the Root.bat command, follow the instructions, and cross your fingers.
After rebooting at least three times the phone should be rooted.


Read More
Posted in Android, Windows, x86 | No comments
Newer Posts Older Posts Home
Subscribe to: Posts (Atom)

Popular Posts

  • Transferring Files from a computer to your Android device
    Android devices have file systems similar to regular computers. Subject to permissions restrictions, we can transfer files from a computer t...
  • Meeting The Tate's
       Hello, we are Cody and Aimee Tate. We live in Florida and have been married for 3 years. Recently we have decided to start doing product ...
  • Python For Android (Py4A)
    A better solution for cross-compiling Python for Android is to use the Py4A project which is made to be used together with SL4A (Scripting L...
  • Problems with new version of rpmbuild
    The Problem With the new version of rpmbuild installed on CentOS 6.x, if you try to use an old RPM spec file, you will get an error like the...
  • Installing the Android SDK
    These instructions refer to a Ubuntu 12.04.1 LTS system running on an Intel processor. Head to the developer.android.com web site and downl...
  • Process Attribution In Network Traffic
    Author: Phil -at- DigitalOperatives Overview Digital Operatives recently completed a DARPA Cyber Fast Track (CFT) contract called  Process A...
  • Installing the Android NDK
    These instructions refer to a Ubuntu 12.04.1 LTS system running on an Intel processor. Head to the  http://developer.android.com/tools/sdk/n...
  • How to build the gcc Fortran cross-compiler for Android (ARM and x86)
    If you need to cross-compile for Android a program written in Fortran, you know already that the official Android NDK does not come with the...
  • LifeProof iPhone Case Review
       Today we are reviewing the LifeProof iPhone case, for iPhone 4 and 4S.  Like their slogan says its life-proof, which means waterproof, ...
  • How to Cross-Compile libiconv for Android
    If your legacy C/C++ code includes <iconv.h> to convert the encoding of characters from one coded character set to another, and you ne...

Categories

  • amazon
  • amazon.com
  • Android
  • Apple
  • Arduino
  • ARM
  • baby
  • baby reviews
  • back to school
  • beef jerky
  • bicycle. wagon
  • bike
  • Blanket Buddies
  • blogging
  • Blogging with The Tate's
  • books
  • busybox
  • camera
  • camera giveaway
  • candle giveaway
  • candles
  • CaseApp
  • CentOS
  • coffee
  • david haskell
  • dermorganic
  • DHCP
  • digital camera
  • events
  • Florida
  • Fortran
  • free blogger giveaway
  • free blogger sign-ups
  • full of flavor
  • giveaways
  • GNU
  • GPON
  • hair care
  • happy husband
  • Hot tea
  • Husband and Wife perspective
  • iMac
  • ipad
  • iphone
  • iphone case
  • iphone case review
  • Javascript
  • Keurig Coffee Review
  • Keurig Review
  • Kindle
  • ksh
  • LifeProof iPhone Case Review
  • Linux
  • MacOSX
  • Malachite Bloomers
  • man and women perspective
  • meat
  • Mips
  • Network
  • Pretzel Crisps
  • Pretzels
  • product reviews
  • products
  • Python
  • Router
  • scentsy
  • scentsy candles
  • school
  • scooter
  • security system
  • skin care
  • snacks
  • sony
  • sony cyber-shot
  • Stuff Animal
  • suface pro
  • Summer
  • summer fun
  • surface pro giveaway
  • techno thriller
  • Timjan Design
  • too much information
  • UNIX
  • vegan
  • vegan products
  • verizon
  • verizon fios
  • VitaminsBaby
  • waterproof case
  • Windows
  • x86
  • yummy

Blog Archive

  • ▼  2013 (41)
    • ▼  November (2)
      • Too Much Information, by: David Haskell, Book Review
      • VERIZON... What did you change?
    • ►  October (2)
    • ►  September (3)
    • ►  August (3)
    • ►  July (2)
    • ►  June (2)
    • ►  May (6)
    • ►  April (8)
    • ►  March (2)
    • ►  February (5)
    • ►  January (6)
  • ►  2012 (17)
    • ►  December (3)
    • ►  November (4)
    • ►  October (8)
    • ►  July (1)
    • ►  June (1)
Powered by Blogger.

About Me

Unknown
View my complete profile