Welcome back.
Let's talk about the decks and decks file format and also the difference between a normal Java instance
and a Java instance on the Android platform, which is regarding to the ARM architecture.
We do this on a very high level approach, so don't worry, we do not dive into the single processor
instructions.
We just take this on a high level approach.
All right.
On the left, we have our Android applications, and those Android applications are written in Java.
And this code gets loaded into the Java virtual machine.
But on the Android platform, it's related to the Dalvik virtual machine.
And there's a difference between our normal Java and this type of Java.
And this is something we want to figure out right now.
So on the right we've got the source code.
And if we run the source code on our laptop, for example, and compile this one, we generate a new
file, which is the main dot class file, and this file stores our Java source code in some kind of
byte format.
Now if you would take this approach onto our Android smartphone, onto this device, for example, right
here, then we would have some troubles because this Java approach would require a lot of more resources.
And if our CPU on the smartphone requires more resources, it will heat up.
And heating up will also mean we use more resources on the device and we also drain the battery dramatically.
And this approach is therefore not working on battery and power devices.
We therefore have on the arm architecture something different.
And what this is, is it's the dalvik executable file format.
So we take the same Java source code, but we compile it for a different architecture, the ARM architecture,
and therefore we also compile it in a different byte format.
In our case, this one is now called Dalvik executable format and we will generate those classes.
Text File.
I know this animation is super sick, so those classes don't contain also the Java bytecode, but now
in the Dalvik executable format and this format is designed to work on battery, empower devices on
the arm architecture and therefore does not run the battery that dramatically and also do not require
a lot of more resources.
And this is the approach by.
And this is also the reason why pretty every smartphone is running in the market.
And this is the reason why every and this is the reason why pretty every smartphone is running an arm
CPU in and this is the reason why every smartphone device out there has an arm CPU in there.
There are, of course, disadvantages to this architecture.
But regarding to a battery and power device, it's absolutely brilliant to use it in this way.
And yeah, this is the difference between x86 and arm in a nutshell on a very high level approach.
So what I would like to point out right here is that your PC or your laptop is running on a different
architecture than your mobile device.
And the reason behind this is that your smartphone needs to rely on a battery pack instead of your constant
voltage or ampere out of a power supply.
And therefore, it has to be designed in a different architecture.
And this is the reason why the Java source code has also to be designed a little bit different.
All right.
Now it has this odd X file format.
And what is this old X file format?
Well, it's not that complicated.
It's simply just an optimized text file format.
And we can use a command to put this old X file format back to a text file format.
And therefore, this really doesn't affect us at all during our reversal process.
So we just have to convert this from this old, this optimized text file format to in text file format,
and then we are on our basic approach and can analyze this file.
All right.
Now, there's also one last thing I want to point out, and this is something regarding to the classes
text file.
So your class is the text file can only contain 65,535 methods.
And if you would write more methods, then you will end up in multiplexing.
And you might have encountered or seen those files because we've got the class text and in the same
directory we have a class as to text file.
And this is the reason for those split up dalvik executable files.
It's regarding to the amount of methods and now you might think of yourself, wait, what?
Whoever wrote 65,535 methods into one application?
Yeah, I guess this is pretty ridiculous.
But it also affects, of course, libraries, frameworks and the Android system itself.
So meanwhile, by importing some libraries, you really end up easily by having multiple text files,
because all those libraries contain a lot of methods, even if you do not use them.
And the important thing right here is if we reverse engineer and analyze those applications, we need
to make sure that we analyze all classes, not X files, because we cannot tell if our necessary information
are in classical text or in classes.
Two dot x or yeah, how many files we get right there.
Therefore, we need to analyze all of them.
And now you also know why we have multiple text files.
And so we figured out the difference between a PC or laptop, which has a constant power supply and
a smartphone which needs to rely on a battery pack.
And this difference also affects the operation system of this device.
And we also have learned that the class store text is also just a Java bytecode format, but we are
optimized for this architecture, this platform, and we also know why there can be multiple text files.
And that's all what we need to understand for this section.