Malware in a PLC?

[Lord Farquaad]

This threat from the subsupplier, do you have it in writing ? It is totally illegal unless it is specifically mentioned in the contract.

I don't. I am not involved in any of this. I am only trying to figure out if it was actually done, or was the sub-supplier bluffing when he mentioned this.



Actually, the reason for the post was to ask where I should look for a time-bomb, if it was installed. Timers and counters are the most obvious. But maybe there are other ways?

 

[parky]

There are probably hundreds of ways, you would need to look for code that does not seem to tie in with the operation of the machine, some of the ways could be: data memories used as counts, date based on the RTC, maybe direct call to an offset of the memory i.e. get the address of the D area, find the end and add a ridiculous number, this would write to a system data area or something crashing the PLC, indirectly addressing a out of range variable or as simple as divide by zero in floating point maths with the stop mode set on this error.

 

[Steve Bailey]

maybe there are other ways?

Plenty of ways. Here are a few off the top of my head.


Stopping the PLC program.
Conditional calls to subroutines.
Preventing I/O module updates.
Preventing progression through sequences.

 

[I_Automation]

Actually, the reason for the post was to ask where I should look for a time-bomb, if it was installed. Timers and counters are the most obvious. But maybe there are other ways?

Depending on how technical and how much time the programmer put into it.

It could involve comparing runtime, cycles, or product count values then moving a new value to an integer or set a bit. That integer or bit could be part of a shift register/bitshift somewhere else. Then the new integer could look at an array out of range or the new bit could inhibit a critical operation (say the exhaust motor or a main pump has to be on to run) not in an obvious way.

 

[James Mcquade]

Just a few thoughts on my part.


Something is definitely up with the vendor. to demand payment immediately is unheard of to me.


If you still have the machine at your site, you may want to start the system and set the pc and plc date to jan 5, 2025 for example.
then try to run the software.
if there is a logic bomb, the software will not run, if there is a virus, it will not run.


I suspect that the software may not be a permanent license, but one that has a yearly expiration date.


in any case, you need to keep all email and regular mail correspondence for the legal department.


regards,
james

 

[goghie]

Unfortunately to you, GXWorks3 has excellent protection scheme. Not only protecting code with classical password, which is now very secure, but also prohibiting copy and change of program to unauthorized personal, not having adequate Security Key.
Just to note that if customer asks me to for similar thing as your customer did, without good explanation why problem with vendor occurred I charge him with much, much higher price. In this industry we need to stick together, otherwise the "big" companies will depreciate our services.

 

[drforsythe]

Over 20 years ago, I was called in to service a US / Japanese joint venture plant that used primarily Mitsubishi PLCs. A new dispensing line was installed and the machine supplier was from the UK. Mere hours after the technician boarded a plane to go home (against his will), two identical machines stopped within an hour of each other. I found a time bomb in the program that had a jump command to a non-existent subroutine which threw a critical fault and stopped the processor. The code that compared the actual time to the target time set a bit that was retentive. Stopping or powering down the controller made no difference. I removed the two lines of logic in each controller and was on my way in no time. Apparently the programmer was upset he had to leave the US earlier than he wanted. My suggestion is to search for calls to labels or routines and ensure that the labels really exist.

 

[TheWaterboy]

I knew a guy that did that time bomb thing in his windows based software. He insisted on a maintenance agreement with his customers and if they didn't renew there would be some sort of issue some months later that he would have to fix.

... for him to fix it they must first get current with maintenance agreement, back-paying for the time that they didn't have one. Quite the deal, he made a lot of money back then.

He also worked on the Denver airport luggage handling software... I always wondered
what went on there when they were having so many problems... maybe it was him.

This same guy put a modem (a long time ago obviously) in the ceiling of an office building of one the businesses he used to own, installed a phone line and could dial into his software whenever he wanted to monitor what they were doing to it.

I'm surprised he's not in jail actually .

 

[Maxkling]

he also worked on the denver airport luggage handling software... I always wondered what went on there when they were having so many problems... Maybe it was him.

bae?

 

[goghie]

Just a few thoughts on my part.


Something is definitely up with the vendor. to demand payment immediately is unheard of to me.

regards,
james

Why? We are not banks. When you go to supermarket to buy bread you pay immediately. I have projects that last for years, not due to my mistake, but due to investors errors in mechanical department. If I had to wait for them to pay me all the time, I would go crazy and bankrupted.
When I finish the job I request that testing starts immediately, and if investor is not satisfied with something he needs to write what is not according to contract and I will fix it and pay penalties if he is right - but we work for money, and if they want job done good and fast they need to pay in the same way - good and fast.

 

[kalabdel]

This is all true and I can help you.
I can disable the maleware for 2000.00 euro, guaranteed. PM for more info regarding money transfer in exchange for a one time secure access to said file.

 

[James Mcquade]

goghie,


I got into this business in September 1986, and in all that time there are contracts with payment clauses and terms. Sometimes the payments and clauses, contract terms and scopes of work gets changed, again it's on paper.
in the original post, the terms were spelled out and there is a warranty issue, that's when the vendor demanded an immediate payment. To me, that's a red flag. this is when you dot every I and cross every t and triple check all paperwork. just my opinion.
james

 

[JesperMP]

Why? We are not banks.

In a way you do commit to a complex transfer of values with a plan for paying back. Just like if you were a bank agreeing a loan with a customer.
edit: For large projects it is not enough that the customer sign a contract and puts a down payment upfront. We usually demand an LC that must run until shipping and the main payment.

I have projects that last for years, not due to my mistake, but due to investors errors in mechanical department. If I had to wait for them to pay me all the time, I would go crazy and bankrupted.

Payment should never be 100% based on a single condition. That is unacceptable to both seller and buyer.
Payment is usually split into 3 parts.
Up front, say 5-15% so that the seller can start work on the engineering and buy parts.
Upon shipping, say 70-90 %. Think about that you risk a malicious customer not paying anything at all after the seller ships the machine.
The rest upon take-over. This usually means that the customer starts using the machine in his production. At this time, if there are any remaining issues the seller agree with the customer which issues there are and when the seller will finish solving them. Essentially, the solving of the issues is part of the sellers warranty.
The warranty runs for a limited time period, 1-2-3 years, and it starts upon signature of the takeover documents.
This final agreement may require quite a bit of arm-wrestling, but if push comes to shove the seller can insist that the buyer have to decide to sign or not use the machine.

When I finish the job I request that testing starts immediately, and if investor is not satisfied with something he needs to write what is not according to contract and I will fix it and pay penalties if he is right

Penalties must also be specified in the contract. Usually these are a relatively small sum, and are dependant on when the production on the machine can start, not if all issues are solved 100%.
In my world penalties are very rare. Usually the customer has to pay for them himself since we simply up the sales price accordingly.
Also, we never accept to cover costs caused by "consequental damages".

EVERYTHING of the above must be stated in the contract. Anything less is unprofessional.

 

[cardosocea]

The rest upon take-over. This usually means that the customer starts using the machine in his production.

As someone on the buyer side, this doesn't fly. I'm more than happy to pay less for the delivery of the machine, pay for the commissioning of the machine on site, but the final payment is upon updated documentation delivery. I've been lucky/unlucky to have had to fix this type of bungles where payment was done but the drawings not updated with modifications from the commissioning, installation certificates not delivered, bankruptcy, etc... and it's hard to fall for that again.

As for the other payment milestones, I'm also happy to work with the supplier and arrange as many payment milestones as needed to ensure that he's not left hanging when production decides that it's going to take another 3 months to free up a machine or production line. Again, this helps with terms and penalties, but also with the relationship with the supplier.

 

[JesperMP]

As someone on the buyer side, this doesn't fly. I'm more than happy to pay less for the delivery of the machine, pay for the commissioning of the machine on site, but the final payment is upon updated documentation delivery.

I can see your argument, but it would be unacceptable for us.
One thing is payment, the other thing is responsibility of safety. Until takeover, we are responsible for the safety. After takeover the buyer is responsible for the safety (not including safety issues due to design or construction).
It would be unacceptable for us that we would be responsible for a machine in operation at a customer, and we would be liable if an accident happen due to the customers own negligance.

I imagine that if a customer would demand something like you descibe that, we would offer that 1% of the contract sum would be dependant on the final documentation.
But we would never accept to allow the customer using the machine without taking over the ownership and responsibility of safety.