1. Denny Crane's Avatar
    Surur, you need help.
    08-01-2007 08:58 AM
  2. surur's Avatar
    Yup, so for the 9 days we'll be abroad we'll use about 3,758KB/day based on current usage. Bringing our cost to about $7.70/day. I can live with that.
    Also, (I may be wrong about this) but to sign up to that plan is $25 per month, and is for a whole year, or a $175 ETF.

    Is that right or wrong?

    I decided to re-do your calculation for you.

    3.758x9=33.8 MB

    At $25 x 12 = $300 for the first 20 megabytes, leaving 13.8 MB at $5 per megabyte=$69

    Total = $369, or if you use the ETF, $25 + $175 + $69 =$269

    So its either $41 or $29 per day - about the cost of drinks.

    You will probably just be better of paying $169 at $5/MB, at $18 per day.

    Again, I sure hope you dont use google maps...

    Surur
    08-01-2007 09:16 AM
  3. whmurray's Avatar
    Apple just released firmware 1.0.1. So far reported benefits are increased volume, and no safari crashes while listening to music. The official change log is merely "bug fixes."

    Update: the volume increase is disputed.
    Update: on security issues, apple posted this: http://docs.info.apple.com/article.html?artnum=306173
    Watched the install. One interesting step was identified as "verifying current software." It will be interesting to see what happens when someone tries to update a user modified iPhone.
    08-01-2007 09:40 AM
  4. cmaier's Avatar
    Watched the install. One interesting step was identified as "verifying current software." It will be interesting to see what happens when someone tries to update a user modified iPhone.
    People have done so. Some had to first restore.

    By the way, the reports of lost SMS or whatever surur is trying to point out only happen when you have to restore. If you haven't hacked your phone, you don't lose any data. Not all hacked phones required restoration. Not clear on why.
    08-01-2007 09:44 AM
  5. whmurray's Avatar
    Yup, so for the 9 days we'll be abroad we'll use about 3,758KB/day based on current usage. Bringing our cost to about $7.70/day. I can live with that.
    Me too; an iPhone is not about the money. (T-Mobile did charge me $1500- for one two week trip to Europe, y'all be ca'ful, heah?)
    08-01-2007 09:44 AM
  6. cmaier's Avatar
    Oops.. Not everything is fixed. And of course Safari still runs as root, meaning every crash is a potential arbitrary code execution with full system access possiblity...


    http://forums.macrumors.com/showthread.php?t=336070

    Surur
    Why do you say that? Does ARM not allow protected code pages?

    I'm no ARM expert, but i'm not aware of very many modern processors that share the x86 problem of treating code and data as being freely interchangeable (absent specific instructions to do otherwise).

    Also, what's your source for it still running as root?
    08-01-2007 09:51 AM
  7. surur's Avatar
    Why do you say that? Does ARM not allow protected code pages?

    I'm no ARM expert, but i'm not aware of very many modern processors that share the x86 problem of treating code and data as being freely interchangeable (absent specific instructions to do otherwise).

    Also, what's your source for it still running as root?
    We now know, from the patches, that the claim that a safari crash can lead to arbitrary code execution is real. Right?

    The hackers who created the exploit said any safari crash is a potential exploit. Safari still crashes. Do you disagree with this?

    I am assuming Safari still runs as root until we know otherwise. Apple's descriptions of their fixes did not mention fixing the architectural issue.

    Surur
    08-01-2007 10:07 AM
  8. AnteL0pe's Avatar
    Also, (I may be wrong about this) but to sign up to that plan is $25 per month, and is for a whole year, or a $175 ETF.
    You sign up on a month by month basis

    Total = $369, or if you use the ETF, $25 + $175 + $69 =$269

    So its either $41 or $29 per day - about the cost of drinks.

    Again, I sure hope you dont use google maps...

    Surur
    I redid my math as well, keeping it in KBs as thats what all the measurments are in. I also realized that I had initially left out the $25 fee so here's the math with that included. We average 3,785KB/day with average every day use here in the US, that includes browsing, email and yes, Google Maps. Now assuming i stopped using Google Maps my cost could be even lower.

    3,758 KB/Day * 9 Days = 33,822KB - 20,000 Free 20MB = 13,822 KB * $.005/KB = $69.11 + $25 upfront fee = $94.11 / 9 Days = $10.46/Day
    08-01-2007 10:10 AM
  9. cmaier's Avatar
    We now know, from the patches, that the claim that a safari crash can lead to arbitrary code execution is real. Right?

    The hackers who created the exploit said any safari crash is a potential exploit. Safari still crashes. Do you disagree with this?

    I am assuming Safari still runs as root until we know otherwise. Apple's descriptions of their fixes did not mention fixing the architectural issue.

    Surur
    That's some twisted reasoning. First of all, we know for a fact that not all changes were reported by Apple. There are several visible changes that don't show up on the change log. There are also several apparent bug fixes that don't show up on the change log.

    Second, we don't know that crashes can be used for exploits. In the report you are talking about (http://www.securityevaluators.com/iphone/) they are clearly speculating; the actual exploit they reported had nothing to do with crashing. I've seen no proof that a crash can lead to arbitrary code execution, and if it's using protected code pages it seems that it can't.

    What they say is:

    "Is it likely that there are other vulnerabilities in the iPhone?

    It's a near certainty. For example, every cause of Safari crashing on the iPhone is a potential vulnerability. And getting Safari on the iPhone to crash isn't that hard. Additionally, it's likely there are vulnerabilities in the other iPhone applications as well."

    The actual "arbitrary code" thing is arbitrary web page code that gets executed without you intending - and that was supposedly fixed.

    You say you are "assuming" but you originally stated your assertion as a fact. But this report says nothing about crashes resulting in arbitrary code being run, says nothing about root (though i've seen that referred to elsewhere), and the published exploit has nothing to do with crashes or root.
    08-01-2007 10:22 AM
  10. surur's Avatar
    You sign up on a month by month basis
    Are you sure about that? This post seems to disagree.

    Re: Calling when overseas
    Posted: Jul 27, 2007 6:14 PM in response to: Cenk Reply Email


    All other plans state clearly when you need to sign a 1-year agreement, not this one:

    International Data Global Plan for iPhone
    For just an additional $24.99 per month, iPhone customers may add a Data Global Plan to their existing domestic data plan and receive 20MB of data usage in 29 countries, including Canada, China, Mexico and many additional countries in Europe/Asia. Overage rate is $.005/KB. Outside the 29 discounted countries, the data usage rate is $.0195/KB

    But I was told by the CS agent that there is a 175$ termination fee and , yes, you need to sign for a full year. I guess 175$ is not that bad if you consider that a week
    http://discussions.apple.com/thread....readID=1029360

    I redid my math as well, keeping it in KBs as thats what all the measurments are in. I also realized that I had initially left out the $25 fee so here's the math with that included. We average 3,785KB/day with average every day use here in the US, that includes browsing, email and yes, Google Maps. Now assuming i stopped using Google Maps my cost could be even lower.

    3,758 KB/Day * 9 Days = 33,822KB - 20,000 Free 20MB = 13,822 KB * $.005/KB = $69.11 + $25 upfront fee = $94.11 / 9 Days = $10.46/Day
    Sorry, you will have to do your maths again. And apparently without a plan its $0.02 per kilobyte, or $20.48 per megabyte. Your 33.8 megabytes will cost you $690

    Surur
    08-01-2007 10:33 AM
  11. surur's Avatar
    That's some twisted reasoning. First of all, we know for a fact that not all changes were reported by Apple. There are several visible changes that don't show up on the change log. There are also several apparent bug fixes that don't show up on the change log.

    Second, we don't know that crashes can be used for exploits. In the report you are talking about (http://www.securityevaluators.com/iphone/) they are clearly speculating; the actual exploit they reported had nothing to do with crashing. I've seen no proof that a crash can lead to arbitrary code execution, and if it's using protected code pages it seems that it can't.

    What they say is:

    "Is it likely that there are other vulnerabilities in the iPhone?

    It's a near certainty. For example, every cause of Safari crashing on the iPhone is a potential vulnerability. And getting Safari on the iPhone to crash isn't that hard. Additionally, it's likely there are vulnerabilities in the other iPhone applications as well."

    The actual "arbitrary code" thing is arbitrary web page code that gets executed without you intending - and that was supposedly fixed.

    You say you are "assuming" but you originally stated your assertion as a fact. But this report says nothing about crashes resulting in arbitrary code being run, says nothing about root (though i've seen that referred to elsewhere), and the published exploit has nothing to do with crashes or root.
    Arbitrary code execution is not arbitrary javascript execution

    And you said you were a professional!

    Surur
    08-01-2007 10:36 AM
  12. cmaier's Avatar
    Arbitrary code execution is not arbitrary javascript execution

    And you said you were a professional!

    Surur
    You are making my point. I've seen nothing revealed about CRASHES causing arbitrary code execution.

    The only exploit those guys announced had to do with you going to a webpage that does NOT cause a crash, but which allows running of arbitrary code. The way they do this had to do with, apparently, a buffer overflow caused by executing arbitrary javascript or some other html structure, or somehow screwing with the networking stack. In the end, it required a bogus access point, cross-site scripting, or some other way to get you to the bad web page.

    But, and here's the point: the only mention of "crash" comes in that language I quoted, which was speculation about other possible attacks. The "crash" discussion had nothing to do with arbitrary code or with root.
    08-01-2007 10:44 AM
  13. surur's Avatar
    You are making my point. I've seen nothing revealed about CRASHES causing arbitrary code execution.

    The only exploit those guys announced had to do with you going to a webpage that does NOT cause a crash, but which allows running of arbitrary code. The way they do this had to do with, apparently, a buffer overflow caused by executing arbitrary javascript or some other html structure, or somehow screwing with the networking stack. In the end, it required a bogus access point, cross-site scripting, or some other way to get you to the bad web page.

    But, and here's the point: the only mention of "crash" comes in that language I quoted, which was speculation about other possible attacks. The "crash" discussion had nothing to do with arbitrary code or with root.
    Again, I am concerned by your understanding of buffer overflows and how they work. Did you really do x64 work, or were you making that up?

    I will try and explain it in simple language. A program receives data (e.g a web page or an mp3 etc) in a buffer. If the programmer did not put enough checks in, the data can over run the buffer the programmer prepared to accept the data. Thats a buffer overflow. This can commonly cause a crash.

    However, if the data is specially crafted, the hacker may overrun registers which tell the OS which command to execute next. Execution passes to the code the hacker just injected into the buffer, and his code can do anything, including download further code for example, install a root kit, send 1000's of sms's to premium numbers etc.

    Read more here. http://en.wikipedia.org/wiki/Buffer_overflow

    Arbitrary code means arbitrary code. I assume your use of a mac at home explains your lack of education.

    Surur
    08-01-2007 10:54 AM
  14. AnteL0pe's Avatar
    Are you sure about that? This post seems to disagree.
    Yes i just spoke to someone at ATT and had it set up.

    Sorry, you will have to do your maths again. And apparently without a plan its $0.02 per kilobyte, or $20.48 per megabyte. Your 33.8 megabytes will cost you $690

    Surur
    But I am not without a plan, thats the whole point. I have the plan, thats why its $.005. Stop making things up.
    08-01-2007 10:55 AM
  15. cmaier's Avatar
    Again, I am concerned by your understanding of buffer overflows and how they work. Did you really do x64 work, or were you making that up?

    I will try and explain it in simple language. A program receives data (e.g a web page or an mp3 etc) in a buffer. If the programmer did not put enough checks in, the data can over run the buffer the programmer prepared to accept the data. Thats a buffer overflow. This can commonly cause a crash.

    However, if the data is specially crafted, the hacker may overrun registers which tell the OS which command to execute next. Execution passes to the code the hacker just injected into the buffer, and his code can do anything, including download further code for example, install a root kit, send 1000's of sms's to premium numbers etc.

    Read more here. http://en.wikipedia.org/wiki/Buffer_overflow

    Arbitrary code means arbitrary code. I assume your use of a mac at home explains your lack of education.

    Surur
    Wow, nice. The only thing more annoying than the fact that you have no idea what you are talking about is that you think you do.

    Why don't you look up "protected page." On modern microprocessors, a memory page can be marked in various ways (read-only, etc.) One thing that is commonly done now (even on x86-64) is to mark a page as "code" or "data." You cannot execute code on a data page, and you cannot modify (via buffer overflow) a code page.

    Yes, as I pointed out, x86 does not have such protections (while x86-64 does), but almost every other modern architecture (i assume ARM) does.

    Thus if i overflow my buffer, all i can do is corrupt a data page. I can never actually execute any code i put into memory that way, as it is on a data page and the CPU will refuse to execute it.

    x86 suffers from this problem because it was designed to permit self-modifying code, and mixed data/code pages. You may know of something called DEP (Data Execution Protection) that you can do in windows xp IF you are running on an x86-64 chip that supports it (like the one I designed). Any time you try to executed a data page, it kills the program and gives you a message. This is hardware level protection, and other processors have it too.

    And, mr. expert, you don't "overrun registers." Registers are not the same thing as memory. Registers exist within the cpu, and you can't "overrun them" by overrunning a buffer. Buffers are arrays in memory.

    And just because "buffer overflows" CAN cause a crash doesn't mean they necessarily allow arbitrary code to run. You are substituting your own paltry excuse for knowledge in place of actual references because you got caught making up what the exploit report said.
    08-01-2007 11:07 AM
  16. cmaier's Avatar
    Apparently (at least some) ARM processors do support the sort of memory protection to which I have consistently referred:


    http://www.arm.com/products/CPUs/ARM_Cortex-M3.html

    See "Memory Protection Unit."

    Again, I am concerned by your understanding of buffer overflows and how they work. Did you really do x64 work, or were you making that up?

    I will try and explain it in simple language. A program receives data (e.g a web page or an mp3 etc) in a buffer. If the programmer did not put enough checks in, the data can over run the buffer the programmer prepared to accept the data. Thats a buffer overflow. This can commonly cause a crash.

    However, if the data is specially crafted, the hacker may overrun registers which tell the OS which command to execute next. Execution passes to the code the hacker just injected into the buffer, and his code can do anything, including download further code for example, install a root kit, send 1000's of sms's to premium numbers etc.

    Read more here. http://en.wikipedia.org/wiki/Buffer_overflow

    Arbitrary code means arbitrary code. I assume your use of a mac at home explains your lack of education.

    Surur
    08-01-2007 11:15 AM
  17. surur's Avatar
    Apparently (at least some) ARM processors do support the sort of memory protection to which I have consistently referred:


    http://www.arm.com/products/CPUs/ARM_Cortex-M3.html

    See "Memory Protection Unit."
    Your faith in Apple is endearing, but exploitingiphone, acknowledged by Apple in that update, says the heap is executable.

    Unfortunately, once an iPhone application isbreached by an attacker, very little prevents an attacker from obtaining complete control of the system. All the processes which han-dle network data run with the effective user id of 0, i.e. the superuser. This means that a compromise of any application gives the abil-ity to run code in the context of that applica-tion which has the highest possible privilege level. Additionally, no address randomization was used in by the operating system. This means that each time a process runs, the stack, heap, and executable code is located at precisely the same spot in memory. This helps attackers write reliable exploit code by allowing them to guess the layout of memory from run to run of an application and even from device to device. Most modern operat-ing systems incorporate some sort of address randomization. Additionally, the heap (and possibly the stack) is executable. Again, this has the effect of making exploit development easier for an attacker as it allows them to simply place their code on the heap and jump to it once they have control of the program. Had these precaution been taken, it would have forced attackers to use more sophisti-cated methods of exploitation such as return-to-libc. Therefore, while precautions were made to reduce the amount of code available to a remote attacker, once a vulnerability is located it is relatively easy for them to suc-cessfully exploit and obtain complete control of the device.
    http://64.233.183.104/search?q=cache...lnk&cd=1&gl=uk

    Why do you assume Apple is using specific security features when everything so far demonstrates they dont?

    Surur
    08-01-2007 11:33 AM
  18. mikec#IM's Avatar
    Rumours rumours.

    Wouldn't put much stock in it until real numbers come out; we're only 60 days until 1M units, right?
    08-01-2007 11:44 AM
  19. cmaier's Avatar
    Your faith in Apple is endearing, but exploitingiphone, acknowledged by Apple in that update, says the heap is executable.


    http://64.233.183.104/search?q=cache...lnk&cd=1&gl=uk

    Why do you assume Apple is using specific security features when everything so far demonstrates they dont?

    Surur
    THe only one assuming is you. You assume there are no changes in the update that are not on the published list, despite the fact that we know that's not true. You assume(d) that:

    - safari runs as root (even the paragraph above doesn't say that. it is talking about the network stack, not safari)
    - if you run as root and crash, you necessarily can run arbitrary code (again, not true if protected memory features are used)
    - registers are the same thing as memory
    - you know more about microprocessor architecture than everyone else

    If Apple is not using the security features available in the microprocessor, then shame on them. Based on the cited text, it appears that prior to this update they did not, at least not to the degree they should have. But unlike you, I don't just make assumptions. I look for actual facts and data to support a reasonable conclusion.

    And your original statement was, to paraphrase:

    safari still (unknown if there were changes) runs as root (not true. that's the network stack) and therefore a crash can lead to executing arbitrary code (a crash is not necessary to use a buffer overflow exploit, though buffer overflow exploits can be defeated entirely via hardware precautions.)

    Unlike you, I never stated as fact that Apple hardware behaved a certain way. I simply pointed out that modern microprocessor generally support the protection to which i referred, found a source that showed that at least some ARM processors do support that hardware, and suggested that this meant that iphone could be immune from that particular kind of attack.

    And, since you don't know the difference between a register and memory, i highly doubt you know what a "heap" is (though I'm sure you'll run over to the wikipedia to figure it out).
    08-01-2007 12:12 PM
  20. mikec#IM's Avatar
    THe only one assuming is you. You assume there are no changes in the update that are not on the published list, despite the fact that we know that's not true. You assume(d) that:

    - safari runs as root (even the paragraph above doesn't say that. it is talking about the network stack, not safari)
    - if you run as root and crash, you necessarily can run arbitrary code (again, not true if protected memory features are used)
    - registers are the same thing as memory
    - you know more about microprocessor architecture than everyone else

    If Apple is not using the security features available in the microprocessor, then shame on them. Based on the cited text, it appears that prior to this update they did not, at least not to the degree they should have. But unlike you, I don't just make assumptions. I look for actual facts and data to support a reasonable conclusion.

    And your original statement was, to paraphrase:

    safari still (unknown if there were changes) runs as root (not true. that's the network stack) and therefore a crash can lead to executing arbitrary code (a crash is not necessary to use a buffer overflow exploit, though buffer overflow exploits can be defeated entirely via hardware precautions.)

    Unlike you, I never stated as fact that Apple hardware behaved a certain way. I simply pointed out that modern microprocessor generally support the protection to which i referred, found a source that showed that at least some ARM processors do support that hardware, and suggested that this meant that iphone could be immune from that particular kind of attack.

    And, since you don't know the difference between a register and memory, i highly doubt you know what a "heap" is (though I'm sure you'll run over to the wikipedia to figure it out).
    Isn't a "heap" the amount of cash you fork over to buy and use and iPhone? :-)

    Sorry, couldn't resist, but I for one am enjoying the ping pong....
    08-01-2007 12:37 PM
  21. surur's Avatar
    THe only one assuming is you. You assume there are no changes in the update that are not on the published list, despite the fact that we know that's not true. You assume(d) that:

    - safari runs as root (even the paragraph above doesn't say that. it is talking about the network stack, not safari)
    - if you run as root and crash, you necessarily can run arbitrary code (again, not true if protected memory features are used)
    - registers are the same thing as memory
    - you know more about microprocessor architecture than everyone else

    If Apple is not using the security features available in the microprocessor, then shame on them. Based on the cited text, it appears that prior to this update they did not, at least not to the degree they should have. But unlike you, I don't just make assumptions. I look for actual facts and data to support a reasonable conclusion.

    And your original statement was, to paraphrase:

    safari still (unknown if there were changes) runs as root (not true. that's the network stack) and therefore a crash can lead to executing arbitrary code (a crash is not necessary to use a buffer overflow exploit, though buffer overflow exploits can be defeated entirely via hardware precautions.)

    Unlike you, I never stated as fact that Apple hardware behaved a certain way. I simply pointed out that modern microprocessor generally support the protection to which i referred, found a source that showed that at least some ARM processors do support that hardware, and suggested that this meant that iphone could be immune from that particular kind of attack.

    And, since you don't know the difference between a register and memory, i highly doubt you know what a "heap" is (though I'm sure you'll run over to the wikipedia to figure it out).
    cmaier, let go of the heap thing. I was just simplifying things for you.

    Again, your faith in Apple is endearing. Safari runs as root.

    No one said all crashes can be exploited, but a crash shows where the problems handling data are.

    I dont know more than everyone about processors, but I sure seem to know more about security than you.

    Surur
    08-01-2007 12:38 PM
  22. cmaier's Avatar
    Let's stick to the people who actually managed an exploit rather than some random website which is guessing based on reading a crash log: http://www.securityevaluators.com/ip...tingiphone.pdf

    You quoted the language yourself. "the processes which handle networking" is not the same thing as "safari." It's the network stack.

    "No one said all crashes can be exploited." You did:

    Message 2146: "..meaning every crash is a potential arbitrary code execution" (go ahead and now overemphasize "potential")

    Message 2157: "we now know...that the claim that a safari crash can lead to arbitrary code execution is real."

    Message 2157: "the hackers who created the exploit said any safari crash is a potential exploit. Safari still crashes."

    Message 2163: "if the data is specially crafted, the hacker may overrun registers...and his code can do anything."

    At the very least, as your statements evolved, they evolved to the point of "any buffer overrun can be exploited."

    And now you show further ignorance with "crash shows where the problems handling data are." Really? So all crashes are caused by "problems handling data?"

    You don't know squat about security, microprocessors, operating systems, programming, or the iphone. Every time you open your own mouth and try to state something as fact as opposed to copying and pasting other people's complaints you show your ignorance.

    You still haven't explained why when we know things have changed which were not on the official list, we should assume that nothing else security-related changed. I'm not assuming it has, I'm waiting for data, but you are assuming it hasn't.

    "I was just simplifying things for you." Actually, it was the register thing, not the heap thing, and I can assure you you don't need to simplify for me. (And you're full of it. No one would simplify "memory" into "register." Who takes a generic term and turns it into a term-of-art to simplify something?)
    08-01-2007 01:04 PM
  23. mikec#IM's Avatar
    Let's stick to the people who actually managed an exploit rather than some random website which is guessing based on reading a crash log: http://www.securityevaluators.com/ip...tingiphone.pdf

    You quoted the language yourself. "the processes which handle networking" is not the same thing as "safari." It's the network stack.

    "No one said all crashes can be exploited." You did:

    Message 2146: "..meaning every crash is a potential arbitrary code execution" (go ahead and now overemphasize "potential")

    Message 2157: "we now know...that the claim that a safari crash can lead to arbitrary code execution is real."

    Message 2157: "the hackers who created the exploit said any safari crash is a potential exploit. Safari still crashes."

    Message 2163: "if the data is specially crafted, the hacker may overrun registers...and his code can do anything."

    At the very least, as your statements evolved, they evolved to the point of "any buffer overrun can be exploited."

    And now you show further ignorance with "crash shows where the problems handling data are." Really? So all crashes are caused by "problems handling data?"

    You don't know squat about security, microprocessors, operating systems, programming, or the iphone. Every time you open your own mouth and try to state something as fact as opposed to copying and pasting other people's complaints you show your ignorance.

    You still haven't explained why when we know things have changed which were not on the official list, we should assume that nothing else security-related changed. I'm not assuming it has, I'm waiting for data, but you are assuming it hasn't.

    "I was just simplifying things for you." Actually, it was the register thing, not the heap thing, and I can assure you you don't need to simplify for me. (And you're full of it. No one would simplify "memory" into "register." Who takes a generic term and turns it into a term-of-art to simplify something?)
    Did something just get thown down?
    08-01-2007 01:20 PM
  24. surur's Avatar
    Let's stick to the people who actually managed an exploit rather than some random website which is guessing based on reading a crash log: http://www.securityevaluators.com/ip...tingiphone.pdf

    You quoted the language yourself. "the processes which handle networking" is not the same thing as "safari." It's the network stack.

    "No one said all crashes can be exploited." You did:

    Message 2146: "..meaning every crash is a potential arbitrary code execution" (go ahead and now overemphasize "potential")

    Message 2157: "we now know...that the claim that a safari crash can lead to arbitrary code execution is real."

    Message 2157: "the hackers who created the exploit said any safari crash is a potential exploit. Safari still crashes."

    Message 2163: "if the data is specially crafted, the hacker may overrun registers...and his code can do anything."

    At the very least, as your statements evolved, they evolved to the point of "any buffer overrun can be exploited."
    First, do you understand English? You understand potential, may, can, if etc? If so, how do you translate it into "all"? I started doubting your credentials, now I am doubting your intelligence.

    And now you show further ignorance with "crash shows where the problems handling data are." Really? So all crashes are caused by "problems handling data?"
    Please dont go setting up straw men. And read up on fuzzing.
    http://en.wikipedia.org/wiki/Fuzz_testing

    Surur
    08-01-2007 01:28 PM
  25. oalvarez's Avatar
    regardless of what Surur and his copied/pasted threads might say,

    i still like my iPhone
    08-01-2007 01:32 PM
3,194 ... 8586878889 ...
LINK TO POST COPIED TO CLIPBOARD