QuishGuard – QR Code Scam Detection App | Cyber Security Final Year Project with Source Code

Abstract

Scan to pay. Scan to donate. Scan to check in. QR codes have quietly become the default way Indians move money, and scammers noticed that a long time ago. "Quishing" — QR phishing — works because nobody can look at a black-and-white square and tell what's inside it. A scammer pastes a sticker over the shop's real QR, and the money goes somewhere else entirely. You'd never click a random link from an SMS, but you'll happily point your camera at a sticker on a petrol pump.

QuishGuard fixes that blind spot. The app decodes a QR on the device, sends the payload to a Django backend, and the backend actually investigates it — where the URL really redirects to, how old the domain is, whether the TLS certificate is valid, whether Google Safe Browsing has flagged it, whether the UPI handle belongs to a real payment service provider or a lookalike pretending to be one. Then it returns a verdict: safe, suspicious, or dangerous. In plain English or Hinglish. With every single rule that fired shown on screen, so it's never a mystery number.

What This Project Actually Does

Think of it as a background check for QR codes.

You open the app, point the camera at a QR, and it decodes on-device — no image ever leaves your phone, only the decoded text. That text goes to POST /api/v1/scan/ on the Django backend. The backend figures out what kind of payload it is (a URL or a UPI intent), runs it through a chain of analyzers, adds up weighted scores from a rule table stored in the database, and hands back a verdict plus a findings list.

A few rules skip the arithmetic entirely. If the link triggers an APK download, or Safe Browsing flags it, or the domain is already on the community blacklist — dangerous, immediately, no matter what the numeric score says. Because a 47/100 that ends in a malware install isn't "suspicious," it's just dangerous.

Then a Groq-hosted LLaMA model turns that findings list into two or three human sentences. If the LLM call fails or you haven't added an API key, a template fallback writes the explanation instead — so the app never shows a blank screen just because an external service was having a bad day.

The scoring pipeline, step by step

1. Flutter decodes the QR (live camera or a gallery import, and it handles images containing more than one code).
2. Payload is POSTed to the backend with an X-Device-Id header — no login, no account, no OTP.
3. Backend parses it as a URL or a UPI intent string.
4. Analyzers run: RDAP/WHOIS domain age, TLS certificate check, Google Safe Browsing lookup, URL-shortener expansion, suspicious TLD check, lookalike-domain detection, PSP handle validation, brand-impersonation check.
5. Each hit contributes a weighted score from an editable rule table. Critical rules override the total.
6. The LLM writes the explanation. The verdict, score, and every individual finding go back as JSON.
7. App renders it, caches it in local SQLite for offline history, and offers a "Report this QR" button.

Key Features

• Camera and gallery scanning with multi-code handling — point at a QR or import a screenshot; if a single image has three QR codes in it, you pick which one to check instead of the app silently grabbing the first.
• A verdict in seconds, not a raw score — safe, suspicious, or dangerous, colour-coded, with the reasoning underneath.
• Every rule that fired is visible — "domain registered 6 days ago," "not a recognized PSP handle," "certificate expired." Each with its own severity. Open the box and look inside.
• English or Hinglish explanations — generated by Groq/LLaMA, switchable in settings, with a template fallback if the API is unreachable.
• Works with no internet, partially — the app syncs the backend's blacklist to a local cache, so a known scam domain or VPA still gets flagged even when the scan request can't reach the server. Scan history is cached locally too.
• Community blacklist with moderation — a user reports a scam QR from the verdict screen, an admin approves it in the Django moderation queue, and it lands in the blacklist every other device syncs against.
• Zero-friction identity — a locally generated device id instead of accounts. Rate limiting is per device id, so there's no auth system to build, break, or explain to your examiner.
• Async enrichment via Celery — a brand-new domain is scored inline, but a stale cached one is served instantly while Celery refreshes it in the background, plus a nightly sweep. Live scans never sit there waiting on a slow WHOIS server.
• Accessibility done properly — screen-reader semantics throughout, a light/dark "Trust Grid" theme, and a non-gesture alternative to swipe-to-delete in history. Small thing. Examiners notice it.
• In-app Learn screen — short explainers on how quishing scams actually work, which makes this an awareness tool and not just a filter.

Real-World Applications

• Everyday UPI payments — the fake sticker slapped over the parking attendant's or fruit vendor's real QR. Catch it before the money moves.
• Donation drives — cloned charity QR codes spike around festivals and disaster relief. This flags the lookalike domain before someone donates to a scammer.
• Phishing and malware interception — QR codes that redirect to fake bank login pages or kick off an unsolicited APK download.
• Digital literacy programs — colleges, NGOs, and bank branches running awareness sessions can hand people something they can actually try.
• An embeddable safety layer — the scoring API is standalone and device-id based, so a payment app or bank could put its own scanner in front of the same verdict engine without touching QuishGuard's UI.
• Crowdsourced threat intel — a live user base surfaces new scam VPAs faster than any manual feed would.

What's Hard and What's Easier Than It Looks

The honest hard part: the domain intelligence layer. You're making network calls to RDAP, TLS endpoints, and the Safe Browsing API from your own server, which means you have to fetch untrusted URLs safely — the project ships an SSRF-safe fetcher for exactly this reason, and understanding why it exists takes a bit of reading. Layer Celery on top for background refresh and there's genuine engineering in there. Which is great for your viva, and slightly annoying on a Tuesday night.

The easier part will surprise you. The whole risk engine is a weighted rule table in the database. Want to make expired certificates count for more? Change one number in the Django admin and rescan. No code edit, no redeploy, nothing. And Redis is optional in development — Celery falls back to eager mode, so tasks just run inline and you can build the entire thing without ever installing Redis. If you've built a Django CRUD app before, you already know 60% of this backend.

Who Should Buy This

If you're a student who needs a working project for your college submission, final-year project, semester project, internship, or academic demonstration, this is for you. Whether you're studying BCA, B.Tech, MCA, M.Tech, Computer Science, IT, AI, Data Science, or another related field, you can choose a project that fits your requirements. If you need the source code, project report, documentation, or help setting up and running the project, CodeAj gives you the resources and support to get started faster.

Specifically worth it if your department wants a mobile app and a real backend, if "cyber security" is on your syllabus and you're tired of seeing the same keylogger and caesar-cipher submissions, or if you want something you can demo live in front of a panel by generating a QR pointing at a sketchy domain and watching the app light up red.

Why CodeAj

You get the complete monorepo — the Django backend and the Flutter app, both finished, both tested, with their own READMEs. Plus the project report and documentation written to match what Indian universities actually ask for: abstract, literature survey, system design, methodology, results, future scope. If it won't run on your machine, the setup support is real support, not a link to a generic FAQ. Browse more cyber security final year projects if you want to compare, or check the Flutter projects with source code collection for other mobile builds. The backend side sits comfortably alongside our other Django final year projects if your guide insisted on Python.