So I was doing some reversing on a binary I created to learn assembly and I came across a subroutine that had fewer return statements than I had in my original source code. The .text section has 2 return statements, the decompiled c-source code has 3 return statements but my original source code has 4 return statements.
I'm using 64-bit IDA 7.0 pro, my file is also 64-bit. I'm trying to figure out why this is.
IDA .TEXT VIEW: https://gyazo.com/00fc89ed15dfe8485df620f89185bbdf
IDA DECOMPILED C-SOURCE VIEW: https://gyazo.com/b78e153a50716e1804d08921438f4289
ORIGINAL SOURCE CODE: https://gyazo.com/e0071904abc06c51958af009e23808ae
Related
I have a problem with the binary's size of old Pascal versions.
We need very small simple programs. We would like to use Turbo Pascal 2 in MS-DOS (higher is the same problem) to compile COM files. But the size is always 10 KiB and larger, even for an empty project like:
begin
end.
Compiled file sizes 10052 bytes. I do not understand why. I tested compiler commands, changed stack/heaps with no results.
Compilation output:
Compiling --> c:emtpy.com
3 lines
code: 0002 paragraphs (32 bytes), 0D7B paragraphs free
data: 0000 paragraphs (0 bytes), 0FE7 paragraphs free
stack/heap: 0400 paragraphs (16384 bytes) (minimum)
4000 paragraphs (262144 bytes) (maximum)
Is it possible to get a smaller COM file, and is it possible to convert the Pascal code automatically into ASM code?
Any version of Turbo Pascal up to 3.02 will result into an executable file which includes the whole Run-Time Library. As you discovered, the size of it for TP2 on your target operating system is about 10,050 bytes.
We need very small simple programs.
... then Turbo Pascal 2 is not a good option to start up. Better try with any version from 4 up, if you want to stick with Pascal and are targeting MS-DOS. Or switch to C or assembly language, which will be able to produce smaller executables, at the cost of being more difficult to develop.
[...] is it possible to convert the Pascal code automatically into ASM code.
It can be done using Turbo Pascal but it is not practical (basically you need a disassembler; IDA is such a tool, used nowadays; the version you need is not free.) Also you won't gain much by smashing some bytes from an already compiled application: you will end much better starting it straight in assembly language.
Anyway, the best course to achieve it is to drop Turbo Pascal and go to Free Pascal, which compiler produces .s files, which are written in assembly language (although maybe not in the the same syntax as you are used.) There is (was?) a sub-project to target the 16-bit i8086 processor, which seems reasonably up-to-date (I never tried it.)
Update
You mentioned in a comment you really need the .COM format (which Turbo Pascal 4-7 does not support directly). The problem then is about the memory model. .COM programs are natively using the so-called tiny model (16-bit code and data segments overlapping at the same location), but it can be somewhat evaded for application (not TSR) which can grab all the available memory; TP 1-3 for MS-DOS uses a variant of the compact model (data pointers are 32-bit "far" but code pointers are 16-bit "near", which caps at 64 Ki bytes of code); TP 4-7 are instead using the large model where each unit have a separate code segment. It could be possible to rewrite the Run-Time Library to use only one code segment, then relink the TP-produced executables to convert the FAR CALLs into NEAR CALLs (that one is easy since all the information is in the relocation table of the .EXE). However, you will be home sooner using directly Free Pascal, which supports natively the tiny memory model and can produce .COM executables; while still being highly compatible with Turbo Pascal.
Program compiles, but freezes after starting. If replace the format and include with 32-bit versions or comment out the MessageBox, then everything works fine.
format PE64 GUI
include 'E:\Fresh\include\win64a.inc'
entry start
section '.data' data readable writeable
text db 'Hello world!',0
section '.text' code readable executable
start:
invoke MessageBox,0,text,text,0
invoke ExitProcess,0
section '.idata' import data readable writeable
library kernel32,'KERNEL32.DLL', user32, 'USER32.DLL'
import kernel32, ExitProcess, 'ExitProcess'
import user32, MessageBox, 'MessageBoxA'
Your stack is not aligned to 16 bytes, as the ABI requires. Add and rsp, -16 to the beginning of your code, and it will work.
Regarding this exchange in the comments:
Ruslan: What does the disassembly look like? Are invoke macros expanded as expected?
rancid_rot: Not sure, there is MessageBox in cs instead of ds. And mov rcx,0 instead push 0.
I'd recommend avoiding invoke and similar macros until you learn what they should expand to. Otherwise you think you write in assembly, but actually you write in a high-level language only resembling assembly, not even knowing what code you will get in the end—thus defying the whole purpose of using an assembler.
To actually learn to call functions in Win64 assembly, see the documentation on Win64 calling conventions.
I have some C++ code that contains 5 or so lines of code that I want to refactor into a function. When I right-click->refactor->extract function, the refactor generates the function correctly, but it insists also on reformatting a large chunk of code that has nothing to do with the code I'm refactoring. Furthermore, neither the reformatted code nor the generated function fits my current style (K&R modified by me) as near as I can tell.
Why does it do this?
Is there a way to get it to follow my code style?
Is there a way to turn it off?
I try to write matlab mex code with Cuda integrated but it is just hard enough to compile and debug all around. Is there any better approach to code and test? I am on Matlab 2012b.
Currently I am writing code in sublime then compile it on matlab but I am also newbie at CUDA as well thus it is just hard to code it without seeing the result instantly.
The comment by Robert Crovella is interesting.
I just wanted to mention the way I was used to compile mex file with CUDA instructions (and which works also on different versions of MATLAB).
1) Compile by nvcc and transform the source code in C++ code by the command
system(sprintf('nvcc -I"%s/extern/include" -cuda "mex-fun.cu" -output-file "mexfun.cpp"', matlabroot));
2) Link it to Matlab by
mex -I/opt/cuda/include -L/opt/cuda/lib -lcudart mex-fun.cpp
This was originally suggested at the MATLAB Newsreader page.
I have both a matlab entry point (i.e. a file with the function "mexFunction") and a C++ entry point (a file with "main"), and the rest of my actual CUDA code is independant of what entry point was used.
This way, I can debug the code used for my MEX files using the standard set of CUDA tools (i.e. nvprof, cuda-memcheck, etc) without having to deal with the MEX file. Then once I'm sure I have no bugs or memory leaks, I just compile it to a MEX file. Alternately you can always just attach cuda-gdb to your MEX file, although your mileage may vary with this.
I am totally a newbie in Matlab
I want to ask that when we write a program in Matlab software or IDE and save it with a
.m (dot m) file and then compile and execute it, then that .m (dot m) file is converted into which file? I want to know this because i heard that matlab is platform independent and i did google this but i got converting matlab file to C, C++ etc
Sorry for the silly question and thanks in advance.
Matlab is an interpreted language. So in most cases there is no persistent intermediate form. However, there is an encrypted intermediate form called pcode and there are also the MATLAB compiler and MATLAB coder which delivers code in other high level languages such as C.
edit:
pcode is not generated automatically and should be platform/version independent. But it's major purpose is to encrypt the code, not to compile it (although, it does some partial compilation). To use pcode, you still need the MATLAB environment installed, so in many ways it acts like interpreted code.
But from your follow-up question I guess you don't quite understand how MATLAB works. The code gets interpreted (although with a bit of Just-In-Time Compilation), so there is no need for a persistent intermediate code file: the actual data structures representing your code are maintained by MATLAB. In contrast to compiled languages, where your development cycle is something like "write code, compile & link, execute", the compilation (actually: interpretation) step is part of the execution, so you end up with "write code, execute" in most of the cases.
Just to give you some intuitive understanding of the difference between a compiler and an interpreter. A compiler translates a high level language to a lower level language (let's say machine code that can be executed by your computer). Afterwards that compiled code (most likely stored in a file) is executed by your computer. An interpreter on the other hand, interprets your high level code piece by piece, determining what machine code corresponds to your high level code during the runtime of the program and immediately executes that machine code. So there is no real need to have a machine code equivalent of your entire program available (so in many cases an interpreter will not store the complete machine code, as that is just wasted effort and space).
You could look at interpretation more or less as a human would interpret code: when you try to manually determine the output of some code, you follow the calculations line by line and keep track of your results. You don't generally translate that entire code into some different form and afterwards execute that code. And since you don't translate the code entirely, there is no need to persistently store the intermediate form.
As I said above: you can use other tools such as MATLAB coder to convert your MATLAB code to other high languages such as C/C++, or you can use the MATLAB compiler to compile your code to executable form that depends on some runtime libraries. But those are only used in very specific cases (e.g. when you have to deploy a MATLAB application on computers/embedded devices without MATLAB, when you need to improve performance of your code, ...)
note: My explanation about compilers and interpreters is a quick comparison of the archetypal interpreter and compiler. Many real-life cases are somewhere in between, e.g. Java generally compiles to (JVM) bytecode which is then interpreted by the JVM and something similar can be said about the .NET languages and its CLR.
Since MATLAB is an interpreter, you can write code and just execute it from the IDE, without compilation.
If you want to deploy your program, you can use the MATLAB compiler to create an stand-alone executable or a shared library that you can use in a C++ project. On Windows, MATLAB code would compile to an .EXE file or a .DLL file, respectively.