The whole problem with AI is that the model that is being used as a basis is not understood and too complex to implement with current technology. The human brain has in the neighborhood of 10,000,000,000 neurons, each having up to thousands of connections. All of these are working in parallel. Even the fastest super computers could not simulate its structure in real time. New approaches are needed that use a different model for its basis. However these too have a problem in that we as of yet do not know if they possess the potential for independent thought. Another crippling feature of current AI approaches is the lack of sensory information and lack of ability to interact with a real environment.
A dremel comes in really handy when you don't have the specialized screw driver that is needed for brand XYZ cases. You just make it into a standard flathead screw and everything is fine.
Don't you just love how they make it so that you have to have umpteen different screwdriver heads to do a simple repair. I now only have two (philips and flathead) and a set of allen wrenches and a socket set. If none of these work out come the dremel. I've even had customers thank me later when they needed to take one of my modified screws off.
A bit of a history lesson... The US used the Navajo Language to send secure messages back and forth. This was their encryption. In fact is was never broken by the Germans Encryption is the translation of one set of symbols into another set of symbols in such a way as the information is still present, but much harder to understand. Like I said before just because it can be broken and understood doesn't make it not encrypted. People don't read the binary and understand it they have to translate it back into a set of instructions that they understand.
"NAVAJO CODE TALKING
Most experts agree: one of the most cryptanalytically sound form of code-making is simply to speak in Navajo.
There are a few tricks here, the first being that Navajo is an intensely nuanced and dialectic form of language, and is thus royally difficult to pick up if you don't either grow up as a Navajo Indian, or spend 30 years hanging out, 24 hours a day, with Navajo Indians.
That's why the U.S. military hit upon Navajo as the singularly most successful code in World War II--because it wasn't a code at all. At the time of the war, it was estimated that only about 30 people outside of the Navajo nation could speak the language, making it extremely cryptanalytically sound. In fact, Navajo code was so successful that it is perhaps the only traditional code technique to be profiled on an episode of the X-Files--pop culture's official stamp of paranoia-culture approval."
Python is you want to be able to read it later.
There is a great example in "Programming Python 2nd Ed." by O'reilly. You can make it a Threaded or Forked server with just the examples in the book.
I always get amused when open source people spout of about how slow Java supposedly is and how much they love perl/python/php in the other. Java is pretty much faster than all of those.
There are different standards for "compiled languages" than there are for "interpreted languages." Plus you have to look at what the language is intended for. Java touts itself as an application language when perl/python/php are more of utility languages. Yes I know that you can do more than just simple parsing and cgi with perl/python/php, but that is not the point. The point is the type of language and what it is typically used for. You don't see many word processors written in an interpreted language.
At my work we have a program that is needed for information gathering. It was a custom job done by an outside agency. They chose Java as their language of choice. The program runs lots of processes and many threads. The average thread size is something like 52 MB. The total memory use of this program is something like 1.5 GB with about 500 MB of that resident in memory.
Can anyone explain why java uses so much memory or is it just bad programming by the contractor we used.
A quick disassemble, a long period of code inspection, and an equally long translation to equivalent c and we will have an open source version of the driver.
So you are admitting that you require a program to understand the binary and convert it back into something that you can read. That sounds exactly like decryption to me. My point wasn't that it was impossible to read the binary files only that is was very difficult to the point were few would attempt to and less actually could. Just because a form of encryption can be broken doesn't mean that it is not encryption. Granted I do agree that compiling was not created as a form of encryption, but as programmers have become increasingly dependent on higher level languages they have become less and less familiar with byte code.
BTW here are some definitions from googling.
Encrypt - to convert from one system of communication into another; especially : to convert a message into code
Decrypt - to discover the underlying meaning of
No. Reverse engineering is a process where a program or device is taken apart to understand how it works, generally for the purpose of reimplementing, complementing, or modifying a behavior of the system.
Do you read binary files on a daily basis. There's nothing like a good binary before bed. Compiled code has been used intentionally by programmers as a sort of encryption/stenography. You can't see what my program is doing so you can't do anything but use it. This program reads the binary and translates parts of it into meaningful messages. Giving you information about the product that you didn't have before this is reverse engineering.
Not only does BugScan automatically detect security errors, it recommends how to fix each error with
detailed code examples.
No hardware or software system is completely unhackable. There is a reason that systems that must be really secure still relay on sneaker-net. The only way to completely protect your data from others is to destroy it. If you don't want to get caught with something on your computer DON'T put it there in the first place.
Well let's see... There is UNIX which is still in use today by many corporations, Tron which is running on more microprocessors that any other operating system. These are both legacy systems that did their job well and are still doing it today. Oh yeah, then there is Linux which was designed to mimic UNIX on the X86 architecture. Just because it is old doesn't mean that it is not worth knowing about.
Slashdot Mirror
The whole problem with AI is that the model that is being used as a basis is not understood and too complex to implement with current technology. The human brain has in the neighborhood of 10,000,000,000 neurons, each having up to thousands of connections. All of these are working in parallel. Even the fastest super computers could not simulate its structure in real time. New approaches are needed that use a different model for its basis. However these too have a problem in that we as of yet do not know if they possess the potential for independent thought. Another crippling feature of current AI approaches is the lack of sensory information and lack of ability to interact with a real environment.
Don't you just love how they make it so that you have to have umpteen different screwdriver heads to do a simple repair. I now only have two (philips and flathead) and a set of allen wrenches and a socket set. If none of these work out come the dremel. I've even had customers thank me later when they needed to take one of my modified screws off.
"NAVAJO CODE TALKING
Most experts agree: one of the most cryptanalytically sound form of code-making is simply to speak in Navajo.
There are a few tricks here, the first being that Navajo is an intensely nuanced and dialectic form of language, and is thus royally difficult to pick up if you don't either grow up as a Navajo Indian, or spend 30 years hanging out, 24 hours a day, with Navajo Indians.
That's why the U.S. military hit upon Navajo as the singularly most successful code in World War II--because it wasn't a code at all. At the time of the war, it was estimated that only about 30 people outside of the Navajo nation could speak the language, making it extremely cryptanalytically sound. In fact, Navajo code was so successful that it is perhaps the only traditional code technique to be profiled on an episode of the X-Files--pop culture's official stamp of paranoia-culture approval."
From Navajo
Python is you want to be able to read it later.
There is a great example in "Programming Python 2nd Ed." by O'reilly. You can make it a Threaded or Forked server with just the examples in the book.
There are different standards for "compiled languages" than there are for "interpreted languages." Plus you have to look at what the language is intended for. Java touts itself as an application language when perl/python/php are more of utility languages. Yes I know that you can do more than just simple parsing and cgi with perl/python/php, but that is not the point. The point is the type of language and what it is typically used for. You don't see many word processors written in an interpreted language.
At my work we have a program that is needed for information gathering. It was a custom job done by an outside agency. They chose Java as their language of choice. The program runs lots of processes and many threads. The average thread size is something like 52 MB. The total memory use of this program is something like 1.5 GB with about 500 MB of that resident in memory.
Can anyone explain why java uses so much memory or is it just bad programming by the contractor we used.
A quick disassemble, a long period of code inspection, and an equally long translation to equivalent c and we will have an open source version of the driver. So you are admitting that you require a program to understand the binary and convert it back into something that you can read. That sounds exactly like decryption to me. My point wasn't that it was impossible to read the binary files only that is was very difficult to the point were few would attempt to and less actually could. Just because a form of encryption can be broken doesn't mean that it is not encryption. Granted I do agree that compiling was not created as a form of encryption, but as programmers have become increasingly dependent on higher level languages they have become less and less familiar with byte code. BTW here are some definitions from googling. Encrypt - to convert from one system of communication into another; especially : to convert a message into code Decrypt - to discover the underlying meaning of
Do you read binary files on a daily basis. There's nothing like a good binary before bed. Compiled code has been used intentionally by programmers as a sort of encryption/stenography. You can't see what my program is doing so you can't do anything but use it. This program reads the binary and translates parts of it into meaningful messages. Giving you information about the product that you didn't have before this is reverse engineering.
No hardware or software system is completely unhackable. There is a reason that systems that must be really secure still relay on sneaker-net. The only way to completely protect your data from others is to destroy it. If you don't want to get caught with something on your computer DON'T put it there in the first place.
Well let's see... There is UNIX which is still in use today by many corporations, Tron which is running on more microprocessors that any other operating system. These are both legacy systems that did their job well and are still doing it today. Oh yeah, then there is Linux which was designed to mimic UNIX on the X86 architecture. Just because it is old doesn't mean that it is not worth knowing about.