Ohio class sub sonar / navy software contracting

spice chai · Jan 27, 2013

I have a story with a plot that hinges on the Soviets inserting sabotaging code into the programming that runs the sonar in US Ohio class submarines. Specifically the code listens to the sonar, waiting for a specific audio signal. When it hears this particular audio signal, it mutes the audio feed to the sonar operators, sends on a few pings, and then unmutes the audio feed.

So a Soviet submarine just needs to broadcast that code, then listen for for any return pings, thus the Soviet sub knows where the Ohio class sub is, but not vice versa. I'm guessing the crew of the Ohio will know something is wrong with the sonar, but won't immediately know they are in deadly danger, and even once they do, won't be able to find the compromised module. I would think the best they could manage would be to turn off all sonar and go blind, in which case they would be at a huge disadvantage.

I have a lot of questions about this scenario and haven't been able to find any detailed information on the subject. It would be best if the code and ping were outside of human hearing, because I assume the crew can hear their own pings if they're between 20 to 20,000 hertz. Can Ohio subs broadcast in infrasound or ultrasound? Are there any problems with this scenario? If the Soviets wanted to compromise a navy software contractor writing a system update for a computer module for the Ohio sonar, what would be the best way to do that?

thanks!

jclarkdawe · Jan 28, 2013

The problem you're going to have is that most of the answer here is at a minimum of top secret, and some of it is beyond that. Technological capabilities of the US Navy tend to have limited release, and the sub service is even less forthcoming then the surface Navy. For instance, although there are lots of good guesses as to the maximum speed and depth of subs, there is absolutely no hard data pinpointing exact numbers. It's all guesses.

Compounding that problem is the fact that you're new to the forum. Nobody knows you, and the people who could give you an answer are going to be a bit concerned as to who you are. A track record of being here a year or two would go a long ways to avoiding that problem.

You're going to have to do what Tom Clancy did and just dig it out. Clancy did such a good job with HUNT FOR RED OCTOBER that there were concerns he had violated security clearances. By being able to show his published sources, he was able to dispel that concern. One problem for you is that you find a sonarman who explains how this could work. You don't know whether that sonarman is violating his security clearance (which he probably is) and as a result, you're violating security laws by publishing it.

Best of luck,

Jim Clark-Dawe

Buffysquirrel · Jan 28, 2013

The upside to what Jim says is that if you make it up, hardly anyone will know.

Duncan J Macdonald · Jan 28, 2013

I'll second and third Jim's response. Technical capabilities of sonar systems, whether air, surface, or subsurface deployed, are classified.

I'll also second Buffysquirrel's thoughts.

I'm a twenty-year veteran retired Navy officer who is currently employed as a ~~Parkway Patriot~~ ~~Beltway Bandit~~ Defense contractor.

thothguard51 · Jan 28, 2013

I will add, it depends on the sonar operators experience. They spend a lot of time listening to anything from a school of fish to whales and other boats. They become familiar with sounds and suspect when something is off...

spice chai · Jan 28, 2013

Good points. Maybe what I should have said is that for my plot to work, I need to make sure it's not contradicted by any unclassified information that is fairly widely known by military fiction buffs.

If the information is classified - no problem. I'll just make it up and there will be like, 1,000 people on earth who could tell me I was wrong, and they're sworn not to!

backslashbaby · Jan 29, 2013

Ha! There ya go.

I don't even like it when folks research this stuff too fervently, btw. There is a lot out there that probably shouldn't be. I think Tom Clancy was a brilliant --but very bad-- boy

If you do find a great source, there may be other fun stuff you could add that adds reality without compromising any knowledge. Those 1,000 people will get a chuckle at who you must have talked to

jclarkdawe · Jan 29, 2013

As far as adding something to a computer program, learn about checksums. That's what you're going to have to fool.

Best of luck,

Jim Clark-Dawe

spice chai · Jan 30, 2013

Yeah, checksums would catch any mischief that happens after the official code is compiled, but my tentative plot is to have the soviets compromise the programmer who is originally writing the software. (Probably writing a software update, as I suspect there will be less scrutiny of an update than of the version 1 code.)

lcwrite · Jan 31, 2013

I work with a guy that was on special boats back in the 70s. He frequently mentions a book called Blind Man's Bluff that was written by someone on the same boat. When the book came out the Navy called my friend and others that had crewed that boat and reminded them of their confidentiality agreements. He does say that much of what is in it is accurate. You might look for it and see if it helps any.

MoLoLu · Feb 4, 2013

spice chai said:
Yeah, checksums would catch any mischief that happens after the official code is compiled, but my tentative plot is to have the soviets compromise the programmer who is originally writing the software. (Probably writing a software update, as I suspect there will be less scrutiny of an update than of the version 1 code.)

Be careful about this assumption. Working systems are proven. Changes to working systems must be proven. Even in cases of critical-existence-failure bugs, the patch must be tested extensively - doubly so on systems which have already been in use - triply so when said system is part of an SSN. Now, developing a new system is something different. Very easy to slip stuff into new systems. Not so easy to slip them into existing ones.

But if it works (the sonar software, I mean) why would anyone update it?

BDSEmpire · Feb 4, 2013

MoLoLu said:
But if it works (the sonar software, I mean) why would anyone update it?

I think the numerous bugs in the flight software of the F-22 would be a decent real-world example of why software would get updated. The sonar package is your eyes out into the world so having the latest and greatest cutting edge processing of the received sound is highly desirable. Of course, what looks okay during compile time might bump into something unexpected during run time (like the international date line and the F-22's).

It's not implausible to suggest that a company finds itself down to the wire to deliver the software, sees a bunch of housekeeping crap it needs to have done but can get programmed by any smart intern and decides, against some greybeard's better judgement to farm that out to one of the many many offshore software houses that exist to pound out boring code all day.

Thing is, this company is being watched by THEM and as soon as they do this, the subcontractor gets infiltrated and nasty code gets inserted in a way that without careful code review practices and solid testing procedures that won't happen in a crunch-time environment, the backdoor code makes it into production. There it sits, a ticking timebomb of ones and zeroes waiting for THEM to activate it.

thothguard51 · Feb 4, 2013

A good sonar program can tell the difference in prop noise and can even identify a vessel by its prop noise. Provided it has been identified and entered into the system previously. This is a real good reason for updating sonar programs regularly.

spice chai · Feb 4, 2013

BDSEmpire, thothguard51: That is exactly my scenario except I don't think the US Navy would allow a foreign sub contractor. Still, an individual US programmer would be easy enough to compromise with blackmail or bribery or both.

MoLoLu · Feb 4, 2013

BDSEmpire said:
I think the numerous bugs in the flight software of the F-22 would be a decent real-world example of why software would get updated. The sonar package is your eyes out into the world so having the latest and greatest cutting edge processing of the received sound is highly desirable. Of course, what looks okay during compile time might bump into something unexpected during run time (like the international date line and the F-22's).

It's not implausible to suggest that a company finds itself down to the wire to deliver the software, sees a bunch of housekeeping crap it needs to have done but can get programmed by any smart intern and decides, against some greybeard's better judgement to farm that out to one of the many many offshore software houses that exist to pound out boring code all day.

Thing is, this company is being watched by THEM and as soon as they do this, the subcontractor gets infiltrated and nasty code gets inserted in a way that without careful code review practices and solid testing procedures that won't happen in a crunch-time environment, the backdoor code makes it into production. There it sits, a ticking timebomb of ones and zeroes waiting for THEM to activate it.

I'm not saying it doesn't happen. I'm not saying it can't happen. I'm just saying it's a pretty drastic failure of employee security and quality control to allow software designed for a 40-year old class of SSNs to be compromised by a single coder. The reason I say this is that it isn't a bug like the F22 dateline issue - bugs always occur. It's someone who deliberately went in, wasn't noticed in any way, and inserted this code, which was then missed by all the quality control that code went through, and manged into production. And the scenario outlined by the OP isn't exactly the standard functionality for sonar. Unless the Government's really got lax in quality, I can't imagine no one would wonder why on earth there's a bit of code in there that deliberately turns off the sonar's output in normal operation.

(on a side note, I have this wacky mental image of "inserted little bit of code that russian agent paid me to" in the change log somewhere)

thothguard51 said:
A good sonar program can tell the difference in prop noise and can even identify a vessel by its prop noise. Provided it has been identified and entered into the system previously. This is a real good reason for updating sonar programs regularly.

Except that wouldn't be an update of the program. It's a configuration update. Isn't the same thing. You can reconfigure windows without touching the source code. This is safer. Not fool-proof. But safer.

thothguard51 · Feb 5, 2013

spice chai said:
BDSEmpire, thothguard51: That is exactly my scenario except I don't think the US Navy would allow a foreign sub contractor. Still, an individual US programmer would be easy enough to compromise with blackmail or bribery or both.

Think of John Walker, the notorious Navy guy who sold info to the Russians. They believe the information he passed on helped the Russians make quieter propellers...

Ohio class sub sonar / navy software contracting

spice chai

jclarkdawe

Feeling lucky, Query?

Buffysquirrel

Duncan J Macdonald

Plotting! Not Plodding!

thothguard51

A Gentleman of a refined age...

spice chai

backslashbaby

*

jclarkdawe

Feeling lucky, Query?

spice chai

lcwrite

practical experience, FTW

MoLoLu

BDSEmpire

Kindly Bumpkin

thothguard51

A Gentleman of a refined age...

spice chai

MoLoLu

thothguard51

A Gentleman of a refined age...

Ohio class sub sonar / navy software contracting

Feeling lucky, Query?

Plotting! Not Plodding!

A Gentleman of a refined age...

~~~~*~~~~

Feeling lucky, Query?

practical experience, FTW

Kindly Bumpkin

A Gentleman of a refined age...

A Gentleman of a refined age...

*