I Reverse Engineered a Dangerous Virus and Found Something WEIRD (ESXiargs ransomware deep dive)
HTML-код
- Опубликовано: 17 фев 2023
- ESXiArgs has been running a rampage on the internet, but we need to figure out what. In this video we'll do a deep dive on the ESXiArgs malware and see if there's anything fishy that we can take advantage of to decrypt the files.
🏫 COURSES 🏫
Learn to code in C at lowlevel.academy
🛒 GREAT BOOKS FOR THE LOWEST LEVEL🛒
Blue Fox: Arm Assembly Internals and Reverse Engineering: amzn.to/4394t87
Practical Reverse Engineering: x86, x64, ARM, Windows Kernel, Reversing Tools, and Obfuscation : amzn.to/3C1z4sk
Practical Malware Analysis: The Hands-On Guide to Dissecting Malicious Software : amzn.to/3C1daFy
The Ghidra Book: The Definitive Guide: amzn.to/3WC2Vkg
🔥🔥🔥 SOCIALS 🔥🔥🔥
Low Level Merch!: www.linktr.ee/lowlevellearning
Follow me on Twitter: / lowleveltweets
Follow me on Twitch: / lowlevellearning
Join me on Discord!: / discord 
Наука
Sign up for my NEW weekly newsletter on software development and cybersecurity industry trends! bit.ly/3OaLCVb
I've never seen a reverse engineer video before. Man this is nuts!! Pretty cool!
Thankyou triple L for the big font size!🎉
Where is the part about the visual binary analysis? I came here from the Short, to see the part about the entropy, but it's not in the video :-(
Did you added wrong link to the short?
Maybe they left the debug symbols because they knew that even when you disassemble it, you won't be able to extract any information that could help the victim. I.e. it was a "flex".
That and it makes it clear that if they pay and get the private key that the data is actually recoverable.
Or the binaries were simply „borrowed” from something else by script kiddie… ;)
Borrowing code doesn't necessarily mean you are a script kiddie.
@@jordixboy the implication here is that they 'borrowed' the code, and didn't bother with removing the debug symbols, or didn't even know how one would do that
I'd rather think it's incompetence, ransomware authors typically "flex" by specially naming mutexes, threatening ransom notes, unobfuscated strings and so on instead of leaving the debug symbols.
Honestly, the large font size is useful on larger screens as well! Much, much easier to read.
large font gang rise up
My god i didn’t understand anything you said lol maybe it’s my age 76 😎
Yes, thank you!
I was able to watch this video from my neighbor's laptop without needing binoculars!
😄
I'm a little on the fence. It's dead easy to read, but it reduces the amount of context I get from the surrounding code because of the little that fits on a single screen
Agreed.
Even if I can read small print, doesn't mean that I want to when it's available in a larger size just as easily.
Considering the part that causes actual harm is an unobfuscated *bash script,* it's pretty safe to say that leaving symbols in their generic encrypt/decrypt binaries wasn't a consideration.
This kind of malware is effective thanks to women in the workplace. You can rest assured that Karen from HR will click the link to reveal how she can claim the $500 amazon gift card she just won....every...friggin...time.
pretty funny to see it's a regular shell script
@@dingdong2103 Is it though? Funny, I mean. Demented and sad, maybe, but is it really funny? Like, two guys walk into a bar, which is weird because you would think that after the first guy walked into it, the second guy would have seen it. That's funny. Hey, want to hear a joke? This guy I don't know had all of his ERP files encrypted by some scammer using a regular shell script! He couldn't afford the ransom, so ended up losing his business! Ha ha ha ha! It was a shell script! Get it? That's not really funny, right? There's a set up, but not much of a pay off.
I'm really sorry, I've gone off for far too long; I get like that sometimes. If by funny you mean, wow interesting, then yes, it is disturbingly interesting that the whole thing is based around PKI and a trivial shell script. Stupid simple, yet potentially devastating.
@@douggodsoe It's funny because anyone can read the bash script before running it so the chances of this attack being successful is close to none. It's done in an extremely amateur way.
@@dingdong2103 Oh, definitely, but people don't read, they just click and run. Good Times! Sorry for being a dick earlier. I get like that when I've been drinking, which is often. Still, good video, yeah?
Keep the cybersecurity stuff coming 😎
Yes please :)
They made the binaries easy to use because they wanted you to know that there is no backdoor, you need to get (ie. pay for) the private key.
Plus not stripping also increases the odds that their genius will be talked about, maybe even on RUclips.
Anyone qualified to make that determination would not need the debug symbols. (or trust them!)
Yeah, this is a very straightforward encrypt/decrypt solution using libssl. It's very similar to how TLS streams work at a high level (pub key used to encrypt a symmetric session key.)
One property of good encryption & decryption algorithms is you should be able to know everything about them and how they work, and not be able to decrypt ciphertext without the secret or private key. In theory at least, for example there are implementation errors, like using a weak random number generator
And more importantly they wanted their "customers" to trust that their data is recoverable.
Thank you LLL
Thank you LLL!
3:57 *Missing summary:* There are two types of encryption:
* symmetric, and
* asymmetric.
*Symmetric* cryptography uses the *same key* for encryption and decryption.
*Asymmetric* cryptography has the *key split in half:* a public key and a private key.
Thank you triple L. Loving the cyber security content! Keep it coming.
Thank you for the big fonts!! I wish the other RUclipsrs would do this more: I only consume content from my phone and it’s always hard to read.
On made-for-mobile content the click here endings look silly. Everyone does them. I chuckle.
I'm approaching old fart status and I enjoy content on a 50 inch 4k TV as my monitor ;) Quite legible with small fonts no matter how many terminals or windows I choose to have open.
On mobile you can pinch to zoom in up to 8x.
Be honest; small fonts are not the reason you don't read. I get it. Words are hard.
I'm just teasing you, man. Don't go getting all angry and start beating your kids when they refuse to learn Python because untyped languages are for kitty cats.
I, too, dig the big readable fonts.
Great video, this has been on my mind though: Why would a ransomware writer want to obfuscate their code? If their main goal was to collect ransom, and the program was cryptographically secure, wouldn't they want to lay out everything they did in an easy to understand way? Beeing able to see exactly how I was pwned would give me at least a little bit more confidence that I would get a key in exchange for money.
the point is presumably - they realize they could have bugs, so it makes sense to make it harder to find them
Ransomware authors may do so to evade AV heuristics and prevent other ransomware authors from copying features from their own product.
These two binaries are vanilla encrypt/decrypt apps with nothing to hide.
I don't think these people are that sophisticated to consider such things. It's like asking, why would a rock want to roll down a hill? Don't think too hard on it. The answer will not provide enlightenment.
@@Randrew .. which makes them much less likely to be detected as malware than custom code which has been used in other malware and is known to the anti-malware community.
common lowlevellearning W
very nice code! I've seen corporate code that looked worse than this malware. Also: security lives from openness. The symbols were left in, so you could read it. And if you had found a bug, only then they could have improved your malware ^^
I think they can leave the debug on because anyone analyzing the binaires will just learn that he cannot actually decrypt the files without the private key.
The sooner the victim realizes that he cannot decrypt the files without the private key, the better for the scammer.
The scammer could truly send the source code that it wouldn't matter.
As for obtaining the private key form the public key, that is possible in theory.
However, you won't be able to find the private key in practice unless the key is way too small (which is unlikely) or has been made by a program that is way way too predictable in how it generates its keys (and you know or guess that that program has been used to create the key) . You could wait until quantum computers with as many quantum bits as the public keys are a real thing (and boy that will be a mess when they reach that stage...) but that might be a long wait... As for using modern supercomputers, you are very unlikely to find the private key with them unless it was generated using some weak algorithms.
It is never impossible to decrypt a file, but if the expected decrypt time is too long, nobody will bother trying. Most professional cryptographers aim for a typical decryption time to sink to about 10 years before they improve their algorithms.
Great video!
4:14 Large font is very much appreciated but 64 pt is maybe a tad TOO large. 48 pt or 56 pt might be a better compromise.
5:32 Also, maybe make your camera be a slightly smaller circle and move it up to the right so it doesn’t obscure the code
Thank your triple L
I just wanted to take a moment to express my appreciation for your incredible RUclips channel. Your dedication to teaching low-level programming concepts and techniques is truly inspiring,. I would love to hear your personal story about how you learned reverse engineering, and any tips or advice you have for people who are just starting to explore this topic, and thank you.
There was a time when the only "easy" way to reverse engineer something was by examining hex code dumps. A very good way to learn reverse engineering is to do forward engineering - if I write this source code, what does it look like after it has been compiled etc
This part of the malware is not the valuable part. This is just some basic encrypt / decrypt software that probably took them like half a day to make. Hell I'm surprised they didn't provide a readme / documentation for how it works. After all, their goal is to convince you that you'll get your stuff back if you pay the ransom. The real important part is how they got the files onto your server and ran them. That's the secret part that I'm sure they'd want to protect.
Yes, good point. It also makes it clear to the victim there is no trick they can do to recover the files.
Thank you for the font size! - and also for the great content in general 🙂
They can run just string reversion, for example taking some strings from the end of file and putting it to the start of file, so you cant open it, and mention that it's strongly encrypted. ive got a ransom like that once. Its time saving, when you need to corrupt large amount of data, before ransom to be found
They don't care if you have the encryption/decryption algorithm since it doesn't do much good without the private key. It seems unlikely they're "mad at you".
Still, an interesting video.
Thank you LLL!!! Seriously bro, that move is next level! That is how you take care of the peeps consuming your content. This is the first video I have seen of yours but I have subbed and liked this vid. Keep killing it!
Yessss!! More security stuff! I'm trying to learn it, but it's tough, lots to learn!
The large fonts are great. This is the first malware video I've ever seen. I'm very glad that you're a white hat guy! Keep up the good work.
I think, even stripped binary without debug info would have symbol table. Due to external linkage in C/C++ for main function, you'll see it there as it is required for possibility of late symbol resolution (e.g. substituting original main with something else during run-time).
Yes, it's also required for dynamic linking if I am not wrong.
Was the "encrypt" command really malware though? It looks like a useful cli tool for legitimate purposes, and maybe it's open source software that they pulled off someone's github - in which case they wouldn't care if someone gets into the source code.
Probably was malware, given that they opened OpenSSL and dynamically loaded symbols. You usually wouldn't do that...
True, but if it's open source, maybe that's the only thing they actually changed.
You're mostly right. Like David mentions in this thread, the design is a tad aggressive about finding an openssl lib to load. Everyone else would stick to a major and/or minor openssl version and fail hard in other cases since incompatibilities open up support problems. But other than that, it's a very robust (would run on most any linux) pair of encrypt/decrypt openssl wrappers.
Forgetting to remove debugging symbols is just inefficient. No reason not to remove them in your final executable.
if you think about it, ransomwares are just script that encrypt your files. The action of encrypting things isn't malicious because you might want to do it yourself for privacy.
As a cell phone user i love that you made the font larger 🙃 i appreciate your thoughtfulness
Great content man, nice work!
They bought the code. They didn’t write it themselves and must pay a fee to the script writer.
The signatures are to ID the program and who must be paid.
LLL Is the best! Thank you! Just a question, the name of disassembler software that you use is "Ghidra" ?
Yes, correct
Great VLOG. Nicely done. I missed what they did with the private key. Stored it somewhere, or transmitted it back to themselves.? Thanks (I used to work at RSA on their cryptography architecture team.) I wound up in data security consulting.
You know what people I commented on a lot of videos about not being able to read them and stuff. This is the first content creators that I ran into that's actually blown it up for the people that have to use the phones that are too poor for the internet. So just content creator on the sign up for that thank you for considering us is part of your viewing group.
They use rsa_encrypt directly on a blank symmetric key? Did you check the public key for having a low exponent e? If it's 3 or 7 you might just be able to take the 3rd or 7th root of the value to get the symmetric key out.
Hey, cybersec engineer student here poking around with reverse engineering. Love the quality of the content!
I'd love to try and apply my knowledge on some malware reversing. Is there any (softly) obfuscated malware that you would recommend to play with?
Thanks for putting up with the large font, certainly was appreciated. Cheers ~Smile oN
Nice! I look forward to seeing more security related content on your channel! Thank you for supporting our community! 🧠🏴☠
love this type of content !
Thank you triple L! Excited for more rev content! Also binary exploitation and other cyber subjects would be cool
Well they are certainly going with the No Security Through Obscurity Principle.
Thanks LLL! Would love more cyber sec content!
As someone who's recently been getting into the low-code/JS space due to work, this was very interesting, as you covered the main functions and described what they do, leading to better understanding! Got a subscribe from me.
Love your LL system-related content, could you do one regarding how to use the core dump of a segfaulted C executable? I'd love your explanations on that.
wdym "use the core dump"?
@@xblxckxpxny1005 A core dump contains the registers (such as IP), memory, and callstack; this can be used to help determine where add why the program crashed.
Thank you LLL. Fascinating stuff, can barely follow it ( last time I "played" with code was Dos. LOL. Yeah, old). But its nice to see a pro work.
I haven’t a clue what you just did or either do I understand what you said, but I still appreciate your knowledge, and respect the fact you’re always trying, and most instances succeeding, to be one better than the people who cause so much misery to so many people. Thank you 🙏
I feel the same 😂
Cool to see the walk through. How the script gets the argument ls to run the encrypt command. So we know what it ran. Even have how to use the decrypt binary. Still doesn’t save the day or what the decrypt rsa token would be.
Why should they strip their code? If it is secure, then this information is useless anyway?
Exactly, in fact it might make the victims more likely to payout because they can see that your binary uses openssl and therefore is unlikely to have cryptographic vulnerabilities.
Moreover, by keeping everything they show they understood the math. Obfuscation is only ever done to hide ineffective security algorithms or by those who do not understand at all. Hiding proprietary encryption would always amount to hiding probably ineffective algorithms, so even those cases are ruled out. If you understand science your only real option is to take a stance and show everything, they should even provide a donload link for the source code.
Conclusion: Nothing weird or unexpected.
On a side-note, if more linux programs were made this way, where they scan for the libs they need and then check each lib to ensure it has what they need, they'd save people a lot of headache with the perpetual fail of libs and their dependencies, and the various versions of them, which often make it difficult to produce an executable that "just works" regardless of the distro.
The reason that apps usually don't do this is that there can be other changes not captured by the symbol name alone that would cause crashes or other misbehavior if it loaded the "wrong" version. So most apps, especially open source apps that will just be recompiled with exactly the right version, just expect a single known version to avoid potential incompatibilities.
@@Mirality While what you say is true, how is that worse than the program not working at all because of some subversion increment on a lib?
Linux is by nature a collection of individual programs that do stuff, so while larger apps may not work using this approach, single-executable programs would probably work best. For example, megacli (for viewing details about LSI Logic raid controllers and making changes as needed).
Because "other misbehavior" is not limited to crashing. It could include formatting your drive or sending your credit cards to scammers. While this particular case is malware anyway so those things are on the table even without misbehavior, leaving those kinds of holes can be openings for malware to trick regular programs into doing it, or if you're really unlucky, it happening by accident.
Provided that library authors follow the rules, that particular version number is only incremented for "serious incompatible change", which does require programs to at least recompile, if not also change their code. There are different version numbers for more backwards-compatible changes which do allow upgrading a library without recompiling.
@@Mirality You could make a malicious program that follows the "rules". I don't really see that as a valid counterpoint. There are also plenty of programs that do things the "right way" and still end up with memory leaks and vulnerabilities. Perhaps linux has been somewhat resilient to malware due to the poor to non-existent compatibility among distros but it is also a hindrance. From the programmers' perspectives you either compile for all distros you want to support or release source and let them do it...but maybe you just want to distribute a 'universally compatible' executable. There is nothing wrong with that, and rules are really just suggestions.
@LunacyStudy That's the theory, but you miss the point that the linker will only link what is on the particular distro you are building on. You can't compile an exe on fedora that depends on certain libs of certain versions, then expect it to run without issue on gentoo or even older versions of centos. Loading what you need at runtime works, and there really is no good argument against it, especially if you are dealing with basic stuff like openssl.
I have been coding in assembly since the late '70s, working with processors like 8088/86. One effective method to avoid dealing with semi-script kiddie activities is to restrict access to specific files through a tunneling script stored in the RAM. There are various ways to achieve this using concise code snippets. It seems like the world has it backward; instead of preventing such issues with straightforward methods, many rely on extensive, advanced, and expensive antivirus software. What's the point?
Very nice work on this. Subbed as well !!
It seems like the authors took "security through obscurity isn't security". I mean, having it not obfuscated probably lets the victims know there is no other way than paying up, and prevents wasting everyone's time I guess.
And it also makes it abundantly clear that the only way out is the private key, and could also be a way to tell "lmao it's so simple, babies could write this encrypt binary, get rekt lol", so maybe a flex there too, I guess? This shows that the actual "malware" isn't advanced, the way they got it in is. And honestly, bringing light to this is the good part. Because let's face it, most OSs these days have good protection. The only "vulnerability" is probably the organization and/or the humans in the gears.
passwords are obscurity, encryption is obscurity, heck even a firewall is obscurity. Obscurity is big part of security. The way i fixed SSH brute force attempts is obscurity, not obscuring just by port but by ip address as well. You can block port scanning and use port knocking as well but ultimately what stopped it is getting a seperate IP adress for SSH(and not putting that IP address on your DNS records of your web service).
@@ChrisWijtmansI guess what I was trying to say is that obscurity shouldn't be the only / the most 'powerful' of the protections that are there, You do make valid points, but in my head, it feelsl like the only thing obscurity does is slow someone down. There are pretty good analyzers these days that might get through it. Basically, defeating obscurity is a matter of when, not a matter of if, unlike more established security practices. But yeah obscurity perhaps does have its place, at least at stopping the script-kiddies that just think "haha script go brr"
If they give you the private key, wouldn't that mean that you could just share it and everyone else will be able to decrypt their files? Also, I think the thing I was most curious about was how they encrypt the file in place. The cryptography stuff seems like they are just using standard stuff, seems unlikely they would mess up there.
BTW, wouldn't they want for people to be able to inspect the code at some extent? If you are confident that the code will actually recover your files you're more likely to pay than if you suspect the files may just been overwritten entirely and are now impossible to recover. Leaving debug info may be intentional. There's nothing to hide there anyway, they are doing exactly what you'd expect and the only solution is paying them.
They would encrypt with a different public key per victim, so the corresponding private key wouldn't be helpful to anyone else
@@I3i11W So this is spear phished? It's not clear from this info where the RSA keypair comes from.
Sha-256 salted is what they use to do
The faster they know that the cryptography is sound the faster they pay
Ok, I didn't expect a simple open bash script doing a lot of it. Possibly explains why there was a lot of seemingly rookie moves in the encryption code. I suppose it does what it needs to do to accomplish what they're trying to get done. It will be enough to get a result from most people and businesses.
So the only weird thing was the presence of debug symbols? I was expecting _a lot_ more with such a clickbait title. This ended up just being a walkthrough of the most basic steps for how _ordinary_ encryption/decryption works, and barely even that.
Thank you LLL, as a mobile consumer it’s appreciated
ok, I'm very happy that (at least until you put it in the disassembler) you didn't run this under GDB.
I'm a gdb developer, this is a public service announcement: As much as we would LOVE to make gdb safe to just look at a file without executing it, it isn't safe to do that just yet. We have a few issues in how we read debug information. Maliciously crafted debug information can at the very least cause your GDB to crash, and while no one ever managed to prove that those crashes lead to controllable memory corruption or code execution or whatever, no one ever manage to prove it _doesn't_... so for the time being, if you wish to look at an untrusted binary - even if you just look at it statically - sandbox your environment.
And if you wanna see how something ticks with GDB, it's literally as secure as running it raw, we perform no security controls whatsoever.
Thank you for the big fonts, makes it more accessible, I have difficulty reading small fonts!❤
Good stuff. Still eagerly awaiting part 2 of the baby monitor pen testing too 😉
As someone who often watches on his phone, I appreciate the effort, but you don't need the font THAT big. If you're watching a programming video in portrait mode on your phone you're doing something wrong.
Also, "with debug_info, not stripped" LOL. I'm no infosec/reverse engineering guy, but seeing that in malware is hilarious.
The bigger font is helpful for computer users and people who struggle to see. Not everyone can afford glasses sadly
It's not the malware, it's the payload. The malware is the program that loads and executes theese programs.
thanks for doing this, very interesting talk. From where I sit I'd be worried about this code could get onto an ESX in the first place. I can imagine how but it makes me cringe :D
As someone that binges these during downtime while not at my pc I appreciated the larger font
Obviously the people making this were just shitty script kiddies. Not only did they not strip their code and left the debug info in it, but you can clearly see that their code is absolute garbage as well.
Anytime you have to commit the crime of nesting 5 or 6 "if else" statements you know your code sucks.
TRUE
are you sure code is garbage not because decompiler?
I'm also not sure why they chose to dynamically link these cryptography libraries, either. Wouldn't you want to make the code more portable?
@@xBZZZZyt well they did leave the debugging symbols, so more than likely no optimizations on the binary.
I didn't find the nested ifs that hard to follow. Why the hate
they left the debug info to prove that if they give you the private key, you can build a decrypter by yourself, so you know that there is something to buy. quite smart. also if you buy the decript key but you don't have a way to verify or build by yourself the decrypt program, the effort to write a decryptor could be significative and also you may not trust the decrypted data and then make less likely to buy the key.
i think that it is really to make you to buy the key, and it is a very smart move.
Nice analysis! Liked the large font too.
Also, what computer are you using? Helpful info, thank you
If all universities taught like this, we would have a much difficult time getting jobs...
People who got hit by this ESX attack should be fired. The version that was touched by this attack had been release in december 2020 for 7.x and february 2021 for 6.7 ! They were a year late in patching
Unfortunately, VMWare release practices prevent upgrading past the last version with hardware drivers released for a given server model. When the latest attack description came out it was something that should have been blocked by firewalls already (remote access to an internal admin network address). But yeah, replacing ESXi by something else will be more maintainable.
Thank you triple L. Loving the cyber security content! Keep it coming.. Keep the cybersecurity stuff coming .
what was the something WEIRD? the debug symbols?
why should the attacker care if you reverse engineer their binary? 2:47
- They don't want you to find the vulnerability that gave them exec permission on the host. And they don't want the channel used for money transfer to lead to their identity. That's all.
- Antivirus people will find a way to fingerprint the binary regardless of it being stripped or reverse engineered or what not.
- If the data is "properly" encrypted, it doesn't matter that you know the alg - without the key you cannot do anything anyway.
Correct me if I’m wrong (probably am) but the random bytes is the initialisation vector for each chunk? (9:20)
Just a bunch of random data; you could consider it an IV or "key" or both... But I agree, I would refer to it as IV since that is usually stored with a file since it isn't secret whereas a (private) key is.
It's a key, and they don't store it directly, only an encrypted copy.
I'm on the toilet with my phone on hand really appreciating the fontsize. Thank you Mr. Triple L
The .pem file in the encrypt argument list gave everything away, even without the debug info.
The concept of the series is nice but the example is not great. You can tell exactly what the binaries do just from looking at the shell script, and it doesn't really help to have debug symbols etc because what you really need is the private key. They pretty much could have done the same thing using readily available cli tools.
It would be nice if you could show examples where reverse engineering lets you fix the damage because they have done something stupid like embedded the key in the binary etc, but I don't know how easy it is to find examples of that kind of thing.
I would love to see death penalty for those who write ransomware and malware.
That would be a terrible idea. Because many people who now work in cybersecurity used to write these kinds of software themselves before „coming clean“.
Also the death penalty is completely unjustified for this and completely immoral.
Thanks for the readable font size!
The way the ransomware is encrypting--ie. making the symmetric key with their public key, and then they supply the corresponding private key to that when someone pays--doesn't that imply that the first person to get that private key could decrypt anyone else's ransomware-encrypted files? ie. Their algorithm does not employ perfect forward secrecy.
Thanks LLL for the mobile code display. I just subscribed because I have low vision and it helps out a lot when creators go to that lengrh for us.
Thanks for the big font - nice video, strange that though debug symbols show the variables with strange names...
you went from an informative, straight to the point, understandable and good title (iirc it was "I reverse engineered this malware" or something)
and then changed it to "I HACKED THIS MALWARE OMG"
Another here who likes the large font. I watch via casting to my TV and it made everything nice and easy to read. No squinting required. Thanks!
This was 12 minutes of recommended video, that I watched and said "I'll take your word for it"🤣🤣
Thanks for the large fonts, I am now enjoying your videos from bed before going to sleep 👍
Hey Lx3, thanks for enlarging the text so I can see it on my phone. Not that I have any idea what any of it means, it's just nice to know that you're thinking about your audience. Good form, brotha. Bravo.
This was really interesting. I'd love to see more content like this.
TY for blowing up that font so I don't have to turn on my other machine while I'm working.
Hay. Thank you for increasing the font size. I appreciate it.
~♡
THANK YOU TRIPPLE L! JUst found your channel today I love it I don't even code.
Thank you L. L. L.
The visible size text was quite helpful.
I'm all microcontroller firmware, but I've been very interested in higher level info sec for a long time.... been listening to old stuff like Security Now for a decade. Definitely love this content.
Thank you, LLL. I appreciate the large code font! It doesn't looks cursed as a video.
It makes a lot of sense to leave ransomware easily reverse-engineered, because it helps prevent a few of the ways the scam can fail if the victim suspects the ransomware isn't being candid -- about what it actually did to the files, or whether it's actually worth paying up in the hopes the decryption key they receive works.
Keeping the malware easily inspected, a savvy victim can assure themselves that (a) the encryption _is_ reversible, the files aren't just scrambled to "look" encrypted, (b) there's no "stage 2" to the malware when they run the decrypt binary, (c) the encryption itself is sound, with no way to defeat it except by actually obtaining the key from the hacker, and (d) the files themselves probably haven't been exfiltrated, so there's no PII dump that'll be putting them in the news in a few weeks even if they _do_ pay up.
With debug info not stripped, that's luxurious :D
Also, thanks youtube algorithm for recommending this!
I'm just smart enough to hear you speak and know that I'm not smart enough to understand 90% of what you said.
Whatever you're doing, keep it up
Thank you triple L. I went down a youtube rabbit hole and found a cool video with a cool creator (facial hair game is on point btw) who's considerate to their viewers. Y'all are cool
props to you for including mobile/partially blind accessibility
Thanks for the larger font size!
Thank you for the huge font, my laptop is upstairs.
Thank-you LLL!
Not on mobile, but on TV, and eyes appreciate readability.
I had an email from a scammer telling me they had my password. They did, but it was a very old one that I only use for unsecure networks where I have to log into crap I don't want to use that I only use there.
I remember the email was "I have my malware in your modem" or something "you can try to change your password but I will catch it every time". He demanded bitcoin and then he's go away, and "don't be mad, we all have our jobs".
Seriously, who tries to pass off such disgraceful attacks as "just doing their job"? Obv the scum never got a penny.
I usually watch youtube on mobile, and when I'm watching tutorials I watch on my smart phone while I code on my laptop, I don't have a second monitor