RE: release dates of early microcomputer operating systems, incl. Intel ISIS
By the way I have now found out how to retrieve this through the University of Salford Library, where I am a member... Dave > -Original Message- > From: cctalk [mailto:cctalk-boun...@classiccmp.org] On Behalf Of Al Kossow > Sent: Tuesday, 15 September, 2015 2:58 PM > To: cctalk@classiccmp.org > Subject: Re: release dates of early microcomputer operating systems, incl. > Intel ISIS > > On 9/15/15 4:57 AM, Noel Chiappa wrote: > > the machine had to be configured (via connecting up computing units > > with cables) > > In 1947 ENIAC was modifed at BRL to be a stored program computer. > > http://dl.acm.org/citation.cfm?id=1339839 > > >
Cryptolocker (was RE: Is tape dead?
I took on a brand new client a while back, and before doing any real work for them they were hit by cryptolocker. I hadn't yet even done a "IT Review" for them, so didn't yet know what systems they had in place. Thus, under the gun, I started looking at their backup setup, and found it "severely lacking". They did have a backup system from the previous IT guy, but due to the way it was set up it would have taken days to get the data off of it and all moved back into the correct spots. So given days of billable time/work or paying the ransom, we chose to pay the ransom as the most expedient solution. They only accepted bitcoin, and there was a deadline after which the ransom doubled or more. So we jumped through hoops to get a bitcoin account set up, funds deposited, etc. That was a rather convoluted process and took time (albeit less time than working with the existing "backup" system). Soon as the bitcoin was transferred to the hostages account, a key was received online via the TOR browser. Yep, the key worked, and decrypted all the data. A new (and easy/functional) backup system was put in place immediately thereafter. I've also talked to a few of my associates who own IT consulting firms, and any of them that decided to pay the ransom did in fact get a working decryption key. ZFS is a good solution :) Best, J
Clearpoint Q-RAM 11 chip locations
Documentation for the Clearpoint Q-RAM 11 board seems to be rather scarce; all I could find was a user manual, with no technical info (manual or prints or other documentation) online. (I'd be glad to be proved wrong! :-) So as part of a project I needed to figure out which memory chips were which; now that I've worked it out, I'm putting that info online here in the archives, where eventually Google will find it, and make it available to anyone who needs it. So, looking at the card from the component side, with the handle at the top, and the contact fingers at the bottom, there's an array of memory chips 12 columns wide, and 6 rows high; I see no ID system on the card, so I number the columns A-L (from the left), and the rows 0-5 (from the top). The card can have 4 banks of 128KB each, for a max total of 512KB. The chip-bit relationship is pretty random: Bank 0 - Columns A, E, I: 01 I2 02 E5 04 I3 010 A5 020 A4 040 A2 0100A0 0200A1 0400E3 01000 A3 02000 E0 04000 E4 01 E1 02 E2 04 I1 010 I0 Bank 1 - Columns B, F, J: Bank 2 - Columns C, G, K: Bank 3 - Columns D, H, L: The banks 2/3 column assignments are a guess, not verified as yet. The bit allocation seems to be the same in all banks; I tried a few in bank 1, and they matched the ones in bank 0 (suitably offset in column, of course). Noel
Desperately need BA11-N/BA11-S Technical Manual
So, I'm trying to fix a broken Power Monitor Boards (the thing that drives ACLO/DCLO) in an H786 (BA11-N power supply), and although I have the prints, I can't make head or tail out of them. (The circuit is a maze of op-amps and 555's. OK, OK, so maybe an analog guy can take one quick look, and understand instantly how it works. But I don't have that gene! :-) So I'm looking for a BA11-N or BA11-S Technical Manual, to explain it to me (my experience is that the DEC Tech Manuals for power supplies are _really_ good at that). (Either the BA11-N or BA11-S since, although the PM boards have different part numbers in the two - 54-12528-0-1 in the BA11-N/H786, and 54-15048-0-1 in the BA11-S/H7861, the circuits in the two seem to be pretty much identical, looking at the prints.) Alas, neither seems to be available online. (The BA11-N is EK-BA11N-TM-001; the BA11-S is in the "PDP-11/23B Mounting Box Technical Manual", EK-23BMB-TM-001.) I have clues to the existence of a couple of copies of the BA11-N one, though. A "David Powell" (then at ICUKnet in the UK) sent out a message saying he had one, but the email address for him at ICUKnet no longer works - I haven't (yet) tried to find him via LinkedIn because it's a common name. I don't suppose anyone here knows him, do they? Also, this page: http://ed-thelen.org/comp-hist/Book-Catalog.html which claims to be the "Book Catalog (incomplete) of the Computer History Museum, as of July 27 2002" says they have one. Would it still be there, and is there any chance that, if so, it can be scanned an put online? Many thanks, in advance, for any help with this - I'm pretty desperate! Noel
RE: Desperately need BA11-N/BA11-S Technical Manual
> So, I'm trying to fix a broken Power Monitor Boards (the thing that drives > ACLO/DCLO) in an H786 (BA11-N power supply), and although I have the prints, > I can't make head or tail out of them. > > (The circuit is a maze of op-amps and 555's. OK, OK, so maybe an analog guy > can take one quick look, and understand instantly how it works. But I don't > have that gene! :-) Do you have a URL for the prints (to save me going through all possible candidates on bitsavers)? I'm no 'analog(ue) guy' but I can see if there is anything obvious. What is the fault with your board? -tony
Re: PDP-11 manuals scanned/scanning
>Noel Chiappa wrote: OK, so I finally got set up to scan manuals, with a scanner with a document feeder, so I don't have to sit there and feed the beast! So now I can scan in a number of 'missing' (online, at least) PDP-11 manuals which I happen to have. The first thing through the machine was the DZV11 Technical Manual (which Paul Anderson was gracious enough to loan out, to enable it to be put online - thanks Paul!), now available here: http://ana-3.lcs.mit.edu/~jnc/tech/pdp11/EK-DZV11-TM-001_Jun78.pdf (as always, please download/distribute/replicate to other repositories). I also did the 11/34 cache board user manual, now here: http://ana-3.lcs.mit.edu/~jnc/tech/pdp11/EK-KK11A-UG-001_Oct78.pdf I was able to look at both manuals. THANK YOU!! However, both of the directories at the next level up are blocked. If there is any possibility that both these directories could be made available to allow the other PDF files to be viewed, that would be appreciated. If not, a list of the actual links to the other PDF files which are available to be viewed would be appreciated. Also, do you have any files of source code or binary distributions of RT-11 files? I have a number of RT-11 DOC sets which I am no longer using: V05.05 RT-11 DOC set V05.04G RT-11 DOC set V05.02 RT-11 DOC set I am not positive about the latter two, but the V05.05 RT-11 DOC set is probably available unless Jay West wants it now rather than waiting for the V05.07 RT-11 DOC set. Since not of these dead tree RT-11 DOC sets are bound, they would be easy to (automatically) scan - except that each of the RT-11 DOC sets is approximately 5,000 pages and both sides must be scanned for a total of about 10,000 pages each. Since the V05.07 RT-11 DOC set is already scanned and available as many PDF files, there may not be any interest in the prior versions. Please let me know. If no one is interested, then I will start discarding them in a few months. I have promised to send the dead tree version of my V05.07 RT-11 DOC set to Jay West, but that will wait until I am on the other side of the green rug - or at least close enough. Jerome Fine
Re: Desperately need BA11-N/BA11-S Technical Manual
On 9/16/15 6:36 AM, Noel Chiappa wrote: Also, this page: http://ed-thelen.org/comp-hist/Book-Catalog.html which claims to be the "Book Catalog (incomplete) of the Computer History Museum, as of July 27 2002" says they have one. Would it still be there, and is there any chance that, if so, it can be scanned an put online? 2002? No, it is not there, and I wish Ed would take that page down. That was an inventory of the bookshelf at the old building at Moffett Field and has minimal value as a search tool for what CHM actually has today. The text collection has been reboxed and moved at least four times since that list was made. All of the technical manuals were pulled out when the CHM Library room was created. The library no longer exists, and the hardcovers and periodicals that were there were cataloged and are in the CHM database at http://www.computerhistory.org/collections/search/ If you can't find something in there (currently almost 100,000 records) it hasn't been cataloged. Everything is in archival record cartons, stored two-deep on shelves in two different buildings, making random searches pretty much impossible. There is a two-year project that just started to start to catalog the text backlog, but that will just scratch the surface of what needs doing. That was one of the driving forces for me scanning things, the time to catalog was so long for the past ten years that I could never find anything when I was looking for it, and I'm still finding things that I didn't know we had, like the CE manuals for the 7040 CPU, which I came across in the catalog last night looking for a IO processor manual the 1401 guys were looking for. Alan Frisbie may have scanned it. I think he is on the cctlk list.
Re: Cryptolocker (was RE: Is tape dead?
Windows? On 16-09-15 14:41, Jay West wrote: I took on a brand new client a while back, and before doing any real work for them they were hit by cryptolocker. I hadn't yet even done a "IT Review" for them, so didn't yet know what systems they had in place. Thus, under the gun, I started looking at their backup setup, and found it "severely lacking". They did have a backup system from the previous IT guy, but due to the way it was set up it would have taken days to get the data off of it and all moved back into the correct spots. So given days of billable time/work or paying the ransom, we chose to pay the ransom as the most expedient solution. They only accepted bitcoin, and there was a deadline after which the ransom doubled or more. So we jumped through hoops to get a bitcoin account set up, funds deposited, etc. That was a rather convoluted process and took time (albeit less time than working with the existing "backup" system). Soon as the bitcoin was transferred to the hostages account, a key was received online via the TOR browser. Yep, the key worked, and decrypted all the data. A new (and easy/functional) backup system was put in place immediately thereafter. I've also talked to a few of my associates who own IT consulting firms, and any of them that decided to pay the ransom did in fact get a working decryption key. ZFS is a good solution :) Best, J -- Met vriendelijke Groet, Simon Claessen drukknop.nl
Re: Still seeking 3B2 information
On 8/11/15 7:36 AM, Jerry Kemp wrote: Hello Seth, We were having a 3B2 discussion on the Sun Rescue list, and that got me to thinking about your emulator project. Can you share a status update? Is there anything us non-developers can do to assist? Thank you, Jerry On 01/19/15 01:45 PM, Seth Morabito wrote: Hi everyone, I've made tremendous progress on my 3B2 emulator. It's being implemented under the SIMH simulator platform, which has been a huge help. fyi http://forums.bannister.org/ubbthreads.php?ubb=showflat&Number=101593#Post101593
Re: Cryptolocker (was RE: Is tape dead?
On 9/16/2015 5:41 AM, Jay West wrote: ZFS is a good solution:) Is it a versioning file system? I know it handles large data sets. Does versioning or such as time machine setups (Mac OS type of backup) defeat the problem. I know you don't have time machine with PC's that get hit, are other than Windows systems vulnerable? Did it hit the NAS storage, or just the attached drives? One system, or did it propagate thru the organization? Did you eradicate it, then get a tool for the decrypt? Curious as to details here to think about measures to stop it, or mitigate it. I'd apologize for the off topic direction, but this is a pretty serious threat that is hard to find info on that isn't bullshit or glossed over. Reply offline if you would rather, but I suspect anyone with classic Windows XP systems and the like should pay attention. thanks Jim
Re: Still seeking 3B2 information
* On Wed, Sep 16, 2015 at 08:24:15AM -0700, Al Kossow wrote: > On 8/11/15 7:36 AM, Jerry Kemp wrote: > >Hello Seth, > > > >We were having a 3B2 discussion on the Sun Rescue list, and that got me to > >thinking about your emulator project. > > > >Can you share a status update? > > > >Is there anything us non-developers can do to assist? > > > >Thank you, > > > >Jerry [...] > > fyi > > > http://forums.bannister.org/ubbthreads.php?ubb=showflat&Number=101593#Post101593 Shattered has been contributing some bug fixes back to the 3B2 project, for which I'm very grateful. I'm terribly excited to see where his DMD 5620 emulator goes. -Seth
Re: Desperately need BA11-N/BA11-S Technical Manual
On 16/09/15 14:36, Noel Chiappa wrote: Alas, neither seems to be available online. (The BA11-N is EK-BA11N-TM-001; the BA11-S is in the "PDP-11/23B Mounting Box Technical Manual", EK-23BMB-TM-001.) I guess they're not much use to you, but both the user guides (EK-BA11N-UG and EK-23BMB-UG-001) are available online. I do have EP-BA11N-TM-001 and EK-BA11N-IP and EP-23BMB-TM-001 but they're microfiche and I have no easy way of scanning that. If you don't get anywhere, I can try firing up the fiche reader and see what's actually described in there. Antonio arcarl...@iee.org
Re: PDP-11 manuals scanned/scanning
> From: Noel Chiappa > I have also gone through my set of manuals and prepared a list of all > the ones which aren't online. > ... > EK-1184A-TM-PR4 11/84 Technical Reference (Preliminary) > EK-1184E-TM-001 PDP-11/84 System Technical and Reference Manual > EK-1184E-MG PDP-11/84-E User's and Maintenance Guide So I spaced. 1184E-TM-001 _is_ online; not sure how I missed it! > From: Henk Gooijen > I would be very interested in the 11/84 docs, as far as not available. I'm not sure there's much in the other two which isn't in the other 11/84 manuals which are already online - I think the content is mostly the same, just arranged differently. A few minor tweaks (e.g. that sentence I found a while back about the BIAK/BDMG jumpers on the 11/84 backplane), but nothing major. I'll get to them at some point - alas, I bound them, so now I have to un-bind them before I can scan them! Oh well!! > I have EK-KK11A-TM-001 "KK11-A cache memory technical manual" Lyle Bickley made that one available a couple of months back. It doesn't seem to have made it into the repositories, though? Should I upload a copy to my web site, and send along the URL? > From: Jerome H. Fine > However, both of the directories at the next level up are blocked. If > there is any possibility that both these directories could be made > available to allow the other PDF files to be viewed Err, there are no other PDF files there, except the 11/73 CPU board prints, which I mentioned here recently and have now been mirrored. > If not, a list of the actual links to the other PDF files which are > available to be viewed would be appreciated. I should probably throw together a web page with links to all the PDP-11 files there (e.g. the one I just put together, of print sets that are available inside other print sets), and link to that from my home page. > Also, do you have any files of source code or binary distributions of > RT-11 files? Alas, being of the MIT persuasion, we never did anything with DEC software (except TWENEX, on the DECSystem20's), so I have nothing of anything to do with DEC software - Unix all the way! ;-) Noel
re: Backups [was Re: Is tape dead?]
>From: Mouse > >> I think a more important issue in backing up is "How many GENERATIONS > >to you keep around?" > >For many purposes, that's an important consideration, yes. There's >something (small) I back up weekly for which I keep the most recent >seven backups, the oldest backup in each of the most recent twelve >months, and the oldest backup in any year. I'm considering something >of the sort for my house backups - live replication to a backup host, >with a once-a-week freeze of the replica, storing past replica drives >on a scheme somewhat like the above. There is a ramsomware variant that encrypts the files but silently decrypts them when they are accessed. It does this for six months before deactivating the on-demand decryption and displaying the ransom message, the theory being that by that time all of the backups will be of the encrypted files, and thus will be useless for restoring good versions. As to how one can become infected, see http://www.theregister.co.uk/2015/08/27/malvertising_feature/?page=1. Major sites, such as The New York Times, Reuters, Yahoo!, and Bloomberg, have been serving malware -- including ransomeware -- through hijacked advertisements. No need to click on anything, the ad serves up the malware. BTW, where I work got hit with ransomeware in December. We were lucky that it first hosed the accounting/time tracking database, which generated errors when someone tried to enter her time. When I went to restore a backup of the database, I noticed the ransomware's html ransom note file and shut down the system before too many more files were encypted. We were able to restore everything (except the originally infected user's computer, which we wiped and reinstalled) from an unconnected backup drive. Bob
Re: Cryptolocker (was RE: Is tape dead?
On Wed, 16 Sep 2015, jwsmobile wrote: One system, or did it propagate thru the organization? Did you eradicate it, then get a tool for the decrypt? Not very hard to stop it, but the damage that it does to the files (RSA encryption) is irreparable, unless you pay the ransom. A significant percentage of the victimes pay up! A few people have reported that the malevolent assholes are honorable, and do provide a working key. A small few report NOT getting the decryption key. Without major distributed work on it, decryption through brute force key trials would take millenia. The purveyors of one variant were stopped, and their key database revealed. I don't know if or why they are still alive. Curious as to details here to think about measures to stop it, or mitigate it. I'd apologize for the off topic direction, but this is a pretty serious threat that is hard to find info on that isn't bullshit or glossed over. Reply offline if you would rather, but I suspect anyone with classic Windows XP systems and the like should pay attention. It relies on social engineering (suckers). Sometimes PDF files, but, I now think that I got it by falling for a fake Adobe upgrade popup.
re: Backups [was Re: Is tape dead?]
On Wed, 16 Sep 2015, Robert Feldman wrote: There is a ramsomware variant that encrypts the files but silently decrypts them when they are accessed. It does this for six months before deactivating the on-demand decryption and displaying the ransom message, the theory being that by that time all of the backups will be of the encrypted files, and thus will be useless for restoring good versions. Thereby rendering generations of backups ineffective. When you restore, you still can not get back any of the file modifications (work) done in the last 6 months. Thus, the only acceptable solution would be early detection. Neither AVG (resident), nor McAfee (manually run weekly) detected my infection of Cryptowall. What WILL detect it? As to how one can become infected, see http://www.theregister.co.uk/2015/08/27/malvertising_feature/?page=1. Major sites, such as The New York Times, Reuters, Yahoo!, and Bloomberg, have been serving malware -- including ransomeware -- through hijacked advertisements. No need to click on anything, the ad serves up the malware. But, those still require a gullibility error on the part of the user, don't they? Do the ads actually load and run the ransomware, or just present the fraudulent upgrade offer to bring it in?
RE: 12" Floppy Disks
To the best of my recollection there never was any production FD greater than 8-inches, but u don't have to rely upon my fallible recollection since neither Porter's 1977 nor his 1982 Disk/Trends for FDDs mentions anything about larger media diameter.The 1977 version was the first one Jim published. Tom -Original Message- From: Jules Richardson [mailto:jules.richardso...@gmail.com] Sent: Tuesday, September 15, 2015 12:03 PM To: General Discussion: On-Topic and Off-Topic Posts Subject: Re: 12" Floppy Disks On 09/15/2015 03:39 AM, Adrian Graham wrote: > Morning folks, > > I've been contacted by a teacher who's looking for any information > about 12" floppies. Am I imagining that they really existed? I'm sure > I've seen one or seen adverts for them, maybe at Bletchley Park. > Others he's contacted think he's getting confused with 12" laser discs > but I'm not so sure. Ask him if he remembers whether the disk had a jacket or not, that might help narrow it down. Was it read-write or read-only? Was it definitely digital data or perhaps something analog-but-with-a-computer-application?
Re: Cryptolocker (was RE: Is tape dead?
This brings up something that's always baffled me. Why does a user's (or worse, the entire system's) files have to be immediately accessible to any application wanting to take a look. Take a legacy example, SCOPE or NOS on a CDC mainframe. At start of job, you start out with a null file set available to you, but for standard input and output pre-named files. If you need a pre-existing "permanent" file, you attach that to your current session, providing the necessary password and other information, such as the cycle number--and then giving that file its own (local) name--i.e. user-permanent files have a different (usually longer) name than what they're known as locally. To the best of my knowledge, outside of password leaks (a different password, if you wanted, for each type of access), we had no security issues. The better approach in modern times, I suppose, is to sandbox your browser--and never, never, never browse with administrative privileges. (Something the average Windows user doesn't seem to understand). Has cryptolocker ever invaded the world of Unix/Linux/BSD? --Chuck
re: Backups [was Re: Is tape dead?]
We have 10 years of backups.ed# Sent from my Verizon Wireless 4G LTE smartphone Original message From: Robert Feldman Date: 09/16/2015 10:40 AM (GMT-07:00) To: cctalk@classiccmp.org Subject: re: Backups [was Re: Is tape dead?] >From: Mouse > >> I think a more important issue in backing up is "How many GENERATIONS > >to you keep around?" > >For many purposes, that's an important consideration, yes. There's >something (small) I back up weekly for which I keep the most recent >seven backups, the oldest backup in each of the most recent twelve >months, and the oldest backup in any year. I'm considering something >of the sort for my house backups - live replication to a backup host, >with a once-a-week freeze of the replica, storing past replica drives >on a scheme somewhat like the above. There is a ramsomware variant that encrypts the files but silently decrypts them when they are accessed. It does this for six months before deactivating the on-demand decryption and displaying the ransom message, the theory being that by that time all of the backups will be of the encrypted files, and thus will be useless for restoring good versions. As to how one can become infected, see http://www.theregister.co.uk/2015/08/27/malvertising_feature/?page=1. Major sites, such as The New York Times, Reuters, Yahoo!, and Bloomberg, have been serving malware -- including ransomeware -- through hijacked advertisements. No need to click on anything, the ad serves up the malware. BTW, where I work got hit with ransomeware in December. We were lucky that it first hosed the accounting/time tracking database, which generated errors when someone tried to enter her time. When I went to restore a backup of the database, I noticed the ransomware's html ransom note file and shut down the system before too many more files were encypted. We were able to restore everything (except the originally infected user's computer, which we wiped and reinstalled) from an unconnected backup drive. Bob
Re: PDP-11 manuals scanned/scanning
-Oorspronkelijk bericht- From: Noel Chiappa Sent: Wednesday, September 16, 2015 7:29 PM To: cctalk@classiccmp.org Cc: j...@mercury.lcs.mit.edu Subject: Re: PDP-11 manuals scanned/scanning > From: Henk Gooijen > I have EK-KK11A-TM-001 "KK11-A cache memory technical manual" Lyle Bickley made that one available a couple of months back. It doesn't seem to have made it into the repositories, though? Should I upload a copy to my web site, and send along the URL? Noel == Thanks, but that manual will pop up eventually :-) Besides, my 11/34 is functional running RT-11, although it cannot hurt to run a few diagnostics, especially for the KK1 cache. But there are several other machines waiting in line (literally) to get TLC (and repair work). - Henk
Re: Backups [was Re: Is tape dead?]
On 9/16/15 11:15 AM, couryhouse wrote: We have 10 years of backups.ed# ever verified them?
Re: Desperately need BA11-N/BA11-S Technical Manual
> From: tony duell > Do you have a URL for the prints (to save me going through all possible > candidates on bitsavers)? Yeah, as per my 'where are subsystem prints' page, they are in the 11/23 print set MP00740, pg. 81-87 (schematic on pg. 87): https://archive.org/details/bitsavers_decqbusMP0_10391074 (Doesn't seem to be on BitSavers?) > What is the fault with your board? First, I should explain that I do have a working PM board, so we can swap back and forth to see what a working one looks like. It also verifies that the fault is on that board, since the working one is fine in that chassis. Anyway, on the bad one, both ACLO and DCLO (BPOK and BDCOK, I guess the QBUS guys call them :-) are being pulled low. Looking at the board, D5 (the Q3 end) is at ground, the other end is at around ~-3V; with D4, both ends are at ground. On the good board, both ends of each diode go to -12V shortly after the machine powers on. (Advance thanks for any help! :-) Noel
Re: Backups [was Re: Is tape dead?]
> On Sep 16, 2015, at 2:01 PM, Fred Cisin wrote: > ... > Neither AVG (resident), nor McAfee (manually run weekly) detected my > infection of Cryptowall. What WILL detect it? Linux? :-) paul
Re: Cryptolocker (was RE: Is tape dead?
> On Sep 16, 2015, at 2:10 PM, Chuck Guzis wrote: > > This brings up something that's always baffled me. > > Why does a user's (or worse, the entire system's) files have to be > immediately accessible to any application wanting to take a look. > > Take a legacy example, SCOPE or NOS on a CDC mainframe. ... Just remember that those older systems may well have had any number of security issues of their own. They did benefit a lot from "security by obscurity" as well as the fact that they weren't connected to the Internet. I never had any incentive to look for holes in CDC operating systems, but I still remember a simple hole I found in OS/360, about a month after I first wrote a program for that OS. It allowed anyone to run supervisor mode code with a couple dozen lines of assembler source code. I found it on OS/PCP 19.6, but I noticed in graduate school that it still worked on the university's 370 running OS/MVS 21.7. (The magic? Use the OS service to give a symbolic name to a location in your code, with a well chosen name, then give that name as the name of the "start I/O appendage" in an EXCP style I/O request.) paul
Ransomware [was Re: Backups [was Re: Is tape dead?]]
> There is a ramsomware variant that encrypts the files but silently decrypts $ This depends on the backup-taking accessing the files in a way that doesn't trip the decryption. It also depends on nobody test-restoring from the backups, or at least not sanity-checking the results if they do. It also depends on being able to infect the OS and sit there for months without anyone noticing. > As to how one can become infected, see http://www.theregister.co.uk/2015/08/$ This depends on the user - perhaps by proxy in the form of something the user runs - executing content offered by the malvertising-serving server. Thus, defense in depth: (1) Don't run things that execute live content without explicit, specific approval by the user. Educate users as to the few cases when giving such approval is sane. (2) Avoid common OSes and ISAs, so that most malware (ransomware or otherwise) can't run even if it gets through to the machine. (3) Test-restore from your backups periodically. Of course, most people will say they "can't" do one or more of those, actually meaning they're not willing to pay the prices involved. Such people need to realize that they will pay one price or the other, and they'll just have to decide which prices they prefer. Personally, I do about two and a quarter of the above: (1), 3/4 of (2), and 1/2 of (3). /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: Desperately need BA11-N/BA11-S Technical Manual
On 9/16/15 11:23 AM, Noel Chiappa wrote: https://archive.org/details/bitsavers_decqbusMP0_10391074 (Doesn't seem to be on BitSavers?) http://bitsavers.org/pdf/dec/qbus/MP00740_1123_schem_Oct81.pdf
Re: Backups [was Re: Is tape dead?]
On 09/16/2015 11:20 AM, Al Kossow wrote: On 9/16/15 11:15 AM, couryhouse wrote: We have 10 years of backups.ed# ever verified them? Mine go back to sometime around 1980. I have customer records that go back to 1987. Curiously, we got a note from a fellow needing an update to CopyQM. He registered his product in 1992. We found it and provided him with a 1999 update--the last we did before the sale of the software (the terms of sale allow us to support existing customers). Just keep carrying the stuff forward. I've even provided other authors with copies of their own source code after they'd lost track of it. You never know when having complete archives will come in handy. But you already know that, Al! --Chuck
Re: Backups [was Re: Is tape dead?]
Enough repeated material over time just in case but yes,at one point random did . BACK UPS on backups on backups in my cases. Of course if one orig source file is bad from 10 years ago the backups of said file are eckky too. I await the dvds made of stone stuff I like to stash backups off site scattered about the country too. Geographical diversity is great... az though saver than calif ...earthquakes. ..and safer than areas with floods and huricanes.. I guess it is all a roll of the dice though. .. but just do it lots and cast it far and wide. I have no only museum stuff to worry about but also the news service stuff we do.Ed# www.smecc.orgSent from my Verizon Wireless 4G LTE smartphone Original message From: Al Kossow Date: 09/16/2015 11:20 AM (GMT-07:00) To: cctalk@classiccmp.org Subject: Re: Backups [was Re: Is tape dead?] On 9/16/15 11:15 AM, couryhouse wrote: > We have 10 years of backups.ed# > ever verified them?
Re: Backups [was Re: Is tape dead?]
Well then we have hp 3000 stuff from 23 years ago... Was then.. But soon we will see if these tape sets live.. it will be good if so as there is hp software of unique nature that only existed being saved on our tape sets. then there is the older hp 2000 stuff 5 fascinating unique things some were rewritten for 3000. But a few not and if you want ron on a 2000 you can not go backwards. ..need more hp2000 and 3000 hardware help! Ed# www.smecc.org Sent from my Verizon Wireless 4G LTE smartphone Original message From: Chuck Guzis Date: 09/16/2015 11:54 AM (GMT-07:00) To: "General Discussion: On-Topic and Off-Topic Posts" Subject: Re: Backups [was Re: Is tape dead?] On 09/16/2015 11:20 AM, Al Kossow wrote: > On 9/16/15 11:15 AM, couryhouse wrote: > >> We have 10 years of backups.ed# >> > ever verified them? Mine go back to sometime around 1980. I have customer records that go back to 1987. Curiously, we got a note from a fellow needing an update to CopyQM. He registered his product in 1992. We found it and provided him with a 1999 update--the last we did before the sale of the software (the terms of sale allow us to support existing customers). Just keep carrying the stuff forward. I've even provided other authors with copies of their own source code after they'd lost track of it. You never know when having complete archives will come in handy. But you already know that, Al! --Chuck
Re: Cryptolocker (was RE: Is tape dead?
On 09/16/2015 11:29 AM, Paul Koning wrote: I never had any incentive to look for holes in CDC operating systems, but I still remember a simple hole I found in OS/360, about a month after I first wrote a program for that OS. It allowed anyone to run supervisor mode code with a couple dozen lines of assembler source code. I found it on OS/PCP 19.6, but I noticed in graduate school that it still worked on the university's 370 running OS/MVS 21.7. (The magic? Use the OS service to give a symbolic name to a location in your code, with a well chosen name, then give that name as the name of the "start I/O appendage" in an EXCP style I/O request.) I recall going through a dump of a 360/40 running DOS and digging out the names of the various transient phases. Lots of interesting stuff there--and DOS did nothing to verify that a phase could be invoked only internally. At CDC a couple of us were dealing with a SCOPE 3.1.6 or 3.2 version (I don't recall which) and decided to see what would happen if one combined the RPV PP call (job reprieve) with the RSJ (reschedule job) call. What happened was what you'd expect to happen--said job would keep spawning copies of itself--and like the sorcerer's apprentice, spawned another new copy when the operator tried to kill the job. The simple way to kill the thing was to deadstart--there may have been others, but the input queue filled up pretty quickly. We tried this out on dedicated block time and were delighted with its operation. Some idiot in CPD tried it on COMSOURCE time was was told in no uncertain words that severe disciplinary action would be taken should he try that one again. SCOPE 3.4 introduced the "Read List String" CIO call, which was intended for use by the loader. The idea being that you presented 1SP with a list of disk addresses to read into a single buffer to build the executable. Someone, noticing that this was a linked list, decided to see what would happen if the list looped back on itself. Of course, the obvious *did* happen with 1SP so distracted that no other disk request would be honored, including PP overlays. That reminded me of the S/360 trick of using chained CCWs to ring the bell on the 1052 endlessly. Fun times. --Chuck
RE: Desperately need BA11-N/BA11-S Technical Manual
> > Yeah, as per my 'where are subsystem prints' page, they are in the 11/23 > print set MP00740, pg. 81-87 (schematic on pg. 87): OK, got it... A one page schematic, a board witht 4 ICs. Shouldn't be too hard... (famous last words!) OK, first thing, the things that look like op-amps are in fact comparators. They have open collector outputs. I would read the LM339 datasheet if you've not come across this chip before. It is a very common IC. Because of the power connections to E1 and E4 (shown on the right hand side of the schematic) the ouptus swtich between -12V and floating. This means that resistors connected from said outputs to ground are actually pull-up resistors. That threw me for a few seconds! The 555s are being used unconventionally. But let's not panic for the moment. Since you have a working board, the first thing I would compare is the reference voltage from D2. Measure the voltage on pins 7 and 9 of the chip E1. If that's the same on both boards, attempt to isolate the problem by checking the voltage on in 3 of the 555 timers. Are those the same on the good and faulty boards? -tony
Re: Desperately need BA11-N/BA11-S Technical Manual
On 9/16/2015 1:23 PM, Noel Chiappa wrote: > > From: tony duell > > > Do you have a URL for the prints (to save me going through all possible > > candidates on bitsavers)? > > Yeah, as per my 'where are subsystem prints' page, they are in the 11/23 > print set MP00740, pg. 81-87 (schematic on pg. 87): > > https://archive.org/details/bitsavers_decqbusMP0_10391074 > There is a separate BA11-N print set, MP-00487, as well. I have a hardcopy, but that one does not seem to be on bitsavers. There is a BA11-S schematic, MP01233, that is in Bitsavers, directory qbus. I don't have a technical manual. One thing I note from the schematics is the "+12V startup" generated off of a 7812 three terminal regulator, Z1 on the H7861 P.S. Master Board. I'd want to check that, because if it isn't right, nothing else will work, and it would be really easy to check. The 555's reference in one of the messages seem to be involved in generating AC L and DC L. JRJ
Re: Cryptolocker (was RE: Is tape dead?
Cyber systems didn't get much love from the H/P kids back in the day :O http://phrack.org/issues/18/5.html That said; NOS is one of the few mainframe systems ever really discussed in Phrack... MVS/TSO and VM/CMS you also see occasionally, but beyond that, it seems like most of the G-files were focused on midrange systems ... UNIX, VMS, MPE, PRIMOS, TOPS and the like. Very little discussion of many of the mainframe vendors ... There are a few Youtube videos where I guess people have done presentations at Defcon or something recently, about mainframe security ... kind of neat to watch ... of course, the z/OS they show has got all kinds of POSIX stuff grafted onto it and ... it's fairly indistinguishable from something older that I would recognize... like MVS 3.8J :O Best, Sean On Wed, Sep 16, 2015 at 2:29 PM, Paul Koning wrote: > > > On Sep 16, 2015, at 2:10 PM, Chuck Guzis wrote: > > > > This brings up something that's always baffled me. > > > > Why does a user's (or worse, the entire system's) files have to be > immediately accessible to any application wanting to take a look. > > > > Take a legacy example, SCOPE or NOS on a CDC mainframe. ... > > Just remember that those older systems may well have had any number of > security issues of their own. They did benefit a lot from "security by > obscurity" as well as the fact that they weren't connected to the Internet. > > I never had any incentive to look for holes in CDC operating systems, but > I still remember a simple hole I found in OS/360, about a month after I > first wrote a program for that OS. It allowed anyone to run supervisor > mode code with a couple dozen lines of assembler source code. I found it on > OS/PCP 19.6, but I noticed in graduate school that it still worked on the > university's 370 running OS/MVS 21.7. > > (The magic? Use the OS service to give a symbolic name to a location in > your code, with a well chosen name, then give that name as the name of the > "start I/O appendage" in an EXCP style I/O request.) > > paul > >
Re: Cryptolocker (was RE: Is tape dead?
And I actually got to play with NOS ... many years after the fact ... never thought I'd see that! What the cray-cyber.org guys are doing is remarkable. Best, Sean On Wed, Sep 16, 2015 at 3:22 PM, Sean Caron wrote: > Cyber systems didn't get much love from the H/P kids back in the day :O > > http://phrack.org/issues/18/5.html > > That said; NOS is one of the few mainframe systems ever really discussed > in Phrack... MVS/TSO and VM/CMS you also see occasionally, but beyond that, > it seems like most of the G-files were focused on midrange systems ... > UNIX, VMS, MPE, PRIMOS, TOPS and the like. Very little discussion of many > of the mainframe vendors ... > > There are a few Youtube videos where I guess people have done > presentations at Defcon or something recently, about mainframe security ... > kind of neat to watch ... of course, the z/OS they show has got all kinds > of POSIX stuff grafted onto it and ... it's fairly indistinguishable from > something older that I would recognize... like MVS 3.8J :O > > Best, > > Sean > > > On Wed, Sep 16, 2015 at 2:29 PM, Paul Koning > wrote: > >> >> > On Sep 16, 2015, at 2:10 PM, Chuck Guzis wrote: >> > >> > This brings up something that's always baffled me. >> > >> > Why does a user's (or worse, the entire system's) files have to be >> immediately accessible to any application wanting to take a look. >> > >> > Take a legacy example, SCOPE or NOS on a CDC mainframe. ... >> >> Just remember that those older systems may well have had any number of >> security issues of their own. They did benefit a lot from "security by >> obscurity" as well as the fact that they weren't connected to the Internet. >> >> I never had any incentive to look for holes in CDC operating systems, but >> I still remember a simple hole I found in OS/360, about a month after I >> first wrote a program for that OS. It allowed anyone to run supervisor >> mode code with a couple dozen lines of assembler source code. I found it on >> OS/PCP 19.6, but I noticed in graduate school that it still worked on the >> university's 370 running OS/MVS 21.7. >> >> (The magic? Use the OS service to give a symbolic name to a location in >> your code, with a well chosen name, then give that name as the name of the >> "start I/O appendage" in an EXCP style I/O request.) >> >> paul >> >> >
Re: ENIAC programming Was: release dates of early microcomputer operating systems, incl. Intel ISIS
> From: Al Kossow >> the machine had to be configured (via connecting up computing units >> with cables) > In 1947 ENIAC was modifed at BRL to be a stored program computer. Well, I did say "in the original ENIAC usage" it had to be configured by plugging! I was aware of the later conversion. > http://dl.acm.org/citation.cfm?id=1339839 Crispin Rope, "ENIAC as a Stored-Program Computer: A New Look at the Old Records", IEEE Annals of the History of Computing, Vol. 29 No. 4, October 2007 Thanks for that pointer. I couldn't get access to that paper (it's behind a paypal I don't have the ability to pierce - I would be grateful if someone could send me a copy), but in looking for it online, I did find the very similar: Thomas Haigh, Mark Priestley, Crispin Rope, "Engineering 'The Miracle of the ENIAC'", IEEE Annals of the History of Computing, Vol. 36, No. 2, April-June 2014 which includes the same author, and is later, so hopefully more definitive. It's quite interesting: according to that, the conversion of ENIAC to a 'stored program' configuration, after a period of about a year of discussion and planning, took place starting around March, 1948, and the first problem was run using it in April, 1948 - and it cites a lot of contemporary documents to that effect. (As the article points out, this contradicts the long-and-widely-held impression, from a statement in Goldstine's book - and if anyone knew, it should have been him! - that gave the date of that as September, 1948.) Anyway, the new, earlier date is of course is very shortly before the Baby ran _its_ first program, in June, 1948. So there is a rather interesting question as to which 'computer' ran first. I'd always gathered it was the Baby, but this new data may overturn that. It is true that the 'program ENIAC' (to invent a term to differentiate that stage of the machine from the earliest configurations, which used the cabling method) did not store its program in the same read-write memory as data, as the Baby did, instead storing it in 'EPROM' (switches). However, I don't consider that very important; nobody says that a machine running out of PROM isn't a computer! The important thing is that it's a program, with things like subroutine calls from different locations, address modification for data access, etc, and the 'program ENIAC' apparently had all that (see the list at the bottom of page 51 in the article). So it's likely indeed be the 'first computer'. Noel
RE: ENIAC programming Was: release dates of early microcomputer operating systems, incl. Intel ISIS
> -Original Message- > From: cctalk [mailto:cctalk-boun...@classiccmp.org] On Behalf Of Noel > Chiappa > Sent: 16 September 2015 22:06 > To: cctalk@classiccmp.org > Cc: j...@mercury.lcs.mit.edu > Subject: Re: ENIAC programming Was: release dates of early microcomputer > operating systems, incl. Intel ISIS > > > From: Al Kossow > > >> the machine had to be configured (via connecting up computing units > >> with cables) > > > In 1947 ENIAC was modifed at BRL to be a stored program computer. > > Well, I did say "in the original ENIAC usage" it had to be configured by > plugging! I was aware of the later conversion. > > > http://dl.acm.org/citation.cfm?id=1339839 > > Crispin Rope, "ENIAC as a Stored-Program Computer: A New Look at the > Old > Records", IEEE Annals of the History of Computing, Vol. 29 No. 4, > October 2007 > > Thanks for that pointer. I couldn't get access to that paper (it's behind a > paypal I don't have the ability to pierce - I would be grateful if someone could > send me a copy), but in looking for it online, I struggled to get it out of the University Library system. > I did find the very > similar: > > Thomas Haigh, Mark Priestley, Crispin Rope, "Engineering 'The Miracle of > the ENIAC'", IEEE Annals of the History of Computing, Vol. 36, No. 2, > April-June 2014 > > which includes the same author, and is later, so hopefully more definitive. > > It's quite interesting: according to that, the conversion of ENIAC to a 'stored > program' configuration, after a period of about a year of discussion and > planning, took place starting around March, 1948, and the first problem was > run using it in April, 1948 - and it cites a lot of contemporary documents to > that effect. > > (As the article points out, this contradicts the long-and-widely-held > impression, from a statement in Goldstine's book - and if anyone knew, it > should have been him! - that gave the date of that as September, 1948.) > > Anyway, the new, earlier date is of course is very shortly before the Baby ran > _its_ first program, in June, 1948. So there is a rather interesting question as > to which 'computer' ran first. I'd always gathered it was the Baby, but this > new data may overturn that. > I believe that its generally accepted that is true. > It is true that the 'program ENIAC' (to invent a term to differentiate that > stage of the machine from the earliest configurations, which used the cabling > method) did not store its program in the same read-write memory as data, as > the Baby did, instead storing it in 'EPROM' (switches). However, I don't > consider that very important; nobody says that a machine running out of > PROM isn't a computer! It is notable that in order to solve all problems, a computer must permit self modifying code. In the above article Crispin notes that ENIAC was succeeded by the IBM 701 and then omits the fact that the 701 used the Williams tubes from the Baby as its main store, so clearly both machines had a non-significant influence on early computing. Without Williams and ENIAC there would have been no IBM701... > > The important thing is that it's a program, with things like subroutine calls > from different locations, address modification for data access, etc, and the > 'program ENIAC' apparently had all that (see the list at the bottom of page 51 > in the article). So it's likely indeed be the 'first computer'. > > Noel What is and isn't a computer is always open to debate. The Manchester SSEM or Baby is I would say the simplest thing that you could call a computer. I could explain how to program the Baby to almost any one on this list. It has seven instructions, so in a 32 bit word, a 5 bit address and a 3 bit op code. Crispin Rope concentrates on the power of ENIAC and its usefulness, neither of which can be argued with, but to me a "computer" without self-modifying code is a programmable calculator even if it has index registers... If you want to rate a computer by the work it did ENIAC was far more useful, but the SSEM was never intended to be a "Useful" computer. It was a testbed for the Williams Tube. ... on the other hand whilst both added to our knowledge of computing in the longer term neither were IMHO especially influential going forward. Self-Modifying code became the norm, and Williams Tubes were rapidly superseded by core... >From what I have seen the UK was slow to move onto Core store, probably because IBM bought the patents, so whilst the IBM 704 was already using Core in 1954 the Ferranti Pegasus from 1956 went back to using Nickle Delay Lines and a Drum for "Main Store" although IMHO the Delay Lines were really main store, from what I remember all code must be in the delay lines. The LEO (Lyons Electronic Office) also used Mercury Delay Lines Dave Wade
Re: Cryptolocker (was RE: Is tape dead?
On 09/16/2015 12:23 PM, Sean Caron wrote: And I actually got to play with NOS ... many years after the fact ... never thought I'd see that! What the cray-cyber.org guys are doing is remarkable. Sad that they don't have any early software. In the beginning there was COS (Chippewa Operating System), followed by SCOPE (which doesn't really describe a specific OS, but more on that later). On the 6000, both were essentially PP-oriented, leaving the CP to do the real work. MACE was essentially a bootleg product mostly done a night on the Arden Hills QA floor by (Dr.) Dave Callender (he of the bats) and Greg Mansfield (whom I had the privilege of introducing to the delights of gelato--but that's another issue. Greg wanted a slimmed-down operating system for the CE community--hence, the name "Mansfield's Answer to Customer Engineering). Greg, unfortunately, was your basic geek, not good with people, but very talented. Without Dave's promotion, I doubt that it would have gotten anywhere. MACE did make its way into the academic community. I believe that Purdue added and extended it quite a bit. One aspect is that the OS was considerably more CP-involved than SCOPE. So, for the interactive stuff like PLATO, MACE was re-named KRONOS and launched as a separate official product. At the user level, the two were pretty much compatible, but internally, they were very different. For example, SCOPE had a rather elaborate disk driver, called 1SP (for "Stack Processor"), which sorted and prioritized disk requests based *partly* on the distance that a seek to cylinder involved. KRONOS on the other hand, used a much simpler "first-come, first-served" principle. Mostly, it was a battle of cultures. SCOPE was maintained out of Palo Alto (Porter Drive) and later, Sunnyvale (Moffet Park Drive) and KRONOS out of Arden Hills. Sometime around the advent of the Cyber 70 series, management made a non-decision (with 128 vice presidents, how could it be otherwise?) So, KRONOS was re-christened NOS (network operating system) and SCOPE became NOS/BE (batch environment). Eventually, enough of the BE aspect was rolled into NOS that only one--NOS survived. Besides, CDC was doing their best to get rid of as much staff as they could at CDC Sunnyvale. Certain key people, however, refused to transfer, so it took well into the 80s before the last light went out in Sunnyvale. Now, that's about Cyber 70/6000 NOS/SCOPE. The 7600 was a very different beast. For one, the 7000 PPs didn't run as slots in a barrel--they were fully independent. Secondly, the PPs were hard-assigned a buffer region each in SCM--they did not have unfettered access to memory. This meant that the PP-resident aspect of 6000 SCOPE (and KRONOS) was unworkable on the 7600. So, 7000 SCOPE was born--mostly, what I saw was SCOPE 2 and SCOPE 2.1. With the PPs dedicated to pretty much nothing but simple I/O, the whole business of job control and user interface fell to the CP. Note that the 7600 had very fast SCM, but not much of it, so storage of transient programs was left to slower LCM. The scheme adopted was to have various functions of the OS be nested, matryoshka-doll style with the user program in the inside. So outside of the user program, you could have the job supervisor, then the record manager, then the buffer manager and so on.. So 7600 SCOPE was nothing like 6000 SCOPE (or NOS). There were other 6000-series operating systems, not very well known to this day. For example, the ROVER people had their own version of what I assume was an early SCOPE--I'm not certain if this has been declassified even today, so the less said the better. There was TCM, Time-Critical Monitor which claimed to have a maxiumum average event latency of 100 nsec ZODIAC was built on the TCM OS, used lots of ECS in multi-mainframe configurations to host "chains" of real-time transactions (a bit complex to explain) that essentially operated with its own I/O and filesystem. Life was interesting back then... By the time you hit the 80s and the CYBER 180, not so much. --Chuck
Re: Ransomware [was Re: Backups [was Re: Is tape dead?]]
>Mouse wrote: There is a ramsomware variant that encrypts the files but silently decrypts $ This depends on the backup-taking accessing the files in a way that doesn't trip the decryption. It also depends on nobody test-restoring from the backups, or at least not sanity-checking the results if they do. It also depends on being able to infect the OS and sit there for months without anyone noticing. As to how one can become infected, see http://www.theregister.co.uk/2015/08/$ This depends on the user - perhaps by proxy in the form of something the user runs - executing content offered by the malvertising-serving server. Thus, defense in depth: (1) Don't run things that execute live content without explicit, specific approval by the user. Educate users as to the few cases when giving such approval is sane. (2) Avoid common OSes and ISAs, so that most malware (ransomware or otherwise) can't run even if it gets through to the machine. (3) Test-restore from your backups periodically. Of course, most people will say they "can't" do one or more of those, actually meaning they're not willing to pay the prices involved. Such people need to realize that they will pay one price or the other, and they'll just have to decide which prices they prefer. Personally, I do about two and a quarter of the above: (1), 3/4 of (2), and 1/2 of (3). The system which I use to develop programs and produce code is used only to download e-mail and news groups. This seems to have isolated the system to some extent. As for (3), I don't understand how a test-restore would help. I don't know if this is relevant, but I shut down my system every night and boot the C: drive again in the morning. After booting from DOS using a floppy disk, my backup consists of using Ghost to make an image copy (compressed) of all the files on the C: drive to the D: drive which is used ONLY for that purpose. Even if the files have been encrypted, I don't understand how a restore would detect that the files are being encrypted / decrypted on the fly if a boot every morning does not notice a problem. As it happens, once or twice a year when I do need to access the internet, I first do a backup of my C: drive, access the Internet to make copies of the files that I want - PDP-11 stuff for RT-11, obviously. Then just in case, I do a restore from the backup to my C: drive. How would that be any different from just booting the same C: drive each morning? Jerome Fine
Re: Cryptolocker (was RE: Is tape dead?
On 09/16/2015 01:10 PM, Chuck Guzis wrote: Has cryptolocker ever invaded the world of Unix/Linux/BSD? It would be much harder. In general, browsers do not activate just any file you would download. There are weaknesses in various graphical/video add-ons to browsers that may cause vulnerabilities. But, in GENERAL, malware in videos, etc. would either do nothing at all when sent to the add-on program, or get a message saying something like "this script contains macros, executing it could be a security risk: Yes / No" I've been browsing quite fearlessly with Linux systems for about 17 years, and NEVER had any problem. Now, I've also had a Linux web server up for about 15 years, and have had 2 successful penetrations. One was totally innocuous, they just added a phishing web site for a bank, and it was easy to remove. Another attack put in a root kit, and it caused a major mess, including me sending out some infected code to other people. (OOPS, red face!!) These were both done by cracking insecure passwords on my system. The best defense for that is running denyhosts, which counts login failures from specific IP addresses, and cuts off all access from that IP after a threshold. I set it very tight, two failed attempts within a month and you are out for a year. It was VERY interesting, exactly, to the HOUR, two weeks after I set this up, the 1000 per day attempts to break in dropped to 3 a day. This means the botnets actively track how long the horizon on the login failures is set, and they've been programmed to give up on any node that has a horizon over 2 weeks. Jon
Re: Cryptolocker (was RE: Is tape dead?
On 09/16/2015 01:29 PM, Paul Koning wrote: I never had any incentive to look for holes in CDC operating systems, but I still remember a simple hole I found in OS/360, about a month after I first wrote a program for that OS. It allowed anyone to run supervisor mode code with a couple dozen lines of assembler source code. I found it on OS/PCP 19.6, but I noticed in graduate school that it still worked on the university's 370 running OS/MVS 21.7. (The magic? Use the OS service to give a symbolic name to a location in your code, with a well chosen name, then give that name as the name of the "start I/O appendage" in an EXCP style I/O request.) paul Yup, the classic breakin was you set up an exception handler with SPIE (specify program interrupt exit, I think) and then do a divide by zero. This gives the handler the PSW of the problem program. You turn the P bit of the PSW off and return. The stock OS would actually ALLOW you to DO this, and just return to the user program now in supervisor state! It was a VERY simple fix, you just don't allow any exception handler to change the state of the P bit. But, MANY systems did not do that check. So MANY other weaknesses could easily be caused by accident. Like, the file that contained valid account numbers was often not protected. Anybody could just print out that file. Jon
Re: Ransomware [was Re: Backups [was Re: Is tape dead?]]
>> Thus, defense in depth: >> [...] >> (3) Test-restore from your backups periodically. > As for (3), I don't understand how a test-restore would help. The theory is, if the restore restores good contents then the backup contains good contents. > Even if the files have been encrypted, I don't understand how a > restore would detect that the files are being encrypted / decrypted > on the fly if a boot every morning does not notice a problem. It wouldn't. That was to defend against the "the backup contains the encrypted version" risk - which only some backup mechanisms will suffer from. If you use something like tar(1) to make your backups, something that uses the usual file-access mechanisms to read the files, it will back up the decrypted-on-the-fly version, which is what you want. But if you use something like dump(1) that goes behind the filesystem's back to read the files, or something like dd(1) that is filesystem-blind and just backs up the disk's contents, it easily could end up backing up the on-disk encrypted version (which is what that kind of ransomware hopes for, of course). /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Self modifying code, lambda calculus - Re: ENIAC programming
On 2015-09-16 6:18 PM, Dave G4UGM wrote: ... It is notable that in order to solve all problems, a computer must permit self modifying code. Is that true? AFAIK Lambda calculus can describe any computable function (as can a Turing machine), and it has no concept of "self modifying code". --Toby ... Dave Wade
Re: Self modifying code, lambda calculus - Re: ENIAC programming
On 9/16/2015 9:25 PM, Toby Thain wrote: On 2015-09-16 6:18 PM, Dave G4UGM wrote: ... It is notable that in order to solve all problems, a computer must permit self modifying code. Is that true? AFAIK Lambda calculus can describe any computable function (as can a Turing machine), and it has no concept of "self modifying code". I never studied any of that, but you do have to LOAD and RUN the program ToSolveAnythingBut42 some how so I guess that would count AS Self Modifying Code. --Toby
Re: Cryptolocker (was RE: Is tape dead?
There were / are bugs in the mpg and jpg libraries that allow for remote execution that may or may not have been fixed. If it can screw over cell phones running on Linux, it can screw you over if you are running on garden variety Linux. Since we are all users on an ongoing basis of fossilized non updated systems, likely all of your older Linux systems have at least the mpg problem, and it is a fun one. The only thing saving you is that you would need to target it at a specific binary target. thanks JIm On 9/16/2015 6:29 PM, Jon Elson wrote: On 09/16/2015 01:10 PM, Chuck Guzis wrote: Has cryptolocker ever invaded the world of Unix/Linux/BSD? It would be much harder. In general, browsers do not activate just any file you would download. There are weaknesses in various graphical/video add-ons to browsers that may cause vulnerabilities. But, in GENERAL, malware in videos, etc. would either do nothing at all when sent to the add-on program, or get a message saying something like "this script contains macros, executing it could be a security risk: Yes / No" I've been browsing quite fearlessly with Linux systems for about 17 years, and NEVER had any problem. Now, I've also had a Linux web server up for about 15 years, and have had 2 successful penetrations. One was totally innocuous, they just added a phishing web site for a bank, and it was easy to remove. Another attack put in a root kit, and it caused a major mess, including me sending out some infected code to other people. (OOPS, red face!!) These were both done by cracking insecure passwords on my system. The best defense for that is running denyhosts, which counts login failures from specific IP addresses, and cuts off all access from that IP after a threshold. I set it very tight, two failed attempts within a month and you are out for a year. It was VERY interesting, exactly, to the HOUR, two weeks after I set this up, the 1000 per day attempts to break in dropped to 3 a day. This means the botnets actively track how long the horizon on the login failures is set, and they've been programmed to give up on any node that has a horizon over 2 weeks. Jon
Re: Cryptolocker (was RE: Is tape dead?
On 9/16/2015 6:36 PM, Jon Elson wrote: On 09/16/2015 01:29 PM, Paul Koning wrote: I never had any incentive to look for holes in CDC operating systems, but I still remember a simple hole I found in OS/360, about a month after I first wrote a program for that OS. It allowed anyone to run supervisor mode code with a couple dozen lines of assembler source code. I found it on OS/PCP 19.6, but I noticed in graduate school that it still worked on the university's 370 running OS/MVS 21.7. (The magic? Use the OS service to give a symbolic name to a location in your code, with a well chosen name, then give that name as the name of the "start I/O appendage" in an EXCP style I/O request.) paul Yup, the classic breakin was you set up an exception handler with SPIE (specify program interrupt exit, I think) and then do a divide by zero. This gives the handler the PSW of the problem program. You turn the P bit of the PSW off and return. The stock OS would actually ALLOW you to DO this, and just return to the user program now in supervisor state! It was a VERY simple fix, you just don't allow any exception handler to change the state of the P bit. But, MANY systems did not do that check. The SPIE fix was fixed in MVT 21 which we ran at UMR in my memory before I left in 75. I know of at least three of us who wrote up exploits, which stored the PSW to show supervisor state, and let it go at that. That was on the UMR 360 / 50 The really fun "trojan" was a console logger that was around which watched the MVS VS1 console screen for changes and rendered a scrolling rendition of the log on a terminal. The computer operators at our remote site didn't have that working with their remote Hasp workstation, only had the entries pertinent to locally submitted jobs. This was on a 370 / 158 at University of Missouri, Columbia. Also there was a password logger which watched all the TSO logins, and logged the password and account for every user. That exploit still existed when I left. The IBM code had an 8 byte double word in which it stored a "scrambled" version of the password for use by jobs that needed authentication (way before RACF or such) and could verify w/o re-prompting a lot for the password. However when you entered your password the first 8 characters, which were all that were used for authentication were stored for a few cycles in that same word. So to get the password, you watched the login state, and as long as the process was logged off, the entry was zero. You would grab the values and store the first value that appeared after it went non zero and about 99% of the time it was the clear text. Fun times. So MANY other weaknesses could easily be caused by accident. Like, the file that contained valid account numbers was often not protected. Anybody could just print out that file. Jon
