Okay so I just made a C++ program that is basically a notebook,
you write stuff in it and it saves it to a .dat file and then you can
read it later.
I compiled it with Microsoft Visual C++ and now I sent it to a friend and it's
saying that it is a virus? I scan it online and it also says that it's a virus.
I don't know why this is happening, as I literally just used some if/else statements, created some strings and used a couple getlines. (and fstream to create the .dat files).
This is the virus report: https://www.virustotal.com/en/file/a1b72280a32915429607fd5abeef1aad4f8310867df1feb7707ea0f7a404026e/analysis/1455735299/
Here is my code. (Its 400+ lines). And I'm almost certain there's nothing wrong
with it. http://pastebin.com/ZwJZrRSu
Any idea why this is happening?
Most probably your PC is already infected by a virus, which adds itself to any executable it can find on your machine. That would easily explain this behavior. Try to compile the same program on PC that is clean for sure and check your PC by antivirus.
I am not sure but I think it because you imported kernel32.dll
Again, it is hard to tell without the source
Also take a look at the file detail in the report
Related
In the Xbox 360 game Project Sylpheed: Arc of Deception. There are secret sub objectives for each level. On stage 11 "Flaming Clouds" there are 4, I have found two sources claiming they know each of them, but is actually untrue. One is still hidden. This is a very unpopular game, and no one has investigated it, and I want to know what it is. I have a disk image file of the game (ISO file). How would I go about finding the level trigger for the sub objective? I have already attempted to extract the 7gb iso using 7zip and Winrar, but each yielded the same 12mb files that contain nothing relevant what so ever. Obviously the core of the information is hidden and remains unextracted. Please advise.
https://wincdemu.sysprogs.org/ or linux/mac mount -o loop /path/to/my-iso-image.iso /mnt/iso
from there you're going to need a reverse compiler probabably but I don't know what your game is written in. You might luck out and find the levels coded in lua or something though.
Something else that can be happening is 7zip is actually opening the iso right, and the 12mb could be instructions to go download the actual game code from somewhere else. That sometimes happens with consoles.
Does anyone have a clue what could cause a breakpoint not to show the actual place of the code in a specific file?
This is the second time this has happened to me.. maybe someone could help, my parameters:
I am working in visual studio 2010.
This one specifically is a static lib but it also happened to me inside dll's.
The PDB's are generated in Z7, although this has also happened to me in the default pdb generation.
I am sure the code is compiled with the correct lib(also happened in dlls so..)
Also I have some Doxygen comments I first suspected causing this problem(could it be?)
Attached is an image that show where the breakpoint arrow is compared to the callstack of where it ACTUALLY is..
Thanks!
If you debug code that has optimization enabled, the method might just be inlined. This is at least one proven source of breakpoints not pointing to the right position.
One of the scenario's which I have generally noticed is when source file changes due to fetch of a file from source control while debugging. Break point uses the line number of older code.
So, apparently the visual studio text editor doesn't adapt well to CR..
I found that the file had some CR (and not CRLF) and that confused the compiler all together..
When I actually made a compile error on purpose, it didn't even point to the correct line...
So I added LineFeeds(LF) after every CR and it compiles fine...
(Used notepad++ to detect where it was missing but I'm sure VS has a way as well..)
Cheers.
I just downloaded this code in which it says in the manual that the 'main results are directed to standard output (cout)'. However, when I run the code as described in the manual, everything runs just fine but I don't see any results showing on the terminal (not being written to an output file either)
This is a Linux code so I tried to run it form both Ubuntu terminal and from cygwin but I'm having the same problem - nothing is showing.
Could it be that 'the main results are directed to a standard output (cout)' means anything else? Other that it's supposed to show the results on the terminal?
There's no other meaning that I can think of for "standard output (cout)" - it should be the terminal that's running the program. Are you sure the program produces output?
Unless you have the source code, it's a little difficult for you (or us) to tell if it may have another meaning ("directed to standard output (cout)" is a little hard to misinterpret however, there's no other sane reading of that snippet).
If you do have the source, you can look for the cout <<-type statements to ensure something is done. You may have to examine the logic closely to see why nothing is being output for your specific case.
If you can share the source with us, we could help out further but it doesn't appear you're comfortable with that so the "analyse the code yourself" is probably the best answer you'll get.
Of course, there's always the option of going back to the author if your analysis is not going well, or if you don't have the source.
Ensure that there is no "wrapper" script encapsulating the program, which is internally redirecting the standard output to a file.
This is the first time I am writing in this forum, I hope someone could help me. I have been searching on the Web but have not found any answer related to my question.
I have a very large file (about 25000 lines) with thousands of definitions that must be used by another file
All these files (and about 600 more of them) are converted to .c files using a special tool. I am almost sure this conversion is made propertly.
If I create a.exe with all these files, there is no problem and everything works all right. Unfortunately, I need a .dll which crashes when I try to access to the very large file.
I have check that its .obj file is larger than 65MB so I have added the compiler command /bigobj as far as I have seen on the Internet but it didn't solve the problem.
I have also checked that the problem happens when access to the large file because everything works ok when I join both files (which is not possible in my development)
I am using Visual 2008
Could it be related to compile as C (/TC) or C++ (/TP) code? What's the difference between .exe and .dll that may make my program crashes?
Any ideas please?
Thanks in advance
Indeed, without the code not much can be said... (tho not sure if anyone would have the patience of reading 600 files each with 25k lines of code :) )
As advice, rebuild the exe and dll in debug mode, run the exe from MSVC, then put a breakpoint where you know it crashes. Next set a data breakpoint on the variable after you get its address from the watch window. ASSUMING the app does what it should correctly, then the pointer is set, but lost along the way; that means it should be triggered twice.
Alternatively, try an assertion check.
Another scenario is because the variable is volatile.
Another scenario is the value is returned from a temporary value and gets lost...
And last but not least, the value is never set because of wrong\bad conditions...
If your problem is the crash and not the missing value, just do a null check and return the call if you really want to avoid the complication, however, I would recommend you find why the value isn't set. Your choice.
I would like to set a break point on file modification for a particular file, or on opening a particular file. This is a file which our software opens and modifies during portions of legacy code. I'm not exactly sure how to approach this problem. One approach I have thought about was to find all of the places where we are opening files, break on all of them, and inspect the file path to determine if it is the path we are concerned with. The other approach I was thinking was to attempt to set a break point in the file system opening code when the path matches what I am concerned with (possibly more difficult, as I am presently running under Windows. This might be an option under Linux but a Visual Studio 2005 solution would be ideal and a Linux solution potentially useful).
Presently, I am using Visual Studio 2005 for my software project in C++. I was not able to find anything online about this as an option or an approach people would like to take.
Normally, I would say that I should just understand where this file is being opened. Unfortunately this section of code is quite difficult to understand and will be re-factored, but for the immediate future this functionality would help me.
Thank you very much for reading my question,
-Brian J. Stinar-
Put conditional breakpoint to kernel32.CreateFileW and check file name.
Then you will get file handle, so you can put conditional breakpoint to kernel32.CreateFileW and check file handle.
Also you can hook CreateFileW and call __debugbreak() in it.