15. RE: Malware "eating" PRGs and SPRs (Chris Davis)
Chris,
Turns out the cause was an "autorun.inf" worm. Very difficult to remove.
Below are a few paragraphs from one of the links below.
Wes Wilson, ERW Custom Programming, Inc.
Malware activity exploitin
Alan Bourke wrote:
Wait until XP is not getting security updates any more. All it'll take
is one crappy XP machine in the corner of the shop floor that management
can't be bothered updating ...
Still 85% of Britain's NHS computers on XP
http://www.theregister.co.uk/2013/10/01/six_months_en
On Thu, Oct 10, 2013, at 04:27 PM, José Olavo Cerávolo wrote:
> I would like to know how did you clean it.
We didn't - our customers IT providers do this as it's their
responsibility. We don't support the infrastructure. I believe they used
a dedicated removal tool.
> We think the virus came
That just happened to me on one of my customers.
The DBF files used on their ERP were compromised.
The data is kept on SQL server, but there are several DBF's responsible for
several functions; menus, reports, report options, etc.
We decided to restore a 2 day copy of the server, luckily they us
m] On Behalf Of Wes Wilson
Sent: 02 October 2013 13:38
To: profoxt...@leafe.com
Subject: Malware "eating" PRGs and SPRs
I was at my customer's site from 8/20-8/31/13. On 8/21, we discovered that all
of the PRGs in \SBT7\AP\ were empty. Date and time stamps
were untouched. We a
Hi Gérard,
VFP first temporarly renames the .bak (if it exists)
> Then, it copies the original on a 'new' .bak
> And then it creates the new .prg.
Actually, it depends...
If you configure the VFP editor to create a BAK file when saving a PRG
file, then you are correct. VFP renames the existing
Could it be write ahead cache?
Al
-Original Message-
No. AFAIK,
VFP first temporarly renames the .bak (if it exists) Then, it copies the
original on a 'new' .bak And then it creates the new .prg.
___
Post Messages to: ProFox@leafe.com
Subsc
- Original Message -
From: "Christof Wollenhaupt"
a file, it
renames the original, saves the new one, deletes the copy and then renames
the new one. When the PRG/SPR files is opened with a read lock by another
program (usually a virus scanner or a text viewer), the delete operation
succ
> I was at my customer's site from 8/20-8/31/13. On 8/21, we discovered
> that all of the PRGs in \SBT7\AP\ were empty. Date and time stamps were
> untouched. We are converting an old VisionPoint, SBT7 program to Visual
> FoxPro.
>
I've seen similar behavior with virus scanners. The suddenly bl
On Wed, Oct 2, 2013, at 01:37 PM, Wes Wilson wrote:
> About a week after I left, my customer said his entire system was
> compromised by malware that attaches nasty code to autorun.inf. No
> question in his mind that we caused it. Turned out he had an antiquated
> firewall and workstations wit
Wes Wilson wrote on 2013-10-02:
> I was at my customer's site from 8/20-8/31/13. On 8/21, we discovered
that all of the PRGs in \SBT7\AP\ were empty. Date and time stamps
>
> were untouched. We are converting an old VisionPoint, SBT7 program to
Visual FoxPro.
>
> My customer blamed me s
On Wed, Oct 2, 2013 at 7:37 AM, Wes Wilson wrote:
> I was at my customer's site from 8/20-8/31/13. On 8/21, we discovered
> that all of the PRGs in \SBT7\AP\ were empty. Date and time stamps
>
> ---
"I love you", nimda, hit the screen files in 2013 could this be the I hate
you vir
I was at my customer's site from 8/20-8/31/13. On 8/21, we discovered that all
of the PRGs in \SBT7\AP\ were empty. Date and time stamps
were untouched. We are converting an old VisionPoint, SBT7 program to Visual
FoxPro.
My customer blamed me since his network was behind a firewall and the
13 matches
Mail list logo
