DEV Community: Ali Zaib

I Spent Three Weeks Reverse Engineering a Mobile App’s API — Here’s What It Took

Ali Zaib — Sat, 20 Jun 2026 09:05:56 +0000

A while back, a client asked me a deceptively simple question: "Can you find out how our competitor's mobile app talks to its backend?"

No public API docs. No Postman collection floating around GitHub. Just a Flutter app, a few permissions in the manifest, and a backend that clearly wasn't expecting anyone to come knocking.

I said yes before I fully understood what I was signing up for.

The First Wall: Flutter Doesn't Decompile Like a Normal App

If you've reverse engineered a native Android app before, you know the drill — pull the APK, run it through a decompiler, read mostly-readable Java or Kotlin, find the API calls, done in an afternoon.

Flutter apps don't play by those rules. The business logic isn't sitting in readable bytecode — it's compiled down to a Dart AOT (ahead-of-time) snapshot, a chunk of near-opaque machine code that standard decompilers just shrug at. Tools like jadx show you the Android shell around the app, but the actual logic — the part that mattered — was somewhere else entirely, encoded in a format almost nothing in the public tooling ecosystem handles well.

That was the first sign this wasn't going to be an afternoon job.

Going Lower: Snapshot Parsing and Runtime Hooking

I ended up going two layers deeper than I'd planned.

First, static analysis of the Dart snapshot itself — figuring out how Flutter lays out compiled functions and objects in memory, well enough to start identifying where the authentication logic actually lived inside this blob of machine code.

Second, once static analysis hit its ceiling, I moved to dynamic instrumentation — attaching to the running app and hooking functions as they executed, watching real values flow through real function calls instead of guessing from disassembly. This is where things got genuinely interesting: confirming hypotheses by intercepting live execution rather than reading static bytes is a completely different skill than traditional reverse engineering, and most of the public writeups on Flutter analysis stop well before this point.

There was also a side quest I didn't expect: the app pinned its own SSL implementation in a way that defeated the usual bypass tools outright. The standard playbook (objection, frida-ssl-pinning-bypass) just didn't work — which meant going up a layer, hooking application logic instead of the network layer, and finding a different way to observe what was actually being sent.

The Wall That Took the Longest

Eventually I could see the request format. I could see that something was signing each request cryptographically before it left the device. What I didn't have yet was the exact signing behavior — and getting it wrong didn't throw a helpful error. It just failed, silently, the same way, no matter what I changed.

I lost more time to that single wall than to everything else in the project combined. The eventual breakthrough came down to one detail buried in how the signing input was constructed — small enough that I'd walked past it a dozen times without seeing it.

I won't go into the specific fix here — partly because it's the most sensitive part of the work, and partly because it's genuinely the best part of the writeup, and it deserves more than a paragraph.

Where the Full Breakdown Lives

This post is the story. The full technical writeup — the Dart snapshot parsing approach, the actual Frida hooking strategy, how I worked around the SSL pinning, and the exact detail that broke the signing wall open — is published on IQCrafter:

Read the full technical breakdown →

If you've fought with Flutter reverse engineering, Dart AOT snapshots, or signed mobile APIs before, I think you'll find it useful — and if you're dealing with something similar right now, that's also exactly the kind of problem my team and I take on.

I'm Ali, a software engineer working on backend systems, mobile security research, and the occasional deep technical rabbit hole. I write about the same kind of work at IQCrafter.

Stop Uploading Your CSV Files to Random Tools — Use This Instead

Ali Zaib — Thu, 26 Mar 2026 19:47:23 +0000

Every backend engineer has hit this at least once.

You export a CSV from the database — users, orders, transactions —
and something is wrong. The import fails. Columns are misaligned.
Excel mangled the encoding. Half the dates are in the wrong format
because the file came from a European locale.

So you do what feels natural: paste it into ChatGPT, or upload it
to some random online converter, just to look at the structure.

And somewhere in the back of your head, something feels off about
that. Because it should.

I built a browser-based CSV Toolkit to fix this

CSV Toolkit on ToolsHubKit
— free, no signup, runs entirely in your browser. The file never
leaves your machine. You can disconnect from the internet and it
still works.

Why CSV is actually hard

CSV looks simple. Values separated by commas, rows by newlines.

Except there's no real standard. RFC 4180 is advisory, and most
exporters partially ignore it. Here's what actually breaks in
production:

Delimiter confusion

Not all CSVs use commas. European Excel uses semicolons (because
the comma is the decimal separator there). MySQL dumps use tabs.
Legacy systems use pipes. Assume the wrong delimiter and every
column is misaligned — and the error is often silent.

Encoding mismatches

Excel on Windows exports Windows-1252 or Latin-1 by default.
Google Sheets exports UTF-8. MySQL defaults to Latin-1. Open a
Latin-1 file in a UTF-8 parser and é becomes Ã©. Fun to
debug at 2am.

The BOM problem

Excel prepends a UTF-8 Byte Order Mark (EF BB BF) to CSV
exports. When parsers don't handle it, your first column header
gets an invisible character prefix. The toolkit strips BOMs
automatically.

Inconsistent column counts

Row 47 has 8 fields. Every other row has 7. The import fails at
row 47 — or worse, silently shifts all data right for the rest
of the file.

Quoted field edge cases

Per RFC 4180, any field containing a comma must be quoted. Many
generators skip this. So Acme Corp, Inc becomes two separate
fields in your import target.

What the toolkit does

Auto-detects delimiter — comma, semicolon, tab, pipe
Handles encoding — UTF-8, Latin-1, Windows-1252, BOM stripping
Instant table preview — see exactly what a parser sees
Highlights malformed rows — inconsistent column counts, unbalanced quotes, escaped field issues
Filters in-browser — keep rows where status = "active", drop PII columns, reorder to match import target schema
Multi-format export — clean CSV, JSON array, Markdown table
Works on large files — 100k+ rows, all local

The import workflow that saves hours

Before any significant data import:

1. Preview first
Drop the file in and scan the first 50–100 rows. Catch structural
issues before they affect the full dataset.

2. Validate column counts
Malformed rows are highlighted immediately. Fix them before the
import, not after it fails at row 50,000.

3. Handle PII
Before sharing any CSV in a ticket or Slack thread — remove
sensitive columns in the toolkit, or run it through the
PII Redactor
for full redaction.

4. Export to JSON if needed
For API testing or JavaScript pipelines, export directly to JSON
array. Validate the structure with the
JSON Formatter
before submitting.

5. Import the cleaned version
Not the raw export. Always the cleaned version.

A 30-second preview step consistently catches the issues that
would otherwise fail halfway through importing 500,000 rows and
leave the database in a partial state.

The privacy argument

Most of us have a vague sense that uploading sensitive data to
random web tools is bad. Let's be specific:

Database exports contain PII almost by default — names, emails,
phone numbers, addresses, payment references. When you upload
that file to an online tool, you have no visibility into:

Where the file goes
How long it's stored
Whether it's logged
Whether it ends up in a training dataset

The CSV Toolkit's client-side architecture isn't a marketing claim
— it's a technical constraint. There's no server to upload to.
The parsing runs in your browser's JavaScript engine, on your
hardware, against your local memory.

Safe for: production database exports, customer data samples,
internal financial reports — anything you'd think twice about
emailing.

Try it

→ CSV Toolkit on ToolsHubKit

Free. No account. No upload. Works offline.

ToolsHubKit has 40+ developer utilities built the same way —
all browser-based, all privacy-first. If you find this useful,
the suite is worth bookmarking.

Built this as a side project. Feedback welcome in the comments
— especially edge cases the parser should handle that it
currently doesn't.

Securing Next.js + Supabase After Switching to NextAuth

Ali Zaib — Sun, 08 Feb 2026 13:36:34 +0000

Securing Next.js + Supabase After Switching to NextAuth

The Problem

I was using Supabase Auth with Google OAuth, but users saw "supabase.co" on the consent screen instead of my app's branding. Custom domains require a paid Supabase plan, so I switched to NextAuth.js.

But here's the catch: Removing Supabase Auth also removed Row Level Security (RLS), which created major security vulnerabilities.

The Security Risk

Without proper implementation, your Supabase database becomes wide open:

// ❌ Anyone can grab your keys from the browser and do this:
const supabase = createClient('YOUR_URL', 'EXPOSED_ANON_KEY')
await supabase.from('users').select('*') // Read everything
await supabase.from('orders').delete() // Delete everything

Why? Because:

Your Supabase keys are exposed in the frontend bundle
No RLS means no access control
Client-side checks can be bypassed

The Secure Solution

All database operations must go through Next.js API routes with proper session validation.

Architecture

Browser → Next.js API Routes → Supabase
            ↓
      Session Check
      Authorization

Step 1: Environment Variables

# .env.local (server-side only)
NEXTAUTH_URL=https://yourdomain.com
NEXTAUTH_SECRET=your-secret
GOOGLE_CLIENT_ID=your-google-id
GOOGLE_CLIENT_SECRET=your-google-secret

# Use SERVICE_ROLE key, not anon key!
SUPABASE_URL=https://your-project.supabase.co
SUPABASE_SERVICE_ROLE_KEY=your-service-role-key

Step 2: NextAuth Configuration

// pages/api/auth/[...nextauth].js
import NextAuth from "next-auth"
import GoogleProvider from "next-auth/providers/google"

export const authOptions = {
  providers: [
    GoogleProvider({
      clientId: process.env.GOOGLE_CLIENT_ID,
      clientSecret: process.env.GOOGLE_CLIENT_SECRET,
    }),
  ],
  callbacks: {
    async session({ session, token }) {
      session.user.id = token.sub
      return session
    },
  },
}

export default NextAuth(authOptions)

Step 3: Secure API Routes

// pages/api/get-data.js
import { getServerSession } from "next-auth/next"
import { authOptions } from "./auth/[...nextauth]"
import { createClient } from '@supabase/supabase-js'

export default async function handler(req, res) {
  // 1. Verify authentication
  const session = await getServerSession(req, res, authOptions)
  if (!session) {
    return res.status(401).json({ error: 'Unauthorized' })
  }

  // 2. Create Supabase client (server-side only)
  const supabase = createClient(
    process.env.SUPABASE_URL,
    process.env.SUPABASE_SERVICE_ROLE_KEY // Never expose this!
  )

  // 3. Query with proper authorization
  const { data, error } = await supabase
    .from('items')
    .select('*')
    .eq('user_id', session.user.id) // Critical: filter by user

  if (error) {
    return res.status(500).json({ error: error.message })
  }

  return res.status(200).json({ data })
}

Step 4: Client-Side Calls

// ❌ NEVER do this in client components
import { createClient } from '@supabase/supabase-js'
const supabase = createClient(url, key) // Exposes keys!

// ✅ ALWAYS call your API routes instead
async function fetchData() {
  const response = await fetch('/api/get-data')
  const { data } = await response.json()
  return data
}

Complete CRUD Example

// pages/api/items/[id].js
import { getServerSession } from "next-auth/next"
import { authOptions } from "../auth/[...nextauth]"
import { createClient } from '@supabase/supabase-js'

export default async function handler(req, res) {
  const session = await getServerSession(req, res, authOptions)
  if (!session) return res.status(401).json({ error: 'Unauthorized' })

  const supabase = createClient(
    process.env.SUPABASE_URL,
    process.env.SUPABASE_SERVICE_ROLE_KEY
  )

  const { id } = req.query

  // GET
  if (req.method === 'GET') {
    const { data, error } = await supabase
      .from('items')
      .select('*')
      .eq('id', id)
      .eq('user_id', session.user.id)
      .single()

    if (error) return res.status(404).json({ error: 'Not found' })
    return res.status(200).json({ data })
  }

  // PUT
  if (req.method === 'PUT') {
    const { title, description } = req.body
    const { data, error } = await supabase
      .from('items')
      .update({ title, description })
      .eq('id', id)
      .eq('user_id', session.user.id) // Verify ownership

    if (error) return res.status(500).json({ error: error.message })
    return res.status(200).json({ data })
  }

  // DELETE
  if (req.method === 'DELETE') {
    const { error } = await supabase
      .from('items')
      .delete()
      .eq('id', id)
      .eq('user_id', session.user.id) // Verify ownership

    if (error) return res.status(500).json({ error: error.message })
    return res.status(200).json({ success: true })
  }

  return res.status(405).json({ error: 'Method not allowed' })
}

Security Checklist

Before deploying, verify:

[ ] No Supabase imports in client-side code
[ ] All data operations through API routes
[ ] Every API route validates session
[ ] All queries filter by session.user.id
[ ] Service role key only in server environment variables
[ ] Open DevTools → No requests to *.supabase.co from browser

Quick Test

Open your browser DevTools:

Go to Network tab
Perform data operations
If you see requests to *.supabase.co from the browser, you have a problem!

All requests should go to your /api/* routes.

Common Mistakes

1. Forgetting to Filter by User ID

// ❌ Returns ALL users' data
const { data } = await supabase.from('items').select('*')

// ✅ Returns only current user's data
const { data } = await supabase
  .from('items')
  .select('*')
  .eq('user_id', session.user.id)

2. Using Anon Key Instead of Service Role

// ❌ Limited permissions
SUPABASE_ANON_KEY

// ✅ Full access (server-side only!)
SUPABASE_SERVICE_ROLE_KEY

3. Skipping Session Check

// ❌ No authentication
export default async function handler(req, res) {
  const { data } = await supabase.from('items').select('*')
  return res.json({ data })
}

// ✅ Always verify session
export default async function handler(req, res) {
  const session = await getServerSession(req, res, authOptions)
  if (!session) return res.status(401).json({ error: 'Unauthorized' })
  // ... rest of code
}

Additional Security Layers

Rate Limiting

import rateLimit from 'express-rate-limit'

export const limiter = rateLimit({
  windowMs: 15 * 60 * 1000, // 15 minutes
  max: 100 // limit each IP to 100 requests per window
})

Input Validation

import { z } from 'zod'

const schema = z.object({
  title: z.string().min(1).max(200),
  description: z.string().max(1000),
})

// In your API route:
const validated = schema.parse(req.body)

Performance Tips

The API layer adds ~50ms latency, but you can optimize:

Use SWR for caching:

import useSWR from 'swr'

function Component() {
  const { data } = useSWR('/api/get-data', fetcher)
  return <div>{data}</div>
}

Add database indexes:

CREATE INDEX idx_items_user_id ON items(user_id);

The Tradeoff

What you gain:

✅ Custom branding on OAuth
✅ Full control over auth flow
✅ No vendor lock-in
✅ Actual security

What you lose:

❌ Automatic RLS convenience
❌ Built-in Supabase session management
❌ Direct client-to-DB queries
❌ Some Supabase auth features

When to Use This Approach

Good for:

Early-stage products where branding matters
Apps on tight budgets
Teams that want full auth control

Not ideal for:

Enterprise apps heavily using Supabase auth features
Teams that prefer less backend code
Projects where Supabase Pro is already affordable

Alternatives to Consider

Supabase Pro - Just pay for custom domains (~$25/mo)
Custom JWT Integration - Complex but allows direct frontend calls
Custom SMTP - Fixes email branding (not OAuth)

Conclusion

Client-side security isn't real security. When you remove Supabase Auth, you must implement proper backend authorization. The extra code is worth it for the peace of mind.

Key principle: Never trust the frontend. Always verify on the server.

Live example: I've been running this architecture on ToolsHubKit.com for months without issues.

Questions? Drop a comment below! Happy to review your implementation.

Resources

Found this helpful? Give it a ❤️ and follow for more Next.js security tips!

🚀 Privacy-First Developer Tools: Why We Built ToolsHubKit

Ali Zaib — Wed, 04 Feb 2026 19:05:44 +0000

In an era where every click is tracked and every input is potentially harvested for AI training or advertising, where can developers go for simple, reliable utilities without the "privacy tax"?

Today, I’m excited to share ToolsHubKit—a comprehensive suite of developer tools built with a radical "Local-First" philosophy.

🛡️ The Privacy-First Manifest

The core problem with many online "utility" sites is the hidden backend. When you paste an API response to format it or generate a Dockerfile, where does that data go? Often, it’s logged, stored, or analyzed.
At ToolsHubKit, your data never leaves your browser.

1. Local Processing by Default

Whether you are using our Dockerfile Generator or the Emoji Picker, the logic is executed client-side. We use modern Web APIs to ensure that your configurations, code snippets, and even sensitive strings remain strictly within your local environment.

2. Zero-Tracking Philosophy

We believe tools should be transparent. No intrusive analytics, no data harvesting. Just high-fidelity tools that work instantly.

3. Future-Proof Consent

As we expand ToolsHubKit to include even more powerful features (like cloud syncing or collaborative blueprints), we make a solemn promise:

If a feature requires data to reach our servers, it will be used solely for the purpose of that feature. No third-party sales, no data-mining. Full transparency and explicit user consent are our baseline, not an afterthought.

🛠️ What’s Inside the Kit?

We’ve curated a range of tools that solve daily developer friction:

Advanced Dockerfile Generator: Create production-ready blueprints for Node.js, Python, Rust, Java, and more with support for ARG, HEALTHCHECK, and USER instructions.

Unicode 15.0 Emoji Library: A massive, searchable library with skin-tone support and multiple copy formats (Hex, HTML, CSS).

Invoice & Credit Note Tools: Professional templates for freelancers and agencies, keeping all financial data local.

* And 40+ more utilities ranging from JWT decoders to Cron builders.

💎 Local Data, Global Impact

By keeping tools local, we don't just protect privacy; we increase speed. There are no round-trips to a server. Everything is instant.
We are building ToolsHubKit to be the "Swiss Army Knife" for the modern developer. No fluff, no trackers—just the code you need to move fast.

Check it out and let us know what you think:

👉 Explore ToolsHubKit

DEV Community: Ali Zaib

I Spent Three Weeks Reverse Engineering a Mobile App’s API — Here’s What It Took

The First Wall: Flutter Doesn't Decompile Like a Normal App

Going Lower: Snapshot Parsing and Runtime Hooking

The Wall That Took the Longest

Where the Full Breakdown Lives

Stop Uploading Your CSV Files to Random Tools — Use This Instead

I built a browser-based CSV Toolkit to fix this

Why CSV is actually hard

Delimiter confusion

Encoding mismatches

The BOM problem

Inconsistent column counts

Quoted field edge cases

What the toolkit does

The import workflow that saves hours

The privacy argument

Try it

Securing Next.js + Supabase After Switching to NextAuth

Securing Next.js + Supabase After Switching to NextAuth

The Problem

The Security Risk

The Secure Solution

Architecture

Step 1: Environment Variables

Step 2: NextAuth Configuration

Step 3: Secure API Routes

Step 4: Client-Side Calls

Complete CRUD Example

Security Checklist

Quick Test

Common Mistakes

1. Forgetting to Filter by User ID

2. Using Anon Key Instead of Service Role

3. Skipping Session Check

Additional Security Layers

Rate Limiting

Input Validation

Performance Tips

The Tradeoff

When to Use This Approach

Alternatives to Consider

Conclusion

Resources

🚀 Privacy-First Developer Tools: Why We Built ToolsHubKit

Today, I’m excited to share ToolsHubKit—a comprehensive suite of developer tools built with a radical "Local-First" philosophy.

🛡️ The Privacy-First Manifest

1. Local Processing by Default

2. Zero-Tracking Philosophy

3. Future-Proof Consent

If a feature requires data to reach our servers, it will be used solely for the purpose of that feature. No third-party sales, no data-mining. Full transparency and explicit user consent are our baseline, not an afterthought.

🛠️ What’s Inside the Kit?

* And 40+ more utilities ranging from JWT decoders to Cron builders.

💎 Local Data, Global Impact

Check it out and let us know what you think: