Actually, I've been in the biz for more than 20 years... I only joined Slashdot a year or so ago (hangs head in shame).
I'm trying hard to embrace open source so that I can a) wean myself off the Microsoft tit, and b) atone for past sins.
I'm not a Microsoft appologist, it just bugs me when I see people spreading misinformation that I know is absolutely 100% untrue. I guess that's just life on the Internet...
You are correct in that there are two mechanisms for programming sockets under Windows, but you are incorrect in how they work and interact.
First, there is no "berkley code that can be programmed via the std C libraries..." Part of the Winsock API specification is based on Berkley sockets -- bind(), listen(), accept(), etc. The design of the APIs is based on Berkley sockets, but the implementation is not.
The Window Message based APIs are not, in general, just wrappers around the traditional Berkley APIs. If you really want the gory details, I can provide them with some authority. (I was head of the Winsock 2 Framework group, and I wrote the Winsock 2 implementation that shipped with NT 4.)
Except that Microsoft does not use the BSD IP stack.
I worked for nearly 10 years in the Windows NT networking group.
I worked very closely with the guys who wrote the TCP/IP stack that shipped with NT 3.51 and later.
I know the NT TCP/IP sources very well.
There is some residual BSD sources in the resolver (DNS client) code (most of which has been rewritten), and in the piece-of-shit FTP client, but not in the TCP/IP stack.
In a previous life, I worked in a group that tested third-party software, but my manager was too cheap to buy a separate copy for each tester. (The company will remain nameless to protect the guilty.) One of my "unoffical" job duties was breaking copy protection of new apps (mostly games) so we could all test them.
One day, we were visited by a group of folks from ProLock. Of course, they claimed their protection scheme was completely unbreakable. As if.
Their basic technique was pretty solid. By burning a hole (with frigin' lasers) in the floppy, they introduced physical changes in the media that absolutely could not be duplicated with software.
As Deadstick mentioned, the crack consisted of a two-byte change somewhere on the disk. Basically, at some point the program called a routine to see if the special laser-blasted sector was present. If so, the program continued. The patch was just to pretend the sector was always there.
As an analogy, the ProLock scheme was like putting a bank vault lock on a rice paper door. Instead of wasting time picking the lock, it's much easier to just rip another hole in the door.
Many years ago, Apple was developing a new computer under the code name "Carl Sagan". Well, Carl Sagan learned of this and had his lawyers send a C&D letter to Apple. So Apple changed the code name to "Butt-Head Astronomer". A few details are here.
I heard the following story during my time in Microsoft's Windows NT group.
Dave Cutler (chief architect of Windows NT and well known has having a rather "abrasive" personality) had to attend an employee orientation meeting, just like every other grunt in the company. A big part of the meeting is the signing of Many Confusing Contracts, especially the one saying "everything you create during your employment belongs to Microsoft".
Dave refused to sign it. The HR dweeb running the meeting told Dave "You don't understand. If you don't sign this, I can't hire you."
Dave replied "No, you don't understand. You didn't hire me!"
This would be much better than the Airzooka toy. Not only could you mess up someone's hair from across the room, you could probably stop their heart as well.
...is to write a disassembler, preferrably in assembly language. Of course, you this won't teach you a lot of the required practical aspects (interacting with the OS, etc), but it will teach you everything you need to know about the processor's instruction set. Highly recommended.
The DoS you describe would probably be possible only when trying to connect through a proxy. From the Linux Journal article:
...a method is required to extract the sequences of ports from the log file and translate their payload into usable information. In this step it is important to be able to (a) detect when a port sequence begins and ends, (b) correctly detect a port sequence in the presence of spurious connection attempts that are not part of the sequence and (c) keep track of multiple port sequences arriving at the same time from different remote IPs.
I think using failed connection attempts as a covert channel is Pretty Damn Cool (tm).
I suspect the future of emulation/virtualization environments will resemble dynamic translation projects like HP's Dynamo as described here. Unfortunately, HP's papers on this project are from 1999, so there doesn't appear to be much activity lately. Anyway, combining something like Dynamo with a virtualization environment would allow non-native applications to run without the excessive overhead of Bochs. In theory.
Here's a short excerpt from Niels Ferguson and Bruce Schneier's excellent book Practical Crypography:
The standard (WEP) was designed by a committee which didn't include any cryptographers. The results where horrible....RC4 is a stream cipher and needs a unique nonce. WEP didn't allocate enough bits for the nonce, with the result that the same nonce value had to be reused, which in turn resulted in many packets being encrypted with the same key stream. That defeated the encryption properties of the RC4 stream cipher and allowed a smart attacker to break the encryption. A more subtle flaw was not hashing the secret key and the nonce together before using it as the RC4 key, which eventually led to key-recovery attacks. A CRC checksum was used for authentication, but since CRC computations are linear, it was trivial (using some linear algebra) to modify any packet without any chance of detection. A single shared key was also used for all users in a network, making key updates much more difficult to do. The network password was used directly as the encryption key for all communications, without using any kind of key negotiation protocol. And finally, encryption was turned off by default, which meant that most implementations never bothered turning encryption on in the first place.
WEP wasn't just broken, it was
robustly broken.
I strongly recommend Practical Cryptography for any geek with more than a passing interest in cryptography.
A friend of mine had a 4-cyl Fiero with an automatic (yuck). He called it "The Plastic Pig".
You mention that the Fiero "spun out easily". IIRC, most mid-engined cars suffer from this due to a lower polar moment of inertia as compared to a typical front-engine car. Was there some other defect (other than shitty tires) in the Fiero that contributed to this?
...and not my job, but a friend of mine had one of the worst jobs I've ever heard of.
He worked for a factory that makes cement and delivers it to building sites in those big "mixer" trucks. Back then, the cement containers on the trucks were chain driven (I think they're mostly hydraulic now). Sometimes, the chains would break. If a drive chain broke while a truck was loaded, it had to be *quickly* returned to the factory to be unloaded.
Sometimes, the cement would "set" before it could be unloaded. And thus, my friend's job...
He had to crawl into the container with a jack-hammer, break up the cement, and throw it out. Just imagine the noise of a jackhammer operating within a giant metal trash can. There was also one additional hazard -- the "blades" attached to the container that mix the cement. The cement basically acts like a grinding stone and sharpens the blades until they are like razors.
Whenever we would sit around at talk about really bad previous jobs, he was not allowed to play:-).
2) We still won't see a big example of cyber-terrorism simply because nobody has figured out how to actually kill people that way.
Terrorism is more than just killing people. It's about control; about one group forcing its will upon another. Control can be achieved by threats of physical violence. It can also be achieved by destroying economies and "ways of life". (Exactly who are the "terrorists" is left as an exercise for the reader.)
Slashdot Mirror
You should really keep up with your mail. I retired 4 years ago. So fuck off.
Kisses,
Ann
Actually, I've been in the biz for more than 20 years... I only joined Slashdot a year or so ago (hangs head in shame).
I'm trying hard to embrace open source so that I can a) wean myself off the Microsoft tit, and b) atone for past sins.
I'm not a Microsoft appologist, it just bugs me when I see people spreading misinformation that I know is absolutely 100% untrue. I guess that's just life on the Internet...
You are correct in that there are two mechanisms for programming sockets under Windows, but you are incorrect in how they work and interact.
First, there is no "berkley code that can be programmed via the std C libraries..." Part of the Winsock API specification is based on Berkley sockets -- bind(), listen(), accept(), etc. The design of the APIs is based on Berkley sockets, but the implementation is not.
The Window Message based APIs are not, in general, just wrappers around the traditional Berkley APIs. If you really want the gory details, I can provide them with some authority. (I was head of the Winsock 2 Framework group, and I wrote the Winsock 2 implementation that shipped with NT 4.)
Except that Microsoft does not use the BSD IP stack.
Ah, ProLock, now there's a blast from the past.
In a previous life, I worked in a group that tested third-party software, but my manager was too cheap to buy a separate copy for each tester. (The company will remain nameless to protect the guilty.) One of my "unoffical" job duties was breaking copy protection of new apps (mostly games) so we could all test them.One day, we were visited by a group of folks from ProLock. Of course, they claimed their protection scheme was completely unbreakable. As if.
Their basic technique was pretty solid. By burning a hole (with frigin' lasers) in the floppy, they introduced physical changes in the media that absolutely could not be duplicated with software.
As Deadstick mentioned, the crack consisted of a two-byte change somewhere on the disk. Basically, at some point the program called a routine to see if the special laser-blasted sector was present. If so, the program continued. The patch was just to pretend the sector was always there.
As an analogy, the ProLock scheme was like putting a bank vault lock on a rice paper door. Instead of wasting time picking the lock, it's much easier to just rip another hole in the door.
Many years ago, Apple was developing a new computer under the code name "Carl Sagan". Well, Carl Sagan learned of this and had his lawyers send a C&D letter to Apple. So Apple changed the code name to "Butt-Head Astronomer". A few details are here.
Maybe Lindows should be named Butt-Head CEO?I thought VD usually happened after someone scored...
I believe win2k/private/ntos/ke/bugcheck.c is the file you need...
Microsoft has great "flextime". You can work any 80 hours per week you want.
Ahh... This may partially explain I had to download a 312K update to fix a 51K DLL...
I heard the following story during my time in Microsoft's Windows NT group.
Dave Cutler (chief architect of Windows NT and well known has having a rather "abrasive" personality) had to attend an employee orientation meeting, just like every other grunt in the company. A big part of the meeting is the signing of Many Confusing Contracts, especially the one saying "everything you create during your employment belongs to Microsoft".
Dave refused to sign it. The HR dweeb running the meeting told Dave "You don't understand. If you don't sign this, I can't hire you."
Dave replied "No, you don't understand. You didn't hire me!"
In the end, Dave didn't sign the document.
This would be much better than the Airzooka toy. Not only could you mess up someone's hair from across the room, you could probably stop their heart as well.
...is to write a disassembler, preferrably in assembly language. Of course, you this won't teach you a lot of the required practical aspects (interacting with the OS, etc), but it will teach you everything you need to know about the processor's instruction set. Highly recommended.
I suspect the future of emulation/virtualization environments will resemble dynamic translation projects like HP's Dynamo as described here. Unfortunately, HP's papers on this project are from 1999, so there doesn't appear to be much activity lately. Anyway, combining something like Dynamo with a virtualization environment would allow non-native applications to run without the excessive overhead of Bochs. In theory.
Blaming the "UNIX mail servers" for spreading MyDoom is like blaming the USPS for spreading anthrax.
...reminds me of the old "ICMP REDIRECT to 127.0.0.1" trick.
javascript:open( "http://ftp.mozilla.org/pub/mozilla.org/mozilla/re leases/mozilla1.6/mozilla-win32-1.6-installer.exe" )
A friend of mine had a 4-cyl Fiero with an automatic (yuck). He called it "The Plastic Pig".
You mention that the Fiero "spun out easily". IIRC, most mid-engined cars suffer from this due to a lower polar moment of inertia as compared to a typical front-engine car. Was there some other defect (other than shitty tires) in the Fiero that contributed to this?
...and not my job, but a friend of mine had one of the worst jobs I've ever heard of.
He worked for a factory that makes cement and delivers it to building sites in those big "mixer" trucks. Back then, the cement containers on the trucks were chain driven (I think they're mostly hydraulic now). Sometimes, the chains would break. If a drive chain broke while a truck was loaded, it had to be *quickly* returned to the factory to be unloaded.
Sometimes, the cement would "set" before it could be unloaded. And thus, my friend's job...
He had to crawl into the container with a jack-hammer, break up the cement, and throw it out. Just imagine the noise of a jackhammer operating within a giant metal trash can. There was also one additional hazard -- the "blades" attached to the container that mix the cement. The cement basically acts like a grinding stone and sharpens the blades until they are like razors.
Whenever we would sit around at talk about really bad previous jobs, he was not allowed to play :-).
"Digital Rights Management" is to "rights" as "Lung Cancer" is to "lung".
...especially if you'll be doing any extensive soldering work.