Getting started on your cyber security journey? Click the subscribe button, I have a lot of content already here to help you get started and more on the way! If you're looking for full courses, consider checking out my content on Pluralsight - www.pluralsight.com/authors/josh-stroschein
This is very much up my alley, this is a good video and I wanted to point out some little nuances that I've learned from using a very similar software, CFF Explorer: 10:47 you point out that these section names are "known sections that the operating system will understand," but be careful assuming things based on the section names. If you experiment and rename the sections of an ordinary executable, you'll often find that you can freely change the name to any string less than 8 characters (the size limit for section names.) Indeed, I've seen instances where a packer will rename the original .text section to .bss or .data, or to something else completely. The section's Characteristics field (not shown in this interface) is what actually determines how the section behaves, like if it's read only, executable, etc. In theory, according to the Microsoft docs, the names like .text or .data are reserved for sections with particular characteristics. In practice, Windows will run the executable even if these names are paired with non-matching characteristics. As such, although the names can be useful, you should not consider them the be-all end-all. Aside from changing where the raw data gets loaded virtually and changing the permissions on that section, the sections don't actually do much - I've seen instances where every executable section is combined into one. At the end of the day, the entrypoint is the only thing in the headers that definitively tells you "there is code at this address." _Typically_ in an ordinary, non-malware executable the first section will be .text. That's not necessarily a guarantee, but if the first section is not .text it should set off some alarm bells. 13:25 so, I'm not sure if this is how it works in Detect It Easy, but at least in IDA, you have to be careful with assuming stuff based on missing strings. Particularly, IDA by default will not scan the Resources for strings. So it's possible for a string to be loaded using an ID and the WinAPI Resource functions (like FindResource, LoadResource, etc.) It's also possible for data - strings, or packed data - to be after the executable sections entirely, in the EOF Extra Data, and read from the file on disk (because only the sections are loaded into memory.) This isn't as common but some legitimate programs do this, for example 7-Zip's self-extracting archives work by copying the zipped data onto the end of an executable file after the last section. If packed data is stored this way, it may not show up in the Entropy view shown later on, assuming it only shows sections (but I could be wrong on that assumption.) Finally, it's possible the individual string is just base64 encoded or something but not the whole program. 17:40 "oddly repeating patterns" aren't that unusual to see in the Resources section - it's probably the executable's icon. It isn't compressed, so if there is a solid colour background in the icon, it'll appear as a repeating pattern. 26:28 you don't really explain why an ordinary developer would want to use UPX, but typically, because it reduces the filesize of executables so they can download faster, as is the actual intended use. There are a handful of similar packers where they're publicly available programs anyone can freely use, with varying levels of complexity. For example, Engima Virtual Box is a more modern example, a packer that not only applies compression but also allows packing other files and DLL libraries the executable uses into the executable itself. 27:45 What's making it confusing here is that the entrypoint is being shown as a virtual address, but the memory map is only showing raw addresses. If the virtual addresses were shown it'd be easier to quickly identify that the entrypoint is indeed in the second section. In the first example shown in the video, the unpacking work is done in the first section of the executable, but this is atypical. UPX does it in the last section instead, and this is how most normal packers go about it. The advantage of having the entrypoint in the last section is that, when the earlier sections are unpacked in-place, the original executable will be lined-up with its original base address. Having the first section unpack means shifting every later section over, or compiling the original executable with a strange base address before packing it. Although it is not a guarantee that ordinary executables will always have an entrypoint in the first section, you should be at least a little suspicious if it isn't.
Thank you for the detailed feedback - it not only helps me but others that may be watching this video! In any topic there is usually a ton of side topics and other detours that I could go down, so I don't always do that for the sake of time. This can make some areas of the video feel a little incomplete, especially to those that already have a good understanding. Of course, there is ALWAYS something that I'm not as familiar with and maybe misunderstanding it or not giving it the best description possible :) I find that no matter what topic I post about, there is always more to learn and comments like this are a great example of that. One reason I personally like sharing videos/teaching/etc is that I always learn more from those around me. In any case, thanks again for taking the time to provide such detailed feedback, please keep it coming!
![Blox Fruits Dragon Rework Update [Full Stream]](http://i.ytimg.com/vi/EqDAp8udhm0/mqdefault.jpg)
![Felix "Unfair" | [Stray Kids : SKZ-PLAYER]](http://i.ytimg.com/vi/Oswujxm2Ag0/mqdefault.jpg)
Getting started on your cyber security journey? Click the subscribe button, I have a lot of content already here to help you get started and more on the way! If you're looking for full courses, consider checking out my content on Pluralsight - www.pluralsight.com/authors/josh-stroschein
I love the way you summarize everything I discovered by myself in 1 year in a 32 minutes video. Keep up your amazing work !
Thanks! Please keep in mind I've been doing this for several years now myself, so there is usually a lot of my experience baked into these videos :)
Thanks Josh. The depth of your content is second to none. Pls keep making such videos :)
More to come!
Thanks @Josh, Beautiful and in-depth explanation!!
Glad you liked it!
again really great videos! no words to describe your effort many thank you dr. Josh
Most welcome!
glad to see you still making content, hope all is well at new position
Thanks! So far so good, definitely staying busy and appreciating the change of pace :)
Awesome content as usual, thank you Josh!
My pleasure!
This is very much up my alley, this is a good video and I wanted to point out some little nuances that I've learned from using a very similar software, CFF Explorer:
10:47 you point out that these section names are "known sections that the operating system will understand," but be careful assuming things based on the section names. If you experiment and rename the sections of an ordinary executable, you'll often find that you can freely change the name to any string less than 8 characters (the size limit for section names.) Indeed, I've seen instances where a packer will rename the original .text section to .bss or .data, or to something else completely. The section's Characteristics field (not shown in this interface) is what actually determines how the section behaves, like if it's read only, executable, etc.
In theory, according to the Microsoft docs, the names like .text or .data are reserved for sections with particular characteristics. In practice, Windows will run the executable even if these names are paired with non-matching characteristics. As such, although the names can be useful, you should not consider them the be-all end-all. Aside from changing where the raw data gets loaded virtually and changing the permissions on that section, the sections don't actually do much - I've seen instances where every executable section is combined into one. At the end of the day, the entrypoint is the only thing in the headers that definitively tells you "there is code at this address." _Typically_ in an ordinary, non-malware executable the first section will be .text. That's not necessarily a guarantee, but if the first section is not .text it should set off some alarm bells.
13:25 so, I'm not sure if this is how it works in Detect It Easy, but at least in IDA, you have to be careful with assuming stuff based on missing strings. Particularly, IDA by default will not scan the Resources for strings. So it's possible for a string to be loaded using an ID and the WinAPI Resource functions (like FindResource, LoadResource, etc.) It's also possible for data - strings, or packed data - to be after the executable sections entirely, in the EOF Extra Data, and read from the file on disk (because only the sections are loaded into memory.) This isn't as common but some legitimate programs do this, for example 7-Zip's self-extracting archives work by copying the zipped data onto the end of an executable file after the last section. If packed data is stored this way, it may not show up in the Entropy view shown later on, assuming it only shows sections (but I could be wrong on that assumption.) Finally, it's possible the individual string is just base64 encoded or something but not the whole program.
17:40 "oddly repeating patterns" aren't that unusual to see in the Resources section - it's probably the executable's icon. It isn't compressed, so if there is a solid colour background in the icon, it'll appear as a repeating pattern.
26:28 you don't really explain why an ordinary developer would want to use UPX, but typically, because it reduces the filesize of executables so they can download faster, as is the actual intended use. There are a handful of similar packers where they're publicly available programs anyone can freely use, with varying levels of complexity. For example, Engima Virtual Box is a more modern example, a packer that not only applies compression but also allows packing other files and DLL libraries the executable uses into the executable itself.
27:45 What's making it confusing here is that the entrypoint is being shown as a virtual address, but the memory map is only showing raw addresses. If the virtual addresses were shown it'd be easier to quickly identify that the entrypoint is indeed in the second section.
In the first example shown in the video, the unpacking work is done in the first section of the executable, but this is atypical. UPX does it in the last section instead, and this is how most normal packers go about it. The advantage of having the entrypoint in the last section is that, when the earlier sections are unpacked in-place, the original executable will be lined-up with its original base address. Having the first section unpack means shifting every later section over, or compiling the original executable with a strange base address before packing it. Although it is not a guarantee that ordinary executables will always have an entrypoint in the first section, you should be at least a little suspicious if it isn't.
Thank you for the detailed feedback - it not only helps me but others that may be watching this video! In any topic there is usually a ton of side topics and other detours that I could go down, so I don't always do that for the sake of time. This can make some areas of the video feel a little incomplete, especially to those that already have a good understanding. Of course, there is ALWAYS something that I'm not as familiar with and maybe misunderstanding it or not giving it the best description possible :) I find that no matter what topic I post about, there is always more to learn and comments like this are a great example of that. One reason I personally like sharing videos/teaching/etc is that I always learn more from those around me. In any case, thanks again for taking the time to provide such detailed feedback, please keep it coming!
@@jstrosch Oh yeah, it wasn't meant as a criticism or anything, just wanted to give some further reading :)
Great videos! Many thanks
Glad you like them!
You say too many words but give too little necessary info.
It is one of my talents :)