So to see how difficult it was to make an actual privacy focused app in the present and to see if the developers are just lazy, i started making a web based encryption storage system.

At first it was easy, I made the plan; to make a really isolated storage app in the web which nobody could poke into.

I divided my project into 5 phases, the first one was ofcourse the usual one of laying the foundation and the concept, I wanted the app to be completely air-gapped, so my plan was to manually download the libraries needed and make it work flawlessly offline. I used Tailwind for a custom 'Mac OS 8/9 Platinum' style, I really don't know why i chose that but it looked retro and good, then I chose the CryptoJS library for the data encryption and authentication, for storage i was using the browser's localStorage as it was ideal enough for the project and remember that all of these was free amd open source and coud be downloaded from almost anywhere on the internet. First i planned that the whole app aas going to be an SPA(Single Page Application) so i could already patch up a surprising number of vulnerabilities, and as it already was completely offline based, i had made it nearly impossible for anybody to remotely hack it. And i made the basic version of the app, with a login tab and a registration tab, i purposefully removed the back up option to not make a security/privacy backdoor hence again removing another common vulnerability and also making the app easier to develop. I used AES-256 for the encryption of the data stored and used SHA-256 for the hashing of all the credentials, for the passkey, i used the same hashing but layered with PBKDF2 with 100000 iterations hence again preventing brute force attacks, and it has only been a day of work. Next i added a feature called the Volatile Random Access Memory Purge(VRAMP) which when logged out would wipe the entire credential entered clean and overwrites the wiped memory with random noise which are separately generated through the window.crypto.getRandomValues feature of the CryptoJS library. After this i created the very espionage-esque feature of a 'Duress Passkey', a secondary passkey set during registration, and if this is entered duting log in, the system silently wipes the entire data stored in the given user's vault, saves the empty state and logs the user(or the interrogator) in. It appears as a legit log in but actually the data is purged, and this was done through very simple lines of code.

And with a bunch of other features, i made a pretty powerful and secure text based storage(as in the end i thought, a hybrid storage of both text and images could open up new vulnerabilities) system called PIES or Pretty Isolated and Encrypted Software(it's on the dev repo) which was completely zero gapped amd could be text based storage apps which normies like us could get our hands on(only if used correctly), and this all happened in a matter of a week, so now i proved that it's not that hard to make a very privacy focused tool or is it unfeasible as in this world where you could be tracked or hacked in a matter of minutes, with the right tools you can stay safe, and also a big deemed problem by the devs is that making some systems could get the devs themselves in jeopardy on matters like illicit users(which are just excuses used by entities for mass surveillance), but with this app where there is no server collecting data or anything pinging anyone other user storing data, nobody can practically subpoena me to give up info, as i'm legally not binded to, hence stripping myself of my 'responsibilities' so look in this way, was this even expensive or even time consuming, no it was not. So just make more privacy focused apps.

After a bit of usage, I started to like Bluesky, but i still didn't like that it had the suggestions tab and used analytics(something that i hate a lot and is the primary reason for my loath towards the data harvesters), so i planned to make a client for Bsky in the holy trinity of web dev.

The final product of a coding streak for this aim which lasted for three days was LycaClient, it was a full feature web based client in which there was no 'for you' tab or a suggestions feed but only the immediate settings and a search bar, so you would just search up for people who you want to see without a distraction from a third entity amd that you had control of who you wanted to look up for and algorithm wouldn't be there to breathing down your neck. And it did a great job in being a great client.

I didn't use any fancy frameworks or integrations for these as i really hate bloat, and used pure HTML5, CSS and Vanilla JS(ES6+). I used the Bluesky XRPC for the real-time integration and for the user sign and used the Fetch APIfor the data pulling. You can just check on the specs by just going to the GitHub repo. It was actually really simple and as Bsky uses the ATProto it was completely open source and free and naturally, dApps like Bsky are way more friendly with data fetching than the data harvesters because of the open source ATProto and the whole project was way easier than it looked

And as I was coding i also had an idea to create a 'Feather' version which could be compatible with older systems and as I aas finished with the main version(v.1.1) I started with the development of Feather and in a day or so I had finished that too and the Feather version, when I checked could be used in systems as old as 16 years.

And with this, I pushed the code for both versions and now i'm on my way on working on something else, and I'm planning on adding video feed features and better richText formatting which currently is not there in v.1.1.

After v.1.1, the v.1.2 was obviously a bit more effort-heavy, as adding the richText formatting was a bit of a headache, because Bsky uses UTF-16 for its formatting while the normal web uses UTF-8 so i had to come up with a good parser for it, bit still it was way easier than anything i had done before, i had also added the video support for posts and good for devs, i had also made the overall code a bit more readable than before.

I had done the transformation of UTF-8 format to UTF-16 through a parser which took most of the development time of the v.1.2. The video support was surprisingly easier as I only had to use the HLS.js library to import the feature and it was pretty good then. So overall the v.1.2 is looking 'professionally' good.

So i had known about the IPFS project for long time but had never done much of value for it even if i'm very interested in dApps and decentralized systems. So i planned as usual to do something. File transferring systems are abundant when it comes to IPFS but what i created was something which was more than a usual ones. And in the end I created what I call a hybridized system which is just a partially deccentralized system.

I called it EtCAN or the Eternal Content Addressable Network, and here a user will generate a private and a public key as a form of identity (like PGP) and uses the reciever user's public key to send the data and vice versa and this was the concept, I used the battle tested TweetNaCl library as my cryptographic base. Curve25519 was used for nacl.box operations, and this provided pretty high speed, eliptic-curve based encryption for the assymetric encryption. And for the symmetric encryption i used the XSalsa20-Poly1305 for the local data(contacts, config, and the secret key) using a master password. i then used the PBKDF2-HMAC-SHA256 with 600000 iterations which was the OWASP recommended standard.

But what made it better was that it had a pretty high level security and privacy feature other than the encryption, it had a pretty well performing steganography engine built in it which was pretty good at the job and used the scattered LSB technique with a deterministic PRNG(Mulberry32) seeded by a random 32-bit integer hidden in the first 32 pixels. And Instead of writing bits sequentially (which creates a visible "noise" pattern at the top of an image), it scatters the payload across the image's Least Significant Bits (LSB). It also forced Alpha channels to 255 to prevent data loss during transmission or the canvas rendering, and all this made this better than a lot of the same type applications. And this was also pretty easy as the hard part was actually a pretty expected one.

As it presented itself the hardest part actually was finding the 'pinning' service, so i started with supporting the Pinata JWT but for a complete decentralization this was not ideal as it would only maks the app partially decentralized, so i dabbled a bit with the Crust network but for some reason whenever i typed keys and credentials, it was always malformed for some reason so because of this i ended up with a partially decentralized applications, and i dabled with a lot of other ones but didn't work at all even though i digged deep enough and was just searching for a good pinning service for hours, i don't know why but for some reason none like i mean NONE worked amd using the self hosting option just broke the thing so there i was, a fish CAN forever. so I'll keep it Pinata till i find a good alternative but it's not actually a big deal as with the steganography and the encryption Pinata doesn't have anyway of surveillance as they will only see encrypted blobs lf data and seemingly normal images going through, so keeping it like this or changing doesn't change much. of the practice. And also that i added multiple gateway system in the downloading of the files which made it a bit more decentralized.

The next big feature i added was the feature of uploading entire directories of websites for mirroring or distributing them, and i used the v1 of CID as it was the version good for site upload as it didn't need encryption. And with this features I think i have an actual high quality and sophisticated file transferring system, and please let messsage me on Matrix or something of you find a nice pinning service.

And when i dug deeper, the whole thing looked stupid, it was that the map file for the version 2.1.88 had all the source code needed for every file within a sourcesContent array, and with this anybody could just run a simple script to map all the files and all the 512000 lines of Anthropic's original code in TypeScript. And all this happened just with the npm package for the 2.1.88 which had accidentally included these source files. So all of this was just behind a command like npm publish --access public and such a simple error(or a 'human error' as quoted by Anthropic) could cause this mayhem(only for the company as i'm happy with this data harvester getting hit hard).

So the reception and response to this breach was your usual stuff, Anthropic was hit hella hard by the media amd everyone concerned. The leak was first found by a developer/security researcher by the name of Chaofan Shou who at approximately 4:23 AM (ET) on 31 March found this leak and posted about itbon X(@Fried_rice), and he provided a direct download link to the original expoaed source code in TypeScript hosted on Anthropic's Cloudflare R2 bucket (which by this time would be have been taken down), but then soon, a prominent Korean researcher who goes in the interconnected network by the name of Sigrid Jin published a Python-ised version of the source code under a new name of 'Claw-Code' on GitHub and boy, that repo bece the fastest growing GitHub repo of all time and by now mostly be having more than 160000 stars on GitHub.

But you guys be careful as some guys(idbzoomh1) has published repos with names like 'Leaked Claude Code' which was actually a lure attack containing Vidar. So i suggest you guys to download the Claw-Code instead of anything which looks suspicious on GitHub amd says stupid stuff like it offers 'enterprise features'.

The code was immediately analysed by devs, and the result was both expected and surprising, people found a some new features which was in beta or was unreleased like a feature called Buddy which was tamagotchi style companion, and a continuously used term in the code called KAIROS which was likely an always-on agent mentioned in the code nearly 150 times, according to the code it acts proactively in the background, responding to GitHub webhooks or Slack messages. It also had some questionable features like the telemetry and 'kill switch', which showed that the CLI tool polls an Anthropic settings endpoint every hour. This allows the company to remotely toggle feature "kill-switches" and push policy changes to your local running instance without your direct interaction. But it was expected as for an AI company which would do anything to harvest your data. The code also had some info on some upcoming models(names like Capybara and Fennec).

When i audited the code when i was free, it was not a magic box that everyone said it was but more like a really normal source code for a pretty powerful agent. So i was not necessarily surprised by the features but was surely surprised on the scale of the breach and how much have gone public domain.

And in the middle of this breach some people had used it as a pretty vile opportunity to do some cyber mischief as a bunch of fake repos have popped up in GitHub offering the 'leaked code' which will instead infect your device with something like Vidar and a pretty large scale npm poisoning attack happened in which the users who have downloaded the update(2.1.88) on 31 between 00:21 and 03:29 UTC might have had a chance of inadvertently pulling a Remote Access Trojan(RAT) ware. But cmon, why all this on March 31st, it would've been perfect if it was the April 1st.

after staring at the wall for sometime, i had developed the bigger picture, that the tool would be in the form of a JS script Or a library which would be pretty easy to plug in a website, basically that the tool could be planted easily in a website which would then start doing the recon on each user or the target whi visited it. but for this i had to exploit something in the browser,as this should be stealty and aggressive and shouldn't be like nMAP which anybody who know a bit of networking could detect with a nice firewall. so after some digging, i decided that i'd use 'the supreme IP leaker of browsers', WebRTC, and here i would exploit the flaws of WebRTC to get the recon working and use other browser APIs. and here the tool would establish a dummy WebRTC channel with the target which then would increase the trust of the browser and then would harvest as much as possible through that.

then i started with the classic IP leaker feature, which RTC was notoriously known for. unfortunately the latest versions of Chrome and Safari and hardened ones like Firefox and Brave had had enough of WebRTC and had either sidelined the API or had patched the issue, and here i couldn't do the simple raw local IP grab as the vendors had now used a thing called multicastDNS or mDNS(RFC6762), and this masks the local IP with an encoded string with a .local suffix, hence now unreadable for the tool and i knew about the age old technique of getting media permission to force the browser into unmasking the IP(here the browser is tricked as usually WebRTC and media permission usually means that a video con or something is going on and the browser will unmask the IP for 'the best possible streaming quality') but currently it was only working smoothly for Chrome and Chromium based browsers and stuff like Firefox and Safari had made that, even if media permission is given unmasking wouldn't be done default unless with some enterprise config, so I had to add the 'loud' feature of media permission, but it was kinda a partial win for me as most people use Chrome and most people give media permissions and even if it's not given the other info would still be there and the users would just shrug it off as 'normal'.

then i added the other features like the detection of VPN through using WebGLto find if the target's GPU, and as most servers use GPUs like SwiftShader and home PCs use stuff like an Nvidia RTX, it would be a very strong identifier. and then i added features which used things like Canvas Fingerprinting and WebCodecs to get hardware-level info.

one of my favorite processes in this tool was the LAN mapping process, it was not like your usual LAN mapping where you have a bunch of common ISP IPs which you use to hit the router. but here it's pretty clever, the script starts with a hardcoded Set of the most common default gateways used by home and corporate routers.

192.168.1.1 192.168.0.1 10.0.0.1

then it's the 'adaptation' to the environment, it looks at the local IP it harvested during the WebRTC phase(this.localInterfaces), then it uses the .split('.') method:

1. it takes the local IP(eg., 192.168.50.15).
2. it splits it into four parts(octets): ['192', '168', '50', '15'].
3. it slices off the first three: ['192', '168', '50'].
4. It rejoins them to create the subnet prefix: 192.168.50.

once it has your subnet, it guesses where the router or other infrastructure might be by appending common suffixes: .1, .254, and .100. So, if your IP is 192.168.50.15, it automatically adds 192.168.50.1, 192.168.50.254, and 192.168.50.100 to its target list.

but the script doesn't just ping the IPs(which JS usually can't do). it uses two "error-based" detection methods, in the first method it attempts a fetch() to the target IP with the no-cors mode. even though the browser blocks the script from reading the content of the router's login page (due to CORS), the script can still see how the request failed. and in the result, if it gets a "Connection Refused" error quickly, it knows a device is there. if it simply "Times Out," it assumes no device is at that IP. in the second method, as this is is a fallback, it is even more subtle. It creates a hidden iframe and points its src to the target IP on an obscure port (like :31337). it starts a timer using performance.now(). and in the detection, a live host will respond (even with an "Error: Reset" or "Refused") much faster than a non-existent host. if the onerror fires in under 1.4 seconds, the script flags that IP as "ALIVE (Timing Bypass)." by doing this, the script builds a map of the internal network without ever needing specialized permissions or complex pattern matching. It's essentially using the browser's own security errors as a radar.

then i added the other features like NAT topology identification feature, then were several sophisticated anti-analysis features, the first was a armOnMultiInteraction method which ensured the payload doesn't fire in an automated sandbox (like VirusTotal or Joe Sandbox) as it required a stateful response human response of mousemove->scroll->click. then it verifies the isTrusted property on the click event to ensure it wasn't a programmatically generated click by a clanker, then there was a feature for DevTools detection where the code records the exact millisecond before and after a debugger; statement using performance.now(). in a normal environment, the script ignores this and executes it in less than a millisecond. If DevTools is open, the script halts execution. If the time delta exceeds 100ms, the script assumes a human is inspecting the code, and then a Chromium specific thing, the script creates a custom object with a modified toString() method that sets a flag (detected = true) when called. it then logs this object to the console using console.log('%c', detector);. in Chromium-based browsers (Chrome, Edge), the console automatically evaluates and stringifies objects to display them. if the console is closed, the object is never evaluated, and the trap remains untriggered. the second one is deceptive 'noise' method, where instead of terminating the script when analysis is detected (which is a strong indicator of malicious intent), ColdStrain utilizes Dynamic Method Swapping to feed the researcher fake data.

then it was the logic for the exfiltration of the data harvested to the fetcher or the dashboard which would be a site, and the thing i did made it extremely difficult to block the data transmission, as i used Gun.js database for the job, and because of this the whole thing would be decentralized, and instead of sending data to a central C2 server that can be easily blacklisted by DNS, it used a decentralized graph database. and before exfiltration, it uses the Web Crypto API to perform a hybrid encryption (RSA-OAEP for the key wrap and AES-GCM for the payload chunks). this ensured that even if the network traffic is captured, the data remained unreadable without the private key.

but then i found that these techniques or at least the ones which leaked important stuff, could be mitigated in the modern web, so i made it a bit more robust, in which i added more newer and more subtle fallback features for several features which made the whole thing even more robust and difficult to mitigate, like i added the WebGPU fingerprinting as a fallback for WebGL, made the VPN detection a multi feature process where different ways where used to get the data for the VPN detection,as a step by step process and added a new MTU analysis feature with WebTransport which more difficult to catch.

and with all these stuff, and 5 days of work, i created ColdStrain and ngl it was pretty sophisticated and effective for a web-based reconaissance tool....dw i didn't use it in this site, i really value privacy this was just a PoC for seeing how much of we could leak from a browser if we asked nicely.

]]> https://nulsie.mywire.org/article7.html 2026-04-21T00:00:00Z i think it's a bit late to post this, i had learned about this days ago, but was too lazy to write it up, so here we go. so on 6th April, in between 4:22 and 11:06 UTC, almost all WordPress websites using the 'Essential Plugins' portfolio became victims of, in my perspective, the most sophisticated supply-chain attacks the platform has ever seen.

the reason was pretty evident, as if any of you are in touch with web development or web sec, you might know that, WordPress's Plugin system is essentially a swamp infested with vulnerabilities. and the main reason i don't use and nearly avoids using WP is because of this. before learning about the vulns or the attack, you should know that the whole thing of the Plugins in WP are that these are essentially just php scripts which an owner of a WP site uses to add extra functionality that WP doesn't offer by itself, and due to this the whol deal of the Plugins is insanely popular in the platform, but i myself don't think that WP has done a thing of quality to make this system secure, and because of that the platform rarely ever monitors the transfer of ownership of these Plugins(more like insecure php scripts) or do they check on how secure this things are and if there is any zero-days in them.

now we're getting to the attack. likely on the August of 2025, a very nice person by the moniker of 'Kris' legitimately bought the full Essential Plugins Portfolio of WP through the didgital market Flippa for some six-figure sum. then the person waited for nearly 8 months before doing anything. and after the long hiatus, on 6th April, in the timeframe i mentioned, a C2 domain called analytics.essentialplugin.com(it's a common thing in these areas to name the C2 with the word, 'analytics') started to distribute pesky payloads to all the sites using the vulnerable plugins, then as y'all would've guessed the, the plugins downloaded this payload and then they were compromised were attacked. the aim of the attack was apparently to cloak the search rankings, meaning to manipulate the rankings through attacking the search engine crawlers, so that changes the plot, now y'all can see that Kris targeted to manipulate the search rankings of the sites affected, not by actually attacking the sites themselves but using the plugins in these sites as vectors to sending the malicious payloads to the crawler, all done well thanks to how sloppy WP's monitoring systen was.

so this was all done through planting a backdoor in the plugins which let the C2 domain to inject the payloads. and Kris planted the backdoor after buying the Plugins, and this was hella easy as here, you aren't a megabrained mr.robot trying to get into a system and plant a backdoor, but your having the admin privilege for doing anything to the Plugin, so with that Kris could just type up somd lines of php and execute. the malicious code(the backdoor) was planted in v2.6.7 of the Plugin on the August of 2025, the same month Kris bought the Plugin(boy the person is KEEN), the changelog was ofcourse titled as a very innocent thing titled, “Check compatibility with WordPress version 6.8.2". this 191 lines of code sat silent for the whole 8 months. and when the day came, it was activated, then the Plugin's internal wpos-analytics module downloaded the file, which went by the title of wp-comments-post.php and then used that file to inject the code to the most vital file of any WP site, the wp-config.php. then the payload fetched spam links, fake pages etc. and fed them to the Googlebot. and as i said the code didn't do anything visible to the site, and the admins of those sites couldn't see any of this happening, as the code only fed the malicious code to the crawler. the C2 domain was itself pretty clever, instead of a usual domain which coud get seized easily, Kris deployed a tactic which is also seen in my project, ColdStrain as the C2 resolved C2 server through an Ethereum smart contract, which meant Kris could change the domain frequently and change it as much as wanted, hence making it insanely difficult to takedown or blacklist the domain. this whole attack could've been even worse if it had targeted something more vital and had a bit more sophistication than search ranking manipulation, perhaps the user/visitor data if tye website had been a shopping site of sort, as these Plugins or php scripts or whatever have admin privileges in the site they are deployed.

and with this attack the sloppiness of WP's Plugin auditing system(or the lack of one) was crystal clear and WP could mitigate this entire attack if it had a robust auditing system, as it could easily catch the backdoor instantly(the problem being that the code is reviewed by WP when a Plugin is created but if it goes through a ownership transfer, nothing is done), and because of this stupidity, alot of sites had a bad time.

]]> https://nulsie.mywire.org/article8.html 2026-04-22T00:00:00Z So recently, a friend of mine on Discord forced me to join a random server for web devs, but i've had experiences where these 'web dev' servers are actually filled with people who have done only one project in their entire life, a portfolio, with Hugo and hosted on vercel, and then starts to brag about how much they know about the web, yet i still joined because of that guy's insistence.

and one day, a guy came and said he's creating a personal website and posted the address. By this time i was writing a simple CLI tool for extracting OSINT on domains in Node.js, what a coincidence. So to flex, I said what the person was hosting their site on and their DNS service and so on with the tool, but the person, without saying anything like 'cool bro' or 'that's impressive' the person just said, 'due to security reasons i'm not interested in saying where i'm hosting my website...', cmon, i don't know if this person doesn't know what's he doin, but this is basic openly available information, and if they don't know what info is orivate and what is not, they are really gonna mess up.

So i challenged them that their entire infrastructure is insecure and they don't know what's they're doing, because i can extract most about how their infra is like and how many vulns i can find in it with my tool, even if my tool at that moment could only extract basic stuff, and this was a prestige issue. But i was looking on to making at sophisticated as possible.

So it was first a single-file CLI script which just took a target URL, which then sent a HTTP request, and output the respones text. It used the built-in node modules like node:http and node:https to perform basic GET requests and used the readline for handling the user input sequentially, it then just did a console.log output of the response from the target server. And that was the MVP

Next was the addition of the port arrays which needed to be scanned, the RegEx sigs for secrets hunting and all the browser profiles and a collection of tevh stacks sigs for a feature for identifying the technologies used in the target server. i knew it was a bit(read: a fucking lot) cluttered, but i didn't really care. After this i just stopped doing this for sometime, going back to a different project of a chatting or communication system i was developing called LRIS(Live Relayed Interaction System).

And after 3 days of inactivity, i returned, now my motivation was not to show that person taht their infra is screwd, but to make a really sophisticated and well-engineered piece of reconnaissance tool. So now, i coded the tool forSubdomain enumeration, and in that i made the tool take the domain it was given and then to comb through the entire HackerTarget, crt.sh and the Wayback Machine for the enumeration for all subdomains having that given domain. i was nervous about the accuracy of using these zero-cost, sign-up free services instead of something more dedicated like Shodan or Censys, but when i checked it, to be honest, the speed and accuracy genuinely surprised me, when i tested.it, it was almost always accurate and working well. The only wrinkle, was that crt.sh being one of the most comprehensive certificate registry, is annoyingly rate-limiting, not blaming.them, as if a service is completely free and this good, you really have to rate-limit for stopping abuse.

Then was the TCP/UDP scanning, anyway by now in the tool, for versatility i had made two modes, a web mode and a non-web mode, the web as the name suggested was for the web related scanning while the non-web was for stuff like mail servers(forgot to say the tool can find if t a given domain is having a connected mail server or not and its address), Redis and other database servers. And now the TCP/UDP scanning, it was the hardest by far, for now. For this, instead of something like ping or some other HTTP libraries i used the native Node.js modules like node:net and node:dgram and it did it well, but WITH A LOT of false positives. so to prevent this, and then with some work, i made a kinda elaborate system of sig-based validation, stateful timing metrics, structural stability testing and heuristic pattern checks.

Standard port scanners flag a port as "open" if the initial TCP three-way handshake (SYN -> SYN-ACK -> ACK) completes. However, in modern networks, firewalls, load balancers, or software proxies often accept connections on any port (acting as a "catch-all" or "port spoofing" setup), leading to inaccurate results. And TrufflePigg counters this by immediately transmitting specific protocol-compliant binary structures once a connection is established. A true target service will process the packet and return a valid signature, whereas a dead socket or a basic firewall proxy will typically time out or drop the connection. In the sniffer.js, I constructed Buffer objects corresponding to database protocols

Unlike TCP, UDP is entirely connectionless. There is no handshake mechanism to verify if a port exists or is active. If you send a UDP packet to an open port, the service may remain silent unless given highly structured instructions. If the port is closed, the host machine's OS kernel generally issues an ICMP Destination Unreachable packet back to the sender. TrufflePigg handles UDP checking by binding an active UDP socket client via dgram.createSocket('udp4'), sending specialized protocol blocks, and closely monitoring the loop for low-level socket system errors like ECONNREFUSED (which indicates the kernel received an ICMP unreachable message).

Then it was the heuristics for the detection of honeypot systems like Cowrie, what it does is that by identifying impossible network conditions—such as a single host having an extraordinarily high number of open ports, repeating the exact same service banner across multiple unrelated ports, or explicitly matching known honeypot software (like Cowrie or Dionaea).

Now it was time for the part which took the longest time and was the hardest of all, which was what i call the web application intelligence engine(long name ig) and rightfully this was my favorite part and the most engineered part of the tool. The first thing was the tech stack fingerprinting which was a full-fledge process for detecting all the underlying Content Management Systems(CMS)s, frameworks or the web server, this was an advancement of the old hoster look-up. Rather than relying on a single loose match, I coded the tool to run a heuristic evaluation of checking matches of various domains. It analysed the DOM in which: the tool fetches the landing page (/), it normalizes the text to lowercase and evaluates it against array-based regular expressions (sig.dom). This layer targets hardcoded signatures that developers rarely clean up, including; Injected generator meta tags (e.g., meta name="generator" content="WordPress">), Specific path formatting conventions (e.g., wp-content/themes or _next/static), Unique variable structures in global scripts (e.g., window.Vue or drupalSettings). Next was the metadata and cookie auditing, in which the engine processed the response headers in tandem with any active tracking tokens, for headers, the tool inspects operational identifiers like X-Powered-By: PHP, X-AspNet-Version, or reverse-proxy footprints. And for cookies, it inspects state tokens (like laravel_session, django_csrftoken, or PHPSESSID).

And if none of this can't get into a conclusion, the tool falls back to active file probing (sig.files). This involves looking for explicit, non-indexed developer endpoints (e.g., /wp-login.php, /vendor/composer/, or /package.json).

And to execute all this without getting rate-limited in 5 minutes, i coded some mechanics to the engine, one was the tstacksleep, in which instead of executing sequential checks at high speeds, the engine sits on an asynchronous window loop that introduces randomized timing intervals between 300ms and 900ms per attempt. This disrupts the uniform request pattern that automated defensive monitors typically flag, and this was also customizable via a flag. Then was a mechanism of the verification function using the efficient HTTP HEAD requests rather than full GET operations, significantly dropping network overhead. Crucially, it looks for both 200 OK and 403 Forbidden status codes:

After this, i coded a new thing, an automated vulnerability scan, which could prove to be sometimes extremely useful, here TrufflePigg attempts to automate the triage phase by mapping software banners directly to known public vulnerabilities via the National Vulnerability Database (NVD) API. The only wrinkle with this was the same as crt.sh, it was also strictly rate-limited, so i coded a cool-down period for the feature and it's not a big issue as nobody is gonna spam the command each 2 seconds. But this was worth it, because whenever i did a scan, it accurately showed me all the linked CVEs and yeah, but don't worry i never used them.

Then i coded a feature for scraping the robots.txt and the sitemap.xml, then fetching and parsing them and then giving an option for the user to download them, because this could reveal, some very sensitive info if the developer had misconfigured it. Then i added a crawlSitemap function recursively traverses sitemap indices (sitemapindex) up to 15 levels deep, extracting explicit location endpoints (urlset). Now it could map the discovered URLs against a keyword matrix (admin, login, api, dashboard, config, dev) to filter and isolate high-value assessment targets automatically.

Now it was my favorite of all, the Shadow Trust Analysis, the thing is that, a significant portion of modern web vulnerability surface area involves resources hosted outside the target's direct infrastructure. If an asset scripts a resource from an expired domain or bucket, the client remains vulnerable to third-party script manipulation. Using cheerio, TrufflePigg parses all asset tags (script, link, img, iframe, form, a) to discover foreign host domains, ignoring domains present in a local whitelist (WHITELIST_DOMAINS). Then it queries DNS (dns.resolve4) to verify if the third-party domain has lapsed into an unallocated or dead state (ENOTFOUND). If an asset points to AWS S3 infrastructure, it contacts the bucket directly to check if it returns a string matching NoSuchBucket. This signature explicitly confirms that the bucket name has been abandoned and is vulnerable to hijacking. It also calculates mutations of the resource provider's core domain name across standard alternative TLD extensions to detect if alternative paths are unprotected.

Then it was the scrapeJsForSecrets function, where the scanner extracts all relative and absolute script paths linked within the source DOM. It downloads the text content of each source file via the proxy pipeline. It scans the file content against regular expressions (SECRET_PATTERNS) checking for items like Google API keys, AWS credentials, and Stripe endpoints. And toeliminate junk data or placeholder variables, the tool verifies findings against isHighFidelitySecret(), which drops findings that contain low Shannon entropy or nearby indicator strings such as example, test, or placeholder.

Then there was a breadcrumbScan, an optional feature through flag contextual crawling which tracked application workflow transitions up to a user-configured limit (maxHops).

Now after this phase, i came to the final phase, or i that's what i thought. This was the anti-detection phase, trying my best to make the tool as silent as possible and try to make it go undetected by IDSs and WAFs. The first thing i did was to implement some spoofing methods. The reason why recon scripts or bot scripts in general get caught by WAFs or IDSs is because modern WAFs and IDSs are awfully good at scanning the user(or the script) to find if they have 'natural' headers or the timing in using processes. And as y'all clearly know, a headless script scraping a page wouldn't have a header looking like: User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36, not like User-Agent: axios/1.6.0 Node.js/v20.10.0, so what i did was that, i made TrufflePigg reference a pretty extensive pre-defined BROWSER_PROFILES. When a request initializes, it selects a browser environment profile at random and attaches matching, granular metadata parameters to keep the transaction fingerprint consistent.

The other common thing that detection systems used was, to find out if the user was on HTTP/1.1 or HTTP/2, the reason is that, the legacy 1.1 is actually the default traffic method, and this has proven a lot of times, so most systems are built to flag or block HTTP/1.1 traffic, but HTTP/2 is the configuration used by almost all browsers. Because of that i used Node's native node:http2 library to fool these systems and establish asynchronous, long-lived multiplexed channels. Then i fine-tuned configuration states (enablePush: false, initialWindowSize: 6291456) to mimic the flow control behaviors of standard desktop browsers like Chromium. The next thing i added was a bit more paranoid but kinda essential, it was that i added a feature of routing all the traffic, all except for the ones which talks with the external source APIs, through Tor or a list of proxies, i did this through the SocksClient library. And if that was a bit too much you could also use the --protate feature which routes the traffic through a list of proxies but this is a bit faster option but inevitable less anonymous. i then coded a reverse-proxy header spoofing where the tool calls getWafEvasionHeaders() to supplement outgoing streams with fake routing tracking records. By injecting internal loopback ranges or private network signatures into headers like X-Forwarded-For or True-Client-IP, it attempts to pass traffic through upstream appliances without triggering block rules.

Then i coded a user-configurable request jitter, where rather than delivering requests at fixed intervals, scanner.js integrates variable timing controls (tstacksleep and sleep methods). During tech-stack analysis and endpoint discovery routines, the system pauses execution using dynamic mathematical ranges (e.g., between 300ms and 900ms) to mirror human surfing behaviors and avoid threshold-based rate limits.

And finally(or i thought) i was preparing it for release, first Codeberg, then GitHub and also a GitHub package(npm), why not npm itself? Because npm has this insanely annoying authentication system and is just not my thing. But then i re-checked the code, damn it was 3000-something monolith, i was surprised but didn't think much about maintainability, as i could easily find anything by my mind. So for a final test, i gave the code to some of my friends at the Hacker Webring, a person first checked it and said 'damn this could use a bit of separating', and i already knew i should do something about that, and then after sometime, the maintainer of the ring, Dmi shared their comment, '...it's definitely unmaintainable.' and Jak2k said, 'The code really looks messy and unmaintainable', then i was sure i needed to REALLY modularize it, and in 7-8 hours, i had successfully modularized it into 6 parts; TrufflePigg.js: The interface, argument parsing, and orchestration engine. sniffer.js: Handles low-level TCP/UDP socket connections, banner grabbing, custom protocol payloads (SMB, DBs), and DNS/WHOIS interactions. scanner.js: The brain of the tool. It processes the raw data, identifies honeypots, fuzzes directories, analyzes DOM elements, and hunts for secrets. networker.js: Manages HTTP/2 connections, Tor routing, SOCKS5 proxy rotation, and TLS fingerprint evasion. utils.js: Contains string manipulation, entropy calculations, similarity algorithms, and humanized request header generation. data.js: Stores technology signatures, common ports, WAF identifiers, regex patterns for secrets, and byte-level payloads for infrastructure probes.

And with all that I PUSHED THE CODE. Nice.

]]>