Imported from firebitsbr/Writeups-claudeskills (claudeskills/writeup-christinec-dev/SKILL.md). Install upstream with npx skills add firebitsbr/Writeups-claudeskills --skill writeup-christinec-dev. Copyright stays with the author.

name: writeup-christinec-dev description: CTF writeups and security challenges by christinec-dev.

Writeups by christinec-dev

Source repository: /repos/christinec-dev

Repository Index

DIVA_APK_Writeups/README.md
DIVA_APK_Writeups/Harcoding Issues/README.md
DIVA_APK_Writeups/Insecure Logging/README.md
DIVA_APK_Writeups/Insecure Data Storage/Part Four/README.md
DIVA_APK_Writeups/Insecure Data Storage/Part One/README.md
DIVA_APK_Writeups/Insecure Data Storage/Part Three/README.md
DIVA_APK_Writeups/Insecure Data Storage/Part Two/README.md
DIVA_APK_Writeups/Input Validation Issues/Part 1/README.md
DIVA_APK_Writeups/Input Validation Issues/Part 2/README.md
DIVA_APK_Writeups/Input Validation Issues/Part 3/README.md
DIVA_APK_Writeups/Access Control Issues/Part 1/README.md
DIVA_APK_Writeups/Access Control Issues/Part 2/README.md
DIVA_APK_Writeups/Access Control Issues/Part 3/README.md

Writeup Content

File: DIVA_APK_Writeups/Access Control Issues/Part 1/README.md

Part One

If you've seen any of my previous write-ups on the DIVA APK's, you would know that today we are going to cover the last and final section: Access Control Issues. Access Control Issues arise when we, as normal users, can gain access to data that we are not suppose to access either directly or via malicious methods. This is mostly due to poor data/access protection mechanisms put in place by developers. 🤠

Now, with this section there are three parts. Without any further lollygagging, let's jump into it!

gif

Access Control Issues - Part One

When we open the Access Control Issues - Part 1 section on our device we are met with the following objective: try to access the API credentials from outside the app. This means that instead of just clicking the View API Credentials button, we should try and access the credentials on the activity using other methods, such as via the terminal.

DIVA Access Control Issues

For coverage sake, this is what happens when we do press the View API Credentials button directly. We can see that we get instant access to credentials that we shouldn't have access to! DIVA Access Control Issues

Okay, let's start with the fun things. Let's see if we can see what happened in our LogCat after we opened the api credentials. LogCat is powerful since it can reveal useful information for us as the attacker, such as the activity that was opened, which we can use to exploit. Open up your terminal using CTRL + ALT + T and enter the following command.

adb shell logcat

DIVA Access Control Issues DIVA Access Control Issues

We can see that it opens an activity called .APICredsActivity. Let's open jadx.gui and see if we can see where the activity pulls the credentials from. DIVA Access Control Issues DIVA Access Control Issues

Okay, so the data is hardcoded. Now that we know which activity is used to store the hardocded api credentials, we can use the terminal to bypass the "View API Credentials" button and show us the credentials directly. In other words, we will start the activity's Intent directly from the terminal. 👾

adb shell am start -n jakhar.aseem.diva/.APICredsActivity

amis used to manage the activity.
start is used to start the activity.
-n is used to indicate the name of the activity to open (.APICredsActivity).

DIVA Access Control Issues

Hooray! When we go back to our application we can see that we have successfully opened the activity and revealed the credentials without pressing the button! DIVA Access Control Issues

File: DIVA_APK_Writeups/Access Control Issues/Part 2/README.md

Part Two

Now, with this section there are three parts. Without any further lollygagging, let's jump into it!

gif

Access Control Issues - Part Two

When we open the Access Control Issues - Part Two section on our device we are met with the following objective: try to access the API credentials from outside the app without knowing the pin. This means that we cannot go ahead and just view the registered credentials via the interface, nor can we register new credentials, but we should try and access the credentials on the activity using other methods, such as via the terminal (just like before). DIVA Access Control Issues

For interest sake, this is what happens when we click the already registered button:

DIVA Access Control Issues DIVA Access Control Issues

We can see that we get immediate access to the API credentials. When we click the register now button, we are prompted to enter a pin after registering. We cannot register, as this feature does not exist! 😆 DIVA Access Control Issues DIVA Access Control Issues DIVA Access Control Issues

Okay, as we learnt previously LogCat will show us everything we need to know. Let's open up our terminal and run the same command as before.

adb shell logcat

DIVA Access Control Issues

We can see that it returns the .APICreds2Activity activity that opened the API credentials layout when we launched the section layout.Let's head into JADX-GUI and open up this activity to see what we can find in the source code. DIVA Access Control Issues

As we can see, this value was also hardcoded - but this time there is a difference. We can see that we need a pin to access the credentials, whereas previously we had direct access. We will need to bypass this pin check. DIVA Access Control Issues

Okay, from here on we need to disable our authentication checks so that we can just view our ./APICreds2Activity activity without having to do a pin check. I recommend having a look at this ADB Command List before you continue. Go back to your terminal and enter the following command:

adb shell am start -n jakhar.aseem.diva/.APICredsActivity -a jakhar.aseem.diva.action.VIEW_CRED2 --ez check_pin false

amis used to manage the activity.
start is used to start the activity.
-n is used to indicate the name of the activity to open (.APICredsActivity).
-a is used to view our credentials. It's syntax elaborates better: -a .
--ez check_pin false is used to bypass the checks made by the application at the receiving side so we don't need a pin.

DIVA Access Control Issues

And as easy as 123, when we head back to our application we can see that our activity launched. We have completed our activity objective! DIVA Access Control Issues

File: DIVA_APK_Writeups/Access Control Issues/Part 3/README.md

Part Three

Now, with this section there are three parts. Without any further lollygagging, let's jump into it!

gif

Access Control Issues - Part Three

When we open the Access Control Issues - Part Three section on our device we are met with the following objective: try to access the private notes from outside the app without knowing the pin. This means that we cannot go ahead and just create a pin to access the notes, but we should try and access the notes using other methods (not necessarily by launching the activity as prior), such as via the terminal (we know Christine, we know).

DIVA Access Control Issues

For interest sake, this is what happens when we register a pin (I entered a basic 1234 pin):

DIVA Access Control Issues DIVA Access Control Issues DIVA Access Control Issues

Let's open up our terminal and see what activity our LogCat reveals to us.

adb shell logcat

DIVA Access Control Issues DIVA Access Control Issues

We can see that it logs two activities, ./AccessControl3Activity and ./AccessControl3NotesActivity. Let's open up our **JADX-GUI **and have a look at both.

DIVA Access Control Issues DIVA Access Control Issues

We can see our AccessControl3Activity stores our pin via a SharedPreferences object, which we covered way back when. When we enter the pin saved in shared_prefs, it launches the AccessControl3NotesActivity activity which validates this pin before showing the notes via a query(NotesProvider.CONTENT_URI) content query. This content provider will dump all of the notes, and allow us to meet our objective.

We can dump this content provider via the following command in our terminal:

adb shell am content query --uri content://jakhar.aseem.diva.provider.notesprovider/notes/

DIVA Access Control Issues

Thus we have accessed all the notes from outside of the application, without having to register for a pin or launch the activity as before. DIVA Access Control Issues

Conclusion

Congratulations, you have successfully completed all the sections of the DIVA APK! 🥳

gif

I hope this was easy enough to follow/understand. If you have recommendations on any cool tools, techniques, or tutorials that I too can follow feel free to leave them below and I'll check it out! 😊

File: DIVA_APK_Writeups/Harcoding Issues/README.md

Harcoding Issues

If you've read my previous tutorials(or write-ups), you would know that I have started dabbling in the world of hacking, with my most recent write-ups focusing primarily on Android Pentesting. I've shown you how to install Genymotion & Virtualbox, JADX-GUI & ADB, and Android Studio on Parrot OS - but today we will go beyond just installing tools. Today we start hacking, kind of.

First things first, I need to make sure that we are on the same page. What is Android Pentesting? Simply put, it is a simulated cyber attack against a mobile application where we try to expose and find any vulnerabilities or security issues that are present in the application. In the following days to come, we will be Pentesting the DIVA APK, which I explain and demonstrate how to install and set up on an emulated device in this tutorial.

Before we start make sure that you have the following:

Android Studio Installed.
Genymotion and Virtualbox installed, with an emulated device setup and running.
ADB is installed with DIVA APK installed onto the device.
JADX-GUI is installed and open.

Okay, let's get hacking! When we open the DIVA application on our device, we can see that it consists of a menu or navigation that lists many sections for us to Pentest.

Diva Interface

In this section, we will be testing the Hardcoding Issues (Part 1 & 2) sections of this application.

Hardcoding Issues Part One

When a programmer hardcodes a value, it means that they type it into the application, making it a static value. For example:

var password = "iamnotsecure";

This is not only bad from a programming perspective since the developer will have to manually change this value every time they want to update it, but from a security perspective, it allows attackers to easily exploit or hijack firmware, devices, systems, and software.

When we open the Hardcoding Issues Part One section we are met with the following objective: find out what is hardcoded and where. So, we are expected to find what is being hardcoded and where. From the get-go, we can immediately identify what will be hardcoded: the vendor key.

Hardcoded part 1

On to the where. Let's head into JADX-GUI and open up the HardcodeActivity activity to see if we can find anything in the source code.

Hardcoded part 1

Immediately we can see that the vendor key is hardcoded, thus we can copy the "vendorsecretkey" value and pop it into our app.

Hardcoded part 1

Voila, we have gained access to the system!🥳

Hardcoded part 1

So, in summary, we were able to find the following:

What: Vendor Secret Key > vendorsecretkey
Where: HardcodeActivity

Hardcoding Issues Part Two

When we open the Hardcoding Issues Part Two section we are met with the following objective: find out what is hardcoded and where. So, we are expected to find what is being hardcoded and where. Just like previously, we can immediately identify what is probably hardcoded just by looking at the activity layout: the vendor key.

Hardcoded part 2

Now on to the where. Let's head into our Hardcode2Activity in JADX-GUI and open it up. We can immediately identify the DivaJni class that is being referenced, as the rest of the code depends on this class to be able to validate the access key.

Hardcoded part 2

Without wasting further time, let's open the DivaJni class. When I first opened it, without properly assessing the code, I saw the string soName = "divajni", and initially I thought this was the hardcoded value. To my dismay, it was not. Silly me, maybe next time I should read the source code fully! 😂

Hardcoded part 2

We can see upon further inspection that the static function loads the native library of soName, which is a library named divajni. Since we can assume that it calls upon a Shared Library, we can go looking for a file named "divajni.so". The .so extension identifies a Shared Object library that may be dynamically loaded during Android runtime.

Mmh, so we are looking for a library containing "divajni.so" in our lib folder within our APK file. Go to where you installed your DIVA APK and extract the file (to do this easily, just replace .apk with .zip and extract like normal). Once extracted, open it up and go lib > any one of the folders > libdivajni.so.

IMPORTANT NOTE: You can also access this library file via the terminal without having to extract the file and navigate to it like this:

Image description

Hardcoded part 2

You can copy this library file to your Desktop or anywhere with easy access. Open up your terminal using CTRL + ALT + T and cd into Destkop. Make sure your libdivajni.so file is there by entering the ls command.

Hardcoded part 2

To be able to view the text inside a binary or data file such as our library file, we need to use the strings command. Enter it as such: strings libdivajni.so. We can see a list of words popping up, mainly packages and extended libraries. If you look at it, most of them have a similar format: .x, _x, __x, x.so, etc. There is one string that stood out to me, because why would it have a semi-colon? Why? None of the other strings have semi-colons!

Hardcoded part 2

Let's try entering it as our vendor key. Please note that this process is trial-and-error. Sometimes we might not be so lucky as to identify a clear outlier in a string list as in this scenario. If we enter it into our app, we get a popup saying we have gained access, and success!

Hardcoded part 2

So, in summary, we were able to find the following:

What: Vendor Secret Key
Where: libdivajni.so > olsdfgad;lh

Conclusion

Congrats, we have finished the first two sections of the DIVA APK! I hope this was easy enough to follow/understand. I'll see you next time with Section 3: Insecure Data Storage.😊

If you have recommendations on any cool tools, techniques, or tutorials that I too can follow feel free to leave them below and I'll check it out!

Input Validation Issues - Part One

With another day gone, it is time for another Android Pen-test write-up. Today we are going to cover the fourth section of the DIVA APK, Input Validation Issues. When we have an application that does not validate input properly, it makes it easier for an attacker to go ahead and creating input that is not expected by the rest of the application. This has dire consequences, ranging from altered data, arbitrary code execution, or unauthorized data access. Not good!

When you're ready, put on your favorite hoodie and grab your nearest drink, and let's get HACKING! 👾

Image description

When we open the Input Validation Issues - Part 1 section on our device we are met with the following objective: try to access all user data without knowing any username. There are three users by default and your task is to output data of all three users with a single malicious search.

Let's take note of the key to this objective: malicious search. We also see a little hint, which tells us that there are three users in the database, where one is an admin. Image description

Since we are working with a database, we are most likely going to have to create a SQL Injection, but before we get to that, let's see what happens if we enter any username (without knowing the true values).

Image description

When we enter an random/guessed value, we can see that no user gets returned. Yet, when we enter admin, we can see that it returns the details of the admin user! 👀

Image description

Now that we know that admin is most definitely a user, we can use this to construct our SQL Injection command. But, before we do this, I want to cheat a little bit and go snoop around in our database files to see if we can see the three users that we need to return with our command.

If you want to do this, open up your terminal via CTRL + ALT + T and enter the following commands:

adb shell
su
cd data/data/jakhar.aseem.diva/databases

> qlite3 (To enter this option start typing sql, press TAB + Enter)
> .open sqli
> .tables
> .table sqliuser
> .dump sqliuser

Image description

We can see that we need to construct a command to return the users admin, diva, and john. Head back into your application, because we are about to write the most genius, original, most hackery SQL Injection command ever!

''admin' OR 1=1;--

' indicates the start of our query
'admin' we know this is already a user in the database.
OR 1=1; since 1=1 is always true, the query will return all items.
-- comments out the rest of our query.

Image description

DUHN DUHN DUUUUUHN, we've successfully dumped their database table! Wasn't that fun? 😀

Congratulations, you have successfully completed the first part of the DIVA Input Validation Issues! 🥳

File: DIVA_APK_Writeups/Input Validation Issues/Part 2/README.md

Input Validation Issues - Part Two

When you're ready, put on your favorite hoodie and grab your nearest drink, and let's get HACKING! 👾

Image description

When we open the Input Validation Issues - Part 2 section on our device we are met with the following objective: try accessing any sensitive information apart from a web URL.

Let's take note of the important part in this objective, which is to NOT access information from a web URL - so don't go trying to hack Google or your favorite site! We need to access local data. 😂

Image description

Now, before we continue, I need to confess something. I made an oops and had to clean install all of my tools. This means that all those tmp files and shared_prefs we created in the pervious writeups are all gone. Not to worry, because I'm going to work around it. 🤠

Let's go into our APK and see what sensitive data we can exploit. If you aren't me, and you still have your tmp file, you can easily use that file. I will instead create a "secret" file that will contain some user data. We will then use this file to see if we can access it in the application. Open up your terminal and do the following:

adb shell
su
cd data/data/jakhar.aseem.diva/
echo "password:123; username:alex" > private.txt
cat private.txt

Image description

with our file created, and our sensitive data stored locally on our device, we can now go back to our application and try to access our private.txt file via input. Let's navigate to that file via:

file:///data/data/jakhar.aseem.diva/private.txt

When we hit view, we can see that our data is revealed! 🙃

Image description

Congratulations, you have successfully completed the second part of the DIVA Input Validation Issues! 🥳

File: DIVA_APK_Writeups/Input Validation Issues/Part 3/README.md

Input Validation Issues - Part Three

When you're ready, put on your favorite hoodie and grab your nearest drink, and let's get HACKING! 👾

Image description

When we open the Input Validation Issues - Part 1 section on our device we are met with the following objective: ...DOS the damn thing! Do not find the code, just crash the app (and then find the root cause of the crash).

Image description

Firsts things first, let's go over what a DOS attack is. A Denial-of-Service (DOS) attack is an attack that has the intention of shutting down a system, which in turn makes it inaccessible or slow. We perform DOS attacks by flooding the target with traffic or large volumes of information that causes the system to crash.

Now, we can go about this in various ways, but for this writeup let's do it the most basic way: by entering a large amount of data into the input and pushing the red button!

To make the app crash, I simply just spammed my keyboard with 0 until the input no longer accepted my string length, and voila, it worked!

Image description Image description

Okay, so we successfully completed the first part of the objective, which was to crash the app via a DOS attack. Let's head into Android Studio, or alternatively you can use the adb logcat command in your terminal (but I like the pretty AS colors 😆), to see what our log returned.

Image description

Now, there's a lot going on here, and it's easy to get overwhelmed, but let's focus on our error code SIGSEGV. I highlighted the SIGSEGV code because it is is important since it indicates a segmentation fault in Linux containers. Simply put, we get this code since our application tries to read/write outside of the memory allocated for it or when writing memory which can only be read.

Let's open up our JDX-GUI (jadx-gui) and see what our source code says. When we open up our InputValidation3Activity, we recognize a class (Divajni) that we had to use way back when in our hardcoding issues writ-eups. We can see that it uses this value to initiate our launch sequence.

Image description

Let's open up Divajni. We get greeted again by soName, which we know has something to do with our libdivajni.so file.

Image description

Okay, now from here on we can open up our terminal and see if we can find something in our libdivajni.so file that is odd - or related to our error code. We won't have to scroll to far before we identify the culprit: strcpy. Image description

Though we cannot access it to see how it is used, strcpy is a common culprit when it comes to segmentation faults. This is because the strcpy() code is suitable handling for small inputs, but not for large ones such as the input we used for our DOS attack.

Congratulations, you have successfully completed the third part of the DIVA Input Validation Issues! 🥳

File: DIVA_APK_Writeups/Insecure Data Storage/Part Four/README.md

Part 4

If you've read my previous writeup where I covered Logging and Hardcoding Issues (1 & 2) on the DIVA APK, then get ready for the next one. I hope you have your tools open, because today we are going to find all the Insecure Data Storage vulnerabilities in the DIVA APK!😁

So the DIVA APK has four sections to test for Insecure Data Storage. Insecure Data Storage vulnerabilities occur when programmers assume that users, malware, or attackers will not have access to a mobile device’s filesystems and sensitive information that is stored on the device or APK. The problem arises when filesystems are easily accessible. Attackers, or us in this case, can root or jailbreak mobile devices or APK's and view application data - ultimately, sensitive application data.

Without any further lollygagging, let's jump into it!

Image description

Insecure Data Storage - Part 4

When we open the Insecure Data Storage - Part 4 section we are met with the following objective: find out where/how the credentials are being stored and the vulnerable code. So, we are expected to find where the credentials are being stored, how it is stored, and the vulnerable code.

Image description

Let's first start with inserting information into the form. We get a popup saying that our credentials has been saved,and that's about it. Again, not much to it, so let's see if we can find where it saved our credentials.

Image description

Open up JADX-GUI and navigate over to the InsecureDataStorage4Activity.

Image description

From here we can see that our data is being stored in something called Environment.getExternalStorageDirectory(). No worries, this only means that it is saving our file as .uinfo.txt to our devices' SDCard.

Image description

The SDCard will be saved under our root directory. I will show you how to access this file I via two methods: how to access it in Android Studio, and how to access it via the terminal.

Method One: Android Studio

Open up Android Studio and select the Device Manager bar on the right-side of your window. Then head into the File Explorer and navigate to the following directory: sdcard. From here we can see that our file is there, labeled as .uinfo.txt.

Image description Image description

Double click your .uinfo.txt file. You can now read the data!

Image description

Method Two: Terminal

Open up your terminal via CTRL + ALT + T and start a adb shell via the adb shell command. From there on we can go:

su
cd sdcard

Image description

When we list the files we can see our .uinfo.txt file. To read the contents of the .uinfo.txt file, we can simply say cat .uinfo.txt. Now we know all it's dirty little secrets!

Image description

So, in summary, we were able to find the following:

Where: sdcard > .uinfo.txt
How: FileWriter(File)

Congrats, we have finished the fourth part of Insecure Data Storage of the DIVA APK! I hope this was easy enough to follow/understand. If you have recommendations on any cool tools, techniques, or tutorials that I too can follow feel free to leave them below and I'll check it out!

File: DIVA_APK_Writeups/Insecure Data Storage/Part One/README.md

Part 1

Without any further lollygagging, let's jump into it!

Image description

Insecure Data Storage - Part 1

When we open the Insecure Data Storage - Part 1 section we are met with the following objective: find out where/how the credentials are being stored and the vulnerable code. So, we are expected to find where the credentials are being stored, how it is stored, and the vulnerable code.

Image description

Let's first start with inserting information into the form. We get a popup saying that our credentials has been saved,and that's about it. Not much to it, so let's see if we can find where it saved our credentials.

Image description

Let's go ahead and pen up JADX-GUI and navigate over to the InsecureDataStorage1Activity. From here we can see that our data is being stored in a SharedPreferences object. A SharedPreferences object points to a file that contains key-value pairs and provides simple methods to read and write them. Each SharedPreferences file is managed by the framework and can be private or shared. A simple example of using a SharedPreference object is saving the user's preferred background color for the application.

Image description Image description

Usually, the SharedPreference file will be saved under ../data/data/name.company.com/shared_prefs/.. and to access or view this SharedPreference file I will show you two methods: how to access it in Android Studio, and how to access it via the terminal.

Method One: Android Studio

Image description Image description

Double click on jakhar.aseem.diva_preferences.xml, and voila, we have access to the data via Android Studio!

Image description

Method Two: Terminal

Open up your terminal via CTRL + ALT + T and start a adb shell via the adb shell command. ADB Shell will allow us to access the device's files and manipulate the device via the terminal. We need to get super-user access, which is ultimate Darth Vader access, by entering to su command.

Image description

Let's go ahead and list our files on the device via the ls command, and from here on we can navigate to the directory as we did in Android Studio:

cd data
cd data
cd jakhar.aseem.diva
cd shared_prefs

Image description Image description ... Image description Image description

Finally, we can read the data by entering the cat jakhar.aseem.diva_preferences.xml command. And we're done!

Image description

So, in summary, we were able to find the following:

Where: shared_prefs > jakhar.aseem.diva_preferences.xml
How: SharedPreferences() object

Congrats, we have finished the first part of Insecure Data Storage of the DIVA APK! I hope this was easy enough to follow/understand. If you have recommendations on any cool tools, techniques, or tutorials that I too can follow feel free to leave them below and I'll check it out!

File: DIVA_APK_Writeups/Insecure Data Storage/Part Three/README.md

Part 3

Without any further lollygagging, let's jump into it!

Image description

Insecure Data Storage - Part 3

When we open the Insecure Data Storage - Part 3 section we are met with the following objective: find out where/how the credentials are being stored and the vulnerable code. So, we are expected to find where the credentials are being stored, how it is stored, and the vulnerable code.

Image description

Open up JADX-GUI and navigate over to the InsecureDataStorage3Activity. From here we can see that our data is being stored in a FileWriter object that is being stored as uinfotmp - so we are looking for a file with a (tmp) ending.

Image description Image description

The FileWriter tmp file will be saved under ../data/data/name.company.com/.. and to access or view this uinfo file I will show you two methods: how to access it in Android Studio, and how to access it via the terminal.

Method One: Android Studio

Open up Android Studio and select the Device Manager bar on the right-side of your window. Then head into the File Explorer and navigate to the following file (data > data > jakhar.aseem.diva. From here we can see that our file is there, labeled as something similar to uinfoxxxxxxxxxxxxtmp.

Image description Image description

Double click your uinfotmp file. You can now read the data!

Image description

Method Two: Terminal

Open up your terminal via CTRL + ALT + T and start a adb shell via the adb shell command. From there on we can go:

su
cd data
cd data
cd jakhar.aseem.diva

Image description

When we list the files we can see our uinfotmp file. To read the contents of the uinfotmp file, we can simply say cat uinfoxxxxxxxxxxxxtmp (replace uinfoxxxxxxxxxxxxtmp with your filename), and you are set!

Image description

So, in summary, we were able to find the following:

Where: jakhar.aseem.diva > uinfotmp
How: FileWriter(File)

Congrats, we have finished the third part of Insecure Data Storage of the DIVA APK! I hope this was easy enough to follow/understand. If you have recommendations on any cool tools, techniques, or tutorials that I too can follow feel free to leave them below and I'll check it out!

File: DIVA_APK_Writeups/Insecure Data Storage/Part Two/README.md

Part 2

Without any further lollygagging, let's jump into it!

Image description

Insecure Data Storage - Part 2

When we open the Insecure Data Storage - Part 2 section we are met with the following objective: find out where/how the credentials are being stored and the vulnerable code. So, we are expected to find where the credentials are being stored, how it is stored, and the vulnerable code.

Image description

Open up JADX-GUI and navigate over to the InsecureDataStorage2Activity. From here we can see that our data is being stored in a SQLiteDatabase object - so we will be looking for a database file!

Image description Image description

Usually, the SQLiteDatabase database files will be saved under ../data/data/name.company.com/databases/.. and to access or view this database file I will show you two methods: how to access it in Android Studio, and how to access it via the terminal.

Method One: Android Studio

Open up Android Studio and select the Device Manager bar on the right-side of your window. Then head into the File Explorer and navigate to the following file (data > data > jakhar.aseem.diva > databases). From here we can see numerous database files, but just looking at the name we can deduce that "ids2" (id) will be more valuable to look at than "diva notes". So, let's have a look at ids2.

Image description Image description

Right click and save ids2 to a place on your desktop that you feel comfortable with. Once saved, open up your browser and head over to SQLite Viewer so that we can view the contents of our database. Pop in your ids2 file. We can see that there are two tables.

Image description

Let's open the myuser table. We can now see our credentials!

Image description

Method Two: Terminal

Open up your terminal via CTRL + ALT + T and start a adb shell via the adb shell command. From there on we can go:

su
cd data
cd data
cd jakhar.aseem.diva
cd databases

Image description

When we list the files in our databases directory, we can see that the ids2 file is there. To read it, we need to first enter the qlite3 command (enter it by typing sql and hit TAB and enter).

Image description Image description

From there on we need to open up the ids2 database file via the .open ids2 command. If we list all the tables via the .tables command we can see that myuser is one of them. We can then "cd" into the myuser tables via the .tables myuser command.

Image description

To read the contents of the myuser table, we can simply say .dump myuser, and congrats, you've successfully cracked that bad boy open! 😎

Image description

So, in summary, we were able to find the following:

Where: databases > ids2
How: SQLiteDatabase mDB

Congrats, we have finished the second part of Insecure Data Storage of the DIVA APK! I hope this was easy enough to follow/understand. If you have recommendations on any cool tools, techniques, or tutorials that I too can follow feel free to leave them below and I'll check it out!

File: DIVA_APK_Writeups/Insecure Logging/README.md

Insecure Logging

Before we start make sure that you have the following:

Android Studio Installed.
Genymotion and Virtualbox installed, with an emulated device setup and running.
ADB is installed with DIVA APK installed onto the device.
JADX-GUI is installed and open.

Okay, let's get hacking! When we open the DIVA application on our device, we can see that it consists of a menu or navigation that lists many sections for us to Pentest.

Diva Interface

In this section, we will be testing the Insecure Logging section of this application.

Insecure Logging

When we open the Insecure Logging section we are met with the following objective: find out what is being logged where/how and the vulnerable code. So, we are expected to find what is being logged, how it is logged, and the vulnerable code.

Insecure Logging

Let's try and answer these objectives one by one. From first impressions, just by looking at the activity layout (which is the page opened on our screen), we can see that it asks us for our credit card numbers. Thus, our credit card number is probably the data that is being logged (what). Let's test this by entering a number!

Insecure Logging

With our number entered, we get an error popup. Let's see if we can see how it is being logged, ie. where did our data go? The first culprit that we can look at is LogCat in Android Studio. Open up Android Studio and navigate over to the LogCat Output. We can see that it logs everything, which is bad because say we have a user that downloads a malicious APK that secretly monitors their log when they use the app - the attacker can then use this monitored log to read sensitive data, and exploit them in this way.

When we scroll down, we see that our credit card number has been logged. BAD LOGCAT! Now we know how it is being logged, via the LogCat Output in Android Studio underneath a log labeled diva-log.

Insecure Logging

Finally, we need to find the vulnerable code. Easy peasy, just load up your DIVA APK into JADX-GUI and open up the LogActivity activity.

Insecure LoggingInsecure Logging

When we look at the code, we can identify the section where it does the actual logging, thus confirming that it is logging our credit card number. Maybe logging sensitive information is not the best way to capture this information?

Insecure Logging

So, in summary, we were able to find the following:

What: Credit Card Number
Where: LogCat > diva-log
How: Log.e()

Conclusion

Congrats, we have finished the first two sections of the DIVA APK! I hope this was easy enough to follow/understand. I'll see you next time with Section 2: Hardcoding Issues.😊

If you have recommendations on any cool tools, techniques, or tutorials that I too can follow feel free to leave them below and I'll check it out!

DIVA APK Full Android Writeup for Parrot OS

Hey there! Welcome to my repo. This repository contains Android Pentesting writeups of the DIVA APK for Parrot OS. If you are unsure of what the DIVA APK is, please visit the owners GitHub repository first: diva-apk-file. 😁

About

name: writeup-christinec-dev description: CTF writeups and security challenges by christinec-dev.

Writeups by christinec-dev

Repository Index

Writeup Content

File: DIVA_APK_Writeups/Access Control Issues/Part 1/README.md

Part One

Access Control Issues - Part One

File: DIVA_APK_Writeups/Access Control Issues/Part 2/README.md

Part Two

Access Control Issues - Part Two

File: DIVA_APK_Writeups/Access Control Issues/Part 3/README.md

Part Three

Access Control Issues - Part Three

Conclusion

File: DIVA_APK_Writeups/Harcoding Issues/README.md

Harcoding Issues

Hardcoding Issues Part One

Hardcoding Issues Part Two

Conclusion

File: DIVA_APK_Writeups/Input Validation Issues/Part 1/README.md

Input Validation Issues - Part One

File: DIVA_APK_Writeups/Input Validation Issues/Part 2/README.md

Input Validation Issues - Part Two

File: DIVA_APK_Writeups/Input Validation Issues/Part 3/README.md

Input Validation Issues - Part Three

File: DIVA_APK_Writeups/Insecure Data Storage/Part Four/README.md

Part 4

Insecure Data Storage - Part 4

Method One: Android Studio

Method Two: Terminal

File: DIVA_APK_Writeups/Insecure Data Storage/Part One/README.md

Part 1

Insecure Data Storage - Part 1

Method One: Android Studio

Method Two: Terminal

File: DIVA_APK_Writeups/Insecure Data Storage/Part Three/README.md

Part 3

Insecure Data Storage - Part 3

Method One: Android Studio

Method Two: Terminal

File: DIVA_APK_Writeups/Insecure Data Storage/Part Two/README.md

Part 2

Insecure Data Storage - Part 2

Method One: Android Studio

Method Two: Terminal

File: DIVA_APK_Writeups/Insecure Logging/README.md

Insecure Logging

Insecure Logging

Conclusion

File: DIVA_APK_Writeups/README.md

DIVA APK Full Android Writeup for Parrot OS

Section Navigation

Use it

Manifest

Reviews