Now I don't want you to think I'm picking on you, because I'd be picking on me if I was picking on you.
See, there are times where we have to refer to documentation and refresher courses because it's impossible to remember every single thing in IT, especially when it comes to pen testing.
As an example, earlier in this skill, we even had to pull up documentation about Ubuntu and the hash types allowed for password hashing.
Well, this is another one that I want you to take a look at if you get time is CompTIA A plus here on CBT Nuggets with James.
Because there's a couple of skills in there in particular that I'm going to be kind of brushing over here real quick that play into a lot of what we've been doing here.
And that is BIOS versus UEFI.
Now you may have heard of UEFI and you may have heard of BIOS.
I say that selectively because there's actually folks out there not old enough to remember BIOS.
It breaks my heart, makes me feel older.
And there's folks out there that up until recently didn't know about UEFI.
And that's OK, because we're always learning and we're learning together.
I want to give you the bullet points here real quick and basically explain that BIOS is that traditional startup method for checking the system when you first power up.
Now, I am nickel and diming this, and that's why I have the link for James's course below.
But basically what we're doing is we're powering up the system, doing our checks and booting into a predefined order set in the BIOS.
So that would be master boot record, which is something that was generated usually by the operating system whenever it was installed in a partition that was hidden from regular view, which is why you only saw C drive and Windows.
But you could do some digging and you could see the partition manager in there as well.
Now, UEFI is more of a secure boot method that ensures that whatever is booting is booting into the system like it's supposed to.
See, it goes into the actual BIOS or startup of the actual system now UEFI and identifies actual startup files to identify what our operating system down to the partition level that's supposed to be loaded.
James, don't beat me up on this. Like I said, I'm just nickel and diming.
That being said, I want to show you an example of what the two look like inside of my virtual lab environment.
Now I'm going to swap over to my screen here real quick.
And this is just inside of here locally.
So I'm in VMware and what I have here is I'm on my Windows 11 system and this is a UEFI boot up sequence.
So when you start the system up, you hit F2 on a physical system or F1 if it's another like Dell or something like that.
And this is what you would come up with the boot manager.
So as I zoom in for you real quick, you can see here that we have Windows boot manager in there as well.
That's because Windows, when installed, specifically went into the UEFI and stated that there is a Windows operating system on this system.
So you see all the other ones on there.
EFI, EFI, EFI.
I want to show you what BIOS looks like on my Windows XP system here is this is more of a legacy mode.
You can see here that it's just a basic setup utility to give you the information of our configuration of the actual system itself.
It doesn't really go into any kind of security settings.
Specifically, if I move over to actual security, you can see that it's only for like a BIOS password.
But if I go into boot order, you see here that I have CD-ROM selected first removal drives, hard drives and etc.
So all I'm doing is just basically moving around like we did inside of our Hyper-V manager.
Yet inside of here, there's no EFI file or setting configuration that I have to specifically point to.
Why am I telling you all this?
Well, that's because you need to know what it is that you're booting with either on a physical system or inside of that virtual environment.
When you have a hard drive from a different location.
Let's say you went and recovered a physical hard drive and you brought it back to your lab to clone it.
You clone it, you do the forensics copy of it, you hash it, you verify it, you take the original back.
Well, now you have the copy of the original hard drive and you need to know how it boots up.
Thankfully, in a lab environment that includes virtualization, you can set whether you want it to be on a BIOS or a UEFI startup.
And you can change that as much as you need inside of that virtual setup.
On a physical system, it's a little bit harder to do.
So you would need actual physical systems, one with a BIOS board and one with a UEFI board on it.
And that can get kind of expensive.
Whereas in our virtual environment, you just need a hard drive sled that plugs into the actual system.
So if you have a copy of a hard drive that is Windows 11 and UEFI,
you would just need to go and make sure that your settings were compatible and configured for that specific boot up.
HiREN is the exact same way.
There are different versions of it out there.
And you may have noticed inside of the actual folder where I have HiRENs at, C-Drive HiRENs on the actual Adept Lab,
that there are two versions.
The 101, not only does it support systems that's less than four gigs, it also supports BIOS.
Whereas the one that we've been using is a UEFI.
And there are previous versions of it as well.
And you can go through and make sure that you're using the correct one for the correct hard drive that you have.
Kali is the exact same way.
Sometimes you may need to go and download previous versions of the live OS or even HiRENs
to make sure that you have the right one for the physical setup or physical setup in your virtual lab
to support whatever it is that you acquired from the organization we've been testing against.