The .so file is a compiled library, in most cases from C or C++ source code. .so stands for Shared Object, it doesn't have anything to do with obfusation, it just means someone wrote parts of the app in C.
In some cases, there is existing C code and it's just easier for the programmer to build a JNI interface to call the library from java; in other cases, ...
JS-Unpack (see also blog)
Advanced obfuscated ...
Besides Guntram's suggestions, check out the retargetable decompiler aka retdec. It can decompile the binary to Python or C code. At least for me, it reads easier than pure assembly (and it works for ARM binaries).
It works very well for sketching you the rough workings of the shared object.
A plugin for select IDA versions exists, but the main limitation ...
I've been dissecting the firmware for another type of embedded device for a while and thought I'd see if I could find anything out. After a few hours I figured it out! There is a hard way and an easy way that I found only after digging the hard way. This is a long post, but I hope it will help others in similar ventures.
A little Googling and I found ...
These techniques of mutating code (and still keeping it semantically equivalent) are known as polymorphic code.
The software that can achieve a mutations of the code is usually called a polymorphic engine. It is a quite widely used technique in Malware design to evade pattern-matching detection of the anti-virus software.
With these key words in hand (and ...
You can also try a dynamic approach by hooking APIs and observing arguments and return values. This will allow you to look at data going into crypto APIs, which may help a lot when dealing with network protocols. Check out the Frida instrumentation toolkit for an open source cross-platform solution (Android, iOS, Windows, Mac and Linux). There's a tutorial ...
Use android-ndk, https://developer.android.com/ndk/downloads/index.html.
You can use the toolchains inside the ndk to perform the type of disassembling you want to. For e.g. if I decompile an apk and get a .so library out of it, I will do :
./android-ndk-r15b/toolchains/arm-linux-androideabi-4.9/prebuilt/darwin-x86_64/bin/arm-linux-androideabi-objdump -T "...
There are three main contributions of the research
A proposed indistinguishability obfuscation for NC1 circuits where the security is based on the so called Multilinear Jigsaw Puzzles (a simplified variant of multilinear maps).
Pair the contribution in 1 with Fully Homomorphic Encryption and you get indistinguishability obfuscation for all circuits.
Most tools don't support a 'ignore that byte for disassembly' feature, only IDA, Hopper and a few others do.
The only alternative is to patch the byte at 8049444 with a 90 NOP, or change your mind and not rely on basic tools.
I would start with not have critical strings in memory in linear manner
Instead each character can be offseted by some offset like by table mixing all the strings together. For example you got 0123456789 if you store them in memory like this:
where x is anything or another string ... ...
Based on @ws's comment and @nderscore's code, use this JSFiddle to decode the thing.
To find the password that this script asks for, you can use a simple debugging trick.
Go to JSFuck and uncheck the Eval Source option.
It seems to be calling prompt(), so put a breakpoint on it, like this:
(I'll be ...
I'm not sure whether this is along the lines you're looking for (and quite possibly you've already figured out all of this and more), but here's a crude formalization and then some implementation thoughts. Conceptually, this tries to separate what it means to entangle several values from how entangled values are represented.
I wouldn't say that obfuscation detection is strictly related to entropy.
When I detected obfuscated code areas I did it by simple statistical comparison of probabilities of appearances of specific assembly commands.
For example number of jump related commands will be significantly larger in a binary with control flow obfuscation.
Number of arithmetic ...
There are ways to make a Python program hard to reverse engineer. Its' possible but you need to fiddle with the Python source code (which is written in C) and compile a special build for your purpose.
The way Python works is fully documented and open-source. For instance, consider the pyc file format. Much of the code which deals with reading/writing pyc's ...
I do not think code morphism is the or an answer to this question.
What the question was about is obfuscating the algorithm implementation by using less common or undocumented assembly instructions. This can actually be done by some compilers when extensive optimizations are turned on. For example compilers like the Intel C Compiler, GCC, or PGI can ...
The address of sub_1313cba4 is moved to PC/IP but not directly, as this cannot be done. It is done by pushing the address to the stack and relying on the fact that retn will get what's on the top of the stack and redirect the execution there.
Well, it depends on what you mean by damaging the stack. The stack is just a place in memory and the damage can only ...
Stripping line numbers has a minimal impact on the difficulty of reverse engineering code. If it is causing you problems, I would recommend disabling it.
Col-E's answer is a red herring because it is fairly easy for a reverse engineer to insert synthetic line numbers into the bytecode to disambiguate stack traces (assuming they don't just rename the methods ...
This problem comes from the way objdump disassemble a binary. The technique used here is called linear sweep, it is done by starting at the beginning of each symbol in all the sections that are flagged as CODE and disassemble instruction after instruction, supposing that what follow an instruction is also an instruction. The problem with this disassembly ...
Any obfuscation technique (or its formalization) targets one or more assumptions made by some class of analyses A -- in essence, the obfuscation transforms a program P0 into a different representation P1 that has the same execution behavior as P0 but which violates the assumptions made by the analyses A. In doing so, the obfuscation necessarily defines a ...
As others have said, this is for getting current instruction's address. But it's not recommended as it'll hurt performance because it won't return anywhere, causing disagreement of return addresses in data stack and in the CPU's internal calling stack
The recommended way is
mov eax, [esp]
Epic Marketing Technique!
When you look at their cheaper product you see it has it HPF of 5. Throwing with numbers or something people understand is a common trick when trying to sell something customers don't understand but want (e.g. IT security, volcano insurance).
But a rating of 35 is high. And hardly seen in the industry, other known packers like UPX,...
There are a number of ways to accomplish what you've stated. Generally, more robust techniques, while affording a higher level of protection, will also put more burden on the programmer creating the software. So in approximately increasing order of difficulty, here are some ideas:
Store the data non-contiguously
The simplest approach is to simply not ...
Unfortunately it is not enough code to say exactly what it is, but,
as @0xec said, it looks very much like control flow flattening.
Usually such kind of code transformations are done automatically with obfuscators.
There are some obfuscating compilers, and one of them does CFG flattening. As far as I know this compiler is not one-of-a-kind, there are a ...
Metamorphism wasn't used for obfuscation as much as it was used to defeat static AV signatures.
In terms of modern* obfuscation:
A custom virtual machine can be a pain to analyze, especially if it's a custom crafted one (as opposed to something like VMProtect which is more widely studied).
Obfuscation that involves code running in the kernel can also be ...
I figured it out! Some of the comments on this web site made me go back and think harder - actually to think differently.
I thought that I should post the analysis that I did on these messages to try to determine the CRC algorighm.
My analysis is based on a paper written by Greg Ewing http://www.cosc.canterbury.ac.nz/greg.ewing/essays/CRC-Reverse-...
I have spent some time to look into Apple's airplay mirroring support, which is encrypted by fairplay protocol. After investigating serveral existing commercial applications I have finally managed to get a way of decrypting fairplay protected streams.
I have extended the shairplay code to demostrate this ability. Please look at https://github.com/foxsen/...