I am working with a lot of legacy applications here. One of them (deployed in production) need to be edited because doesn't have any log.
I decompiled the it, but I have no idea about how to reassemble in this situation. I could not even recompile de single classes edited because of the compiler optimization.
(I am using Java 6)
Sorry if my english is bad, I am just a junior
No. A WAR file is just a specialized JAR file that contains, in addition to the compiled bytecode, JSP files, static HTML files, and a descriptor file that tells the webserver how to deploy the app. What it does not contain is the original source code. This means your only options are working with the decompiled code, or asking the original developers for the source code.
As you have discovered, compilation and decompilation are lossy processes, so you cannot in general recompile decompiled code, and even if it does compile, it may not be identical to the original binary.
One alternative is to use Krakatau disassembler and assembler. Krakatau can roundtrip Java bytecode to a human readable text format, which makes it easy to edit bytecode losslessly. The main downside is that you have to have a good understanding of Java bytecode to understand the disassembly and it is a lot harder to read or edit than Java source code.
Related
I'm a little bit confused about the qtquickcompiler, the JIT qml caching and what is available (and what is not) in the open source version of qt 5.8 (respectively 5.9).
Basically, I want to protect my .qml and .js files from being readable in my release build. I started a new example QtQuick project without editing any code. I followed these instructions and added the CONFIG += qtquickcompiler in the .pro file, but it has no effect.
My .qml files are built into the .exe (on Windows), but if look in the executable, e.g. with notepad++, I can still see the source code of the .qml files.
On the other hand, if I don't use the QRC for my .qml files, .qmlc files are created for every of my .qml at runtime. These files are not (easily?) readable. But I don't find a way to use only the .qmlc files without shipping the .qml files in my build (and I don't think it was meant to be like that).
Coming to my question: Is there a way to protect my .qml and .js files with the open source version of qt? And what is the difference between the qtquickcompiler and the new JIT .qmlc?
Updated answer:
Since Qt 5.11, the qt quick compiler is also available in the open source version:
CONFIG += qtquickcompiler
See https://wiki.qt.io/New_Features_in_Qt_5.11
No, it was going to be, but then they gave up on those plans for the time being and replaced it with the caching thing.
I don't think you will be able to reuse .qmlc files on another computer, as IIRC they are not architecture portable.
In the future, it should be possible to pre-compile .qml to .qmlc ahead of time and bundle those into the application binary.
If your files are on the file system, then there is no way to protect them, from being read, reverse engineered, or tampered with.
With the compiler, the QML code is translated to C++ code, which is then compiled to a native binary. Also, last time I checked, if you go for the compiler, it is an "either / or" situation, if you use compiled qml you can only use compiled qml, so no mixing with regular qml files. It is also ahead of time, and requires a commercial license.
The qml caching in contrast is just-in-time (possibly ahead of time in the future), doesn't require a commercial license and doesn't come with the limitation that prevents you from using regular qml files. I am not aware of the implementation details, but it certainly is not qml code translated to C++ and then compiled, as it happens on the client side and doesn't require having Qt or even a C++ compiler installed. It doesn't really sound like bytecode either, as IIRC it is not binary compatible between platforms, it is more like caching the qml file processing result to avoid on doing it every time.
As outlined in this answer, with some extra work it might be possible to implement a decent amount of protection, for example encrypted QML files or binary resources, but I still haven't dug into it.
Lastly, if you set compression for the qrc file with a low threshold, it will somewhat obfuscate the QML code in the executable binary, but even so, it is regular zip compression, so if your code is really worth stealing, it will not really prevent that, just make it a tad less trivial.
Is there a way to protect my .qml and .js files with the open source version of qt?
Not yet. Up to (and including) 5.8 you'll need to buy a license in order to use the QML compiler.
And what is the difference between the qtquickcompiler and the new JIT .qmlc?
That the compiler will turn QML into C++, which gets then compiled into your application. The .qmlc files are a cache generated by the engine to avoid parsing / optimizing / etc. the same files all over again. Yet, they're a cache -- you'll need to original source around in case they don't get used. At the Qt Contributors' Summit 2016 there have been some discussions about how to streamline and integrate the compiler with the cache, but so far nothing exists.
Coming to my question: Is there a way to protect my .qml and .js files
with the open source version of qt?
Yes, of course,
look at my answer:
https://stackoverflow.com/a/40861056
You can use an encripted resource file, an decrypt it in execution time...
I do that in all my projects ...
Is not a trivial job, but works fine.
Qt's resource system lets you build an executable that has resources (.qml's, images...) embedded inside it. I'd like to load the files from the filesystem instead, and ship them alongside my executable. Is this a technique supported by Qt? Any gotchas? Any advantages to one way or the other?
Qt doesn't limit you in what you can do here. It's your choice. Qt's resource system is there if you want it, it's not forced down your throat. Not using it doesn't make you automatically wrong.
If you want to deploy files along with your application, go for it - if it makes sense for your particular application.
My personal preference for small (<0.25GB) applications is for a nice monolithic portable executable on Windows, with everything inside, that you don't have to install if you don't wish - mimicking how an app bundle would be on OS X.
The portability helps, as does the slightly stronger locality of reference: most filesystems will attempt to keep a file's blocks together a bit harder than they do for files that merely are in the same folder.
If there's any utility in power users tweaking the contents of the deployed files, then certainly using the files over using resources has advantages. You could also use the resource system as a fallback for files that are missing - that way a user could provide a replacement file optionally, if it's something you could use.
To make it short: If it is applicable for your application and 'business model' it is ok.
Besides being supported by Qt using QFile (for example), Qt's resource system has some advantages:
compression (ZIP)
simple usage in the application
no care about missing files (typically)
If you mind adding all resources to the executable will not work for you and you want to seperate them, look at the option of seperate (binary) resource files with Qt.
I want to translate a program; but its language files (.qm) are in a .rcc file.
The program is not mine, so I haven't got any .qrc file.
Before asking this question, I have searched this site about this issue; but I don't attain anything.
Is there any way to extract/decompile it?
You can take my tool RccExtended - it based on the official Qt resource compiler with additional function to decompile binary resources.
Usage example:
cd \Path\To\MyQtResources\
rcc --reverse
Decompiler will unpack all .rcc files in the current directory, generate .qrc files and make.bat file to compile resources back to the binary format.
There isn't a supported way to decompile it as far as I'm aware, but it's a binary file format that can be read and handled. There's a nodejs example of how to read the file and extract PNGs on github: https://github.com/gcochard/png-extractor. It may be possible to extend that method out for the .qm files.
However there's other issues with attempting to add more translations to a Qt application without having the code, depending on the language you're attempting to add, how the developer has exposed the other languages etc.
I'm trying to write a simple Qt app that will access zip files and read the content of these zip files (the content are text files). Many posts says that Quazip is the solution.
Being new to Qt and coming from .Net background, I really don't know how to use the Quazip, I downloaded the Quazip source but I'm not sure, should I compile it or should I use the source code in my project. I really have no clue.
Any help is much appreciated.
Regards.
It seems as you have various options. You can use source code immediately by copying the relevant files into your project. By default however a static library is compiled when you run
> make install
and in that case you need to add the relevant path to your .pro file so that it finds is static library.
Well, you have several options:
Just add the sources to your project. Pros: you can modify them if you want without affecting your other projects. Cons: updating QuaZip is probably going to be a maintenance headache.
Compile it as a static library (qmake CONFIG+=staticlib). Pros: updating is easier as you don't have to deal with structural changes, only recompile QuaZip and rebuild/relink your projects. Cons: you still have to recompile and relink.
Compile QuaZip as a shared (DLL) library. Pros: updating is extremely easy provided that the new version maintains binary compatibility, plus the code is shared among various applications running at the same time. Cons: it will break everything (that is, until you rebuild/relink your apps) if the new version doesn't maintain binary compatibility.
If you just need to read some zip files in some random project, any of these three will do fine. You probably won't have to update QuaZip either, unless you find some bugs that need to be fixed.
As for the binary compatibility: it is guaranteed that third level version changes (x.y.z1 -> x.y.z2) are binary compatible. As for minor version changes (x.y1 -> x.y2), they probably won't be binary compatible for some time, until the Pimpl idiom is implemented properly.
i have to create a dynamically linked library in zOS . What are the options to be passed to the compiler.
Also, how to check if a library in zOS is dynamically linked[dependent] on other libraries.
we have ldd in linux, which shows this linkage. Do we have a 'ldd' equivalent in zOS land?
You don't say it directly, but I assume you mean a C/C++ DLL. You can do shared libraries in other languages as well (even assembler), but the steps would be different.
First, you need to decide what you want to export. A lot of the IBM examples use the compiler EXPORTALL directive, but be aware this can lead to very slow executables, depending on your coding style. If you don't do EXPORTALL, you'll need #pragma export for anything (code or data) you want to export. Don't forget you can export data (variables) as well as executable functions...sometimes you'll need this to share data with DLL functions.
Then, you need to set your compile options on both client (caller) and DLL to use the DLL linkage...this is the -Wc,DLL compile option and when enabled, it generates extra logic in your program to load and manage the DLL. It's a good idea to also include #pragma csect for your exported functions if you think you'll ever have the need to update the DLL without replacing it entirely.
When you link your DLL, be sure to specify the -Wl,DLL option (there are lots of ways...this part is different if you link in batch - I'm assuming you're building in a make file of some sort). The link will generate the actual DLL, as well as a "side deck" containing "IMPORT" statements for all of your exported functions. You'll need these to link any of the client-side programs that you expect to call the DLL. For example, if your imports are in a file called AAA.x, c89 -Wc,DLL myapp.c AAA.x would compile the calling code, with awareness that functions in AAA.x are off in some sort of DLL.
To your point about DLLs calling other DLLs, don't forget that a DLL can both "serve" and "consume" functions...by including the side deck for functions in other DLLs, you can have a DLL that provides some functions while calling other DLLs to access others.
The actual DLL itself can be in several places depending on the nature of your app. If you're UNIX Services friendly, it's just an executable in LIBPATH. It can also be STEPLIB, LNKLST, LPA and so forth.
If you need to, you can access your DLLs explicitly at runtime using dlopen(), dlsym() and so forth. Generally, this lets you control exactly which DLL you're using (sometimes handy if the user can provide one himself), and it gives you what amounts to function pointers that are resolved within the DLL.
There are some other basic things to consider when linking, such as ensuring that your code is reentrant. Most of these are spelled out in the IBM documentation, and if you build with things like "c89" (or equivalent), the correct options are usually setup for you automatically (in fact, to get a good idea of what's going on, turn on the verbose output and see all the parameters for yourself).
If you need to build up a cross reference of what calls what, the UNIX Services "nm" command can give you that information. If you produce detailed link-edit listings, all the data is in there too when you're building your DLLs.
Good luck!