I do understand the "just get it done" crowd. There are a lot of things in CS school that are extraneous.
However, I like yourself pulled the "improved data structure" trick and equally pissed off a few peers. They said it could go no faster. On really large data sets, I reduced computation from three days to an hour.
I there needs to be CS courses for folks who just went out there and used lots of elbow grease. Creativity and "go-to" is good, but it makes no sense to contantly re-invent the wheel do to ignorance.
I wonder if you could tear off a keycap and then plug in a machine designed to generate keyclicks for all the other keys that aren't their. The number pad is likely hooked up to a standard PS/2 port which would understand the keyclicks.
Since all Windows interfaces are designed to be keyboard navigable, one should be able to browse through the start menu and find a command prompt. At that point you may have access to their internal ATM network.
Of course, you would have to repeat the cause of the crash (probably a dirty card, need a card writer that writes incorrect sequences). And of course, remember to bring a ski mask for the camera and wear gloves.;-)
It's always easier to poke holes into something instead of building things resistent to hole-poking. That's why you need to have hole-pokers on the staff.
Of course hole-pokers are very unpopular with the "just ship it" crowd. Look at NASA for instance (they said "just launch it").
The desire to generate something on a little budget and look good will always outway the concerns of it actually working right. One need only obtain a new position before the shit hits the fan. Either that or cash out your stock.
I dare say that Embedded Windows is available with an MSDN Universal subscription. You could probably download it from Kazaa. The hardware it runs on is a PC, period. It may not have floppy drives or a CD rom, but it certainly has network connectivy. It also has some type of I/O (likely USB, potentially parrallell) to for the card reader and receipt printer.
If it was a Windows CE system, this would be tad bit more difficult becaus these systems vary wildly and getting a comparable system is more difficult. That being said, the widely touted "Diebold" machines running WindowsCE have been shown to have tremendous exploitable flaws even using such a niche hardware set and "SmartCard" readers that have DUMB software.
My method would be tapping the point-to-point communications line AWAY from the ATM. Install hardware that will broadcast it over Wi-Fi so you can access it at your leisure. Read all the credit card numbers etc...
If the link is encrypted (via VPN, like it should be) than the job will be a lot harder.
I think their are LOTS of ways to attack the bank system without physical presence. What I am fearful of is that the bank will rely on the physical security to assure the integrity of their systems. To do good security, one must ASSUME that things are going to break and be compromised, thats where the real security effort is.
If these systems AREN'T using VPN to communicate, then they are sitting ducks.
There is probably more COBOL out there then there is Java. C is probably a close second. COBOL is EASY. It was developed with the same idea that SQL was developed for. COBOL was invented with the idea that executives would write their own programs and reports
Have you ever tried to cDESCRIBE a technical process concisely and completely. It takes a lot of english words. However if you write it in a C-style language, it's actually a lot simpler.
Those who use COBOL believe that COBOL is easy. They've been using it a LONG time. It turns out that introducing English into programs just makes things more complicated. I'm fluent in Pascal and it's dialects (C, C++, Java, C#) etc... I can even manage to read expression languages (ML, Smalltalk, Lisp, Quilt;-) ). But COBOL is freakin' pig-latin to me.
Since it was used so widely, you would think that people would just KEEP USING IT if it was so great!!!! The fact that is shunned by every CS school on the planet should give you an idea of what computer experts think of COBOL.
The frequently quoted statement "it works" devolves into:
"It's generally error prone due to it's elaborate nature. However, over the course of 20 years we've hammered most of the errors out.
The people who know how to manipulate this "easy" language have cobbled together code-sets that resemble a spaghetti ball. We would deperately like to replace it except that the only people who can decode it typically only know COBOL. They are highly paid and they know that their existence relies on them being the sole individuals who can actually work their mess."
Thats not to say that you can't make a mess with C-ish dialects. Nor is object oriented a panacea. However, most C++ programmers will readily admit that C++ IS VERY complicated (read "Effective C++" for details). Otherwise, their would be no need for Java.
Yeah, COBOL may LOOK like English, but it's no English I've ever spoke. Nor does it do anything to clarify the issues. Especially when coding machines that don't speak English AT ALL. It only makes things more complicated.
Now, as for why they're thinking of switching to Windows for ATMs, I really can't fathom; is there some problem with their current systems? The articles seem to imply it's because Windows is "open"; why not use linux (or OpenBSD) instead? Then they can tinker with everything to their heart's content and customize all they want.
The article indicated that they wanted systems that could more easily interface with their desktop sytems. Apparently, OS/2 doesn't have handy features like file sharing and unnecessary shit like that.
Of course, when you talking about ATMs, the use of proprietary hardware and OS systems is actually an excellent security feature since writing moles worms and other nasties will be a lot harder (you don't have access to test equipment).
Their access to OS/2 programmers is also dwindling. Using up to date equipment would allow them to chuck those indepensible programmers for Indian contractors that they can pay 1/4 as much.
It is feasible that they want to be able to do development and testing on their desktops. Thats a reasonable request. It's also possible that they want to develop in Java or deploy in a managed code environment (.net). There again Linux would also do the job.
Finally, it's possible that Microsoft just paid the right people off. It doesn't have to be cash, it could be a job. Who knows, but this is the way that corporate business is conducted.
I'll bet you that ALL of these machines will be upgradeable via network. I can't imagine them sending people out to the machines in order to install patches.
That could be a serious vulnerability. Another vulnerability would be the guys who fill the machines. If the machines have network plugs, you could pay those guys to do a little switcharoo and use a device to install malicious code. A little Wi-Fi node with a power source could allow hackers into a VPN and analyze the nature of the ATM communication network.
Of course, one could simply look carefully at where the wires are running and dig one up to install a tap via wi-fi. Once you understood the update mechanism, you 'may' be able to insert your own modified code. If it's using signature mechnisms, you can fake the signature server by intercepting and re-directing their traffic.
I'm curious if they're planning to use managed code. They could use either Java or.net. Seriously, managed code makes a lot more sense it a low CPU/high security environment. Many common network attacks (buffer overflows) could be nuetralized by a managed code environment.
The additional bonus is that your ATM application would run on top of multiple hardware and OS platforms. In the case of.net you could run mono on linux instead of MS.net on Windows.
For one, the ATMs will use a stripped-down version of Windows NT that is quite different from the software on desktop computers.
The article just says WindowsNT. For all you know they mean NT version 2. Just because they say WindowsNT doesn't mean that it's NT version 4. WindowsNT 6 is the current version, the boxes say WindowsXP. Windows2000 was version 5.
As Microsoft typically doesn't sell license for older software versions (they don't sell or support NT4 anymore) I would suggest that this is likely WindowsXP embedded. I don't believe there was an embedded version of 2000, though WindowsXP has only a few more features than 2000.
Seriously, you can't buy licenses for NT4 anymore. Microsoft simply will not support it. In a few years, Microsoft will likely stop supporting Windows2000. I seriously doubt that they are going to license and support WinNT for bank machines when they have an XP embedded line specifically for these applications.
It simply costs too much money to develop on multiple version levels simultaneously. And Microsoft likely has more than 10,000 security patches since the NT4 version. Think about it.
The benefit of using linux would be an ability to shut down unnecessary/dangerous features at the OS level. You cannot change WindowsXP embedded (though you could possibly tweak drivers).
ATMs simply don't need the bulk of a desktop OS. Yes, I know that this is XP (stripped down) embedded but it is still based on an OS that is driven by consumer features, not embedded stability and security.
Better yet, if you see a mistake on the receipt, THROW IT AWAY. You can always just say that you never saw it.
If the bank can't keep their balances straight, that's THEIR problem.
BTW, I would never actually trust an ATM receipt. To begin with, they don't run transactions real time. If your Debit Card is running out of a checking account, you could have several checks go through that day and it would not be reflected in the balance. Nor would any deposits (outside of the ATM).
Your obviously not aware about what the current administrators are doing to those called "regulators". Bush is slashing there budgets and making them work for industry lobbyists.
The prize for being an evolutionist is having to listen to the constant drole of religious purists who believe in literal biblical translation. It would be far easy to believe with them.
The complete irony is that they are reading a translation of a translation of a translation. When Jerry Falwell learns how to read ancient greek and ancient hebrew, that's when I'll take him serious. Real biblical scholars (who can read ancient greek and hebrew) are a lot more reserved about "belief" (Thomas Aquinas aside).
This is interesting because a truely completely focused individual would IGNORE that weird result that didn't further his goal. A truly creative person will abandon the world for a novell unique idea.
The ball is, literally, a small sun, where an electric field forces deuteron ions (a form of hydrogen) to gather, bang together and occasionally fuse, spitting out a neutron each time fusion occurs.
Well, the reporter seemed to think it was nuclear fusion. If he's doing it AT ALL with such a cheapo Junkyard-Wars apparatus, it has pretty serious consequences.
Other fusion reactors are multi-million pieces of equipment using seriously powerful magnetic fields to keep the genie in the bottle. Effectively, they use more energy then they generate and that defeats the point.
If he's found a novel way of doing it without expensive magnetic containment (or the device generates it's own containment in a novel way) then it could lead to practical nuclear fusion generators.
Of course, it still needs to be seen whether the device actually DOES fuse hydrogen. Yeah, his detectors are measuring excess nuetron emissions (implying fusion) but he's using the detector that he found in a scrap heap. It may have been thrown away because it didn't WORK RIGHT!!!!!
So I hope he actually accomplished what they think he did. Other scientists will have to vet the machine using their super-expensive (perhaps overworked) machines to see if it is indeed fusing hydrogen atoms. I really do hope the machine works the way they say it does.
If it actually works, he's going to get a visit from the oil industry "secret police". Of course, they're under the ultimate command of the 'Oilman in Chief' Dubabya.
"Sorry son, we have to confiscate your source of unlimited energy. It will disrupt our ability to fleece the public and indirectly generate terror as an excuse of robbing you of your liberties.
It's completely inconsistent with our energy policy of controlling all your energy."
The success of our SCOsource licensing initiative, at least initially, will depend to a great extent on the perceived strength of our intellectual property and contractual claims...
The perceived strength is zero. Who writes this insane crap.
It would be a shame if someone posted HIS phone number online ;-)
I do understand the "just get it done" crowd. There are a lot of things in CS school that are extraneous.
However, I like yourself pulled the "improved data structure" trick and equally pissed off a few peers. They said it could go no faster. On really large data sets, I reduced computation from three days to an hour.
I there needs to be CS courses for folks who just went out there and used lots of elbow grease. Creativity and "go-to" is good, but it makes no sense to contantly re-invent the wheel do to ignorance.
I wonder if you could tear off a keycap and then plug in a machine designed to generate keyclicks for all the other keys that aren't their. The number pad is likely hooked up to a standard PS/2 port which would understand the keyclicks.
;-)
Since all Windows interfaces are designed to be keyboard navigable, one should be able to browse through the start menu and find a command prompt. At that point you may have access to their internal ATM network.
Of course, you would have to repeat the cause of the crash (probably a dirty card, need a card writer that writes incorrect sequences). And of course, remember to bring a ski mask for the camera and wear gloves.
It's always easier to poke holes into something instead of building things resistent to hole-poking. That's why you need to have hole-pokers on the staff.
Of course hole-pokers are very unpopular with the "just ship it" crowd. Look at NASA for instance (they said "just launch it").
The desire to generate something on a little budget and look good will always outway the concerns of it actually working right. One need only obtain a new position before the shit hits the fan. Either that or cash out your stock.
I dare say that Embedded Windows is available with an MSDN Universal subscription. You could probably download it from Kazaa. The hardware it runs on is a PC, period. It may not have floppy drives or a CD rom, but it certainly has network connectivy. It also has some type of I/O (likely USB, potentially parrallell) to for the card reader and receipt printer.
If it was a Windows CE system, this would be tad bit more difficult becaus these systems vary wildly and getting a comparable system is more difficult. That being said, the widely touted "Diebold" machines running WindowsCE have been shown to have tremendous exploitable flaws even using such a niche hardware set and "SmartCard" readers that have DUMB software.
My method would be tapping the point-to-point communications line AWAY from the ATM. Install hardware that will broadcast it over Wi-Fi so you can access it at your leisure. Read all the credit card numbers etc...
If the link is encrypted (via VPN, like it should be) than the job will be a lot harder.
I think their are LOTS of ways to attack the bank system without physical presence. What I am fearful of is that the bank will rely on the physical security to assure the integrity of their systems. To do good security, one must ASSUME that things are going to break and be compromised, thats where the real security effort is.
If these systems AREN'T using VPN to communicate, then they are sitting ducks.
This is why these systems should use managed code. Buffer overflows aren't possible at the application level.
There is probably more COBOL out there then there is Java. C is probably a close second. COBOL is EASY. It was developed with the same idea that SQL was developed for. COBOL was invented with the idea that executives would write their own programs and reports
;-) ). But COBOL is freakin' pig-latin to me.
Have you ever tried to cDESCRIBE a technical process concisely and completely. It takes a lot of english words. However if you write it in a C-style language, it's actually a lot simpler.
Those who use COBOL believe that COBOL is easy. They've been using it a LONG time. It turns out that introducing English into programs just makes things more complicated. I'm fluent in Pascal and it's dialects (C, C++, Java, C#) etc... I can even manage to read expression languages (ML, Smalltalk, Lisp, Quilt
Since it was used so widely, you would think that people would just KEEP USING IT if it was so great!!!! The fact that is shunned by every CS school on the planet should give you an idea of what computer experts think of COBOL.
The frequently quoted statement "it works" devolves into:
"It's generally error prone due to it's elaborate nature. However, over the course of 20 years we've hammered most of the errors out.
The people who know how to manipulate this "easy" language have cobbled together code-sets that resemble a spaghetti ball. We would deperately like to replace it except that the only people who can decode it typically only know COBOL. They are highly paid and they know that their existence relies on them being the sole individuals who can actually work their mess."
Thats not to say that you can't make a mess with C-ish dialects. Nor is object oriented a panacea. However, most C++ programmers will readily admit that C++ IS VERY complicated (read "Effective C++" for details). Otherwise, their would be no need for Java.
Yeah, COBOL may LOOK like English, but it's no English I've ever spoke. Nor does it do anything to clarify the issues. Especially when coding machines that don't speak English AT ALL. It only makes things more complicated.
you wouldn't hear about all of the various berak-ins. As is, I don't rememeber EVER hearing about an internal bank system being compromised.
What? you didn't see "Office Space"?
Now, as for why they're thinking of switching to Windows for ATMs, I really can't fathom; is there some problem with their current systems? The articles seem to imply it's because Windows is "open"; why not use linux (or OpenBSD) instead? Then they can tinker with everything to their heart's content and customize all they want.
The article indicated that they wanted systems that could more easily interface with their desktop sytems. Apparently, OS/2 doesn't have handy features like file sharing and unnecessary shit like that.
Of course, when you talking about ATMs, the use of proprietary hardware and OS systems is actually an excellent security feature since writing moles worms and other nasties will be a lot harder (you don't have access to test equipment).
Their access to OS/2 programmers is also dwindling. Using up to date equipment would allow them to chuck those indepensible programmers for Indian contractors that they can pay 1/4 as much.
It is feasible that they want to be able to do development and testing on their desktops. Thats a reasonable request. It's also possible that they want to develop in Java or deploy in a managed code environment (.net). There again Linux would also do the job.
Finally, it's possible that Microsoft just paid the right people off. It doesn't have to be cash, it could be a job. Who knows, but this is the way that corporate business is conducted.
I'll bet you that ALL of these machines will be upgradeable via network. I can't imagine them sending people out to the machines in order to install patches.
That could be a serious vulnerability. Another vulnerability would be the guys who fill the machines. If the machines have network plugs, you could pay those guys to do a little switcharoo and use a device to install malicious code. A little Wi-Fi node with a power source could allow hackers into a VPN and analyze the nature of the ATM communication network.
Of course, one could simply look carefully at where the wires are running and dig one up to install a tap via wi-fi. Once you understood the update mechanism, you 'may' be able to insert your own modified code. If it's using signature mechnisms, you can fake the signature server by intercepting and re-directing their traffic.
I'm curious if they're planning to use managed code. They could use either Java or
The additional bonus is that your ATM application would run on top of multiple hardware and OS platforms. In the case of
For one, the ATMs will use a stripped-down version of Windows NT that is quite different from the software on desktop computers.
The article just says WindowsNT. For all you know they mean NT version 2. Just because they say WindowsNT doesn't mean that it's NT version 4. WindowsNT 6 is the current version, the boxes say WindowsXP. Windows2000 was version 5.
As Microsoft typically doesn't sell license for older software versions (they don't sell or support NT4 anymore) I would suggest that this is likely WindowsXP embedded. I don't believe there was an embedded version of 2000, though WindowsXP has only a few more features than 2000.
Seriously, you can't buy licenses for NT4 anymore. Microsoft simply will not support it. In a few years, Microsoft will likely stop supporting Windows2000. I seriously doubt that they are going to license and support WinNT for bank machines when they have an XP embedded line specifically for these applications.
It simply costs too much money to develop on multiple version levels simultaneously. And Microsoft likely has more than 10,000 security patches since the NT4 version. Think about it.
The benefit of using linux would be an ability to shut down unnecessary/dangerous features at the OS level. You cannot change WindowsXP embedded (though you could possibly tweak drivers).
ATMs simply don't need the bulk of a desktop OS. Yes, I know that this is XP (stripped down) embedded but it is still based on an OS that is driven by consumer features, not embedded stability and security.
Better yet, if you see a mistake on the receipt, THROW IT AWAY. You can always just say that you never saw it.
If the bank can't keep their balances straight, that's THEIR problem.
BTW, I would never actually trust an ATM receipt. To begin with, they don't run transactions real time. If your Debit Card is running out of a checking account, you could have several checks go through that day and it would not be reflected in the balance. Nor would any deposits (outside of the ATM).
Why do we NEED colour screens and Windows anyway? Ever heard of the phrase "if it ain't broke, don't fix it?"
The color screens allow banks to run advertising while your waiting for your money.
Your obviously not aware about what the current administrators are doing to those called "regulators". Bush is slashing there budgets and making them work for industry lobbyists.
Your obviously unaware that those smart people aren't calling the shots ;-)
Seriously, ATMs are an application that screems for an embedded OS or Linux.
The prize for being an evolutionist is having to listen to the constant drole of religious purists who believe in literal biblical translation. It would be far easy to believe with them.
The complete irony is that they are reading a translation of a translation of a translation. When Jerry Falwell learns how to read ancient greek and ancient hebrew, that's when I'll take him serious. Real biblical scholars (who can read ancient greek and hebrew) are a lot more reserved about "belief" (Thomas Aquinas aside).
This is interesting because a truely completely focused individual would IGNORE that weird result that didn't further his goal. A truly creative person will abandon the world for a novell unique idea.
The ball is, literally, a small sun, where an electric field forces deuteron ions (a form of hydrogen) to gather, bang together and occasionally fuse, spitting out a neutron each time fusion occurs.
Well, the reporter seemed to think it was nuclear fusion. If he's doing it AT ALL with such a cheapo Junkyard-Wars apparatus, it has pretty serious consequences.
Other fusion reactors are multi-million pieces of equipment using seriously powerful magnetic fields to keep the genie in the bottle. Effectively, they use more energy then they generate and that defeats the point.
If he's found a novel way of doing it without expensive magnetic containment (or the device generates it's own containment in a novel way) then it could lead to practical nuclear fusion generators.
Of course, it still needs to be seen whether the device actually DOES fuse hydrogen. Yeah, his detectors are measuring excess nuetron emissions (implying fusion) but he's using the detector that he found in a scrap heap. It may have been thrown away because it didn't WORK RIGHT!!!!!
So I hope he actually accomplished what they think he did. Other scientists will have to vet the machine using their super-expensive (perhaps overworked) machines to see if it is indeed fusing hydrogen atoms. I really do hope the machine works the way they say it does.
Bill Maher has an excellent section in his book about this topic. How the American people deserve security services on par with the secret service.
If it actually works, he's going to get a visit from the oil industry "secret police". Of course, they're under the ultimate command of the 'Oilman in Chief' Dubabya.
"Sorry son, we have to confiscate your source of unlimited energy. It will disrupt our ability to fleece the public and indirectly generate terror as an excuse of robbing you of your liberties.
It's completely inconsistent with our energy policy of controlling all your energy."
They just see the word "Nuclear" in front of it and add you to their teorrist watchlist.
Yeah, and don't forget, the President can't even pronounce "Nuclear".
"We have to stem the treat of Nukular weaponry!"
The success of our SCOsource licensing initiative, at least initially, will depend to a great extent on the perceived strength of our intellectual property and contractual claims ...
The perceived strength is zero. Who writes this insane crap.