I have been working on VS Code early this early untill last month when I faced this issue of not compiling and running my code due to some security threat given by McAfee
Here are the image attachments
I don't what is causing this problem, if anyone could help me it would be a lot of beneficial since I have many assignments and I don't like online editors that much
Probably as you are compiling code (generating binary files) McAfee thinks you are generating malware (as an attacker would do) preventing it to complete, why don't you just temporarily disable the AntiVirus and test?
Related
The Basics
So I've been working with Xamarin a decent bit recently, and am looking for a solution to a current problem. I've been using the WoWonder script recently, and launched it on a site. i can confirm that the site is working well, without any hiccups. Although I've reworked some of the UI / UX, and basic functionality, I haven't delved extremely deep into it.
I'm currently using the Mobile Timeline applications to link into the network. I've had to debug a decent amount of problems so far with the NuGet packages, syntax errors, as well as authentication / decryption errors. I solved the first two, and solved the last by switching the SSL & TLS options in the Android Options area.
I would normally seek help from the author of said project, but given people in the comments haven't always gotten their answers, and instead got the runaround (Not to mention the broken english), I thought Stack would be the better option.
So far, I've asked around, and looked around, but haven't found anything. This is my last attempt before I start breaking everything down, line-by-line. I haven't found anyone else having a similar problem, other than the Xamarin > WP8 issue.
The Problem
Screenshots:
https://1drv.ms/u/s!Aub_kvZQCqk8ii7fW8ntcn4dxh-W
https://1drv.ms/u/s!Aub_kvZQCqk8ii9Ksd86tPIHLXMo
SideNote: The project does use 'Xamarin Components," and the syntax / order of things is a mess. It's nothing that breaks anything or issues too many warnings, it just parses a lot that it can't find, or isn't relevant / needed / is outdated.
Edit:
It's difficult to copy the context of the error in the emulator, since it doesn't seem to be showing up in visual studio. I'll transcribe it below.
Code Snippet:
System.Net.HttpRequestException: 500 (Internal Server Error) at System.Net.Http.HttpResponseMessage.EnsureSuccessStatusCode()[0x0002a] in <dcbf7ae3bce147228fa58d5bc31257ae>:0 at WowonderPhone.MainPage+<OnLoginClicked>d_2.MoveNext()[0x00252] in <1284583bda884ff38ca175979b310f47>:0
This has since been fixed. It was a problem on the server side, but had to do with the script, as the person previously mentioned. It wasn't a problem with Apache directives, or heightened security, just an inconsistency in the script syntax. Unfortunately, since another person solved this directly, I don't know the exact margin of error.
I have an issue I don't seem to find a solution for.
One of the transactions gives ABEND ASRA when used in debug mode.
When I compile the Cobol program without debug option and run the program, it works fine.
The error looks like this one (quite exactly like this), only I am using Cobol V4:
http://www-01.ibm.com/support/docview.wss?uid=swg1PM96501
Now the question would be: why is it abending in debugger and not without debugger?
I am using the CICS debugger (DTCN transaction), the program starts normally, I can do steps with F2 and all this, then at some location is abends.
Please note that it is extremely difficult to say where it abends as the program is really big.
This happens only to this program at the moment, others are running fine with debugger. I placed a breakpoint before my modifications, the abend occurs in some other area.
Another weird thing is that this Abend is not consistent, If I do a big portion of the code with small steps (F2 and small breakpoints), sometimes it executes without abend until the end.
Due to the nature of the issue, I can not post much information.
I was hoping you encountered similar issues and you can tell me where to look for.
Thank you!
The issue was solved by deleting my debug tool profile form the system and then login to the debugger (DTCN) again so it creates a new profile (the profile was 3 files: TOOLTEMP.PDTOOLS.{userid}.DBGTOOL.* ). After this the issue was gone. I asked the guys how this happened, they told me this was because I had modified the program between 2 debugging sessions without closing CICS. This was a disfunction that can be avoided by closing CICS while we compile programs used in it (not sure about why exactly.... neither are they).
Hope this helps if you face a similar issue with DTCN debugging.
When I compile my Win32 Windows Application my antivirus thinks it is a virus and removes exe file, I have to turn off antivirus every time to compile project.
How can I solve this problem?
I think this is in the description, and I have to set manufacturer name.
There are various patterns in programs that let it be recognized by a scanner as a malware. This is heuristic scanning: the scanner doesn't recognize your program, but things it tries to do: API calls, certain ways or areas of memory or filesystem access, and so on.
Classic examples consist of reading Outlook's address book and trying to read or execute certain file paths.
I think this is in the description, and I have to set manufacturer name.
So, what happens if you don't set the description (what is "the description" by the way)? Does the executable then not get deleted? There's your answer.
Anyway you will have to analyze why and when the virus scanner removes your executable. Compile your program partially, leaving out significant parts can help deduct which part is causing trouble, and reading the source might just point out why.
Just an anecdote:
Few years ago I was playing with TCC. When I compiled one of the example programs, a simple Win32 program with a window, my antivirus removed the exe. It turned out that it was enough to change the name of the window class to solve the problem. (I don't know whether the current version of that TCC sample code is detected as a virus or not.)
Maybe your case can also be solved with a similar small change, without turning off the antivirus. Good luck :)
I wrote a download manager (in the AutoHotKey language) for a client and it gets flagged by a minority of virus scanners (11% of the scanners used on VirusTotal) as being a trojan, malware, dropper, data stealer, etc. Since my software is none of those things I'd like to correct the erroneous flagging by these scanners. Has anyone dealt with this sort of problem before?
The real complication here is that since this is a download manager the actual signed binary I am delivering is different for each of thousands of downloads, so it's not practical that I could request each and every unique version be white listed or something.
I'd prefer not to try and use actual cloaking techniques to try and fool the anti-virus companies when I really have nothing to hide, but I'm not sure there is another choice (and I'm not sure I'd be successful). Any advice?
Trik has provided the following answer on the forums:
In the AutoHotkey folder (Held in
ProgramFiles) there is a sub folder
named 'compiler' in that folder is a
file named 'upx.exe' rename that to
something like upx.old (or any other
file extension). That should solve the
problem.
Please comment on whether this worked or not.
I'm answering my own question here, and sadly providing a less than satisfactory answer, but it seems the only one available...
From what I've found there is no way to prevent some anti-virus programs from falsely flagging Auto Hot Key, AutoIt, and other scripted/interpreted code. I tried numerous approaches and nothing worked.
The best approach seems to be to avoid using Auto Hot Key, AutoIt, etc. if you can, and if you must then use VirusTotal on the setup file you're planning to release in order to understand what warnings your potential users will receive. In my experience of the 40+ virus scanners that are used by Virus Total only 1-4 generally see an Auto Hot Key included code as suspicious, and those are typically unpopular, unfamiliar virus scanners which likely err on the side of caution because doing so requires fewer resources (in terms of their own manpower, in coding and signature use).
I am trying to help a client with a problem, but I am running out of ideas. They have a custom, written in house application that runs on a schedule, but it crashes. I don't know how long it has been like this, so I don't think I can trace the crashes back to any particular software updates. The most unfortunate part is there is no longer any source code for the VB6 DLL which contains the meat of the logic.
This VB6 DLL is kicked off by 2-3 function calls from a VB Script. Obviously, I can modify the VB Script to add error logging, but I'm not having much luck getting quality information to pinpoint the source of the crash. I have put logging messages on either side of all of the function calls and determined which of the calls is causing the crash. However, nothing is ever returned in the err object because the call is crashing wscript.exe.
I'm not sure if there is anything else I can do. Any ideas?
Edit: The main reason I care, even though I don't have the source code is that there may be some external factor causing the crash (insufficient credentials, locked file, etc). I have checked the log file that is created in drwtsn32.log as a result of wscript.exe crashing, and the only information I get is an "Access Violation".
I first tend to think this is something to do with security permissions, but couldn't this also be a memory access violation?
You may consider using one of the Sysinternals tools if you truly think this is a problem with the environment such as file permissions. I once used Filemon to figure out all the files my application was touching and discovered a problem that way.
You may also want to do a quick sanity check with Dependency Walker to make sure you are actually loading the DLL files you think you are. I have seen the wrong version of the C runtime being loaded and causing a mysterious crash.
Depending on the scope of the application, your client might want to consider a rewrite. Without source code, they will eventually be forced to do so anyway when something else changes.
It's always possible to use a debugger - either directly on the PC that's running the crashing app or on a memory dump - to determine what's happening to a greater or lesser extent. In this case, where the code is VB6, that may not be very helpful because you'll only get useful information at the Win32 level.
Ultimately, if you don't have the source code then will finding out where the bug is really help? You won't be able to fix it anyway unless you can avoid that code path for ever in the calling script.
You could use the debugging tools for windows. Which might help you pinpoint the error, but without the source to fix it, won't do you much good.
A lazier way would be to call the dll from code (not a script) so you can at least see what is causing the issue and inspect the err object. You still won't be able to fix it, unless the problem is that it is being called incorrectly.
The guy of Coding The Wheel has a pretty interesting series about building an online poker bot which is full of serious technical info, a lot of which is concerned with how to get into existing applications and mess with them, which is, in some way, what you want to do.
Specifically, he has an article on using WinDbg to get at important info, one on how to bend function calls to your own code and one on injecting DLLs in other processes. These techniques might help to find and maybe work around or fix the crash, although I guess it's still a tough call.
There are a couple of tools that may be helpful. First, you can use dependency walker to do a runtime profile of your app:
http://www.dependencywalker.com/
There is a profile menu and you probably want to make sure that the follow child processes option is checked. This will do two things. First, it will allow you to see all of the lib versions that get pulled in. This can be helpful for some problems. Second, the runtime profile uses the debug memory manager when it runs the child processes. So, you will be able to see if buffers are getting overrun and a little bit of information about that.
Another useful tool is process monitor from Mark Russinovich:
http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx
This tool will report all file, registry and thread operations. This will help you determine if any you are bumping into file or registry credential issues.
Process explorer gives you a lot of the same information:
http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx
This is also a Russinovich tool. I find that it is a bit easier to look at some data through this tool.
Finally, using debugging tools for windows or dev studio can give you some insight into where the errors are occurring.
Access violation is almost always a memory error - all the more likely in this case because its random crashing (permissions would likely be more obviously reproducible). In the case of a dll it could be either
There's an error in the code in the dll itself - this could be something like a memory allocation error or even a simple loop boundary condition error.
There's an error when the dll tries to link out to another dll on the system. This will generally be caused by a mismatch between dll versions on the machine.
Your first step should be to try and get a reproducible crash condition. If you don't have a set of circumstances that will crash the system then you cannot know when you have fixed it.
I would then install the system on a clean machine and attempt to reproduce the error on that. Run a monitor and check precisely what other files (dlls etc) are open when the program crashes. I have seen code that crashes on a hyperthreaded Pentium but not on an earlier one - so restoring an old machine as a testbed may be a good option to cover that one. Varying the amount of ram in the machine is also worthwhile.
Hopefully these steps might give you a clue. Hopefully it will be an environment problem and so can be avoided by using the right version of windows, dlls etc. However if you're still stuck with the crash at this point with no good clues then your options are either to rewrite or attempt to hunt down the problem further by debugging the dll at assembler lever or dissassembling it. If you are not familiar with assembly code then both of these are long-shots and it's difficult to see what you will gain - and either option is likely to be a massive time-sink. Myself I have in the past, when faced with a particularly low-level high intensity problem like this advertised on one of the 'coder for hire' websites and looked for someone with specialist knowledge. Again you will need a reproducible error to be able to do this.
In the long run a dll without source code will have to be replaced. Paying a specialist with assembly skills to analyse the functions and provide you with flowcharts may well be worthwhile considering. It is good business practice to do this sooner in a controlled manner than later - like after the machine it is running on has crashed and that version of windows is no longer easily available.
You may want to try using Resource Hacker you may have luck de-compiling the in house application. it may not give you the full source code but at least maybe some more info about what the app is doing, which also may help you determine your culrpit.
Add the maximum possible RAM to the machine
This simple and cheap hack has work for me in the past. Of course YMMV.
Reverse engineering is one possibility, although a tough one.
In theory you can decompile and even debug/trace a compiled VB6 application - this is the easy part, modifying it without source, in all but the most simple cases, is the hard part.
Free compilers/decompilers:
VB decompilers
VB debuggers
Rewrite would be, in most cases, a more successful and faster way to solve the problem.