After seeing Mona and Lena and the inspiration behind that, Roger Alsing's blog post on genetic programming, I found myself writing my own slightly different version. Written in Cocoa it only uses two command verbs: brush and triangle. The generation algorithm simply pairs brush and triangle commands together whenever it places a new triangle. I also cheat by letting it sample from the source image. It still plays around with the color of the triangles after the initial color sampling.
Source:
CocoaEvo 106 KB
Disclaimer: hacked together in one night. The actual mutator code runs two worker threads, I ripped that code from another one of my projects, so the CodeMutator module is kind of a mess -- and that's really where the interesting stuff happens.
Some results:
Elapsed time for Dodo (illustration by Roland Savery) was ~19 minutes.
Elapsed time for Circle (illustration by Me;) was ~9 minutes.
Fun. Fun.
Thursday, March 5, 2009
Friday, January 9, 2009
Sandboxing Applications in OS X
Last month I spent most of my time studying the OS X Mach-O file format and the dyld. After playing around with Sandboxie on windows I thought it'd be fun to see how it could potentially be implemented on Mac OS X. The following is basically a dump of what I learned as I ventured into the world of the dyld on Mac OS X.
First, I should define what sandboxing means in this context. Sandboxing an application involves wrapping applications within a lightweight container which restricts what an application is able to do and in some cases changes the behavior of system functions completely. The goal of this type of sandboxing is to prevent an application from arbitrarily writing into the filesystem. Reads come from the source filesystem but writes are redirected into the sandbox filesystem. In this way sandboxed applications cannot change system files.
Is there a need for sandboxing on OS X?
I'm not a security expert so I cannot comment on whether or not sandboxing in this form is effective, beneficial or necessary on OS X. From my average developer's standpoint there are benefits such as:
Ways to Sandbox Applications on OS X
Function Interposing via Dynamic Library Insertion
(Before continuing, note that OS X occasionally uses two-level namespaces, which means that linux method of overriding functions may not necessarily work. Interposing does provide a nice way to address this issue.)
This approach involves directing the dyld (the dynamic link editor) to load a specified library at the process launch time. This is simply done by setting the 'DYLD_INSERT_LIBRARIES' environment variable to the target library before execution of the an application. The inserted library to be loaded has a special '__interpose' segment in the __DATA section which is interpreted by the dyld. Amit Singh's fantastic book has a chapter on interposing. Essentially it is a table of new and old function pointer pairs. Whenever the dyld needs to locate a symbol it will first look at the interposing table. This means that any dynamically linked symbol may be overridden by the library you inserted. So now you can redirect open/read/write system calls from the dynamic library.
The caveat of this method being that you can only call the real functions from within the library. This means that everything you need to do has to happen within the library.
So now we can insert our own versions of functions to be used by arbitrary applications. The question now is what functions should be interposed?
Nearly all the system calls are located within libSystem on OS X but there are also multiple versions of most system calls. From the average developer's standpoint this is handled transparently. In this case, though, it causes issues if the library is to robustly handle any OS X executable. For example, there are actually three different 'open' function calls:
Since we're not necessarily sure which version the executable is going to use each of the three versions of the functions need to interposed. See the multiple symbol variants link below for further explanation.
Of the system calls we are generally interested in the ones that deal with file and directory manipulation directly:
The list ends up being very long and there are a huge number of special cases. Such as how mmap function is handled, or how the /dev/* special nodes are handled.
Current Development State
So that's where I'm at now. Early on, I was able to run Safari inside of another shadow directory simply by hijacking the open call and opening a shadow file (first copying the original to the shadow directory) and returning the file descriptor to the shadow file. This worked surprisingly well but I wanted to get more ambitious and run any application from a single shadow volume file. To do this I've chosen to use sqlfs with sqlite. The result should be an injectable library which runs in user-mode without need for special privileges which writes into one file which can easily be discarded. Well, that's the idea anyway, it's quite a bit of work to be done still and I'm not sure if there is any demand for such a product.
Miscellaneous and References:
dyld was re-written in C++ from a C/asm version for rosetta 10.4/10.5? However, interposing is not included in the open source release?
Guard Malloc(libgmalloc) uses only DYLD_INSERT_LIBRARIES envar to override malloc and it does so by using an interpose table.
Two Level Namespaces
Executing Mach-O Files
dyld Library Reference
Mach-O Reference
Multiple Symbol Variants
OS X Kernel Programming
First, I should define what sandboxing means in this context. Sandboxing an application involves wrapping applications within a lightweight container which restricts what an application is able to do and in some cases changes the behavior of system functions completely. The goal of this type of sandboxing is to prevent an application from arbitrarily writing into the filesystem. Reads come from the source filesystem but writes are redirected into the sandbox filesystem. In this way sandboxed applications cannot change system files.
Is there a need for sandboxing on OS X?
I'm not a security expert so I cannot comment on whether or not sandboxing in this form is effective, beneficial or necessary on OS X. From my average developer's standpoint there are benefits such as:
- Security: Yes, there may not be (m)any malicious apps targeted towards OS X but this could change. Assuming the sandboxing application is lightweight enough to run transparently to the user, there would be little reason to not run inside a sandbox.
- Testing: Run app that is to be tested inside a sandbox. After running the app the sandbox can be deleted when done. No extra cleanup required, system never really was effected by the app.
- Auditing: Track what application adds/removes/modifies files. To be fair there are auditing abilities built into OS X already, see audit(2). Accessed files can also be seen within the Activity Monitor application under the Inspect, 'Open Files and Ports.'
Ways to Sandbox Applications on OS X
- Kernel Extension: From just a glance at sandboxie it seems to use a kernel-mode driver to get most of it's work done. Not having ever done kernel development before, I took a different approach. It could be that a kernel extension would be the cleanest way to achieve app sandboxing however the kext may then become a target itself if it were poorly implemented.
- Some Sort of Emulation: This approach would involve running the process under an emulation layer like Valgrind. Patches do exist to get valgrind running under OS X and would be worth investigating feasibility. One downside would be the extreme performance penalty.
- Function Interposing via Dynamic Library Insertion: Probably the most viable user-level way to achieve sandboxing. Below I have described how it would work.
- Function interposing via Executable Modification: The details would be pretty nasty but you could modify the symbol table within the mach-o executable to point to other functions in other libraries. The problem is that all the other loaded dynamic libraries would need to be modified as well and that's where it'd be really messy.
- Other ways? Certainly I'm probably missing other (easier) methods for doing this. If so let me know!
Function Interposing via Dynamic Library Insertion
(Before continuing, note that OS X occasionally uses two-level namespaces, which means that linux method of overriding functions may not necessarily work. Interposing does provide a nice way to address this issue.)
This approach involves directing the dyld (the dynamic link editor) to load a specified library at the process launch time. This is simply done by setting the 'DYLD_INSERT_LIBRARIES' environment variable to the target library before execution of the an application. The inserted library to be loaded has a special '__interpose' segment in the __DATA section which is interpreted by the dyld. Amit Singh's fantastic book has a chapter on interposing. Essentially it is a table of new and old function pointer pairs. Whenever the dyld needs to locate a symbol it will first look at the interposing table. This means that any dynamically linked symbol may be overridden by the library you inserted. So now you can redirect open/read/write system calls from the dynamic library.
The caveat of this method being that you can only call the real functions from within the library. This means that everything you need to do has to happen within the library.
So now we can insert our own versions of functions to be used by arbitrary applications. The question now is what functions should be interposed?
Nearly all the system calls are located within libSystem on OS X but there are also multiple versions of most system calls. From the average developer's standpoint this is handled transparently. In this case, though, it causes issues if the library is to robustly handle any OS X executable. For example, there are actually three different 'open' function calls:
open
open$UNIX2003
open$NOCANCEL$UNIX2003
Since we're not necessarily sure which version the executable is going to use each of the three versions of the functions need to interposed. See the multiple symbol variants link below for further explanation.
Of the system calls we are generally interested in the ones that deal with file and directory manipulation directly:
open
close
read
write
fstat
link
unlink
mkdir
mknod
mmap
munmap
opendir
...etc...
The list ends up being very long and there are a huge number of special cases. Such as how mmap function is handled, or how the /dev/* special nodes are handled.
Current Development State
So that's where I'm at now. Early on, I was able to run Safari inside of another shadow directory simply by hijacking the open call and opening a shadow file (first copying the original to the shadow directory) and returning the file descriptor to the shadow file. This worked surprisingly well but I wanted to get more ambitious and run any application from a single shadow volume file. To do this I've chosen to use sqlfs with sqlite. The result should be an injectable library which runs in user-mode without need for special privileges which writes into one file which can easily be discarded. Well, that's the idea anyway, it's quite a bit of work to be done still and I'm not sure if there is any demand for such a product.
Miscellaneous and References:
dyld was re-written in C++ from a C/asm version for rosetta 10.4/10.5? However, interposing is not included in the open source release?
Guard Malloc(libgmalloc) uses only DYLD_INSERT_LIBRARIES envar to override malloc and it does so by using an interpose table.
Two Level Namespaces
Executing Mach-O Files
dyld Library Reference
Mach-O Reference
Multiple Symbol Variants
OS X Kernel Programming
Tuesday, December 23, 2008
From the cold snowy hill
A post before the end of 2008
Preface:
My mote-m experiment has effectively ended. Although it's still available in the store it has been superseded by team efforts from real artists looking to (and succeeding) at making it big on the app store. I wrote a postmortem about my experience about two months ago. I never published it because the iPhone App Store scene continues to change at such a rapid pace that anything written is immediately out-dated and irrelevant. In spite of that fact, I will share a few parts.
Introduction:
Let me say that these are my personal experiences and observations as an independent/first-time iTunes App Store game developer. I built Mote-M from the ground-up. I created the web site, wrote the code, created the art and answered everyone's kind emails. I consider Mote-M to be a success in it's original goals and a failure to achieve it's full potential. I might be wrong on any conclusions I make and apologise in advance for my poor grammar and inconsistent tense. You have been warned.
Development:
Mote Massacre, Mote-M for short, is a Tower Defense game in the style of the Desktop Tower Defense games. It started it's life in December of 2007 as a flash multiplayer game. When the iPhone SDK was announced the decision to port the game engine was made. After being approved by Apple in late-july (along with the rest of the non-special developers), I ported over the basic game and decided to launch the app as a fun toy-app for $0.99 in mid-August. The original goal was to build a fun game which would also pay for the developer registration. I really only expected maybe 20 people to buy the game. Since August I've watched the app store grow and evolve.
A Learning Experience:
Revelations I had as a complete n00b in the iTunes app store game business.
Quality of apps: The quality of apps and the relationship with an app's price and sales volume has been discussed elsewhere. It's still important to mention that with very low app prices a developer has to make money somewhere else or succeed in selling a very large volume.
Top sales lists DO matter: there are a set of passionate gamers who read the blogs and the forums and participate in the app store community but I'm willing to bet that the majority buy off the front page and the top paid apps lists. This is not surprising -- I probably wouldn't visit the forums and blogs if I weren't developing for the platform.
Rampant Piracy of Apps: The day you release your app for purchase is the same day anyone with a jailbroken phone can download your app for free. It's a fact of software -- you can't stop it, so don't try. The amount of time I spent trying to figure out the convoluted app DRM scheme could've been spent on developing a better app. To be fair the code signing stuff is pretty much a one time setup but from a goals standpoint it *just* fails.
The app store has huge potential: A developer can make a lot of money if they launch the app perfectly. Where perfectly in that sentence means: releasing an eye-catching, functional app which encourages impulse buys. Impulse buys fuel the app store right now. This may also be contributing to lower prices.
The Community:
This is one area where I was pleasantly surprised. The community of people who gathered around Mote-M are passionate and highly engaged. The e-mails I've received have been almost universally helpful and encouraging. Any developer not embracing their community is definitely losing valuable feedback.
Future Plans:
As I write this I have xcode open to a new super-secret non-game project for the mac. Once that project matures I'll return to the app store to see what sort of climate there is for indie game developers. Right now there seems to be a new flood of ports from existing games: SimCity (tm), TETRIS(r), Brothers In Arms(r), etc. Without users being able to demo apps they may stick to more well-known and bigger names instead of supporting software devs who create more original apps.
About gxjones.com:
Independent software developer Grant Jones started gxjones.com in late 2006. Grant grinds away creating another independent game with the experience he has gained from Mote Massacre and past applications he has written.
Preface:
My mote-m experiment has effectively ended. Although it's still available in the store it has been superseded by team efforts from real artists looking to (and succeeding) at making it big on the app store. I wrote a postmortem about my experience about two months ago. I never published it because the iPhone App Store scene continues to change at such a rapid pace that anything written is immediately out-dated and irrelevant. In spite of that fact, I will share a few parts.
Introduction:
Let me say that these are my personal experiences and observations as an independent/first-time iTunes App Store game developer. I built Mote-M from the ground-up. I created the web site, wrote the code, created the art and answered everyone's kind emails. I consider Mote-M to be a success in it's original goals and a failure to achieve it's full potential. I might be wrong on any conclusions I make and apologise in advance for my poor grammar and inconsistent tense. You have been warned.
Development:
Mote Massacre, Mote-M for short, is a Tower Defense game in the style of the Desktop Tower Defense games. It started it's life in December of 2007 as a flash multiplayer game. When the iPhone SDK was announced the decision to port the game engine was made. After being approved by Apple in late-july (along with the rest of the non-special developers), I ported over the basic game and decided to launch the app as a fun toy-app for $0.99 in mid-August. The original goal was to build a fun game which would also pay for the developer registration. I really only expected maybe 20 people to buy the game. Since August I've watched the app store grow and evolve.
A Learning Experience:
Revelations I had as a complete n00b in the iTunes app store game business.
Quality of apps: The quality of apps and the relationship with an app's price and sales volume has been discussed elsewhere. It's still important to mention that with very low app prices a developer has to make money somewhere else or succeed in selling a very large volume.
Top sales lists DO matter: there are a set of passionate gamers who read the blogs and the forums and participate in the app store community but I'm willing to bet that the majority buy off the front page and the top paid apps lists. This is not surprising -- I probably wouldn't visit the forums and blogs if I weren't developing for the platform.
Rampant Piracy of Apps: The day you release your app for purchase is the same day anyone with a jailbroken phone can download your app for free. It's a fact of software -- you can't stop it, so don't try. The amount of time I spent trying to figure out the convoluted app DRM scheme could've been spent on developing a better app. To be fair the code signing stuff is pretty much a one time setup but from a goals standpoint it *just* fails.
The app store has huge potential: A developer can make a lot of money if they launch the app perfectly. Where perfectly in that sentence means: releasing an eye-catching, functional app which encourages impulse buys. Impulse buys fuel the app store right now. This may also be contributing to lower prices.
The Community:
This is one area where I was pleasantly surprised. The community of people who gathered around Mote-M are passionate and highly engaged. The e-mails I've received have been almost universally helpful and encouraging. Any developer not embracing their community is definitely losing valuable feedback.
Future Plans:
As I write this I have xcode open to a new super-secret non-game project for the mac. Once that project matures I'll return to the app store to see what sort of climate there is for indie game developers. Right now there seems to be a new flood of ports from existing games: SimCity (tm), TETRIS(r), Brothers In Arms(r), etc. Without users being able to demo apps they may stick to more well-known and bigger names instead of supporting software devs who create more original apps.
About gxjones.com:
Independent software developer Grant Jones started gxjones.com in late 2006. Grant grinds away creating another independent game with the experience he has gained from Mote Massacre and past applications he has written.
Saturday, October 11, 2008
Mote-M Base Source Code
Version v1.2 of Mote-M is complete so I took some time to bundle up the base 'framework' I used to create Mote-M. It's pretty unexciting but it takes care of the details which are necessary to setup an OpenGL ES rendering context on the iPhone.
Read further details here or just download it here (released under the BSD license).
Read further details here or just download it here (released under the BSD license).
Wednesday, September 10, 2008
Mote-M v1.2
My blog makes it look like I haven't done any thing for the past 2 months. This is simply untrue! I've been consumed with my Mote Massacre project which is currently available on the iTunes App store for $0.99.
Originally called 'Mote Massacre' I shortened the name to Mote-M because the icon on the iPod showed up as 'Mote...ascre' which doesn't sound quite right.
Mote-M is actually the evolution of the two-player tower defense death-match flash game I created back in December of 2007. Unfortunately I took down the server that was running the 2pTD flash game so it can't be played anymore; maybe someday it will come back -- or maybe Mote-M Multiplayer will be released?
The gxjones.com site has all the details on this game.
Thursday, July 10, 2008
ScatterBrain released
And now for something completely different...
ScatterBrain v1.0
Back in January I set out to create my own clone of a piece of software I thought was cool (a recurring theme I have). I call it ScatterBrain and it's a clone of the todo-list editor TaskPaper. Yes, I can hear the groans now, another todo-list program, yay!
It hasn't been in testing mode and it hasn't been in development mode either, it's just been sitting gathering dust for the past 4 months -- which is a waste. So I'm releasing it for free and without any sort of guarantee that it won't randomly crash or do anything else crazy.
Download
ScatterBrain v1.0 - OS X Leopard Only
If you do use it I'd love to hear from you @: grant -at- gxjones.com (Just know I cannot support this software unless I start charging for it. And if that's the case I recommend you go with the real thing: TaskPaper)
The Format:
It handles the typical taskpaper plaintext format:
Project:
- task
it also adds a group line which is identified by a '+' character and a section line which is identified by a '#':
#Some Section
+ A group
Clicking on the circle to the left of a task will mark is as "@done" as well as adding a @date tag with the current date.
Geeky details
Finally, if you absolutely need to change the color-scheme you can do it via tags within your text (I know that's uber geeky and not user friendly). Adding this to your ScatterBrain file results in project headers being black:
@pv_color_white(project-header-background-color,0.0,1.0)
@pv_color_white(project-header-gradient1-color,0.7,0.38)
@pv_color_white(project-header-gradient2-color,0.0,0.2)
@pv_color_white(project-color,1.0,0.75)
For reference, this is the default presentation context used:
@pv_color_rgb(group-color,0.0,0.5,0.0,1.0)
@pv_color_rgb(note-color,0,0,0,1.0)
@pv_color_white(background-color,1.0,1.0)
@pv_color_white(project-background-color,0.90,1.0)
@pv_color_white(project-header-background-color,0.85,1.0)
@pv_color_white(project-header-gradient1-color,0.86,0.65)
@pv_color_white(project-header-gradient2-color,0.66,0.3)
@pv_color_white(section-background-color,0.90,1.0)
@pv_font(project-font,user,24)
@pv_font(group-font,user,16)
@pv_color_white(project-color,0.25,1.0)
Development Status
I'd go back to it if there is interest. There were two killer features I was working on when I stopped development.
Known issues:
- large files will be fully reparsed and be very slow (so stick to smaller files); this was something I really wanted to address but never got around to it
- sometimes the formatting isn't updated
- formatting the background lags sometimes
- probably some memory leaks in there for good measure
- zero documentation - might be an issue for some people
Friday, July 4, 2008
FlashCanvas: 3 years too late?
So I guess I'm 3 years late to the canvas-emulation party:
Overall, interest in this area seems to have died off - only recently with things like Processing.js and ContextFree.js has there been a renewed interested in backwards compatibility for the canvas tag.
side note: AFLAX uses the ExternalInterface just like FlashCanvas, so the performance observations would apply to AFLAX as well.
- Manish Jethani mentions something about the canvas tag being used for a 3D game, John Dowdell from adobe responds in Nov. 2005
- Manish Jethani suggests a way to do a SWF-based Canvas on Dec 1st, 2005
- iecanvas from Emil A Eklund released December, 2005 (uses VML)
- excanvas from Google released March, 2006 (uses VML)
- AFLAX adds canvas emulation in March 2006
Overall, interest in this area seems to have died off - only recently with things like Processing.js and ContextFree.js has there been a renewed interested in backwards compatibility for the canvas tag.
side note: AFLAX uses the ExternalInterface just like FlashCanvas, so the performance observations would apply to AFLAX as well.
Subscribe to:
Posts (Atom)