They are simply extracting the encryption keys from the memory of a running computer using DMA and firewire. @breaknenter has been doing this with inception and some scripts for years.
Great solution. Ban everything that is good, instead of doing an effort to provide something better. A billion people should be able to come up with something at least as good rather quick, but they're probably busy doing their daytime job for Skype or Yahoo...
I totally agree. While input validation will help you with numeric values, when Chloe O'Brian comes along, she does want her name to be properly stored
... I'm not quite satisfied with the preventative measures. While input validation helps reduce the number of input validation mistakes, disallowing all meta/control characters in input, may leave a pretty limited application. I would combine input validation with proper character escaping. For SQL, use prepared statements. LDAP, escape all meta characters (,|,* etc. For XML, escape Xpath meta characters.
Well, the other hacker, whoever he is, claims he has 30 undiclosed firefox flaws.....but then again my mother claims she has 30 undisclosed security flaws in notepad
The send() (and sendto()) calls I'm referring to here are native C-calls provided by the OS to send messages over TCP or UDP. Changing the semantics could kill/unstabilize applications.
Newer APIs like uDAPL adresses these issues by providing asynchronous message sending using calls with different semantics.
For sending of files I'm sure this has increased performance greatly as you when sending a file might have to first read the file into userland, copy into kernel and then onto nic. Reading directly from disc to a TOE would of course be the real overhead-killer.
Zero-copy techniques are also done for newer APIs like uDAPL for RDMA-operations (over InfiniBand or similar).
Yes. Checksum was one of the problems. The other problem is the memory-to-memory-copying of data due to the semantics of the tcp/udp-send() call. This semantics require that the data existing in the memory location at the time send() is called is the data to be sent. If the application changes the data directly after the send()-call this should not affect what is sent. This means that the OS has to copy the data into kernel memory, and then at some later time copy it onto the nic. This memory-to-memory-copying becomes a severe problem when the traffic and bandwidth increases
As far as I can remember when trying it, it isn't even a real windowing system. It just takes a picture of the application and creates a rectangular surface with the picture on it. When they're sent to the background, you can't actually interact with the windows like you can do with Sun's great looking "Project Looking glass":
Project looking glass
Mixing humans and rabbits(!) actually makes me more concerned about the killer rabbits of Monty Pythons holy grail coming to life....
Bring forth the holy hand grenade!
The above post was meant as a general wondering, not a bashing of XML-databases. Thank you for your clearification.
As far as I'm aware, there are absolutely no requirements on the length of indexed fields
I guess using the term indexing instead of access was kinda bad here.
The reasion why i say fixed length is a good thing is because jumping from record to record is a lot easier when every record has the same length. (To jump to record 100, jump to address if start + 100 times length of a record. (This is overly simplified. When records are deleted and moved things get more complicated)). For fields of varying length an SQL DBMS can divide the record into say two blocks and put a pointer at the end of the first part. Still, changing one record won't affect the position of the other records, like it would do in an XML file. But since "Large XML-file" does not apply, this is obviously not an issue.
Also I'm having trouble understanding how XML can ever compete with SQL when doing large queries. I mean, parsing a file...hello...
In what in this thread is referred to as SQL DBMS, the records have fixed length fields to make indexing possible.
I guess you could index an XML, but all index addresses would be wrong the minute you change a value in the first record.
--
Please write your signature using italic so my brain can separate it from the rest
Slashdot Mirror
Link to inception: http://www.breaknenter.org/projects/inception/
They are simply extracting the encryption keys from the memory of a running computer using DMA and firewire. @breaknenter has been doing this with inception and some scripts for years.
Does that mean this will be a Star Trek "holiday special" ? (http://www.starwarsholidayspecial.com/)
I surely hope he didn't do a natural join with the ocean.
Hotel California (slightly rewritten): "You can log out any time you want, but you can never leave"
Great solution. Ban everything that is good, instead of doing an effort to provide something better. A billion people should be able to come up with something at least as good rather quick, but they're probably busy doing their daytime job for Skype or Yahoo...
I totally agree. While input validation will help you with numeric values, when Chloe O'Brian comes along, she does want her name to be properly stored
... I'm not quite satisfied with the preventative measures. While input validation helps reduce the number of input validation mistakes, disallowing all meta/control characters in input, may leave a pretty limited application. I would combine input validation with proper character escaping. For SQL, use prepared statements. LDAP, escape all meta characters (,|,* etc. For XML, escape Xpath meta characters.
Well, the other hacker, whoever he is, claims he has 30 undiclosed firefox flaws.....but then again my mother claims she has 30 undisclosed security flaws in notepad
No Zero-copy points to the fact that there are no memory-to-memory copies. It's copied (or sent if you will) directly from memory to nic.
The send() (and sendto()) calls I'm referring to here are native C-calls provided by the OS to send messages over TCP or UDP. Changing the semantics could kill/unstabilize applications.
Newer APIs like uDAPL adresses these issues by providing asynchronous message sending using calls with different semantics.
For sending of files I'm sure this has increased performance greatly as you when sending a file might have to first read the file into userland, copy into kernel and then onto nic. Reading directly from disc to a TOE would of course be the real overhead-killer. Zero-copy techniques are also done for newer APIs like uDAPL for RDMA-operations (over InfiniBand or similar).
Yes. Checksum was one of the problems. The other problem is the memory-to-memory-copying of data due to the semantics of the tcp/udp-send() call. This semantics require that the data existing in the memory location at the time send() is called is the data to be sent. If the application changes the data directly after the send()-call this should not affect what is sent. This means that the OS has to copy the data into kernel memory, and then at some later time copy it onto the nic. This memory-to-memory-copying becomes a severe problem when the traffic and bandwidth increases
Couldn't agree more. All the CPU cycles gained by compiling for a specific computer are probably wasted on compiling the darned thing.
As far as I can remember when trying it, it isn't even a real windowing system. It just takes a picture of the application and creates a rectangular surface with the picture on it. When they're sent to the background, you can't actually interact with the windows like you can do with Sun's great looking "Project Looking glass": Project looking glass
Can I install this version without killing my other operating systems?
Ah...nothing beats the old objective "usage" method. A thorough and scientificly acclaimed way of evaluation.
Will an input picture of a badger make it play "badger badger mushroom"?
Mixing humans and rabbits(!) actually makes me more concerned about the killer rabbits of Monty Pythons holy grail coming to life.... Bring forth the holy hand grenade!
Or putting up restaurants calles "Restaurant at the end of the university" on major universities...uhm...maybe not...
Maybe we will finally get an operating system with a thorough security model....hopefully not so thorough that it can't be used...
Oh man, it looks like some sort of "Fisher Price - My first keyboard"
Seeing how the phones keep getting better and better screens, WAP will become obsolete as regular internet is far better.
The above post was meant as a general wondering, not a bashing of XML-databases. Thank you for your clearification. As far as I'm aware, there are absolutely no requirements on the length of indexed fields
I guess using the term indexing instead of access was kinda bad here. The reasion why i say fixed length is a good thing is because jumping from record to record is a lot easier when every record has the same length. (To jump to record 100, jump to address if start + 100 times length of a record. (This is overly simplified. When records are deleted and moved things get more complicated)). For fields of varying length an SQL DBMS can divide the record into say two blocks and put a pointer at the end of the first part. Still, changing one record won't affect the position of the other records, like it would do in an XML file. But since "Large XML-file" does not apply, this is obviously not an issue.
Also I'm having trouble understanding how XML can ever compete with SQL when doing large queries. I mean, parsing a file...hello... In what in this thread is referred to as SQL DBMS, the records have fixed length fields to make indexing possible. I guess you could index an XML, but all index addresses would be wrong the minute you change a value in the first record. -- Please write your signature using italic so my brain can separate it from the rest