Author |
This is the gif image that will crash or restart your SE phone |
sadeghi85 Joined: Oct 13, 2007 Posts: 341 PM |
on a K550@W610, they are all working fine.
EDIT: strange!! when i want to add them in new playlist...... restart without PIN! but i can play them in file manager.
[ This Message was edited by: sadeghi85 on 2008-03-22 11:34 ] |
|
max_wedge Joined: Aug 29, 2004 Posts: > 500 From: Australia PM, WWW
|
On 2008-03-22 08:28:08, mario2004 wrote:
This is one of the few places (real world included), where I can behave like a kid and knowing someone gives a dam about it
Everything you say seems designed to get a reaction rather than contribute thoughtfully to the discussion. Your contempt for SE users is glaringly obvious, it's quite useless of you to pretend anything else.
I don't really mind, you are entitled to be however you like, but to claim you are not biased against SE is a bit of a laugh.
_________________
File System Tweaks for the K750 K750 Tricks
K800 Tips and Themes
Max's K800 Page
[ This Message was edited by: max_wedge on 2008-03-22 13:36 ] |
xtacy Joined: Jan 13, 2007 Posts: 117 From: Oman PM |
doesn't affect the w960 |
harry20larry Joined: Feb 18, 2008 Posts: 338 PM |
I think it overloads the phones ram or something? |
thami Joined: Feb 08, 2005 Posts: 169 From: UK PM |
my p1i is fine  |
chadiwrx Joined: Sep 25, 2005 Posts: 336 PM |
On 2008-03-22 12:07:19, chadiwrx wrote:
I have ringtones for the W890i that reset the phone when they are uploaded to the handset. Tested on the following handsets & they keep rebooting K800i, K810i & W660i.
Btw i have downloaded these ringtones from the Sony Ericsson wap site.
Here are the ringtones in question
Download here
Edit: Tested these on a Nokia N73 ran with no problems
Did anyone else check these out? Did they have the same effect on your phone/s as they did to mine? |
max_wedge Joined: Aug 29, 2004 Posts: > 500 From: Australia PM, WWW
|
The image crashes my K800 and K750 However if you delete the file before it has finished the animation the phone won't crash. It's only once the file has finished it's animation that the phone crashes.
It's a cool animation too!
But my K700 doesn't seem to play the gif animation so never reaches the end of the file and therefore doesn't crash.
The ringtones work fine, no resetting.
_________________
File System Tweaks for the K750 K750 Tricks
K800 Tips and Themes
Max's K800 Page
[ This Message was edited by: max_wedge on 2008-03-23 03:35 ] |
razec Joined: Aug 20, 2006 Posts: > 500 From: Pearl of the Orient Seas PM |
On 2008-03-23 04:29:32, max_wedge wrote:
The image crashes my K800 and K750
_________________
Now that'll be the reason i wont ever try that crazy gif on my phone
agree max, the animation is insanely cool!
~19 years at Esato |
max_wedge Joined: Aug 29, 2004 Posts: > 500 From: Australia PM, WWW
|
it's no worry razec. Just close all java apps (so nothing is running - sometimes java apps can malfunction if closed unexpectedly) and then try it
|
jemuel Joined: Sep 21, 2006 Posts: 124 From: PH PM, WWW
|
my phone crashed too. probably, the reson is its processor and RAM can't handle such "demanding" object. since P990 and p1i have higher processor and RAM ,they aren't affected.
I  my k608i I  Esato |
hanugro Joined: Feb 28, 2005 Posts: > 500 PM |
Actually you need to see it differently. Phone that can receive a corrupted file and behaves as if there is nothing wrong is actually has problem. Imagine if this file is important file and you copy it to your phone, view it and think it is OK then transfer it to other computer far aways who really need it but can't use it because it is corrupted.
But I agree that phone should be more graceful and catch the exception instead of just restarting. At least let the user know what it does not like before restarting. I thought Java should handle this. Maybe J2ME is still way behind J2SE. |
max_wedge Joined: Aug 29, 2004 Posts: > 500 From: Australia PM, WWW
|
On 2008-03-23 06:10:41, jemuel wrote:
my phone crashed too. probably, the reson is its processor and RAM can't handle such "demanding" object. since P990 and p1i have higher processor and RAM ,they aren't affected.
Actually it's not a lack of cpu or memory resources that causes this problem. The image is tiny, it uses hardly any resources at all. The image has been purpose designed to crash A100 phones and it most likely does so by causing a memory addressing error or buffer overflow.
Just about any operating system is susceptible to such an attack, but this particular file is targeted at A100. (That's why UIQ is immune)
On 2008-03-23 06:38:15, hanugro wrote:
But I agree that phone should be more graceful and catch the exception instead of just restarting. At least let the user know what it does not like before restarting. I thought Java should handle this. Maybe J2ME is still way behind J2SE.
It's not J2ME that is to blame.
1st the phones you call "java" phones do not run on JAVA, they run on A100. J2ME is an additional application platform that runs over the top of A100. There is a bit of a perception around that non-symbian SE phones are "java" phones, because you can install "java" applications on them, but the java applications are installed into a java virtual machine that runs over the top of the core OS.
The crash that occurs when virus.gif is viewed on the phone occurs within the core OS (ie: A100). J2ME isn't even operative when the crash occurs. If the crash only occured within J2ME applications, THEN you could blame J2ME
2nd even J2SE can be targeted for these kinds of attacks. I have had many crashes occur in J2SE VM's running on my PC, it's by no means uncommon. So even if you were right to blame J2ME, which you are not, it is still incorrect to claim that J2SE is immune from this kind of thing.
3rd No operating system is completely immune to EOF faults or buffer overflows. EVERY single operating system on the planet is crashable, given the right code. Such a "virus" could be designed for MAC, UNIX, Linux, Windows, Symbian, Palm, WM, Beos, Dos, or any OS you care to name.
But I agree that phone should be more graceful and catch the exception instead of just restarting.
Running crash prediction software in the background is VERY resource intensive and also unreliable. There is no sure fire way to predict a crash of this kind. If it were so, no operating system would ever crash.
Don't be fooled by our friend Mario's bit of fun - this "crash" does not indicate SE phones are in some way inferior to other phones. This attack has designed to exploit characteristics of A100, but could just as easily have been designed to exploit symbian or linux phones.
The Nokia fanboys who created this are are so keen to discredit SE that they go to these great lengths to dishonestly cast aspersions. Meanwhile, SE fanboys spend their time hacking their own phones rather than Nokia. This is probably why there are so much better hacks available for SE than Nokia
_________________
File System Tweaks for the K750 K750 Tricks
K800 Tips and Themes
Max's K800 Page
[ This Message was edited by: max_wedge on 2008-03-23 07:06 ] |
razec Joined: Aug 20, 2006 Posts: > 500 From: Pearl of the Orient Seas PM |
The Nokia fanboys who created this are are so keen to discredit SE that they go to these great lengths to dishonestly cast aspersions. Meanwhile, SE fanboys spend their time hacking their own phones rather than Nokia. This is probably why there are so much better hacks available for SE than Nokia
can't believe those fanboys had gone this long just to bash SE. tbh SE community is the best
~19 years at Esato |
Nipsen Joined: Jul 31, 2007 Posts: > 500 From: Noway PM, WWW
|
On 2008-03-23 07:56:01, max_wedge wrote:
Running crash prediction software in the background is VERY resource intensive and also unreliable. There is no sure fire way to predict a crash of this kind. If it were so, no operating system would ever crash.
Well.. when you're running a java- application, then the program can crash because a module fails, or if some logic or other doesn't work. But the program doesn't take the OS with it (on any good java- machine, such as anything not used by MS). Because he memory used in the program can't "elevate privileges" (read: execute monitor- code for the OS), or execute code that could cause a "buffer overrun", and overwrite memory other programs will crash from. And I'm sure SE chose that platform for applications on their phones for that reason - because of the security, the reliability around installing extra apps on the phone, and because the well- specified modules.
Is it possible to have the same guarantee involved when executing c- code? It's a different framework from the beginning, so no. But it sure is possible to program the modules in your program to operate within the constraints you give it. And then fault the program when it doesn't. And that's what SE hasn't done here, and allowed a picture- animator to run monitor- level code, and overwrite memory.
(Not that certain other manufacturers aren't notorious for just quietly ignoring every fault in the programs - so the hangs can be written off as "random bugs" that somehow are "acceptable" when they happen. But hey..)
Don't be fooled by our friend Mario's bit of fun - this "crash" does not indicate SE phones are in some way inferior to other phones. This attack has designed to exploit characteristics of A100, but could just as easily have been designed to exploit symbian or linux phones.
Well.. no. You won't get an overflow error when launching specific modules in a well- written program environment that isn't designed to give full privileges to every kind of program- string anywhere in the OS. And a good OS has some way to recover from errors in the code, when specific modules are launched to do some task. The same goes for any program trying to access memory directly - the framework can prevent that. I mean - you just won't find that kind of error on a unix system, or in a java machine, because of the memory handling.
(...And that's not expensive algoritms dealing with garbage- collection, and so on. That's proper addressing, and lack of opportunity to elevate code to monitor- privileges executed in a "user"- environment by design).
Bottom line: SE expected the OS code to be self- contained, and impossible to crack. It wasn't, and the only recovery available on the first consistency check is to restart the phone. Not pretty - but at least it won't corrupt the files on the phone afterwards (that too, happens on phones from certain other manufacturers). |
max_wedge Joined: Aug 29, 2004 Posts: > 500 From: Australia PM, WWW
|
Good points nipsen, in other words symbian would be harder to fault. But are we comparing an A100 OS against symbian and if so is it really a fair comparison?
And as you say, the files are protected from corruption atleast. Personally I don't care if makers like SE don't go all out to provide 100% protection of OS's that aren't designed to run high demand file or application servers (or even a home pc). As long as a phone is stable in the situations that average end users find themselves in then I think they have done enough.
As for security (and threat from viruses and malware) on Symbian, because of it's higher complexity probably needs more attention given to code vulnurabilities. Atleast the J2ME platform is well sandboxed from the core OS.
And bluetooth is not that easy to crack - you have to rely on social engineering or unobstructed physical access to gain malicous access to a bluetooth phone.
So I still think the ability of this "malware" gif image to crash an SE phone is not an indication that SE A100 phones are less stable than Symbian.
|
|