Hello readers,

> whoami?

I’m Gaurav Jain, a Cybersecurity Researcher and Ethical Hacker specializing in Web Application Security, Penetration Testing (WAPT), and Bug Bounty Hunting. I focus on identifying and responsibly disclosing security vulnerabilities through hands-on research, real-world testing, and continuous learning.

Passionate about offensive security, I believe in understanding systems deeply, thinking beyond conventional approaches, and making the digital world more secure.

Introduction

Some vulnerabilities are discovered within minutes. Others require days of observation, experimentation, reading documentation, understanding application behavior, and questioning assumptions.

This assessment belonged to the second category.

The objective was to understand a self-hosted web platform, identify weaknesses in its application logic, and investigate whether seemingly ordinary functionality could expose a deeper security issue.

What initially appeared to be a simple profile-picture upload feature eventually led to two significant findings:

• Stored Cross-Site Scripting (XSS).
• Remote Code Execution (RCE) through an uploaded ASP.NET HTTP Handler.

The interesting part was not simply discovering the vulnerabilities. It was understanding how the application processed uploaded files, how its technology stack influenced execution, and why an assumption that worked on one technology would not necessarily work on another.

This is the story of that investigation.

1. Getting Access Was the First Challenge

The first challenge was not vulnerability discovery. It was reaching the application reliably.

The platform was hosted in another country, and accessing it through ordinary free VPN services was inconsistent. Rather than allowing connectivity issues to interrupt the assessment, I configured a residential proxy solution and established a stable connection.

Once access was available, I avoided immediately testing random payloads.

The first objective was to understand the application’s attack surface.

I started with reconnaissance, covering:

• Subdomain enumeration.
• DNS reconnaissance.
• Network and infrastructure analysis.
• Technology fingerprinting.
• JavaScript file analysis.
• Public asset discovery.
• GitHub and public repository reconnaissance.
• Application endpoint discovery.

The purpose of reconnaissance is not merely to collect a large number of URLs.

It is to understand what exists, how different components communicate, which technologies are involved, and where security testing is most likely to produce meaningful results.

After mapping the available functionality, three areas caught my attention:

1. Profile-picture upload functionality.
2. The underlying Microsoft IIS and ASP.NET technology stack.
3. Password recovery and account information update functionality.

These became the initial investigation paths.

2. Understanding the Application Before Exploiting It

I started with the account-management functionality.

The application used ASP.NET session-related identifiers, and I observed behavior involving session changes and account information.

However, an important lesson in security testing is that an unusual response does not automatically represent a vulnerability.

Session identifiers can legitimately rotate during authentication and account-management operations. A security issue must be established through unauthorized access or another demonstrable impact, not simply through a changing identifier.

After investigating this functionality, I did not have sufficiently conclusive evidence to make it the primary finding.

I moved to the next attack surface: file uploads.

This decision eventually became the turning point of the assessment.

3. The Technology Stack Changed the Entire Approach

During reconnaissance and application inspection, I identified the underlying environment as:

• Microsoft IIS 10.0.
• ASP.NET on the .NET Framework 4.x stack.

This information was important because file-upload vulnerabilities are heavily influenced by the server-side technology and its configuration.

A PHP payload, for example, will not automatically execute on an ASP.NET application.

Likewise, an uploaded file does not become executable merely because its content resembles source code. The server must have an execution mechanism that recognizes and processes it.

I spent time studying IIS and ASP.NET behavior, examining relevant security advisories, researching historical vulnerabilities, and reviewing technical articles.

I investigated several possible approaches, but the initial attempts did not produce code execution.

This was a useful reminder:

Technology fingerprinting should guide testing, not become an excuse to blindly try every publicly available exploit associated with a product version.

The application’s actual configuration and implementation matter more than the version banner alone.

4. Investigating the Profile-Picture Upload

The profile-picture functionality initially looked ordinary.

Users could upload JPEG or PNG images, with a client-side file-size limit and MIME-type validation.

I examined the front-end implementation and mapped the workflow.

The observed process looked like this:

Step 1: File selection

The user selected a JPEG or PNG image.

Step 2: JavaScript validation

The browser performed checks involving file size and MIME type.

Step 3: FileReader

JavaScript used the FileReader API to generate a Data URL for the image preview.

Step 4: Profile confirmation

The user confirmed the profile information.

Step 5: HTTP request

The application submitted a multipart/form-data POST request to the profile-registration endpoint, containing the uploaded file in the Picture parameter.

Step 6: Server-side processing

The ASP.NET application received the file.

At this point, an important question remained unanswered:

What exactly happened to the uploaded file after it reached the server?

Was it decoded and re-encoded as an image?

Was the original content preserved?

Was the extension validated?

Where was the resulting file stored?

Could the uploaded object be retrieved directly?

These questions were more interesting than simply asking whether the upload form accepted an unexpected MIME type.

A lesson for beginners

Client-side validation is not a security boundary.

JavaScript validation improves user experience, but an attacker can independently construct an HTTP request. Therefore, security decisions must be enforced on the server.

An upload implementation must validate the actual file and its intended use, rather than trusting browser-side checks or request headers.

5. Intercepting and Understanding the Upload Request

I created an account and completed the profile-registration workflow.

Then I captured the upload request using Burp Suite.

Instead of immediately modifying everything, I first studied the original request and response.

The request contained a multipart/form-data body with a file parameter named Picture, along with a filename, content type, and binary image data.

I examined:

• The upload endpoint.
• The multipart structure.
• The filename parameter.
• The Content-Type header.
• The server response.
• The resulting uploaded-file location.

I also revisited the front-end implementation to understand how the form generated its request.

This helped establish a useful distinction:

The browser’s image preview and the server’s actual file-processing behavior are two separate things.

A file being displayed correctly in a browser preview says very little about how safely the server stores and serves that file.

6. The First Breakthrough: Stored XSS

I began investigating whether the application was trusting the supplied file metadata and content too much.

During controlled testing, I modified the upload request and submitted a harmless HTML document instead of the original image content.

The application accepted the modified content.

More importantly, after the upload, opening the resulting resource caused the supplied HTML to be interpreted by the browser.

That was the first significant breakthrough.

I continued testing with a controlled JavaScript proof of concept and confirmed Stored Cross-Site Scripting.

The uploaded content was not merely being treated as an image.

It was being served in a way that allowed active browser content to execute.

This revealed a weakness in the application’s file-upload and file-serving design.

Why this matters

Stored XSS occurs when untrusted content is persisted and later rendered in a browser in an executable context.

Unlike reflected XSS, where an attacker generally needs a victim to visit a specially crafted request, stored XSS can remain available until the affected content is removed or access to it is prevented.

Depending on the application’s origin, browser context, authentication design, and security controls, this can have significant consequences.

However, I did not stop at the XSS finding.

The more important question was still unanswered:

Was the server only rendering uploaded content in the browser, or could the server itself execute an uploaded file?

That question led to another phase of investigation.

7. Understanding Why PHP Payloads Were Not Working

My next attempts involved investigating whether the uploaded file could be interpreted as server-side executable content.

Some early approaches involved PHP-based files.

They did not work.

The uploaded resources returned HTTP 404 responses when accessed through the expected URLs.

This was a useful technical lesson.

A PHP file is not automatically executable on an IIS/ASP.NET application. Server-side execution depends on the configured handlers, runtime, mappings, and application environment.

Changing the filename extension does not install an interpreter or make an incompatible runtime execute the content.

At this point, I returned to the application’s technology stack.

Rather than continuing to experiment with payloads designed for unrelated environments, I focused on understanding ASP.NET’s request-processing model.

8. The Missing Piece: ASP.NET HTTP Handlers

While researching ASP.NET, I came across the role of HTTP Handlers.

ASP.NET supports handlers that process incoming HTTP requests for particular resource types.

One familiar example is the .ashx extension.

An ASP.NET HTTP Handler can implement the IHttpHandler interface and process an incoming request through its ProcessRequest method.

This is fundamentally different from simply serving an uploaded HTML or image file.

An image is normally returned as content.

An ASP.NET handler can be processed by the server-side runtime.

That distinction was central to understanding what might happen if an application allowed untrusted handler files to be uploaded into a location where IIS and ASP.NET could execute them.

The key investigation question became:

Was the uploaded file merely accessible, or was the upload directory also configured as an executable application location?

I had already established that the application stored uploaded profile pictures in a publicly accessible directory.

The remaining question concerned server-side interpretation.

9. The Second Breakthrough: Server-Side Code Execution

After the previous investigation, I conducted a controlled test using an ASP.NET HTTP Handler proof of concept.

The result was unexpected.

The uploaded resource was accessible through its resulting URL, and instead of returning the file as an ordinary image, the server processed it as an ASP.NET handler.

The handler returned its expected response.

This was the point where the investigation changed significantly.

It indicated that the uploaded file had crossed an important security boundary:

It was no longer just untrusted content being stored by an application. It was being processed by the server-side execution environment.

I then used a minimal, non-destructive command-execution proof of concept to verify whether the handler could invoke an operating-system process.

The server returned the identity of the process executing the handler.

That provided strong evidence of server-side operating-system command execution.

The upload functionality had become an RCE attack surface.

The interesting part was that the application had presented this functionality as a simple profile-picture upload.

The vulnerability was not dependent on discovering an exotic IIS zero-day. The evidence pointed toward an application-level upload security weakness combined with an execution-capable server configuration.

The distinction is important.

A vulnerable application can expose serious security problems even when its underlying software is not affected by a published CVE.

10. Breaking Down the Vulnerability Chain

The investigation revealed two related but technically distinct security issues.

Finding 1: Stored Cross-Site Scripting

The application accepted untrusted content through its profile-picture upload feature and served that content in a browser-interpretable context.

The result was persistent HTML and JavaScript execution in the affected browser context.

Finding 2: Remote Code Execution

The application allowed an uploaded ASP.NET handler to become accessible in a location where the server-side runtime processed it.

The handler’s ability to execute an operating-system process demonstrated command execution under the application’s server-side security context.

The underlying security concerns included:

• Insufficient restrictions on uploaded file types.
• Inadequate validation of actual file content.
• Unsafe treatment of uploaded files.
• Exposure of uploaded content through a publicly accessible application directory.
• Execution-capable server configuration for untrusted upload locations.

Importantly, accepting an unexpected file extension alone is not enough to establish RCE. Server-side execution must be independently demonstrated.

That distinction separates an interesting upload anomaly from a confirmed high-impact vulnerability.

11. What Beginners Should Learn From This Assessment

There are several important lessons worth carrying into future security assessments.

1. Reconnaissance is more than enumeration.

Collecting subdomains and endpoints is only the beginning. Understanding application functionality and identifying relationships between components can uncover attack surfaces that automated scanning misses.

2. Understand the technology stack before choosing an approach.

PHP, ASP.NET, Java, and Node.js have different execution models.

A payload designed for one environment will not automatically work in another.

3. Learn HTTP requests, not just tools.

Burp Suite is powerful, but its real value comes from understanding what is being sent and how the server responds.

Pay attention to multipart boundaries, filenames, content types, HTTP methods, response headers, and resource locations.

4. Client-side validation is not server-side security.

A browser can reject a file while the server might still accept a manually constructed request.

The server must independently enforce validation.

5. MIME type and file extension are not proof of file safety.

A filename, an HTTP Content-Type header, and the actual file contents are different things.

Security-sensitive applications must not trust these values independently.

6. File storage and file execution are different security boundaries.

An application may need to store user uploads, but those uploads should not be interpreted as executable application resources.

7. A failed attempt is still useful evidence.

The unsuccessful PHP tests helped establish that I needed to understand the server’s actual execution environment instead of blindly reusing payloads.

8. Do not confuse an observation with a vulnerability.

A changing session identifier, an unusual HTTP response, or an accepted file extension is not automatically a security finding.

Demonstrable impact and a defensible explanation of the underlying behavior matter.

12. How Should This Be Fixed?

The appropriate remediation is not simply to block one file extension.

The upload architecture needs to enforce a clear separation between user-controlled files and executable application resources.

Recommended controls include:

Strict server-side validation

• Maintain an allowlist of necessary image formats.
• Validate actual file signatures and decode the image using a trusted image-processing library.
• Re-encode accepted images into a safe output format.
• Enforce file-size and dimension limits.

Safe storage

• Store user uploads outside the application web root wherever possible.
• Use generated filenames rather than trusting user-supplied filenames.
• Prevent directory traversal and unsafe path construction.
• Serve uploads through a controlled static-content mechanism.

Disable execution

• Ensure upload directories cannot execute ASP.NET handlers or other server-side scripts.
• Review IIS handler mappings and execution permissions.
• Separate uploaded content from application code and executable directories.

Least privilege

• Run application pools under appropriately restricted identities.
• Limit filesystem permissions.
• Avoid unnecessary access to sensitive system resources.

Browser-side protection

• Serve user uploads from a separate origin where practical.
• Use suitable Content-Type and Content-Disposition headers.
• Apply appropriate Content Security Policy controls.
• Ensure untrusted content is never inserted into an HTML context without proper encoding.

These controls should be implemented together. Blocking .ashx alone would not address the underlying architectural problem.

13. Responsible Disclosure and Final Thoughts

Discovering code execution is an important security finding, but demonstrating impact does not require taking control of a system or accessing sensitive information.

Once execution has been sufficiently established, further exploitation should stop.

The evidence should be preserved, sensitive information redacted, and the vulnerability reported through the authorized disclosure channel.

A strong report should explain the affected functionality, the reproducible conditions, the security boundary that was crossed, the demonstrated impact, and the recommended remediation.

This investigation reinforced something I consider fundamental to security research:

The best findings often come from understanding how an application works, not from knowing the largest collection of payloads.

What began as a profile-picture upload feature turned into an investigation of browser content interpretation, HTTP request processing, IIS configuration, ASP.NET handlers, and server-side execution.

There were multiple dead ends, several incorrect assumptions, and plenty of reading along the way.

But the biggest lesson was simple:

Do not look at a feature only in terms of what it was designed to do. Understand what the server actually allows it to do.

Sometimes, the most ordinary functionality hides the most interesting security boundary.

PLEASE HIT THE CLAP BUTTON AGAIN AND AGAIN
IT BOOOOSTS MY CONFIDENCE PLEASE….😁

Hey, I’m gaurav0xh4ck3r aka Gaurav Jain — a passionate bug hunter who loves exploring web apps, finding bugs, and helping fix them. I’m always learning new tricks and sharing with the hacking community. Making the internet safer, one bug at a time!

Bug bounty hunting is like treasure hunting. Sometimes you find gold, sometimes you find… that someone else already found the gold before you. This is the story of how I discovered a Critical Account Takeover vulnerability on [Redacted], put in hours of work, celebrated early… and then got hit with the dreaded “Duplicate” tag.

But hey, duplicates mean you’re on the right path. Let’s go through my journey.

>> The Hunt Begins

Like every other late-night hacker, I had my Burp Suite open, energy drink in one hand, and Wireshark tabs everywhere. I decided to poke around [Redacted]’s password reset functionality.

Nothing too fancy at first — just the classic “Forgot Password” → Intercept the traffic → Check the response.

And then 💥 … jackpot.

Right there, shining in JSON format, was a recoveryToken — the exact token used to reset user passwords.

>> The Vulnerability

Here’s why this is a big deal:

Normally, password reset tokens are only sent to your email.

But the server was returning the token directly in the API response.

Anyone who intercepted that response (evil Wi-Fi, browser extension, proxy, you name it) could grab the token and reset the password without ever touching the email.

Translation? → Full Account Takeover.
Severity → CVSS 9.5 Critical.

Proof of Concept (high level, safe version)

1. Send a “forgot password” request.
2. Intercept the API response.
3. Copy the recoveryToken.
4. Use it to hit the reset endpoint and set a new password.

Boom 💣 — you’re inside the account.
Simple. Dangerous. Beautiful.

>> 🎭 The Plot Twist: The Duplicate

I submitted the report to the bug bounty platform. I could already imagine the bounty — pizza money for the year.

Then came the reply:

“Hi gaurav0xh4ck3r, thanks for your report… Unfortunately, this was submitted previously by another researcher.”

Bruh 😭.
The exact same bug had already been found months earlier.

>> Lessons Learned

Even though it was a duplicate, here’s why I still count it as a win:

• Validated skills: I found a Critical bug on a big target.
• Proof I’m hunting in the right places.
• Experience matters: The more you report, the higher the chances you’ll be first next time.

Bug bounty is like cricket — sometimes you hit a six, sometimes the fielder catches it before the boundary. But you keep swinging.

>> Final Thoughts

The vulnerability was fixed (thanks to the original reporter).
I confirmed that my methods are solid.
And duplicates are just stepping stones — the next one might be mine.

So here’s to more late nights, more Burp intercepts, and hopefully fewer duplicates.
Until then… stay caffeinated and keep hacking. ☕💻

Thank you so much for reading… Clap if you like it
Connect with me : linkedin

Happy Hacking!!

>> Whoami

Hey, I’m Gaurav Jain — a passionate bug hunter who loves exploring web apps, finding bugs, and helping fix them. I’m always learning new tricks and sharing with the hacking community. Making the internet safer, one bug at a time!

Welcome hackers to my new article - new finding

Chapter 1: The Start — Just Browsing or Bug Hunting?

One fine day, I was casually exploring Target.com (its private program) — a platform where you can submit support requests if you get stuck or have questions.

“Hmm,” I thought, “What if I try to mess with their support form? Maybe I can find some bugs!”
(Because bug hunting is basically trying to politely break things.)

Chapter 2: The Sneaky Idea — Injecting an Evil Link

I found the form where you submit your query. It asked for my username, email, and message — pretty standard stuff.

Then I got mischievous — “What if I put a link to a shady website inside my username?”

So I typed:

<a href=evil.com>Click me</a>

Classic hacker vibes. 😂

Then I got curious and tried another variation — with quotes this time:

<a href=”https://evil.com">Click me</a>

Because hey, why not test both ways?

Chapter 3: The Magic (Or Disaster) Happens — The Email!

After submitting my “support request,” I waited for the confirmation email. When it arrived…

Boom! My username showed up as a clickable link in the email!

For the first payload (no quotes), the link clicked me straight to http://evil.com without any warning.
For the second one (with quotes), the email client did show a redirect warning — good job email security!

But still, both links worked and were clickable. That’s a big problem.

Chapter 4: The Weird Part — No Redirect Warning?!

Usually, clicking weird links in emails triggers a warning:
“Hey! Are you sure you want to go to this site?”

For my quoted link (<a href="https://evil.com">Click me</a>), I got this warning. Good!

But for my unquoted sneaky link (<a href=evil.com>Click me</a>), no warning popped up — it redirected me straight away. Yikes!

Chapter 5: What’s Really Going On? (The Geeky Explanation)

Beginners, pay attention:

• When a site puts your input directly into an HTML email without cleaning it, that’s called HTML Injection.
• It can also be a kind of Stored Cross-Site Scripting (XSS) — but in emails, not browsers.
• Attackers can sneak malicious links into emails users trust.
• If users click these links without warnings, they risk phishing, malware, and worse.

Chapter 6: How I Reported It Nicely

Instead of yelling “You’re hacked!”, I wrote a polite and clear report:

• Explained how I injected the link
• Showed what happened in the email
• Highlighted the risk of no redirect warnings on some links
• Suggested sanitizing inputs and validating URLs

Being nice helps — they actually took me seriously!

Chapter 7: Lessons for Beginner Bug Hunters

• Find places where your input is used later — forms, emails, profiles.
• Try injecting HTML or scripts and see if it’s filtered or rendered.
• Test different payload styles: quotes, no quotes, uppercase tags.
• Remember: email clients handle links differently; test carefully.
• Write reports that are clear, respectful, and helpful.
• Most importantly: Have fun and be responsible!

Chapter 8: Final Thoughts — Wanna Be a Bug Bounty Hunter?

Bug hunting is detective work with a keyboard — fun, frustrating, and rewarding.

Start small. Experiment. Learn. Every bug you find helps make the web safer.

And if you ever get an email with a suspicious “Click me” link… maybe don’t click it unless you’re ready for an adventure. 😄

………………………………………………………………………………………………

simple rule of bug bounty is:

Hack, find, report, repeat — that’s the bug hunter’s grind.👍🏻

Thanks for reading my bug bounty story! Please clap and follow for more…

Got questions or your own hacking tales? Hit me up! in comment section or on linkedin

…………………………………….…Happy Hacking……………………………………

> whoami?

I ( Gaurav Jain ) , a cybersecurity researcher and ethical hacker specializing in web application penetration testing WAPT and bug bounty hunting. I actively identifies and reports critical security vulnerabilities to help companies improve their security posture. With hands-on experience in real-world exploitation and responsible disclosure, I am dedicated to making the internet a safer place while continuously learning and sharing knowledge within the hacking community.

> Introduction

In this write-up, I’ll share how I found two simple but serious bugs while testing target.com:

• A missing rate limit in the password reset confirmation process
• A reflected XSS vulnerability

These were not advanced bugs. Anyone learning bug hunting can find things like this by just being careful and testing small details.

1️⃣ Rate Limiting in Password Reset — Account Takeover Risk

When a system allows unlimited password reset attempts without restrictions, it can lead to:

• Brute-force attacks on reset tokens
• Account takeover if the tokens are short or predictable
• Email flooding abuse

References:

• OWASP Brute Force Attack Prevention
  https://owasp.org/www-community/controls/Blocking_Brute_Force_Attacks
• CWE-307: Improper Restriction of Excessive Authentication Attempts
  https://cwe.mitre.org/data/definitions/307.html
• OWASP Forgot Password Cheat Sheet (Talks about rate limiting reset requests)
  https://cheatsheetseries.owasp.org/cheatsheets/Forgot_Password_Cheat_Sheet.html

2️⃣ Reflected Cross-Site Scripting (XSS)

While testing other parts of the website, I found a Reflected XSS.
I simply sent this input in a URL parameter:

When I visited the page, the script ran directly in the browser. There was no input filtering.

Reflected XSS happens when user input is directly shown in the webpage response without proper sanitization.

This can lead to:

• Session theft
• Phishing attacks
• Running malicious scripts in the user’s browser

References:

• OWASP XSS Cheat Sheet
  https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html
• CWE-79: Improper Neutralization of Input During Web Page Generation (XSS)
  https://cwe.mitre.org/data/definitions/79.html

> Impact

Both bugs were important because they affected account security and user safety.

AND AFTER 7–8 DAYS LATER I GOT THEIR MAIL OF ADDING MY NAME IN HALL OF FAME !

> What You and I Learned

You don’t always need advanced skills to find good bugs.
Sometimes just testing the basics like:

• Rate limiting
• Input sanitization

can lead to valuable findings.

> Thanks for reading!

If you liked this, you can connect with me on:

• LinkedIn
• Github

AND PLEASE HIT THE CLAP BUTTON AGAIN AND AGAIN
IT BOOOOSTS MY CONFIDENCE PLEASE….😁

> whoami?

I ( Gaurav Jain ) , a cybersecurity researcher and ethical hacker specializing in web application penetration testing WAPT and bug bounty hunting. I actively identifies and reports critical security vulnerabilities to help companies improve their security posture. With hands-on experience in real-world exploitation and responsible disclosure, I am dedicated to making the internet a safer place while continuously learning and sharing knowledge within the hacking community.

> Why this task is …C0oo0LLL!!

Ever wondered where lightning is striking the Earth right now? I did too. So, I made an R script that taps into a live stream of lightning data from Blitzortung.org using WebSockets. No paid APIs, no external services. Just me, my laptop, and a direct connection to the sky.

So called “ I hacked the Sky with R 😂 And you can also do this” just read this carefully ….. YES seriously

> What This Project Does

This project listens to a WebSocket stream that sends real-time lightning strike data. It then:

• Decompresses the incoming encoded data
• Parses and structures the data into a dataframe (template_df) — where we got our results.
• Logs each strike in the R console
• Lets me stop the collection at any time.

when you visit to that above website that we use today blitzortung.org -> inspect -> Network-> Socket -> messages

YOU SEE…

These are the messages data of real time lightening strikes in all over the world but these information are in encoded form and there is no API available to get this data.
But you are writing an article that gives you step by step process to do in free…………. let’s goooooooooooooooo

> How to Reproduce This Project ( follow these steps to hack by your own 😂)

1. Download and install R and RStudio on your computer.
2. Open RStudio and go to the Console area.
3. Install these packages by typing:

4. Create a new script and paste the full lightning tracking code into it.

this below is the code

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —-

library(websocket)
library(ggplot2)
library(jsonlite)

template_df = data.frame(time = character(),
lat = character(),
lon = character(),
alt = character(),
pol = character(),
mds = character(),
status = character(),
region = character(),
delay = character(),
lonc = character(),
latc = character())

lzw_decompress <- function(code_str) {
codes <- utf8ToInt(code_str)
dict_size <- 256
dictionary <- as.list(sapply(0:(dict_size — 1), intToUtf8))

result <- character()
prev_code <- codes[1]
result <- c(result, dictionary[[prev_code + 1]])

for (i in 2:length(codes)) {
code <- codes[i]
if (code < length(dictionary)) {
entry <- dictionary[[code + 1]]
} else if (code == dict_size) {
entry <- paste0(dictionary[[prev_code + 1]], substring(dictionary[[prev_code + 1]], 1, 1))
} else {
stop(paste(“Bad LZW code:”, code))
}

result <- c(result, entry)

dictionary[[dict_size + 1]] <- paste0(dictionary[[prev_code + 1]], substring(entry, 1, 1))
dict_size <- dict_size + 1

prev_code <- code
}

paste(result, collapse = “”)
}

# Create websocket client
ws <- WebSocket$new(“wss://ws7.blitzortung.org/”, autoConnect = FALSE)

# On connection open: send subscription message
ws$onOpen(function(event) {
cat(“WebSocket connection opened. Sending subscription message…\n”)
ws$send(‘{“a”:111}’) # Send the same message your browser sends

})

strike_counter = 1
# On message received
ws$onMessage(function(event) {

# Decompress using LZW function
decompressed <- tryCatch({
lzw_decompress(event$data)
}, error = function(e) {
paste(“Decompression error:”, e$message)
})

print(paste0(“strike collected: “, strike_counter))
strike_counter = strike_counter + 1
assign(“strike_counter”,strike_counter,.GlobalEnv)

x = fromJSON(decompressed)
x = x[names(x) != “sig”]
x = data.frame(x)

# template_df = get(“template_df”, envir = .GlobalEnv)
template_df = rbind(template_df, x)

assign(“template_df”,template_df,.GlobalEnv)

})

# On error
ws$onError(function(event) {
cat(“Error:”, event$message, “\n”)
})

# On close
ws$onClose(function(event) {
cat(“WebSocket closed\n”)
})

# Connect and start the event loop
ws$connect()

# DON’T RUN THIS LINE UNTIL YOU WANT TO STOP COLLECTING
#ws$close()

timestamp_ns <- as.numeric(template_df$time)
timestamp_sec <- timestamp_ns / 1e9
template_df$time = as.POSIXct(timestamp_sec, origin = “1970–01–01”, tz = “UTC”)

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

Copy And Paste in your RStudio scrpit.

5. Now hit the RUN button…..

6. You will start seeing messages in console like:

if yes then BOOOOOMMMMM!!! you successfully fetch the data of lightening strikes.

7. Let the code run for a few minutes so it collects data.

8. When you want to stop it, just type ( in console):

— — — — — — — — — — — — — —Now Your screen is like — — — — — — — — -— — —

9. To see the data, type:

and you see your data screen is like

IF YES then………..

> How This Task Works

that is most important to understand

Okay, So let’s imagine you’re on a secret mission to eavesdrop on the sky. You connect to a hidden WebSocket used by weather nerds, send a tiny handshake that says “Hey, I’m listening,” and suddenly — BOOM — you’re getting a flood of encoded lightning strike data. My R script catches each message, decodes it with a fancy LZW function (a.k.a. lightning decoder ring), and saves it all neatly into a dataframe. Every strike gets logged like a live news ticker. And when I’ve had enough, I type ws$close() and walk away like a storm-chasing ninja.

> Lessons we have learned by this task -

• R can handle real-time WebSocket streams
• Blitzortung uses compressed LZW messages, but they can be decoded
• Live weather data is addictive
• Watching “strike collected” roll through the console is surprisingly satisfying

Bro/Sis if you get stuck in any step or any issue while doing this hacking 😂just ping me on linkedin. I will reply instantly.

And if no doubts let’s connect…..

https://www.linkedin.com/in/gaurav-jain-64a24b306/

> Final Thoughts-

This was one of the most fun and unexpected uses of R I and you have tried today.

It combined networking, data handling, real-time streaming, and visualization in one lightweight script. If you love working with data, and want to feel like you’re monitoring the Earth’s atmosphere, give this a shot.

Please Follow for more articles….And Like the article If it helps you, even just a little.

— — — — — — — — — — — -THANK YOU FOR READING — — — — — — — — — — — —

Byeeee byee………