The original post here has been edited to reflect logical recommendations by board members and includes the following:

1.) Construct a C++ output executable
2.) Use a dis-assembler and output the assembler directly.
3.) Using comparative analysis translate the assembler output into FASM
4.) Do the obvious testing; etc. for logical errors

GCC will be the compiler in use; it has been stated that no compiler is perfect and I find that to be an understatement of the fact as it is a profound truth. The recommendation for the intel C++ compiler is also noteworthy for anyone with a Linux box as intel provides the compiler as non-commercial use freeware.

Trace was used in Olly Debug to get a feel for the flow of the code and it is as was stated an opus in a food mixer; sloppy and jumping all over the place and with no obvious linear path prevents trace from being anything but mer curiosity resulting in numerous headaches. The trace helps to establish the credibility in the claims made about compilers spewing out ridiculously bloated, complex and easily broken code.

This will be finished up at a later date:
1.) tool list (as a starting point)
2.) quick step by step on the procedure (not delving into process details)


Good news --I just finished up trace route with the GCC Hello World console application in record time; it only took me 8 years, I think that's a record!

2016: late as h3ll, but decided to go C instead of C++, utilize the time to get familiar with OllyDebug operations and apply what I learned to my FAsm projects.

Anyone considering the same might want to use freeUPX on the output executable and then use Olly Debug to step though the code alongside an Olly Debug setup tutorial. GCC executables are grotesque in size and provide ample opportunity to learn navigation techniques in the debugger.

Some things I learned through comparative analysis was that GCC, fully optimized for C, executable output is well over 2 megs contrasting MSVC C executable size of 70 kilobytes; additionally the GCC console application needs an assistant to the console host of windows for a total memory footprint between 6 and 8 megs. MSVC C console app requires console host raising the total memory footprint up over 2 megs, but is using the C runtime.

I conclusively did the same exact application with no tricks in FAsm and the file output was 1.5 kilobytes and did not require anything else. Still holds true with Windows 10 --original spun in Windows Vista and carried through 7.

Did learn how to use the hell out of Olly Debug and it came in handy trouble shooting a console application I developed that imported SQLite; long story short, the SQLite app works and Olly Debug is the sh!t.

Based on GCC favor in this thread considered its effectiveness heavily, inevitably deciding to focus elsewhere. Now CLang is all I think about and FAsm G with Revo's ARM support.

Anyone reading this post continue reading the comments below are some awesome insights that matter in numerous ways.

Tooling utilized:
1. - Olly Debug
2. - IDA (freeware windows version) "Interactive DisAssembler" great for trace and relational mapping.
3. - freeUPX strips garbage, text and excessive nop reducing overall file size considerably (specifically GCC .exe's).

Currently looking into distorm (kind of a dis-assembler) by recommendation in another thread; is currently developed (version 3) and source is available at GitHub.

This sh!t's a wrap!

...what?

seems they have updated the engine used for mbr_tsr

hahaha...lol

Hey, we should have a like button on this board.

@TheRaven
Dude, don't make me become your nightmare like mbr_tsr. I hope you respond so I don't become one.

f0dder:
I designed an application in C++ using GCC. I am going to use Olly Debug to open the executable and run the app doing a trace. I am reverse engineering the application in order to see the assembler. Once I am comfortable with what I see I am going to attempt to recreate my application in assembler using the C++ executable as a guide.

Then I am going to post the code for the assembler project and the C++ project so that people can see what is there and happening. It's harder to explain than it is to visualize.

vid - mbr_tsr - weird.

Well then, I guess you could have used a visual aid.

Anyways, you don't have to tell us everything you are going to do. There's a place for that, http://facebook.com or just tell us when you are finished with your project.

Run the executable doing a trace? If you want to see what code GCC generates, why don't you just use a disassembler? Or use the "generate assembly listing" for just your code?

Reading code after gcc is like reading a book after using a food mixer on it.

I saw once what stuff GCC generates - optimizations was ON.
I was not impressed at all - in fact it was much worse than Microsoft compiler(s). The best code I have seen is from Intel C++ compiler - excellent code!

^^ I agree...

And duh, they know their chips... lols

It really does depend on which compiler versions you pit against eachother, and what input code you feed them. While I've generally found GCC on third place of the three mentioned, a few times it has surprised me on specific pieces of code.

No compiler is perfect

I've seen more reports of optimization in C++ actually outputting broken executables than I have any type of success story on the topic.

intel's C++ compiler, from what I witnessed at their site, is only available for Linux without a commercial license as a non-commercial freeware download.

Take it easy.

I have tried Intel compiler as 30-days deal.

Have any fun?

I'm pondering the installation of the freeware tool chain for linux in a virtual machine. I ran some C++ through a Dev-C++ system using MinGW GCC and the same code through MSVC and could not get similar results between either.

Define "similar results"? You're obviously not going to get executables that are even remotely similar... but the result of running the executables should be.

That's exactly my point: inconsistent performance, unreliable behaviour and who knows what else. I was rewriting code thinking that I was logically erroneous in areas only to have to go right back to the previous code. It was ridiculous so I closed up shop on the effort for the moment until I can do a re-install and start with a fresh everything. I am seriously thinking that the win32 directory is having an adverse effect on the situation. I should be getting the same results as the system is a basic console app using win32 api and nothing special.

Try:


It will output file.s, which will contain the Intel style assembly of the program.