I have made the necessary changes to the following files
irt_syscalls,
nacl_syscalls,
nacl_syscalls,
nacl_syscalls_common,
nacl_syscalls_handler_gen.py
but I get Undefined reference to NaClSysLibcall (the system call I'm trying to make) while compiling NaCl code
since you are implementing a custom syscall, i'll assume you do not want to run inside of chrome and you just want to run code via sel_ldr.
IIRC the SDK, whether you want newlib or glibc, was built in the chromium tree, and getting the C syscall wrapper to build is probably going to be a pain since you'd need to fetch all of chromium; worse, the SDK source may have already been eradicated from the chromium tree.
an easier way might be to just write your own syscall wrapper that calls the address in the trampoline region that corresponds to the syscall. you can disassemble an existing syscall wrapper to see what the code ought to look like.
Related
I would like to write a program using Scala Native but it has to run on a linux host (centos 6.5) with a very old glibc. So I would like to deploy that program as a statically linked executable, e.g. as golang does.
How do I build a statically linked executable with scala-native? Is it possible? If yes, how do I do it? If no, why not?
The sbt option nativeLinkingOptions takes a Seq[String] of extra arguments which are passed verbatim to clang during linking.
Adding the following to the project build settings works for me in a quick test:
nativeLinkingOptions += "-static"
I'm not an expert on this topic, but from what I understand that's not something that can be done for all kinds of applications, it might be even impossible to do based on what are your dependency libraries;
For example you cannot statically link against glibc (it's not designed to be statically linkable and has dynamic features like nss that prevents it from being linked statically).
You can try another libc implementation like musl which is statically linkable, however you need to compile a lot of things from scratch and in the end, your output binary might have some weird behaviors, for example name resolution might not work and you need to use direct IP addresses, unless you use a resolver library too.
That's a rabbit hole you probably don't want to go to!
But, if you are also an experienced C/C++ developer, you can tweak with linker parameters as mentioned in the other answer; however you might need to link manually, as currently available sbt options does not allow you to change order of existing linking parameters, which is unfortunately important when linking statically!
I add the UnityEngine.UI.dll and UnityEditor.UI.dll to my assets folder with their mdb files . also i add the both project to my current project. i am sure all the unity engine ugui code build success, because i debug log in the event system, and it print message. when i want to step into the event system class, i always failed . I find unity will load the code from a build path ,rather than i original code. Why does it do this ? if i want to debug unity engine ugui code, what should i do ?
To debug code, you need two things:
Symbols, the list of all functions, classes, variables used throughout the module. When using C++ symbols are stored in special .pdb files on Windows (and you obviously are using Windows since you are talking about dlls). Symbols in C# (.NET in general) are stored in the .dll itself. Having symbols will let you see the name of functions on the call stack and possibly some variables but nothing more.
Source code of the module.
U3D's source code is proprietary - you need to spend a good amount of money to receive it. And if I am guess to - UnityEngine.UI.dll is a C++ module with stripped (removed) symbols removed.
Thus you have neither, so you can't debug U3D's code at all.
Why would you need to that anyway? If you want to see how the internals of a big game engine work, there are plenty of other options (for example UE4 and Lumberyard). If you are struggling with a problem and you'd like to be able to solve it through debugging...well though luck. Your best bet would be to ask in unity community.
I'm pretty new to c++ (and programming in general) and I'm currently trying to inlcude the "SDL.h" header into a c++ project in Eclipse (I use minGW btw). I've provided the project with the paths to the the header files and the library of SDL. However, whenver I specifically include "SDL.h" and the build then project I get the following Message:
" 'Launching SDL Basic.exe' has encountered a problem. Program file does not exist. "
I'm pretty sure that this has to do with the fact that no .exe file is generated whenever I build the project with SDL.h included. What I don't get is why this happens. When I include some other SDL header, such as SDL_assert, this is not a problem. Then the .exe file is generated just as usual and the program runs just as it should.[enter image description here][1]
http://i.stack.imgur.com/cdV8U.jpg How it looks when SDL.h is included.
http://i.stack.imgur.com/MW7PX.jpg How it looks when something else from SDL is included.
I seem to have fixed the problem. Whenever I ran the program the console window outout " undefined reference to 'Winmain#16' ". So I googled on it and found out that SDL defines its own main function in SDL_main.h, which in total would give me two main functions. To prevent SDL from defining its own main function I had to define the macro SDL_MAIN_HANDLED before I included SDL.h, and look, it worked:
http://i.stack.imgur.com/mNOOE.jpg
If someone can explain this in more detail I'd really appreciate it.
I did a little research and it looks like the undefined reference to WinMain#16 is because SDL is automatically creating a Windows entry point for your application, but you haven't provided the necessary libraries to link in the SDL implementation of that entry point. However, if you intend to use the SDL functionality, you really do need that entry point, because it performs several important initialization steps necessary to leverage the SDL features that you presumably want to use.
Defining SDL_MAIN_HANDLED is a mechanism that would allow you to provide your own Windows entry point (i.e.: WinMain), but that is a more complicated approach (albeit more flexible). This only solves your problem because it happens to prevent "main" from being redefined to "SDL_main" which in turn means that your .cpp file no longer even requires any of the SDL libraries. So it compiles and links, but you won't have any of the SDL functionality you're looking for.
You need to link in the appropriate libraries. See here - it provides some info that might help.
Often, especially when dealing with malware files, you'll end up in a situation where all the APIs are dynamically resolved at runtime inside a given buffer, this approach considerably slow down the reversing process (and makes the decompiler useless: (DWORD *)dword_123456(INT, UINT)()) because the analyst has to run the malware, resolve the api and by hand put a comment next to each api call. I've found the indirectcalls plugin, but it seems to work only with "standard" C++ methods. Is there any script, or funcionality I don't know about, that's able to patch the executable, even during the debugging, in order to call the APIs with their real names?
There is a script called renimp.idc that is shipped with IDA in the idc folder of IDA's installation directory. Just attach IDA at runtime (in cases of malware analysis you will probably better want to use a remote debugger), navigate to the API address table created by the unpacker and select all entries. Then run the said script. It will rename all pointers to the correct API it points to, so IDA's type-library is able to resolve the correct typedefs for it from it's internal database again.
we all agree that when we use GWT, we compile our application on the server, several javascript file are created. Normally, when deploying, we would use the obfuscated mode.
Now modifying a javascript file in obfuscated mode is almost impossible. Now what happens if we want to make some modification in our GWT application.
Do we have to go back again in Java, modify the file, compile, and then deploy again??
I'd say yes... If you use a code generator you should avoid modifying the generated code by hand.
No, no, no.
You don't "go back" to the Java code to modify it. You simply debug, test and modify the Java code. You ignore the code in the compiled javascript files except to deploy it. As far as you are concerned, GWT source code is Java code, not javascript, written within the environmental restriction of the browser.
Your question is like asking, "I have a C application that gets compiled to object code. Do I modify the object code or go back to the C code to modify it?" !!!
You simply treat the generated javascript as "native code".
No doubt you can include javascript using jsni, and so can you include assembly code when using C. So except for those assembly code you inject and similarly except the javascript code you include, you leave the "native code" alone.
When you try to modify the object code generated from C, that is called hacking. Hacking is an interesting hobby but when you wish to create an application and your main task is not "hacking", hacking would only be your extra-curricular activity not connected to your main employment or project.
Go back to the beginning: http://code.google.com/webtoolkit/overview.html
...Write AJAX applications in Java and
then compile the source to highly
optimized JavaScript that runs across
all browsers
When you're ready to deploy, GWT
compiles your Java source code into
optimized, stand-alone JavaScript
files that automatically run on all
major browsers, as well as mobile
browsers for Android and the iPhone.
While debugging: if you are running in development mode you may not even have to redeploy while in dev.
Thanks to the GWT developer plugin,
there's no compiling of code to
JavaScript to view it in the browser.
You can use the same edit-refresh-view
cycle you're used to with JavaScript...