36 replies to this topic

[zammibro]

Hi evevryone,

 

Kali Linux pen testing is a popular topic on the web, but how would you do it from an old Windows PC with way too limited hardware to run VB or VMWare Kali image inside running Win 10? The obvious answer is - run Kali from VHD(x). But... there is a catch - no boot method is obvious enough to gather attention of the zillion testers pool.

 

I'm not a boot expert by any means, but carry some hope to find the one here, who would suggest How to Boot Kali Linux 64-bit from VHD(x) on Win 10 64-bit PC? I've already used Grub4Dos for the last 10 years mostly for service tasks. That experience yet missing major peaces required to create a working Grub4DOS menu listing for Kali, or whatever the bootloader is. Anyone to help? 

[Wonko the Sane]

Well, forget about VHDX.

 

Now, if you call a (static, not dynamic/extendable) VHD "a Raw image with an added sector that can be ignored appended" (which is what it actually is) your question becomes "How can I boot Kali Linux from a RAW (dd-like) image?".

 

And the answer is "You need to use losetup/kloop." (and grub4dos)

 

http://reboot.pro/to...rom-vhd-how-to/

 

(and also dynamic vhd's are seemingly possible via vdfuse and GRUB2, though they are trickyer)

 

Of course, given the "various versions" of Linux, you may need to experiment to adapt to Kali Linux.

 

Wonko

[zammibro]

Unfortunately, the above link goes to a lengthy thread with multi-arguments and very little yet complex to understand code.

 

May be I'd have a better luck asking for a Grub4DOS menu entry booting Kali Linux install from a local 2nd HDD, with Win 10 on 1st HDD being default to boot by standard Windows means?

Edited by zammibro, 14 August 2020 - 11:19 AM.

[Wonko the Sane]

Unfortunately, the above link goes to a lengthy thread with multi-arguments and very little yet complex to understand code.

May be I'd have a better luck asking for a Grub4DOS menu entry booting Kali Linux install from a local 2nd HDD, with Win 10 on 1st HDD being default to boot by standard Windows means?

Only for the record, your "unfortunately" is "intentionally" here.

You were asking for a complex, advanced, experimental *something*, did you expect a "sure, here it is." kind of reply?

A "normal" Kali Linux install can instead be booted with a "normal" Linux grub4dos menu entry, here it is:
title Kali Linux on second disk (MBR)
#this simply chainloads the MBR of second disk
rootnoverify (hd1)
chainloader (hd1)+1

title Kali Linux on first partition of second disk
#this simply chainloads the PBR of first partition on second disk
root (hd1,0)
chainloader (hd1,0)+1

This (adapted from http://rmprepusb.blo...le-linux.html):
is the "normal" way to boot *almost any* Linux

title Kali 4.9.0 (fully installed OS)\n Boot to Kali linux
root (hd1,0)
# get UUID of drive
uuid () > nul
set UUID=%?%
kernel /boot/vmlinuz-4.9.0-kali4-amd64 root=UUID=%UUID% ro initrd=/install/gtk/initrd.gz quiet
initrd /boot/initrd.img-4.9.0-kali4-amd64

the contents of the kernel and initrd lines need to be adapted for the specific version you are using.

If you post the contents of your grub.cfg or syslinux.cfg (if I remember correctly Kali Linux uses syslinux) it will be easy to give you the right settings.


Wonko

[zammibro]

That's exactly kind of no-nonsense reply I was looking for from an expert. I'll try that and also look for specifics you asked for if no success. Something tells me headache might be ahead. Now, from that great example, can we go back to original "VHD" topic again, and try to get similar coherent answer processed by an expert? I got lost in that thread rhetoric with very little "understandable code" substance, and likely most other down to Earth folks like me need a short primitive skinny example with clarifying notes to leave with, just like you posted above. Wow... P.S. I see you like to engage, which is great, but... someone with clear mind sometimes need to process all earlier engagement mess into a refined sugar for the masses to make this website work as intended.

[Wonko the Sane]

The problems with Linux VHD booting are:
1. there are no "experts" in the matter because:
1a. the "linux" experts either do not consider grub4dos a valid bootmanager, as they are all in love with GRUB2, or do not consider booting a Linux from a file something worth it, or they consider it "basic" and thus not worth a few friggin' lines in a doc wiki, let alone as an option for installing it
1b. the grub4dos experts tend to be not much Linux experts

1c. if either of the two know enough of the matter and have a "ready" solution they are unlikely to post it here, let alone explain in detail how it works

2. the fragmentation on the Linux side is so huge that what is reported as working on distro X, version Y, while it may apply, it will likely need specific tweaks, cheat codes, changes and what not on distro W version Z

 

Due to the above, the most we can offer is a pointer to "known state of the art" and the assistance of good willing but limited Jacks of all trades (and master of none[1]) like yours truly.

 

If you have available a partition table slot that you can use the problem becomes a non-problem, as you can use the partnew method[2] in grub4dos to write an entry in it, but if you actually want a "fully portable"[3] .vhd booting method you have no other resource than the mentioned thread.

 

The key points are:
1) there is no it is unusual that Linux that can be booted "as is" from VHD/RAW image, exception made for a few, namely Porteus is known to have this possibility
2) some modifications need to be made to the actual Linux system, usually in the initrd (initial ramdisk) before it can happen
3) for these modifications we have a "general idea" (kpartrx/losetup) but different distro's might need different modifications
4) the grub4dos entries needed to boot the correctly modified Linux systems are all in all clear enough, but they include/need also some Linux kernel parameters/cheat codes (that again may well change from one distro to the other 

5) there is also a documented approach making use of vfduse and GRUB2, that a well needs modifications to the Linux system to work

 

In a nutshell, (and it is also provided on the given link) the only point in which we can surely help is #4, for #3 and #5 there are simply no simple, straightforward answers, you need to make tests (after having read about the basics) and see what happens, it will be a "discovery process" for which - at the most - we can try and point you in the right direction.

 

Wonko 

 

 

 

 

[1] actually of a very few, but that not include Linux VHD booting, unfortunately

[2] if you are interested in the matter, just ask

[3] the partnew method is portable but still it requires a free usable partition table entry and a non-fragmented vhd file

Edited by Wonko the Sane, 15 August 2020 - 02:13 PM.

[zammibro]

[q]4) the grub4dos entries needed to boot the correctly modified Linux systems are all in all clear enough[/q]

 

Thanks for the critic [1]. As to 4), why in this scenario original Linux needs modification, and what its essence is?

[Wonko the Sane]

Basically when an OS is booted, there are two main parts, in Windows NT:
1) an initial part, often referred to as "real mode" where the OS loader uses info from the BIOS
2) a second part when the OS loader switches to protected mode and the hardware is re-enumerated/inspected and the drivers and the HAL (Hardware Abstraction Layer) kicks in, then GUI OS is loaded and everything that needs to be started automatically (services) is loaded/started

 

In Linux it is slighly different but not that much:
1) the kernel and initrd are loaded, still with info from the BIOS, usually with parameters and/or "cheatcodes" that can modify the behaviour of the booted OS
2) devices (hardware) are re-enumerated/inspected, drivers are loaded, whatever needs to start early is started, then the OS "switches" from the initrd to the "real" storage

 

Now what we do in grub4dos (more or less) is to add information to the BIOS about the RAW image (or VHD), this information is "good enough" for all the first part, but the sheer moment the second part starts it vanishes unless in the second part is added *something*, very early starting, that "hooks" this info and keeps it.

 

In Windows NT this *something* is usually a (virtual) disk driver, such as Firadisk, WinvBlock, nowadays more used is SVBUS.

 

In Linux it is a mechanism that allows a loop device (as in the case of losetup) or a driver (similar to the Windows way) in the case of vdfuse. 

 

Please note how the same info is given on the thread I pointed you to earlier:

http://reboot.pro/to...rom-vhd-how-to/

 

Namely here:

http://reboot.pro/to...ow-to/?p=199727

 

Really, you should read it, even if you skip the technicalities you will get the general idea so that if you have doubts/questions, they will be more targeted and I won't need to repeat the same things to answer you.

 

BTW, re-checking it, I have to correct my previous post, Porteus is one Linux distro that has this feature built-in. 

 

Wonko 

[zammibro]

Let me do recommended reading and some tests. I'm surprised how interest to boot and multiboot in particular seemingly dropped among users over the last few years based on forum posts count despite a PC still remains the only convenient way to thorough internet research.

[wimb]

I can boot from USB straight with kali-linux-2020.2-live-amd64.iso located in folder images on USB Portable SSD

Booting in MBR BIOS mode from grub4dos menu and in UEFI Secure mode from Grub2 menu.

 

grub4dos entry created in menu_Linux.lst

iftitle [if exist %iso_drive%/images/kali-linux-2020.2-live-amd64.iso] KALI Linux - %iso_drive%/images/kali-linux-2020.2-live-amd64.iso
set iso_path=/images/kali-linux-2020.2-live-amd64.iso
map %iso_drive%%iso_path% (0xff)
map --hook
root (0xff)
kernel /live/vmlinuz findiso=%iso_path% boot=live components splash username=kali hostname=kali
initrd /live/initrd.img

=

Grub2  entry created in \EFI\grub\grub_Linux.cfg

if [ -e "$iso_drive/images/kali-linux-2020.2-live-amd64.iso" ]; then
menuentry "KALI Linux - images/kali-linux-2020.2-live-amd64 $iso_drive" {
  set iso_path=/images/kali-linux-2020.2-live-amd64.iso
  loopback loop $iso_drive$iso_path
  linux (loop)/live/vmlinuz findiso=$iso_path boot=live components splash username=kali hostname=kali
  initrd (loop)/live/initrd.img
}
fi

=

Also a1ive Grub2 File Manager can be used from grub4dos menu or from Grub2 menu as first boot option:

In case of UEFI Secure mode the a1ive Grub2 File Manager Debian normal boot option is working OK

In case of MBR BIOS    mode the a1ive Grub2 File Manager partnew option is working OK, but Debian normal boot fails.

 

[zammibro]

@wimb

"I can boot from USB straight with kali-linux-2020.2-live-amd64.iso"

 

Thanks for the hints. Do you think that booting an installed Kali distro from that ISO into an HDD partition would work OK using the same Grub4DOS & Grub 2 menu items? That would be a more viable alternative to booting an ISO from usage standpoint.

 

Going forward, what would it take to move from booting Kali ISO or installed on HDD distro to booting a Kali distro installed from that ISO into a VHD? It appears from our earlier talk the task is way too unknown and/or complex which I doubt a bit given any popular VM can boot Kali install from a VHD.

[Wonko the Sane]

Wimb, tu quoque.

 

The OP asked about booting an installed Kali Linux from VHD or RAW image.

 

You can (like all the rest of the world BTW) boot a Live Kali Linux from .iso image.

 

What will be next post? 

 

Someone that can (again like all the rest of the world BTW) boot Kali Linux in Virtualbox?

 

 

Thanks for the hints. Do you think that booting an installed Kali distro from that ISO into an HDD partition would work OK using the same Grub4DOS & Grub 2 menu items? That would be a more viable alternative to booting an ISO from usage standpoint.

No, it is a COMPLETELY DIFFERENT matter.

 

 

Wonko

[zammibro]

@Wonko, Formally you right, but how would one install Kali distro from ISO into an HDD? I just tried by using YUMI-UEFI (https://www.pendrive...ot-usb-creator/), and it failed to boot the Kali ISO from a USB thumb miserably, so wimb's info is indeed relevant and useful. As well from learning standpoint - to compare menu sections required to boot Kali ISO vs HDD install. Now I wonder if the menu would differ when booting such ISO from an HDD vs USB Thumb, and why?

[Wonko the Sane]

Well, that menu entry is "wrong" (but only because it is over-complicated, as it is a conditional menu entry, and part of a more complex multiboot thingie), as it assumes that a variable, .%isodrive% is already declared.

 

The "simple", "normal" one is as follows:

 

title kali-linux-2020.2-live-amd64.iso
find --set-root /images/kali-linux-2020.2-live-amd64.iso
map /images/kali-linux-2020.2-live-amd64.iso (0xff)
map --hook
root (0xff)
kernel /live/vmlinuz findiso=/images/kali-linux-2020.2-live-amd64.iso boot=live components splash username=kali hostname=kali
initrd /live/initrd.img

It will work on *any*  mass storage device (as long as the file /images/kali-linux-2020.2-live-amd64.iso exists).

 

In detail. title <text> is just what you will see in the interface.

 

find --set-root looks for the.iso file and establishes root to it, so that the folowing command can use a relative path:

 

map /images/kali-linux-2020.2-live-amd64.iso (0xff) this maps the .iso to a (virtual) CD/DVD like device.

 

map --hook hooks or "fixes" the mapping.

 

root (0xff) establishes root to the just mapped device, allowing to use in the following commands relative paths.

 

Now the interesting part:

kernel /live/vmlinuz findiso=/images/kali-linux-2020.2-live-amd64.iso boot=live components splash username=kali hostname=kali

 

the bolded is a "cheat code" or parameter passed to the linux:

the findiso looks for the actual "container" so that the Linux can mount it

 

You would need a parameter *like*:

findvhd=/images/kali-linux-2020.2-live-amd64.vhd

AND 

*something* added to the Kali Linux that actually understands it and proceed to properly mount the hd-like image.

 

This last *something* is what is missing (and the object of the referenced thread) 

 

Wonko

[zammibro]

@Wonko,

 

Going back to basics... After various attempts and considerations, I eventually installed Kali by its installer to 1st partition on a multipartition USB Thumb formatted as HDD, with 2nd partition being SWAB, and 3rd Data (NTFS). That serves as a VHD substitute for now. But there's a catch as well...

 

Grub2 was installed by Kali Installer also to that USB 1st partition, i.e. (hd1,4) as transpired. However, there seems nothing installed to the USB Thumb bootsector, and the boot from USB fails at BIOS. I tried to chainload Grub 2 on the USB from Grub4DOS on (hd0) with Windows installed, but couldn't find a working menu example. The menu adapted from your earlier post ref. Steve's doesn't work from G4D stating "Invalid boot command", while the USB root doesn't have "install" folder for initrd. I'd like very much to pass this boot dilemma, as Kali pen tasks can't wait. But how?

[zammibro]

https://i.postimg.cc...zyzWf/Kali1.jpg

 

https://i.postimg.cc...WdGRq/Kali2.jpg

 

https://i.postimg.cc...cq6xr/Kali3.jpg

[zammibro]

Why this 1st ext4 partition on the 3rd USB drive is called (hd1,4) by G4D? Which is also outdated, supplied with last version of EasyBCD . It seems to have a hard time recognizing EXT4 calling the partition EXT2.

[Wonko the Sane]

Ok, first thing you don't (shouldn't) use a pre-made menu.lst entry when experimenting, but rather use command line as in this way you have direct feedback from commands.

 

Disk numbers (hd0), (hd1), etc. are assigned by BIOS, so if grub4dos sees it as (hd1) it means that it is (as seen by BIOS) second disk.

 

The volume being ",4" means that it is the first logical volume in the Extended partition, I presume this is pretty much normal for a Linux install.

 

The fact that you see it as "first" partition doesn't mean that it is the first partition.

 

The first primary partition (actually the primary partition in first MBR partition table slot) is (hdn,0)

The second primary partition (actually the primary partition in second MBR partition table slot) is (hdn,1)
The third primary partition (actually the primary partition in third MBR partition table slot) is (hdn,2)

The fourth primary partition (actually the primary partition in fourth MBR partition table slot) is (hdn,3)

 

The first logical volume inside Extended (no matter in which MBR partition table slot is the Extended partition) is (hdn,4)

The second logical volume inside Extended (no matter in which MBR partition table slot is the Extended partition) is (hdn,5)

etc.

 

You will need to learn some grub4dos basics, the guide is a bit outdated, but the fundamentals remain the same:

https://web.archive....os/Grub4dos.htm

namely:
https://web.archive....iles/syntax.htm

 

It is advised to download either the .chm or the .htm version:

https://web.archive....rub4dos_chm.zip

https://web.archive....rub4dos_htm.zip

 

 

GRUB2 way of booting uses NOT the bootsector at all, part of the GRUB2 code is written to the MBR (+a number of following sectors) and it chainloads directly the GRUB2.

 

So, back to work. 

 

1) check the contents of \boot\grub\grub.cfg

2) there must be an entry *like*: 

linux <something containing "vmlinuz"> <parameters>

3) immediately followed by an entry *like*:

initrd <something containing "initrd">

 

Likely

the <something containing "vmlinuz"> is /boot/vmlinuz-5.5.0-kali2-amd64 or /vmlinuz

and

the <something containing "initrd"> is /boot/initrd.img-5.5.0-kali2-amd64 or /initrd.img

 

The

/vmlinuz should be a symlink to /boot/vmlinuz-5.5.0-kali2-amd64

and

/initrd.img shuld be a symlink to /boot/initrd.img-5.5.0-kali2-amd64

 

What is really-really needed is the <parameters>, an installed Kali Linux most probably will need a "root" parameter and a pointer to /install/initrd.gz (or maybe not), *like*:

 

https://forums.kali....t-amp-Text-Mode

 

echo 'Loading Linux 4.0.0-kali1-amd64 ...'
linux /boot/vmlinuz-4.0.0-kali1-amd64 root=UUID=5b71b454-853f-4724-a995-599c871cd5af ro single initrd=/install/initrd.gz
echo 'Loading initial ramdisk ...'
initrd /boot/initrd.img-4.0.0-kali1-amd64

 

 

Then you get to grub4dos, press "c" to get to the command prompt and try typing the commands:

set mykernel=/boot/vmlinuz-5.5.0-kali2-amd64

set myinitrd=/boot/initrd.img-5.5.0-kali2-amd64

find --set-root %mykernel%

uuid ()

set myUUID=%?%

kernel %mykernel% root=UUID=%myUUID% ro initrd=/install/initrd.gz quiet
initrd %myinitrd%

boot

 

The red bolded part are the parameters that you MUST get from the grub.cfg, maybe they are correct maybe they are different, no way for me to know.

 

Wonko

[zammibro]

@Wonko

 

No "install" dir as per my pics linked above. I'll try that now, but... it doesn't answer a simple Q why trying to boot the USB directly from BIOS produces rotating slash only, with no attempt to show Grub2 menu? And how to fix that?

Edited by zammibro, 17 August 2020 - 12:53 PM.

[Wonko the Sane]

it doesn't answer a simple Q why trying to boot the USB directly from BIOS produces rotating slash only, with no attempt to show Grub2 menu?

Who knows?

*something* has gone wrong in the install, and this may depend on the exact way you tried to install it, on the specific USB stick, on your BIOS and on a zillion other possible reasons.

 

About the \install directory missing, it is entirely possible that what was valid/accurate even only one version ago of Kali Linux is not anymore, that is one of the issues with many Linux distro's, they are everchanging/everevolving ...

 

Wonko

[zammibro]

@Wonko
I tried that only available as per grub.cfg recipe producing no fruit thus far:
linux /boot/vmlinuz-5.5.0-kali2-amd64 root=UUID=b0d540ac-4343-446d-b7f3-80faa4656237 ro quiet splash
initrd /boot/initrd.img-5.5.0-kali2-amd64

title Kali Linux USB
root (hd1,4)
# get UUID of drive
uuid () > nul
set UUID=%?%
kernel /boot/vmlinuz-5.5.0-kali2-amd64 root=UUID=%UUID% ro quiet splash
initrd /boot/initrd.img-5.5.0-kali2-amd64

Resulting in: "Invalid or unsupported executable format" from G4D. I wonder if scrapping EasyBCD and installing the latest G4D would change that reply? Can I run both together on the same drive (hd0) without disturbing Windows boot as default?

 

"Who knows"

Can I fix the "unknown" or missing MBR record?

Edited by zammibro, 17 August 2020 - 01:31 PM.

[wimb]

How to Make Computer booting with Linux and Windows

 

is described here and combines Win10 + Linux booting from internal Harddisk

is probably a  method that is more according to your original post and  that can be adjusted for KALI

 

  See pages 17 and 18

[zammibro]

@Wonko

 

Rufus mentioned some new type of combo boot implemented in the Kali Install ISO, when transfering it to a USB Flash. I wonder if same approach is implemented in the Kali installed distro boot? May be its a new vmlinuz type?

 

@Wimb

I try to leave simple life one day at a time. Today is Kali Linux installed distro boot day from a USB Flash. Can you read the above and contribute to the very task?

Edited by zammibro, 17 August 2020 - 02:00 PM.

[Wonko the Sane]

@Wonko
I tried that only available as per grub.cfg recipe producing no fruit thus far:
linux /boot/vmlinuz-5.5.0-kali2-amd64 root=UUID=b0d540ac-4343-446d-b7f3-80faa4656237 ro quiet splash
initrd /boot/initrd.img-5.5.0-kali2-amd64

title Kali Linux USB
root (hd1,4)
# get UUID of drive
uuid () > nul
set UUID=%?%
kernel /boot/vmlinuz-5.5.0-kali2-amd64 root=UUID=%UUID% ro quiet splash
initrd /boot/initrd.img-5.5.0-kali2-amd64

Resulting in: "Invalid or unsupported executable format" from G4D. I wonder if scrapping EasyBCD and installing the latest G4D would change that reply? Can I run both together on the same drive (hd0) without disturbing Windows boot as default?

 

"Who knows"

Can I fix the "unknown" or missing MBR record?

EasyBCD grub4dos is an old version, it shouldn't be too much old, but since it is a "spin-off" it may well have issues, last time I checked it it was only a renamed file, but you never know..

 

Yes, the idea is to always use either latest-latest version of grub4dos or a specific known-to-be-working suggested one, right now I would use this one:
http://grub4dos.chen....6a-2020-02-29/

 

Add an entry for grldr.mbr with BootIce to your \boot\BCD, it will be a separate entry, (you need grldr.mbr and grldr on root of the volume).

 

AGAIN, if you run a menu.lst entry, you will NEVER know what is the problem, do use command line, by issuing a command after another you will have feedback (or errors) and know which specific command created it.

New set of commands to try:

set mykernel=/boot/vmlinuz-5.5.0-kali2-amd64
set myinitrd=/boot/initrd.img-5.5.0-kali2-amd64
find --set-root %mykernel%
root
uuid ()
set myUUID=%?%
set my
kernel %mykernel% root=UUID=%myUUID% ro quiet splash
initrd %myinitrd%
boot

run these and report what happens with these (and not with anything else).

.

 

No idea of what Rufus (more likely Akeo) said about Kali Linux.

 

Wonko 

[zammibro]

No, EasyBCD's NeoGrub is not just a renamed grldr, it has some edits to refer back to NST Menu folder, NeoGrub.mbr etc.

 

I did these G4D commands verbatim earlier with the same error after calling kernel from Cmd.

 

Will see how chenall is doing now... Btw, EXT4 partition didn't have Boot flag, I added it in Gparted, and tried to boot again the USB from BIOS. This time the error was "Operation system not found", meaning still no joy with locating Grub 2.

 

And finally with special tribute to Wonko and tireless G4D new dev chenall, Kali Linux booted straight from install on a USB partition. What a difference G4D v1.4.6a can make compare to v1.4.5a ! Default logins are kali & kali.

 

Now can we think how to access that Kali Grub2 menu from G4D instead of booting Kali straight?

Edited by zammibro, 17 August 2020 - 04:39 PM.