Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 7 years ago.
Improve this question
I have a file with the extension .out . I'm running windows 10. From what I understand, .out files are generated while coding in C and C++ in Linux. I was wondering if there was any way in which I could execute the file in windows. Renaming it's extension to .exe gave me an error saying the file was incompatible with 64-bit version of windows.
So is there any way I could execute the file, or better yet, view it's contents as proper code so I can work with it, while using Windows?
There's no way of directly converting a linux executable to Windows format.
You'll have to recompile or use Cygwin, It allows running Linux commands in Windows environment.
a.out is not neccessarily related to C or C++, it can be generated from any other kind of compiler/assembler. If you read the article, then you can see that it isn't even guaruanteed that this actually is what you may think of a.out format.
In order to execute it, the only possible way to achieve this is to install a Unix OS to execute it, but this again wont guaruantee that it really can be executed, because there may be dependencies or the wrong OS, etc..
To view the content of the file, there are different utillities on different platforms. For example you can use objdump on Linux or Cygwin/Windows to take a look at it. You can use a disassembler and see if you can make sense of it. On Windows you can use IDA which covers a broad range of fileformats and may be able to dissect it.
Now that you managed to take a look inside it, there is the next issue you asked for, by converting it. This is a tedious process though, because you must do it by hand. If IDA could identify it, you get a good start because you now have an assembly source as a starting point, but it will likely not assemble, and certainly not run on your target platform (Windows).
Related
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 5 years ago.
Improve this question
I know that the inline asm exists, but is it also possible to execute machine code from a file during RUNTIME?
Would i need to write my own interpreter?
I'm using the GNU C++ compiler with c++ 14 enabled, on Windows 7.
Thanks for reading.
With your rephrasing into machine code, this question starts taking a more reasonable shape.
A short answer: Yes, you can run machine code from within your application.
A longer answer is - it's complicated.
Essentially, any string of bits and bytes in memory can be executed, given some conditions are met, such as the data being legal machine instructions (Otherwise the processor will invoke the illegal instruction exception and the OS will terminate your program) and that the memory page into which the data is loaded is marked with executable permissions.
Having said that, the conditions required for that machine code to actually run correctly and do what you expect it to do, is significantly harder, and have to do with understanding of Virtual Memory, Dynamic Loaders and Dynamic Linkers.
To bluntly answer your question, for a POSIX compliant environment at the least, you could always use the mmap system call to map a file into memory with PROT_EXEC permissions and jump into that memory space hoping for the best.
Naturally, any symbols that code would be expecting to find in memory aren't likely to be there, and the code was better compiled as PIC (Position Independent Code) but this roughly answers your question with a YES.
For better control, you'd usually prefer to use a more standard method, such as compiling your extra code as a shared object (Dynamic Link Library, DLL in Windows) and loading it into your application with dlopen while using dlsym to access symbols within it. It still allows you to load machine code from the disk into your application, but it also stores the machine code in a well formatted, standard way, which allows the dynamic linker to properly load and link the new code segment into your application, reducing unexpected behavior.
In neither of these cases will you need an interpreter, but neither is it a matter of language or compiler used - this is OS specific functionality, and will behave quite differently on Windows.
As a different approach, you could consider using the #include directive to import an external chunk of assembly code into your work while you're still working on it and properly incorporate it in compile time, which will yield far more deterministic results.
Edit:
For windows, the parallel for mmap is CreateFileMapping
dlopen is LoadLibrary
Not a Windows expert, sorry...
Let us distinguish between "assembler code"/assembly code (which is what this question initially asked about) and machine code (after one of the edits).
Anything you might describe as "assembler code" (or more usually "assembly code") but not machine code (i.e. anything not being actual, binary, executable, machine code) cannot be "executed". You can only read it into what I would call an "assembly-code-interpreter" and have it processed. I do not know of any such a program.
Alternatively, you can have it processed at runtime by a build process and execute the resulting executable. That however seems not to be what you are asking about.
Note that this does not mean that you can execute any machine code you might find in a file on your disk. It needs to be for the right, same platform and be supported by the appropriate runtime environment. That is applicable to executeables created for your machine or compatibles, e.g. the result of a built.
Note that I understand "assembler code" ("assembly code") to mean source code in assembly language, which is a (probably the most basic) representation of programs in (not really) human eye readable form. (As immortal has commented, an assembler is the program to process assembly code into machine code.) Opcode mnemonics are used, e.g. cmp r1, r2 for comparing two registers. That string of characters however is guaranteed not to make any sense when trying to execute it straight forward. (OK, strictly speaking I should say "almost guaranteed"...)
Machine code which is appropriatly made for your environment, including a loader, can be executed from a file. Any operating system will support you doing that, most will even provide a GUI for doing that. (I notice this sounds somewhat cynical, sorry, not meant to be.) Windows for example will execute an executable if you double-click its icon in the windows explorer.
An alternative to such executable programs are libraries. Especially the dynamic link libraries are probably quite close to what you are thinking of. They are very similar, in needing to be targeted at your environment. Then they can (usually partially) be executed from a linked program, via agreed calling mechanisms. Those mechanisms in turn ensure that the code is executed in a matching environment, including being able to return results.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
Background:
We have acquired a software product that builds to a 32-bit Windows application in Visual Studio. We wish to port this application to 64-bit.
A mission-critical component of this code is a black-box static library (.a file) originally built using gFortran by a third party. The original developer has since passed away, and the Fortran source we were able to get was incomplete and not the version this library was built off of (and contains critical bugs not present in the compiled library). They did not use a VCS.
Problem:
I would like to create a 64-bit static library whose code is functionally equivalent to the 32-bit static library we have.
What I've Tried:
Using the Snowman decompiler to get C++ source code to recompile in 64-bit. This proved impossible because the code that was generated uses low-level intrinsic functions that appear to be gcc-specific. It likely wouldn't work anyway because such intrinsics would compile to code that isn't functionally equivalent in 64-bit. I'd likely need a better decompiler.
Apparently x86 assembly is valid x86_64 assembly, so I looked briefly into why I couldn't just run the assembly through a 64-bit assembler. Turns out the ABI is different in 64-bit, so the calling convention won't match. MAYBE I could manually convert the function calls to the proper convention and leave the rest the same, but that might be an intractable problem. Opinions?
You could keep the 32-bit binary library but load it into a 32-bit host process, and use some kind of IPC (shared memory, named pipes, local-loopback network connection, etc) to transfer data to/from your 64-bit process.
Another advantage to this approach is that if the Fortran code crashes then it will only bring down the child host process, not your main application and your program can instantly fire it up again; and if it's a single-threaded Fortran program then you could spin up several instances for multi-core parallelism.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 6 years ago.
Improve this question
I have a class project where we need to take a 32-bit executable written in C++ and disassemble it and modify the assembly code and then reassemble it. We're supposed to do things like hardcode cheats into the game.
I've been searching for hours and I can't find any software that will do this. I've looked at Ollydbg and spent about two hours with it and couldn't really figure out how to get it to work. I utilized Cheat Engine and that actually worked out really well for me - I was able to isolate the code modifying the addresses I cared about and replace it with code to have a favorable impact on the game, but as far as I can tell Cheat Engine has no ability to recompile the modified code.
This is a fairly lower level Computer Science class so please take into account my ability level when making suggestions but if there is any software out there or alternative ways that will allow me to do this I would greatly appreciate it. Thanks!
Since you mentioned OllyDBG and Cheat Engine I'm going to assume you're using Windows.
First, you can use OllyDBG to save a file, but for some reason I can't find this option in OllyDBG 2, only in older versions (like 1.10). You can right-click on the code window and then copy to executable > all modifications, A new window will open, right-click on the new window and then choose save file.
An alternative that I really like is x64dbg. it's an open source debugger/disassembler and has an option to save changes via "Patches".
Another option is to apply the changes via an hex editor, which allows you to modify any file (including executables) in a binary format. It is, of course, a bit harder to do since you need to translate your changes to op-codes manually, but if your changes are not too big or only consisting of modifying some constants it can be a faster and easier solution. There are a lot of hex editors out there but my favorite is XVI32.
What I personally like to do is to modify the memory via code using Windows API's WriteProcessMemory and ReadProcessMemory since it allows you to do this things dynamically.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 7 years ago.
Improve this question
I asked in another thread, how to profile my stuff, and people gave me lots of good replies, except that when I tried to use several of free profilers, including AMD Codeanalyst for example, they only support Microsoft PDB format, and MingW is unable to generate those.
So, what profiler can help me profile a multi-threaded application with Lua scripting and is compiled with MingW?
EDIT: gprof is crap, the awnser that says why I don't want it, is right on the spot... If I get all the functions that it litsts as troublesome, NONE of them are related to the issue that I have (there are a certain action that causes a massive slowdown, and I can't figure why, and gprof can't figure it either)
If you don't want to use gprof, I'm not surprised.
It took me a while to figure out how to do this under GDB, but here's what I do. Get the app running and change focus to the app's output window, even if it's only a DOS-box. Then I hit the Control-Break key (while it's being slow). Then GDB halts and I do info threads and it tells me what threads there are, typically 1 and 2. I switch to the thread I want, like thread 2. Then I do bt to see a stack trace. This tells me exactly what it was doing when I hit Control-Break. I do this a number of times, like 10 or 20, and if there's a performance problem, no matter what it is, it shows up on multiple samples of the stack. The slower it makes the program, the fewer samples I have to take before I see it.
For a complete analysis of how and why it works, see that link.
P.S. I also do handle SIGINT stop print nopass when I start GDB.
Does gprof not do it?
I thought MingW provided a gprof version to go with it.
If you want to profile Lua scripting, I could suggest using the LuaProfiler: http://luaprofiler.luaforge.net/manual.html. It works quite nicely.
I would strongly suggest implementing some sort of timers or your own profiler to get a simple profiling tool. A really simple one is to just output the times when certain points in your code is hit, output those times into a textfile and then write a simple lua or python script to parse the file and filter the interesting information.
I've used this (or a slightly more complex) version of profiling for most of my hobby-projects and it has proven very helpful.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 11 years ago.
Improve this question
What is the best (hopefully free or cheap) way to detect and then, if necessary, remove a rootkit found on your machine?
SysInternals stopped updating RootKit Revealer a couple of years ago.
The only sure way to detect a rootkit is to do an offline compare of installed files and filesystem metadata from a trusted list of known files and their parameters. Obviously, you need to trust the machine you are running the comparison from.
In most situations, using a boot cdrom to run a virus scanner does the trick, for most people.
Otherwise, you can start with a fresh install of whatever, boot it from cdrom, attach an external drive, run a perl script to find and gather parameters (size, md5, sha1), then store the parameters.
To check, run a perl script to find and gather parameters, then compare them to the stored ones.
Also, you'd need a perl script to update your stored parameters after a system update.
--Edit--
Updating this to reflect available techniques. If you get a copy of any bootable rescue cd (such as trinity or rescuecd) with an up-to-date copy of the program "chntpasswd", you'll be able to browse and edit the windows registry offline.
Coupled with a copy of the startup list from castlecops.com, you should be able to track down the most common run points for the most common rootkits. And always keep track of your driver files and what the good versions are too.
With that level of control, your biggest problem will be the mess of spaghetti your registry is left in after you delete the rootkit and trojans. Usually.
-- Edit --
and there are windows tools, too. But I described the tools I'm familiar with, and which are free and better documented.
Rootkit revealer from SysInternals
Remember that you can never trust a compromised machine. You may think you found all signs of a rootkit, but the attacker may have created backdoors in other places. Non-standard backdoors that tools you use won't detect. As a rule you should reinstall a compromised machine from scratch.