After checking the code of inetc.dll, I see that the call to win32 wininet HttpOpenRequest is triggering a HEUR:Trojan-Downloader.Win32.Generic. I'm using inetc to download a part of the installation based on the user's os config to allow a smaller installer. Are there any way to avoid this false positives? Are there any other alternatives to inetc that don't get flagged?
It is common to see false positives for both INetC and NSISdl, report it as a false positive and the problem should go away...
Related
I note that when cygwin's setup.exe installs packages now, it looks for a file named "setup.zst.sig" first. What's the content and format of this binary file? How to produce a valid "setup.zst.sig"?
This must have been a recent change. Previously it looked for "setup.exe.sig" first. I use the feature (to detect whether "setup.exe.sig" changed) to decide whether my cygwin installation needs to be updated. See also this for an application example.
EDIT: #matzeri:
setup.zst.sig is not yet used.
The "zst" functionality was introduced in the program to eventually replace the
previous compression methods of setup.ini and the packages
const std::string setup_exts[] = { "zst", "xz", "bz2", "ini" };
For checking the update of setup-ARCH.exe you need to use the standard signature.
https://cygwin.com/setup-x86.exe.sig
https://cygwin.com/setup-x86_64.exe.sig
The pop up you shows seems to happen only on FTP mirror server, the HTTP servers
do not produce it.
It is clearly a bug in setup
https://cygwin.com/ml/cygwin/2019-02/msg00153.html
According to the documentation, the .sig files carry a SHA-512 hash of the respective file without that extension, signed with the private key available only to Cygwin the company.
https://www.cygwin.com/faq.html#faq.setup.install-security
I'm working on a python (3.5) program that use a PyQt5 GUI. In the GUI, I need to add some help links to the documentation on a website. I manage to make it work with:
QDesktopServices.openUrl(QUrl("my_url"))
It works fine but I want to be sure that it will always be the case.
A quick and dirty unittest is to call the function and simply notice that there is no error. I would like to make a test that will check that the correct website page did show up. What should I use?
Checking for an error is not going to work at all, because Qt itself never raises errors (of course, Python or PyQt might do, but for completely unrelated reasons). The best you can do is check the return value of openUrl, which will simply return True or False depending on whether it was "successful". But note the following from the Qt docs for openUrl:
Warning: A return value of true indicates that the application has
successfully requested the operating system to open the URL in an
external application. The external application may still fail to
launch or fail to open the requested URL. This result will not be
reported back to the application.
If you want more control, I suggest you use Python's webbrowser module instead. This would, for example, allow you to register your own mock-browser class for the purposes of testing. The webbrowser module is written in pure Python and the code is quite straightforward.
I use Comodo antivirus scan my mac and found that there are some threads.
All are marked with name:
UnclassifiedMalware#290428014
for file
string-replace-gc.js
Just wonder if Comodo makes mistake or there is something infects V8?
Your comment welcome
It's a test that doesn't even get executed normally.
So I'd bet it's a false positive. You can compare that with github if you want.
Greetings people,
My Windows Store game has been released for more than three weeks now, and I started getting crash reports. I could download the TriageDump.dmp file and have it opened in Visual Studio 2012, but it did not help much, I am constantly getting "No Debugging Information" error message when I click on "Debug with Native Only":
Also, the tool-tip on my Dashboard shows no information of the crashing function (could "Unknown" here mean inlined function or lambda expressions in concurrent::task?):
I would like to believe that I have done everything the way it should be done, of course I may be wrong. Here are some additional information that might be helpful in finding the issue:
It uses DirectX and written purely in C++ (without C# or XAML)
Project setting: C++\General\Debug Information Format = Program Database (/Zi)
Project setting: Linker\Debugging\Generate Debug Info = Yes (/DEBUG)
The game is made up of two native modules: Labyrinth.App.exe and Labyrinth.Core.dll
The generated APPXUPLOAD contains both APPX and APPXSYM files
The APPXSYM file contains both Labyrinth.App.pdb and Labyrinth.Core.pdb
I'm on x64 development machine, and the triagedump.dmp is for x86
I did click on "Include public symbol files, if any, to enable crash analysis for the app" when generating APPXUPLOAD file:
Please let me know if you spotted the issue or suspected something that's wrong above. Thanks in advance for your help, guys! :)
The very same problem here. MS had that working in the past though.
Actually if you still have the .appxsym around you can easily extract the .pdb out of that. The appxsym is just a .zip file it seems.
You can load these pdbs then as symbols after loading the triagedump.dmp.
(I'm using InstallShield2012 V.18)
In setup.rul I defined a function per prototype declaration, included the file with the function definition and compiled it successfully (InstallShield compile).
Now I'd like to test this function (only).
I don't want to run the whole installation, not even test (Ctrl-T) because I want to avoid a complete re-build which takes too long time to do it often.
Is there a way to test only the custom function in InstallShield or per command line?
Not really although I can give you some tips.
Create a dummy feature with a release flag of DEVONLY.
Create a dummy component for that feature.
Create a ProductConfiguration that builds a single MSI with no EXE and a release flag of DEVONLY.
Building this production configuration will be very fast. A couple seconds on my laptop with an SSD. You can selectivly include other features through the use of release flags if you need certain components in order to setup the test environment for your CA.
Another strategy is to develop your CA in a test harness project and then transplant the code into your real installer when you know it all works.
Christopher, thanks for this fast reply. I have to put my answer here because commenting was restricted, because too long.
I also thought about using such a workaround but first wanted to avoid it if possible.
But ok, now I tried these steps, 1 and 2 no problem, but 3: InstallShield didn't allow me to configure a Product Configuration without Setup.exe in my .ism file (although we have IS2012 Pro).
Then I tried to do it in a Basic MSI Project (is that what you meant?), which really builds in very short time. And now I can see my scripting during Test Release, yeah :-)
To "transplant" my script now to the main ism I'm missing an export function for .rul files as it exists for custom actions, but there is only a import. So I will have to copy-paste while switching between ism files, but never mind.