Today's Tutorial [June 18, 2026]
Lesson 219: Hacking Windows Course (Chapter 16: MoveFile)
This chapter covers reviewing the Windows API MoveFileW function in C.
#STEM#Windows#ReverseEngineering
https://t.co/JJ24cE9Y9f
> be pakistan government
> develop custom malware
> used to target high profile targets
> used against indian military and political ppl
> named SHEETCREEP
> send indian ppl file
> UAE-India Strategic Partnership Week
> malicious .lnk file
> .lnk executes malicious c sharp code
> does a bunch of stuff for persistence
> exfiltrates data to Google Sheets
> Google Sheets can be used to control victim pcs
> pakistan gov hardcodes google c2 sheet
> PAKISTAN GOV HARDCODES GOOGLE C2 SHEET
> embed access key in payload
> EMBED ACCESS KEY IN PAYLOAD
> malware nerds find it
> look inside
> find all targets from pakistan gov
> monitoring 91 ppl they think important
THEY STARTED SO STRONG. WHY DID YOU HARDCODE EVERYTHING. YOU BURNED YOUR OPERATION
https://t.co/PcCeV05cu3
I’m convinced that old games feel “hard” because modern emulators have like 30 layers of abstraction between the input and the screen.
Today you’ve got controllers going through bluetooth driver stacks, on general purpose operating systems, with all sorts of thread coordination, GPU APIs, not to mention display latency…
Much easier for the brain to learn when the original hardware is extremely deterministic!
Probably the best free Windows usermode exploit development training in the world.
41 tutorials. 17 years. Stack overflows. SEH exploits. Shellcoding. Egg hunting. ROP chains. Heap spraying. Unicode exploits. Bypassing DEP, ASLR, SafeSEH, SEHOP, stack cookies. Integer overflows. Memory corruption root cause analysis. Win32 and WoW64. Metasploit integration. WinDbg automation. https://t.co/V98i0hvXwu v1 through v3.
Updated in 2026 for Windows 10 and 11 x64 with video walkthroughs and AI-assisted crash triage.
Free. No paywall. No login.
https://t.co/jgBNA410yF
Author: @corelanc0d3r
#ExploitDevelopment #ReverseEngineering #InfoSec
Some rly interesting RCE bugs got patched today!! Would be an interesting test for a certain super saiyan cyber model that’s really goated at exploitation... Oh well 😔
It’s no secret that I’m a big fan of the International Obfuscated C Code Contest!
Excited to watch winners streaming at 11AM PDT today (06/06).
It always brings out an interesting blend of compiler nerds, programming language theorists, and researchers.
Give it a watch, it’s the longest-running programming competition in the world!
This guy sucks. At my first Pwn2Own he asked me over and over if it was my first CVE. I said no but he kept insisting, in front of everyone, he’d never seen my name credited before. Turns out he was confusing me with another woman in infosec. In charge of security research engagement for MSRC btw
RAM exists as a 1-dimensional space. For programming…that’s kind of irritating.
All the important math happens in 2D arrays.
It’s simple(ish) to compress a higher level space into a single dimension (most languages today are row-major), but there’s a funny quirk.
At the *physical* DRAM layer, the actual bits *are* stored in a 2D array, rows and columns. (…well, when you add up all the layers, it’s more like a hierarchy of 2D arrays, but you get my point).
If this information was directly exposed to you…gosh there are all sorts of neat tricks you can get away with!
Unfortunately, keeping memory addresses in a 1-D space makes things much simpler from the OS perspective for memory management, not to mention code portability. There are nasty security problems too...certainly some valid reasons for keeping physical structure hidden.
Yet, think of how much of performance engineering / memory locality work could be shortcutted if it were trivial to understand the exact physical layout of how your arrays were stored!
Since we're sharing MSRC stories: a few months back I gave them an Azure Sign-In logging bypass.
They said it was no biggie, as it merely allows attackers to bypass the logging that every admin relies on. Doesn't meet the bar.
Fixed in record time. No recognition. No bounty.
Chinese Backdoor for Telecom Systems
A while ago we showed the backdoor that the Chinese have been using to maintain persistence across telecom systems.
The backdoor attaches itself to a raw network socket and inspects incoming traffic. It sees packets before firewall rules have a chance to process them. So even if your firewall is configured correctly, the backdoor can still see traffic that should have been blocked.
To access the system hackers send a magic byte to get a reverse shell
We also showed how you can detect it
https://t.co/fBXtksn2Ju
@three_cube@_aircorridor #apt #redteam #blueteam
DO NOT use Telegram in sensitive applications. Telegram does not need to have its message encryption broken for users to be tracked at the network layer. Telegram sends MTProto over unencrypted TCP, exposing auth_key_id - a long-lived identifier tied to the client’s authorisation key. An ISP, hotel WiFi operator, mobile carrier, transit provider, or surveillance system on the network path can see that identifier if they can observe the traffic. It can remain stable across app restarts, IP changes, VPN use, network switches, and location changes. Secret Chats protect message content, but this leak is below that layer. That makes the attack passive. The risk is in retroactive correlation. Think a journalist using Telegram from different networks for months, then joining hotel or corporate WiFi under a real name. That one identity anchor could make old logs searchable for the same auth_key_id. The fix is simple - mandatory transport encryption for all MTProto connections, with no unencrypted fallback. Telegram chose not to do this. Source: @kaepora https://t.co/TJALYAwaOs
A cool way to watermark network packets is to (very subtly) adjust the timing.
Packet comes in a tiny bit late, maybe that’s a 0. Packet arrives on time? Maybe that’s a 1.
Of course, the neat part is that everything can remain entirely encrypted / the side channel doesn’t “touch” the underlying data flow, so it looks relatively normal.
You can actually get this timing to survive through multiple network hops + switches, because statistically they are (mostly) adding fixed delays. Queueing can mess you up, but as long as your information is above the network jitter noise, you can still decode it.
There’s basically an arm’s race going on. Some networks attempt mixing flows with traffic shapers to preserve anonymity…but you also can’t infinitely pad/delay packets without users getting really annoyed.
So, so many ways to hide a bit when you think about it.
…also a lot of ways to detect it too.
this got me thinking, what’s the most token-dense programming language?
One that could fit the most program flow into the smallest context window?
The winner, by a lot, is Array-Based Languages. J, K, that sort of thing.
It’s actually a two-part problem, because you need something that is logically dense (saves length), but symbolically simple. Most tokenizers are optimized for standard text, so if you get *too* fancy with rare mathematical symbols like APL, token usage actually blows up!
Python scores pretty well actually, but whitespace hurts you a bit. Haskell is an interesting outlier; it’s likely the most token-efficient statically typed language.
Now, if you were to extend the problem assuming you’re making your own tokenizer and training a model to *specifically* be as efficient with program writing as possible…
…you probably wouldn’t even use text. Just train/produce Abstract-Syntax-Trees directly, which would eventually start to look like compiler IRs / bytecode, which could eventually start looking like an ISA…
and with hardware/software co-design we’d end up with CPUs where we don’t understand the execution at all ;)
CPUs tend to get slower with time. Probably not for the reason you’d expect.
Unfortunately, many microcode updates are security related, which almost universally cause performance regressions…or even complete feature loss!
Haswell might be the worst performing processor family of all time, in terms of features removed.
TSX - concurrency instruction literally removed due to security concerns
DX12 - removed / broken due to priv escalation
Meltdown, Spectre, Foreshadow, MDS - all lead to perf regressions…for MDS specifically Red Hat and Microsoft still suggest disabling HyperThreading on Haswell!
Over the life of a CPU, I’d expect the typical performance curve (from microcode) to look like:
Initial Launch to +1 year, slight upward trend, platform maturing
1-2 years, mostly flat
2+ years, likely downward trend. Enough time has passed where security people are starting to poke/write papers indirectly leading to vendor microcode regressions
6+ years / EOL -> old CPUs start to have major regressions!
I genuinely wonder if extremely performance-sensitive industries sometimes purposefully delay or otherwise remain on “stale” microcode…and just accept the additional risk.
There’s a famous Usenet story about a programmer (Mel) who refused higher level abstractions.
It was the late 1950s, and even in that era, Mel was…well today we’d call him a boomer.
Mel only wrote in raw hexadecimal. He didn’t approve of compilers, and refused to use optimizing assemblers.
"You never know where it's going to put things”, he said.
Everyone else in the company was moving on to FORTRAN, and they didn’t understand why Mel was so stubborn about using new tools. He *loved* self-modifying code.
“If a program can’t rewrite its own code”, he asked, “what good is it?”
Mel eventually left the company, and other engineers were tasked with understanding what was left.
Mel’s hand-optimized routines always beat the assemblers; but some of it looked absolutely bizarre.
One engineer took ~2 weeks to understand why there were loops with no exit condition…yet the program worked fine.
I won’t spoil all the details, you should really read it, it’s short. But it’s a fantastic piece on “what defines a real programmer?”…which is becoming increasingly relevant in this vibe-coded era.
I strive to understand computers as deeply as Mel! If we aren’t careful, we’re going to lose the “Mels” of this world to time.
That’s part of why I go so deep in my youtube videos. I hope that younger viewers are genuinely fascinated by the inner workings of our machines, instead of handing everything off to higher abstractions.