I've created an auto-updating application which is distributed to 100s of users.
The auto-update utility is being flagged by 55% of antiviruses on virustotal ( link ).
My application was created in Delphi 7. Most of the flags are saying that this is Generic trojan/malware, obviously the software isn't actually malware (I'm the only one with source code access and access to the server which hosts it) but it's causing a lot of users to be
Does anyone have any idea how I can stop this being wrongly flagged?
If, as you stated, empty form applications get rated as virus, you might very well be infected by the Delphi virus. More info about this... thing:
http://www.delphipraxis.net/topic163041_virus+infects+delphi.html
http://www.viruslist.com/en/weblog?weblogid=208187826
Virus in Delphi 7
http://www.itwriting.com/blog/1717-delphi-developer-virus-exposes-weakness-in-anti-virus-defences.html
In addition, you use Delphi 7, which is a target for this virus (as far as I know not all Delphi versions are).
Delphi 2007: New VCL Application
Compile without changing anything and some antivirus packages will report the resulting EXE as a potential virus/trojan. Change the name of the main form or add a second form to the project etc and antivirus warnings disappear. Undo the changes and they come back (so it's not a D2007 port of the "Delphi Upgrade Incentive Virus").
My guess is that someone, somewhere once upon a time wrote a virus/trojan/malware with Delphi and the signature/heuristics associated with that now sometimes unfortunately collides with other Delphi apps.
I think you have two choices:
a) Submit your auto-update program as a false positive to all those companies, (and do so for any new versions that are detected). Make it easier for them by ensuring your meta-data is correct and signing perhaps.
b) Split up the functionality so you don't have a single Delphi program that downloads files from the internet, overwrites files and patches files.
It depends - if the 100s of users are on a corporate network, using the same enterprise antivirus software administered by group policy, one solution could be to specify your software as an exception in your antivirus package.
I would try to refactor the program, changing names, changing the order of the procedures and methods, some program structures, removing, replacing, and adding code.
Submit each change to VirusTotal.
You might eventually detect what is causing the problem.
If your program "modifies" an executable, it will be picked up by a lot of AV programs.
I've even seen Borland's patch program that was distributed with Delphi 7 flagged as a generic virus when installed fresh off the CD.
I'm not sure there is much you can do about it, unless you can turn that "feature" off in the AV program or have the rights to add an exception for it. Personally, I think it's just a lazy "catch-all" created by the AV software writers.
AV software also check the Import Table for common API used in viruses, though I don't see any API that will trigger the AV software in the scan report.
See my post at anyone having problems with delphi 2010 and norton internet security. Lately I have been getting SONAR errors too with Delphi 7 compiled programs (and by programs compiled with other compilers).
I reported this to Norton, look also at hot issues at Norton board.
Of course this is only Norton, you don't specify which virus checkers you encountered.
We got the same problem here...
Ant-virus detect some behaviors of our software too.
The ant-virus company doesn't say exactly what they watch (sure, security issue).
Here for example I got this problem when I started using pipelines.
What we did ? We call the security companies, they analysed our .exe, and now we have "white flag" on them.
...No, it isn't so fast process.
Related
I am a C# developer by trade, but have been tasked with making some changes to a Delphi desktop application. I have never used Delphi and I'm trying to identify the version of Delphi the application has been compiled with, and find a (preferably free) development stack/environment.
Looking at the source, there are a bunch of .DCU, .DPP, .DFM, and .PAS files.
There's a .DPR file that would seem to reference all of the forms.
In the .CFG file I found reference to
c:\program files (x86)\borland\delphi7\Projects\Bpl
Based on the above info, what tools should I use to design and compile this application?
That entry in the .cfg file is a clear cut indication that the project was most recently built with Delphi 7.
However, it may be more tricky to build this project than just to install Delphi 7 and press build. You may very well need to install a bunch of third party packages and libraries. In an ideal world there would be documentation on how to build, or at the very least, how to create a build environment. Sadly, you may not be living in an ideal world!
I'm trying to .... find a (preferably free) development stack/environment.
Well, Delphi 7 is not free. There are free Delphi like development environments, most specifically Lazarus. However, you would need to port the existing code, which is likely to be a non-trivial task. Especially if you have no Delphi experience.
It appears to be Delphi 7.
But the compiler version is only part of your problem, as several commentators have mentioned here. Unless they used only Delphi components, you're going to need to find the component libraries that were used, and that could be nearly impossible in itself. If it used any DLLs or BPLs, you'll need to find them as well, and possibly re-build the interfaces.
I'd spend some time trying to track down a backup that was made of the system that this software was developed on, as that's your best bet. It won't cost you anything assuming everything is still intact.
But trying to load up the source into D7, or anything for that matter, is going to be a total crap shoot unless you know all of the libraries that were used, how things were configured, all that good stuff.
It would be far more efficient for your company to just hire a Delphi expert for a day or so to dig into this for you than for you to waste a week or two of your time on something you don't know anything about.
In our program we are using a web service to pull back data from a third party into our program.
Ever since we updated to Delphi XE from Delphi 2009, Windows server 2003 users are receiving the following error message when making a SOAP call to the web service.
msvcrt.dll on Server 2003 does not have the procedure _ftol2_sse which is now being called for some reason..
I know this procedure was not being called when we had our source code on Delphi 2009 because I don't get this error on Windows server 2003 when running those builds.
Is this feasible? Could a change in the IDE affect which dll procedures are being called? Does anyone have any insight or ideas on how I might track down or fix this error?
Thanks
This is the third similar question you have asked on this topic. I'll attempt to give you some background information and help you work out what is going on.
First of all it's important to know that msvcrt.dll is a system component. It is not the MSVC runtime. It is supplied as part of Windows. Back in the bad old days, in the mid-90s, a lot of devlopers assumed that the MSVC6 runtime was always available. And they neglected to install that runtime as part of their program's installation. This occasionally caused trouble when the install program happened to find a machine without MSVC6.
The MSVC team moved to differently named runtime DLLs, msvcrt70.dll, msvcrt80.dll and so on. And they educated the developers that installing the MSVC runtime should be part of all MSVC application's installation programs.
But the Windows team wanted to help out legacy apps that had installers that assumed MSVC6 runtime was available. So they took the MSVC6 runtime under their control and started shipping it with Windows. I think this started around the time of Windows 2000 or XP.
The point I am trying to make is that msvcrt.dll is a system DLL over which you have no control. In your previous questions you have described your attempts to modify that DLL. Don't do that.
Now, from what I can glean, the version of msvcrt.dll that shipped with 2003 server does not export a function named _ftol2_sse. Hardly surprising since SSE floating point was not widely available back in the days of 2003 server. Clearly something in your system is resulting in an attempt to import _ftol2_sse.
You should be able to work out what is provoking this by using Dependency Walker. Use the functions on the Profile menu to start your application and study closely the logs. You should be able to see the chain of events that lead to an attempt to link to _ftol2_sse.
I'd be surprised if any of the Windows code linked to msvcrt.dll. That library is provided purely as a prop for legacy apps that link against MSVC6. But you never know.
Also try loading your executable in Dependency Walker. Look at the list of imported DLLs. Check to see if msvcrt.dll is in the list. If so, see what functions your executable imports, and if _ftol2_sse is in that list. If so then you'll be able to find it somewhere in the Delphi source code.
From the various similar sounding reports on the web I suspect that the problem you face is benign. Many of the people reporting the same issue can OK the dialogs and have their program continue without problem. This suggests that you can simply suppress the error reporting and so solve your problem. Use the SetErrorMode function to do so. You want to include the SEM_FAILCRITICALERRORS flag.
Be aware that SetErrorMode has a rather perverse interface. Almost all code that I have ever seen uses it incorrectly. Including the code in the Delphi RTL, and so many of the commonly used Delphi third party libraries. Raymond Chen, as usual, explains how to use it correctly.
Could switching compilers provoke the behaviour change? Certainly they could. Either the library code that you are using is implemented differently. Or perhaps the error mode is somehow different at the crucial moment.
I've just downloaded from SVN the DUnit2 code base.
Does someone has compiled it successfully?
What steps/prerequisites I've to follow in order to compile it?
Do someone knows if an already compiled version exists?
thank you
fabio vitale
In the projects directory, find the subdirectory corresponding to your version of Delphi. In it, you should find a project-group file, either DUnit2ProjectGroup.bpg , DUnit2ProjectGroup.bdsgroup or DUnit2Delphi<version>.groupproj. Open it and compile all the projects in order.
Using DUnit2 is pretty much the same as using DUnit.
In case someone else stumbles over this question while trying to make DUnit2 run on Delphi XE (or XE5):
TL;DR:
Dunit2 (official SourceForge source, revision 101) doesn't currently (being as of this writing on 2015-06-01) build successfully on either Delphi XE or XE5.
To make it build on XE or XE5, go get the patch I posted here
Apply it to the source tree. It should now compile and you should be able to open the .groupproj and build all the contained projects successfully.
The patch may be applied with and was created with TortoiseSVN (in case it matters).
Longer version:
Amazingly tonight (2015-06-01) I followed the same steps as Fabio (in 2012 no less) and ran into exactly the same issue (E2010 Incompatible types: 'Pointer' and 'Integer') trying to compile DUnit2 (revision 101 trunk checked out directly from SourceForge) on XE and XE5.
I've come to the following conclusions:
1) There's multiple issues with the head revision with respect to both XE and XE5.
2) The key issue above that Fabio mentions can be fixed by replacing IntPtr with Pointer.
This doesn't actually seem to make any difference in the code as far as I can tell, and the test suites also pass fine on both XE and XE5 after this change, though caveat emptor - I've not looked too carefully either (and also subject to caveats below.)
3) Project search paths being out of date [XE]. Just needed updating/fixing.
4) Missing $DEFINES for XE5 and others, despite some other code being quite aware of XE5
5) Some enhanced TRect stuff that's not available on XE. (The amount is relatively small and relatively trivial to inline to more basic expressions that will compile and is available on XE so was by no means show stopping.)
(Re 3,4 & 5 -- Sadly I get the impression the codebase isn't very well tested against multiple compiler/BDS targets.)
6) Some kind of Application.OnIdle/GUI testing bug (run T_TGUITestCase tests to see it) whereby the GUI automation tests would block unless you keep "feeding" the Windows Message queue by say moving your mouse or pressing the shift key to trigger Application.OnIdle events (repeatable on my Windows 8 XE5 and XE binaries).
Now speaking off the top of my head, and from vague memory from many years ago, I seem to remember having run into this before, and that it is down to a subtle change in behaviour either in Delphi or in Windows some time ago. -- IIRC in past, it used to be the case that one would would actually still get the occasional Application.OnIdle() call in your Delphi app even when nothing else much was going on on the system, even when you set Done to True. And as I recall, this changed at some point due to either a change in Windows or Delphi (can't remember which) several years ago and one had to be a bit more circumspect about setting Done to False if you didn't want your App to go to sleep entirely. In any case, it clearly was/is an issue on my PC tonight with the current (as of this writing) DUnit code, so I had to patch around it.
I did this in arguably a rather kludgy way, e.g. by manhandling things via providing an OnIdle handler while running GUI automation tests to signal that that the app is not in fact done (e.g. "don't block, don't go to sleep") and then reinstating any prior handler immediately after. There is no doubt a more elegant solution to this, perhaps by posting a message to ourselves to keep the app "alive", but my first attempt or 2 at something better didn't work out and I'm not interested enough to pursue this further. I'd be interested to hear of a better fix though.
I've supplied patches, but got no feedback from the DUnit2 team on SourceForge. So I forked DUnit2 with the full commit history into my Github account. I've applied many fixes there, including the compilation issues with XE & XE3+ and the scriptable self-tests that pause if no mouse action occurs. I'll continue my development of DUnit2 on my Github account [https://github.com/graemeg/dunit2].
I've been banging my head against this for the past two days and can't seem to make any progress...
Pretty much from one moment to the next, Delphi XE2 won't properly compile one of my projects any more. That is, it actually compiles without errors but at runtime I get resource not found errors for what is essentially the main "form" (it's actually a data module in this case). I have already reverted to older versions of the project from source control that I know were definitely working alright but to no avail. Judging by that it seems it must be something inside Delphi/the IDE itself rather than in the project source. However, I have also not been able to reproduce the issue with a simple test project nor with any other real-life projects... It only happens with this one.
Another strange thing is that when I look at the produced binary with XN Resource Explorer everything looks as it should: The form resource mentioned in the error message is actually there and intact...
At some point I was suspecting this might be caused by a bug in one of the experts I have installed in my IDE (e.g. Uwe's platform and OI experts and VersionInsightPlus, Andreas' IDEFixPack and DDevExtensions, GExperts) but even after disabling all these the problem persisted.
Unfortunately, I am unable to track down exactly when this started to happen as I had been working for some time without actually running the binary, fixing compiler warnings and errors for the x64-target, adjusting build events for updated third-party tools (localization and license protection) and such things...
Has anyone else ever seen anything like this happen? Any more ideas on how to pin this down?
Some more details about the project:
It is an addin for Outlook built using the Add-In-Express framework (i.e. a COM-DLL).
The "main form" is a TDataModule-descendant - we also inserted our own ancestor-class into the hierarchy, i.e. the "addin module" is not directly inheriting from TadxCOMAddInModule - the resources of the custom ancestor forms also appear to be present and intact in the output binary when checking with a resource viewer.
Built without runtime packages for the Win32 and Win64 platforms.
Let me know if you think I missed to mention any other potentially relevant details.
Update:
I have now transferred the sources in question onto a different machine. Interestingly, the DLL I compiled there did not exhibit the problem - on that machine that is... when I transfered it back to the original machine and I tried to call it, the error was back (to stress this: this was the exact same DLL producing a EResNotFound on one machine but not on the other. Of course, once I had discovered this, I also performed the reverse test and lo and behold, the DLL compiled on the original machine works without errors on the other machine...
Seems this might not be a Delphi problem after all... but what is it then?
Differences between the two machines:
Machine 1 (the one were the problem occurs): Windows 7 Ultimate English 64bit with Delphi XE2 Update 4
Machine 2: Windows 7 Professional German 32bit with Delphi XE2 Update 3
On a third machine that is almost identical to the first except that it doesn't have Delphi on it, DLLs produced by both machines work flawlessly.
I am a bit surprised to see your question here. :)
We faced a number of serious issues with recent Update 4 for Delphi XE2. Though we have never run into or been reported of the "resource not found" error, I think this update might be one of the causes. Have you installed it?
One more thing that comes to my mind is images that you use for your Office controls (command bar and ribbon). Probably they got broken somehow, the run-time code cannot load them and reports this error.
Anyway, as you understand, these are just my guesses, if you need our assistance with your office add-in please contact Add-in Express support service, we will try to help.
Update: Seems I was a bit too quick, drawing conclusions. Apparently the Sisulizer solution is also supposed to perform a fallback to the main resource block. I have now taken this issue to the product forum and will report back here, once this is resolved.
Alright, mystery solved at last:
I had turned off the option to "Copy all resources" in Sisulizer in an attempt to reduce the size of the produced resource DLLs and then had forgotten about it...
I hadn't fully realized the implications of the standard Delphi resource DLL approach to localization on which Sisulizer "piggybacks" - especially that it was an all-or-nothing deal: Our previous translation solution implemented a fallback-mechanism that would read any resources not found in the external resource DLL from the host binary instead. This does not appear to be the case with Sisulizer - at least not out of the box... thus, any resource that's not contained in the localized resource DLL does not exist as far as the application is concerned.
I also didn't realize that the mere existence of a file with the same base name as the main binary and an extension matching the current system's default locale (such as .EN or .DE) would automatically cause the VCL to load it...
The machines that did not exhibit the error either still had the older, larger (=complete) resource DLLs on them, or no resource DLLs at all.
HI:
I've a Delphi 7 program that I wrote many years ago, but I've lost the source code. It's a small program but very useful for me.
I've tried to 'install' it again in a new Windows XP computer, just copying the folder with de data (.db paradox files), and configured the BDE connection.
When the programm starts I receive an "Unknown exception" and halts. I've no idea why this happens, and can't debug cause the lost source code. I've tried in another computer with the same results.
Any suggestions or ideas? What do you do in a situation like this?
Thanks in advance.
EDIT:
When I installed Delphi 7 in the new XP computer, the exception came from unknown to known. It was something related to the folder for the Paradox.net file. Thnk you all.
Delphi IDE can attach to a running process and debug it (Run -> Attach to process), although without debug symbols you will end up debugging plain assembler code, which requires some knowledge of assembler and how a Windows application works. And debugging startup exceptions could be pretty difficult if the debugger can't start the program. You can also use the WinDbg debugger from Microsoft.
There are disassemblers (I used the very powerful IDA Pro) that are able to recognize standard library calls helping analysys a lot. You may also find decompilers, although decompiling native applications is a bit more difficult than with those using a p-code or the like.
If the error is not due to a misconfiguration, patching a binary file is not easy.
You can use any debugger, either Visual Studio one, or a free OllyDbg, don't know if Delphi IDE have a simple external-exe-debugger.
But debugging will be very hard w/o source codes, and you must have at least basic knowledge of Assembler Language and win32api.
Alternatively you can use tools like FileMon & RegMon to examine your app activity and find potential problems.
You can try "Run|Connect to process..." in the Delphi IDE. But what zed_0xff said regarding debbugging without sources still applies.
I would go for the disassemble approach like ldsandon suggest, especially since you have (some) knowledge about what your exe is doing.
Besides IDA Pro also take a look at tools aimed specifically at Delphi such as IDR (Interactive Delphi Reconstructor), DeDe and PE Explorer.
To make sure it is not BDE related, I would build another rudimentary application trying to access the same data on this machine.
Once this application works, you can move on to test on the Pascal code side of things.
I have had my share of BDE oddities so I'd prefer to rule this out.