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
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".
@@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.
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.
@@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?
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
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.
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.
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.
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.
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.
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.
@@hb1338 how do people predict decryption times? As a hypothetical, say I have a four bit decryption key. That's 511 possible combinations. If I can test a combination every second, then there's a 50/50 if I get it in the first 255 seconds, then if I don't it's a 50/50 if I get it in the following 127 seconds, then if not it's a 50/50 if I get it in the next 63 then a 50/50 if I get it in the next 31, then a 50/50 if I get it in the next 15, then a 50/50 in the next 7 then a 50/50 in the next 3 and a 50/50 in the next 1.5 then 100% after 511 seconds. By the time you get to 7 seconds left that's a 1/64 chance that I haven't gotten it. So is it just the time it takes to test half of the possible combinations they use as an estimate or is it 3/4 or at what point do they consider it likely enough to be expected that you've found the combination?
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
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 ^^
Год назад+49
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.
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.
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.
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 *FULL key split in half:* a public key and a private key.
Asymmetric encryption have not "key split in half", there's a private key that is pseudo-raandomly generated and a public key that is derived from the private key.
@@iAPX432 Not even wrong. 1. Yes, the FULL key is _effectively_ split in half, we call this the private key and public key. You are arguing over semantics. 2. Some people DO have access to TRUE random number generation. 3. It depends on the algorithm. In ECC this is true but in RSA this is false. p and q are used to calculate the private key (d,n) and the public key (e,n). While it is possible to generate (e,n) from (d,n), usually due to a bad e, it NOT a guarantee.
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.
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
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
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.
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.
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.
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).
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"
@@ChrisWijtmans passwords are entropy, not obscurity. the two are well-defined and distinct, but you are playing word games and rejecting what words mean.
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?
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.
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.
That's pretty easy to do: you just give it a file and see the result after running it... It even have a usage branch (if the command line was too short) to give details about what each parameter is supposed to be. :-) PS Or if you mean how to test the _shell script_ ... then yeah i'd assume you would want to use a device that has disposable vmFS. ^^
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!
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.
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.
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.
@@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.
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.
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.
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.
Ok, so its just a basic set of encrypt decrypt binaries. Nothing special about that. I wouldn't have stripped it either. Where is the actual virus part that maliciously gets the binaries on there and executes it without the user executing it? Reverse engineering the encrypt and decrypt binaries was just a waste of time and revealed nothing special.
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.
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.
Alway wonder why does pc's allow them to do this like I get editing files for the program itself but there should be restrictions, like what normal dev would use kill[file] command
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.
Just out of curiosity: If this software is using an open source library to generate the encryption key, then wouldn't it be possible to look up the default seed factor like system time or temperature and then write a script to iterate through a probable range of seeds over a file of known contents to get the key yourself?
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.
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.
I don’t know much. But I think that he will still need the private key. Trying to generate a key will take too long and not worth the time. It’s just easier to pay for the key.
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 LLL, not mobile, but legally blind. I was able to read your 64 point font. Since they built the encryption right, it doesn't matter that they didn't strip the binary … all that does is tell you that if you pay, they CAN actually decrypt your data. OTOH it also tells you that once they give you the key that decrypts you, it probably decrypts everyone hit by this malware. That actually poses an interesting thought if I were a malware author myself-a ransom pool. By the time the ransomware is spreading, the servers that'll release the key have already been set up and will never be touched again. If the thing spreads fast and the ask is relatively conservative, a large entity hit hard might have just paid it by the time smaller fish get infected. The malware in that case may just suicide with a "you got lucky" message. Meanwhile before anyone's looking for the bastard who wrote it seriously, they've already cashed out and vanished. IDK why anyone would do that, but it'd be damned hard to catch the people doing their "one-time" heist. Especially if they truly did just do it one-time.
Some virus in my windows system not letting my vm to run after I close it after first use while increasing my gpu temperature nearly to 70 degree celsius without any obvious reason. Last time I found a crypto mining virus. Is there any suggestion for me to solve the issue? Or should I fresh install Windows?
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.
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.
4:06 - what? no. You encrypt using the public key, needing the private from them. - If you encrypted with private key, you could decrypt it with the public key :D (if it's possible at all) EDIT: yeah, ok, sorry, you corrected yourself. It was just a slip of the tongue.
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.
Loved what I could watch of the video, but RUclips was running 30 seconds of ads for every 1:30 seconds of content. It just made the video unwatchable.
So LL, my question is,..... why not set up a dummy file to invoke the " ## Stop VMX " , routine before it's going to do a root-scan of the OS. ??? Tell us all why this might not work if the " Dummy " was placed in say "/opt .... or say .... /usr/share/sbin " ..... or on M$ .... C:\Windows\system 32\ ....... Thanks Stay Safe
My guess is the malware author intentionally left the debug symbols for analysis, so it would be obvious upon review that the victim was indeed screwed! Curious what an openssl dump of the public pem file would reveal??
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.
wanna learn assembly? check out my courses at lowlevel.academy
Thank you, LLL ❤
Love the large cursed font on my mobile
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.
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.
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 :)
Thank you LLL
Thank you LLL!
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.
Oh, geez. I just commented (see above) and then I saw that you guys (and some others) explained this better! Lesson learned.
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.
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.
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.
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.
@@hb1338 how do people predict decryption times? As a hypothetical, say I have a four bit decryption key. That's 511 possible combinations. If I can test a combination every second, then there's a 50/50 if I get it in the first 255 seconds, then if I don't it's a 50/50 if I get it in the following 127 seconds, then if not it's a 50/50 if I get it in the next 63 then a 50/50 if I get it in the next 31, then a 50/50 if I get it in the next 15, then a 50/50 in the next 7 then a 50/50 in the next 3 and a 50/50 in the next 1.5 then 100% after 511 seconds. By the time you get to 7 seconds left that's a 1/64 chance that I haven't gotten it. So is it just the time it takes to test half of the possible combinations they use as an estimate or is it 3/4 or at what point do they consider it likely enough to be expected that you've found the combination?
common lowlevellearning W
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
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 ^^
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.
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 *FULL key split in half:* a public key and a private key.
Asymmetric encryption have not "key split in half", there's a private key that is pseudo-raandomly generated and a public key that is derived from the private key.
@@iAPX432 Not even wrong.
1. Yes, the FULL key is _effectively_ split in half, we call this the private key and public key. You are arguing over semantics.
2. Some people DO have access to TRUE random number generation.
3. It depends on the algorithm. In ECC this is true but in RSA this is false. p and q are used to calculate the private key (d,n) and the public key (e,n). While it is possible to generate (e,n) from (d,n), usually due to a bad e, it NOT a guarantee.
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.
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
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
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
LLL Is the best! Thank you! Just a question, the name of disassembler software that you use is "Ghidra" ?
Yes, correct
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.
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.
Thank you for the font size! - and also for the great content in general 🙂
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.
Thanks for putting up with the large font, certainly was appreciated. Cheers ~Smile oN
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"
@@ChrisWijtmans passwords are entropy, not obscurity. the two are well-defined and distinct, but you are playing word games and rejecting what words mean.
@@ElusiveEel another fake security expert.
If all universities taught like this, we would have a much difficult time getting jobs...
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?
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.
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.
How do they test these to make sure they work? Do you need a separate device for that?
That's pretty easy to do: you just give it a file and see the result after running it... It even have a usage branch (if the command line was too short) to give details about what each parameter is supposed to be. :-)
PS Or if you mean how to test the _shell script_ ... then yeah i'd assume you would want to use a device that has disposable vmFS. ^^
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!
As a cell phone user i love that you made the font larger 🙃 i appreciate your thoughtfulness
love this type of content !
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.
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.
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.
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.
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.
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.
So what was the weird thing you found? That the debug into was left in?
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.
Ok, so its just a basic set of encrypt decrypt binaries. Nothing special about that. I wouldn't have stripped it either. Where is the actual virus part that maliciously gets the binaries on there and executes it without the user executing it?
Reverse engineering the encrypt and decrypt binaries was just a waste of time and revealed nothing special.
Agreed. Didn't really understand the value here.
Thank your triple L
@4:20 ,while watching from phone, Thank You. :)
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.
Thank you triple L! Excited for more rev content! Also binary exploitation and other cyber subjects would be cool
Great content man, nice work!
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.
Thanks for the large fonts, I am now enjoying your videos from bed before going to sleep 👍
Thank you LLL, as a mobile consumer it’s appreciated
Alway wonder why does pc's allow them to do this like I get editing files for the program itself but there should be restrictions, like what normal dev would use kill[file] command
Good stuff. Still eagerly awaiting part 2 of the baby monitor pen testing too 😉
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.
Nice video bro keep them coming
More to come!
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.
Just out of curiosity: If this software is using an open source library to generate the encryption key, then wouldn't it be possible to look up the default seed factor like system time or temperature and then write a script to iterate through a probable range of seeds over a file of known contents to get the key yourself?
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.
Thank you LLL, at 4:20 :D
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.
So is there any way now that you have this info to generate a key to decrypt the file?
I don’t know much. But I think that he will still need the private key. Trying to generate a key will take too long and not worth the time. It’s just easier to pay for the key.
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.
Thank you LLL for the readable font size. I watch on monitor and mobile. Nice to have programming oriented channels that you can view on the bus 🙏
at 05:09 what did the editor do to simplify this line? Why was it *(char **) as arg to atoi ? Why not just int type?
I'm on the toilet with my phone on hand really appreciating the fontsize. Thank you Mr. Triple L
You could just get the encryption key, by looking at the changes made to the magic number of each file type
nope.
what was the something WEIRD? the debug symbols?
Thanks LLL, not mobile, but legally blind. I was able to read your 64 point font.
Since they built the encryption right, it doesn't matter that they didn't strip the binary … all that does is tell you that if you pay, they CAN actually decrypt your data. OTOH it also tells you that once they give you the key that decrypts you, it probably decrypts everyone hit by this malware.
That actually poses an interesting thought if I were a malware author myself-a ransom pool. By the time the ransomware is spreading, the servers that'll release the key have already been set up and will never be touched again. If the thing spreads fast and the ask is relatively conservative, a large entity hit hard might have just paid it by the time smaller fish get infected. The malware in that case may just suicide with a "you got lucky" message. Meanwhile before anyone's looking for the bastard who wrote it seriously, they've already cashed out and vanished.
IDK why anyone would do that, but it'd be damned hard to catch the people doing their "one-time" heist. Especially if they truly did just do it one-time.
Some virus in my windows system not letting my vm to run after I close it after first use while increasing my gpu temperature nearly to 70 degree celsius without any obvious reason. Last time I found a crypto mining virus. Is there any suggestion for me to solve the issue? Or should I fresh install Windows?
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!
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.
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.
Well they are certainly going with the No Security Through Obscurity Principle.
Nice analysis! Liked the large font too.
4:06 - what? no. You encrypt using the public key, needing the private from them.
- If you encrypted with private key, you could decrypt it with the public key :D (if it's possible at all)
EDIT: yeah, ok, sorry, you corrected yourself. It was just a slip of the tongue.
Is there any way to decrypt mssql .MDF file which infected by trigona ransomeware having ._locked extension
I don't have data on that particular malware.
Do you have a video where you explain how you learned all that stuff ???
Who in here also expected him to find a flaw in the code and managed to decrypt the files for free?
Thank you LLL, my eyes appreciate it.
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
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.
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.
Loved what I could watch of the video, but RUclips was running 30 seconds of ads for every 1:30 seconds of content. It just made the video unwatchable.
Thanks for the big font - nice video, strange that though debug symbols show the variables with strange names...
Were you able to extract the private key from the disassembly?
Yessss!! More security stuff! I'm trying to learn it, but it's tough, lots to learn!
With debug info not stripped, that's luxurious :D
Also, thanks youtube algorithm for recommending this!
Hay. Thank you for increasing the font size. I appreciate it.
~♡
Thanks for the large font indeed 🙏simplest is for you to lower screen definition, also font size 64 is quite large
So LL, my question is,..... why not set up a dummy file to invoke the " ## Stop VMX " , routine before it's going to do a root-scan of the OS. ???
Tell us all why this might not work if the " Dummy " was placed in say "/opt .... or say .... /usr/share/sbin " ..... or on M$ .... C:\Windows\system 32\ .......
Thanks
Stay Safe
My guess is the malware author intentionally left the debug symbols for analysis, so it would be obvious upon review that the victim was indeed screwed! Curious what an openssl dump of the public pem file would reveal??
> Curious what an openssl dump of the public pem file would reveal??
Not much, really.
Nice! I look forward to seeing more security related content on your channel! Thank you for supporting our community! 🧠🏴☠
The .pem file in the encrypt argument list gave everything away, even without the debug info.
where do you get copies of the malware?
I am looking for help with piiq ransomware decryption. I came across this video. Can you let me know if there is a way to decrypt pioq files...
Thanks
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.
How did you get the source file\code? How did you extract it?
Weird that what worked for Flipper on youtube buttons doesn't work for me because of some reversive facts