One message in my inbox has attachment with a zip file. Inside zipped file is file with extension ".pif".
After opening file in hex editor I see that file is PE. Apparently someone added some code inside.
Gmail detects virus inside attachment.
I created virtual machine with Windows XP. I tried to run virus but nothing happen.
I'm really curious how does this virus work.
Can I identify in which language virus was written?
Is there a way to decompile or disassembly code inside ".pif" file?
Is there a ways to determine what is the name and type of virus?
Related
I have a delphi project that somehow has become corrupted. I upgraded to Advantage 11.1 components (using XE) and now I'm getting the following error message when opening the project:
acctTbl: Error 5018: The handle given was not recognized by
Advantage. Verify specified handle is open/active. The given handle
is not recognized as a valid Advantage Client Engine
Because the error occurs, the data module DFM is not built, so I can't "adjust" any settings.
acctTbl is the first table in the DFM, so the error might occur for the ones following, but I can't tell.
We are not using the server, just the "Local Server".
I have tried to go back to version 10 of the components, but still the error continues.
I have also tried removing all of the projects object code and only opening the PAS and DFM files (by reverting from SVN).
Any help is greatly appreciated.
You can open the .dfm in a text editor (like Notepad), and change the AdsConnection.Connected property to false, and change any AdsTable or ADSQuery component's Active flags to false as well. (I'd suggest closing the IDE first, to make sure it doesn't cache a reference.) This will at least let you open the project and make whatever changes are needed to compile with the new version of ADS.
If the file has been updated through many older versions of Delphi prior to XE, there's a chance you still have a binary format .dfm file (meaning you'll see all kinds of strange symbols in Notepad when you open the .dfm file). If that's the case, Delphi includes a conversion utility (convert.exe, found in your $(DELPHI)\Bin folder), and you can use the following steps to convert it to text format and then make the changes (there's no need to convert it back after - the default is to create text .dfm files when new forms are created, and Delphi uses them very well as text).
Make a backup copy of your datamodule's .DFM somewhere safe first!
After making the backup copy, open a command window in your project folder, and run
Convert.exe -1 YourDataModule.dfm
The command says to convert in place (-i), which means the existing binary .dfm is overwritten by the new text .dfm (and the reason I stressed making a backup copy first). If you don't want to overwrite, you can omit the -i switch, and it will create a YourDataModule.txt file in the folder instead; you can then manually rename YourDataModule.dfm to a different name, and then rename YourDataModule.txt to YourDataModule.dfm.
Delphi 6 Prof.
We have many applications. The programs have 8-12 MB size.
In this period we many times got reports about "Invalid stream format" errors.
We use shared Windows (or Linux) folders to store the applications, and users running them from these directories with links.
This meaning that OS is paging the files, and loading the needed parts only.
Formerly we got C000006 exceptions.
As I know this meaning that the file paging (loading) failed on any network problem (timeout, etc).
Now we face with "Invalid stream format" errors, and "invalid property xxxx" errors.
If I know well, both error caused by "paging problem", but C06 happens in code, and stream error in the data area of the Exe.
But maybe I know wrong...
Anyway the problem is strange. Sometimes we got it, sometimes we not.
How to avoid it? These errors prevents the users to create new dialogs, to use the programs...
(In other place the user used wifi - then we got same side effects.)
Maybe you have any idea how to prevent, avoid this problem.
UPX (vs. Antiviruses)?
Copy the exe-s to local place?
The system administrators of this customer are "our enemies", because they said: "everything is ok". The source of the problem isn't identifiable...
Thanks for every idea: dd
Assuming your analysis is correct, and the problem is that the executable is located on a network drive with a flaky connection, then there is a solution. You need to add PE flags to your executable that forces Windows to copy the file from the network to the local machine before running it.
Make sure that your .dpr file's uses clause includes the Windows unit. And then add this line:
{$SetPEFlags IMAGE_FILE_REMOVABLE_RUN_FROM_SWAP or IMAGE_FILE_NET_RUN_FROM_SWAP}
just before the begin in your .dpr file. We added the Windows unit so that the two constants would be recognised.
Another possibility could be to pack the exe with upx tool for instance.
http://upx.sourceforge.net/
It will expand the whole file in memory before run.
And it will save bandwidth.
Convert might be the wrong word, but to save a user having to install something I wondered if a small EXE can be embedded in a web-page (IE only) using ActiveX so it is run when a button is pressed. Obviously a big security hole but is it feasible?
Urgh, just thinking about it makes me die a little inside.
But yes, package up the exe and the activex in a cab file and use the activex to launch the exe.
Info on packaging up ActiveX cab files is here: http://msdn.microsoft.com/en-us/library/aa751974(v=vs.85).aspx
A bit more information on Inf files (specifically the DestDir bit): http://msdn.microsoft.com/en-us/library/aa741215(v=vs.85).aspx
This would allow you to put the exe in a known location (Windows or System) so that you could execute it from the activex control providing permissions were set correctly
I am testing one application that handles files (stored in SQL Server using FILESTREAM). It is a Delphi 32bit application.
Opening an XLS document stored in the database (originally saved with Office 2003) gives an error from Excel 2010 64bit. Is there some known compatibility issue of Office 2010 64bit with 32bit applications?
Error messages and workflow
When opening the file Excel gives one of the following error messages:
Impossible to open the file FILE because of problems in contents
Impossible to open the file because some parts are missing or not valid
Opening a file on machine A with Office 2007 opens the file with no problems. Opening the same file on machine B with Office 2010 produces the error message. Opening again on machine A there is also an error message! In all these steps I am just reading from the database, not writing. So why does this can happen?
How do I open the documents?
SELECT query to get 'DOCUMENT' varbinary(max) field for the specific ID_Document.
Extract from database using
TBlobField(sqlQuery.FieldByName('DOCUMENT')).SaveToFile(sDestinationPath + FileUniqueName + .zip');
Copy file from one path to another using Windows.CopyFile
Unzip file using TZipforge component
Set attribute of unzipped file to ROM using FileSetReadOnly function.
Open document using ShellExecute(0, 'open', PWideChar(FIleName), '', '', SW_SHOWNORMAL);
As you can see there is nothing that writes back to the database. Once the file is extracted from TBlobField it is even copied to another place before unzipping and opening it.
Possibly broken installation
Office has been reinstalled and now everything works, the problem of corruption was due to a conflict with an open Office installation that asked "do you want to fix the office installation?". Anyway the problem still remains, because I cannot understand what happened. How can I corrupt a file in the database if I extract it in a folder and open it from the folder without writing anything back to database?
Office 2010 64-bit should have no problems with files created with its 32-bit version. The files (.docx, .xls) are bitness independant.
I have some questions:
How do you open your files?
Can you show some code?
Are you sure that you are only reading the file from the database?
Do you give your files the right extension? Saving a .xls as .xlsx will cause problems when opening the file.
Check if your SQL server database is corrupt. Check disk where database is for errors. Reinstall SQL server.
Solved: it was a bug in my program. There was an error in the logic that persisted the document status and by mistake sometimes Is_File_Compressed was set to False, even if it is true.
Thanks for the support.
I'm using the IdFTP (Indy 10) component to download some files (zip and txt) from a remote location. Before getting each file I set the TransferType to binary.
IdFTP.TransferType := ftBinary;
IdFTP.Get(ASource, ADest, AOverwrite);
I expect that both text and binary files can be downloaded using the binary mode. However it looks like text files contents is messed up while zip files are downloaded correctly. If I set the TransferType to ASCII for text files it works as expected. How can I detect which TransferType to set for a given file? Is there a common denominator or auto setting?
I don't see how the Binary flag can mess up transferred files. Binary type means the server transfers the files without any processing, as is.
The only thing that an FTP server should use the ASCII flag for, is to correctly handle the end of line in text files, usually (1) either only Line Feed in Unix or (2)Carriage Return + Line Feed in Windows. But nowadays most text editors handle both in either system.
So the safest is use only ASCII flag for very well known text files, probably only files with a .txt extension, and use Binary flag for all the others.
When in doubt, rule it out (!) - try transferring the files from the server using the Windows commandline FTP program, and see if text files still come out wrong. The program will transfer binary (command BIN) or text (command ASCII). If you transfer files with this and they still arrive differently to your expectation, then something is being done at the server end*. If they arrive fine, then either you (or Indy) are doing something. :-)
*In what way are the text files messed up? If you're transferring unicode text files, you might be better off transferring them as BINary anyway. I must admit that, as #unknown (yahoo) said, in most cases you should probably stick to BIN mode.
I guess it would also depend on how you are viewing the text file, ANSI or WideChar as to whether the text is messed up or not.