<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	
	>
<channel>
	<title>Comments on: 2011: The year of mobile malware? Nope.</title>
	<atom:link href="http://javacard.vetilles.com/2011/01/20/2011-the-year-of-mobile-malware-nope/feed/" rel="self" type="application/rss+xml" />
	<link>http://javacard.vetilles.com/2011/01/20/2011-the-year-of-mobile-malware-nope/</link>
	<description>A weblog on Java Card, security, and other things personal</description>
	<lastBuildDate>Thu, 18 May 2017 07:26:32 +0000</lastBuildDate>
		<sy:updatePeriod>hourly</sy:updatePeriod>
		<sy:updateFrequency>1</sy:updateFrequency>
	<generator>https://wordpress.org/?v=4.0.32</generator>
	<item>
		<title>By: Tweets that mention 2011: The year of mobile malware? Nope. â€“ On the road to Bandol -- Topsy.com</title>
		<link>http://javacard.vetilles.com/2011/01/20/2011-the-year-of-mobile-malware-nope/#comment-4318</link>
		<dc:creator><![CDATA[Tweets that mention 2011: The year of mobile malware? Nope. â€“ On the road to Bandol -- Topsy.com]]></dc:creator>
		<pubDate>Sat, 22 Jan 2011 10:08:46 +0000</pubDate>
		<guid isPermaLink="false">http://javacard.vetilles.com/?p=683#comment-4318</guid>
		<description><![CDATA[[...] This post was mentioned on Twitter by David Rogers, Eric Vetillard. Eric Vetillard said: Will 2011 be the year of mobile malware? I don&#039;t think so, and static analysis will help http://bit.ly/dYnb1F (#MoCaSa followup) [...]]]></description>
		<content:encoded><![CDATA[<p>[&#8230;] This post was mentioned on Twitter by David Rogers, Eric Vetillard. Eric Vetillard said: Will 2011 be the year of mobile malware? I don&#039;t think so, and static analysis will help <a href="http://bit.ly/dYnb1F" rel="nofollow" class="liexternal">http://bit.ly/dYnb1F</a> (#MoCaSa followup) [&#8230;]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Eric VÃ©tillard</title>
		<link>http://javacard.vetilles.com/2011/01/20/2011-the-year-of-mobile-malware-nope/#comment-4315</link>
		<dc:creator><![CDATA[Eric VÃ©tillard]]></dc:creator>
		<pubDate>Thu, 20 Jan 2011 21:21:36 +0000</pubDate>
		<guid isPermaLink="false">http://javacard.vetilles.com/?p=683#comment-4315</guid>
		<description><![CDATA[Hi Craig,

There is still one point on which I kind of disagree. Strong typing makes the analysis easier, but I don&#039;t think that it is the most difficult part. I rather beileve that the most difficult part comes from the fact that native code execution is arbitrary, and that it can be used to manipulate code pointers. Thismakes the analysis much more complex, because it greatly increases the possible number of execution patterns. There is already some work about such native code analysis, which works under the condition that the code satisfies some properties. This is quite likely to come in the near future.

If we come tu rumors, I would even say that static analysis is one good reason for Apple to force the use of their tools. If the code generated by their tools satisfies a few interesting properties, it makes advanced static analysis possible, which can significantly reduce the cost of vetting applications. Now that can be considered as a competitive advantage, or as a very nice way to balance automation and human discretion very efficiently.]]></description>
		<content:encoded><![CDATA[<p>Hi Craig,</p>
<p>There is still one point on which I kind of disagree. Strong typing makes the analysis easier, but I don&#8217;t think that it is the most difficult part. I rather beileve that the most difficult part comes from the fact that native code execution is arbitrary, and that it can be used to manipulate code pointers. Thismakes the analysis much more complex, because it greatly increases the possible number of execution patterns. There is already some work about such native code analysis, which works under the condition that the code satisfies some properties. This is quite likely to come in the near future.</p>
<p>If we come tu rumors, I would even say that static analysis is one good reason for Apple to force the use of their tools. If the code generated by their tools satisfies a few interesting properties, it makes advanced static analysis possible, which can significantly reduce the cost of vetting applications. Now that can be considered as a competitive advantage, or as a very nice way to balance automation and human discretion very efficiently.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Craig Heath</title>
		<link>http://javacard.vetilles.com/2011/01/20/2011-the-year-of-mobile-malware-nope/#comment-4313</link>
		<dc:creator><![CDATA[Craig Heath]]></dc:creator>
		<pubDate>Thu, 20 Jan 2011 18:42:39 +0000</pubDate>
		<guid isPermaLink="false">http://javacard.vetilles.com/?p=683#comment-4313</guid>
		<description><![CDATA[I think we are actually in agreement here, it just goes to show the limitations of Twitter&#039;s 140 characters!  Bytecode is much easier to do effective static analysis on, because of the type safety and the inability of the code to manipulate references to arbitrary objects.  The vast majority of malware on the Symbian platform is compiled native ARM code though, which is rather harder to make any reliable judgements about.  Nevertheless, static analysis has its part to play, and we agree that there has to both an element of automation and an element of human discretion, so the trick is just how to balance those two most efficiently.]]></description>
		<content:encoded><![CDATA[<p>I think we are actually in agreement here, it just goes to show the limitations of Twitter&#8217;s 140 characters!  Bytecode is much easier to do effective static analysis on, because of the type safety and the inability of the code to manipulate references to arbitrary objects.  The vast majority of malware on the Symbian platform is compiled native ARM code though, which is rather harder to make any reliable judgements about.  Nevertheless, static analysis has its part to play, and we agree that there has to both an element of automation and an element of human discretion, so the trick is just how to balance those two most efficiently.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
