Official MediCat USB - A Multiboot Linux USB for PC Repair

[Jayro]

This was not my question. I know of plenty of software that can flash disk images, but your image is incompatible with all of them. I suspected this was because of the .bin format, but as KaMyKaSii found out, it's because of ImageUSB (which seems to be designed to render the images it produces incompatible with other softwares).
Anyway, I managed to flash the image under Linux thanks to KaMyKaSii. From the testing I've done, the quickest way to get a working image is by running this command (compatible with all Linux distros, as dd is preinstalled everywhere afaik):

sudo dd status=progress ibs=512 skip=1 obs=4096 if=/path/to/medicat.20.06.bin of=/dev/sdX

Maybe you could add it to the original post for Linux and Mac users to have a way to burn Medicat. =)

So would I use KaMyKaSii's method to backup the drive to an image, and this dd command to flash it back?

--------------------- MERGED ---------------------------

Hi Jayro, really appreciate the work. I got a hold of your distros a couple months back in Jan. At that time it was 19.10 at that latest. Just saw the transition to the Linux and that the whole distro is only available as one, even the mini winpe which I think quite a few others perhaps might also think needs to be separated or needs a separate version of itself. As much as I do like a linux version of medicat, it's not the first thing that I work with, being comfortable with windows not to mention that I could also help others fix some issue with the winpe version over teamviewer or some other means of communications (this is also due to the interface more or less, not everyone is as tech savvy as you, generally speaking. And since others are more familiar with windows it helps them understand medicat more easily in the winpe edition. And I know for sure if I used this current huge ass full linux distro, their minds will be blown out). Although it's not much of an issue, I have lots of space and bandwidth and pretty sure I can find a way to extract it without using imgusb (don't have a current usb with that much space, so haha)

That's not why I came here for though. Last time when I used winpe v.19.10 my network drivers were having a slight malfunction. On some deep digging found out that it was the default MS drivers that were either corrupt or just malfunctioning, and I had to do some more digging extract the esd, search the drivers, remove the faulty drivers and repack it up. I don't exactly remember now, but I think it had 2 different drivers for internet. I think one was for win7 and another for win8/10 and for some reason the session was loading the older drivers and which is what was making it not work. Not just that, even if I installed the correct drivers over it my network card wouldn't work, side effects from the faulty drivers. (I am not sure which was corrupt but I do remember I found 2 drivers for the network)

I'll see if it's the same with the current winpe and might have to fix it again, if so I'll point out the exact drivers which are giving the issue. At least in my case.

Also, a slight suggestion. As much as I like the idea of winpe, it would be a little more productive if there was ever a way to keep a session alive even after reboot. Once you reboot the session is gone, so you can't use drivers which need a restart (I could not also check if the side effects of that faulty drivers would go once restarted, and because I couldn't restart I only had a way to either update on the faulty ones or remove and then reinstall, which during both times tells me to reboot)

I know it's a longshot way and not sure if it's even possible, might have to look around and see on theoven site.

EDIT: What I meant with the keeping sessions alive after a reboot, was like how a live windows on usb works. And I know it's hard to have it live without having to install it normally or make a vhd. But it would be convenient if you could switch back and forth through it, from a live to a portable edition and vice versa. Or perhaps there might be a way to save it as some sort of a session in some temp folder on the usb, again if that's something that seems possible.

If you can positively identify the problematic driver's, I'll remove them going forward.

 

[SR-G]

Hello,
I fear i'm stuck with recent version of medicat.
I had a "medicat.16.10.stable.iso" (amonst other thing) written down on a IODD 2541 external case

With current 20.06, i've download all the 4GB files, extracted them to a .bin (imageUsb, per the header), but then i'm 100% stuck - how to extract / retrieve the .ISO that are embedded in that .bin ? I'm running full-Linux and i have no idea how to do that (iat - allowing to convert regular .bin to .iso) is not working at all).

Is this .bin some kind of a very proprietary format ?
Otherwise, which tools can allow to open them under linux (neither unrar nor unzip are working) ?

 

[KaMyKaSii]

So would I use KaMyKaSii's method to backup the drive to an image, and this dd command to flash it back?

If you remove the header from the image using skip=1 when creating the new image, then the skip=1 parameter will not be necessary when installing the image back to a device.
Edit: I just realized that if you use the USB stick as an input to the dd command, then there will be no header to jump and the skip=1 parameter becomes unnecessary. While writing this it was in my head that you would use the current Medicat image as an input, but I remembered that you considered making a new image with NTFS on the primary partition and reduced to the minimum possible size. But my comment below remains valid

I don't know if without the header ImageUSB will continue to accept the image as valid (it would be selfish if it did not), but the other alternatives I have already mentioned can be used. If you remove the header, any program that writes images for devices can be used (with its simple GUIs and all its glory), and in the case of dd the ibs and obs parameters can be merged into the bs parameter, so "sudo dd if=/path/to/medicat.20.06.bin of=/dev/sXX bs=4096 status=progress".

Hello,
I fear i'm stuck with recent version of medicat.
I had a "medicat.16.10.stable.iso" (amonst other thing) written down on a IODD 2541 external case

With current 20.06, i've download all the 4GB files, extracted them to a .bin (imageUsb, per the header), but then i'm 100% stuck - how to extract / retrieve the .ISO that are embedded in that .bin ? I'm running full-Linux and i have no idea how to do that (iat - allowing to convert regular .bin to .iso) is not working at all).

Is this .bin some kind of a very proprietary format ?
Otherwise, which tools can allow to open them under linux (neither unrar nor unzip are working) ?

As previously mentioned in the topic, the bin file is a sector-by-sector backup of a USB stick with the new Medicat installed (this includes the entire partition layout, its contents and the bootloader), the only hindrance to mount the image normally is that the ImageUSB program used to generate the imagefile added its own header at the beginning of the image which is ignored by ImageUSB itself when writing the image to a device but not by other conventional programs, which end up recording the header on the device and then the operating system does not recognize the contents of the USB stick because it expects the first 512 bytes of the disk to contain the MBR (the partition table) and not something else. To have a Medicat mountable image, you can use the command "sudo dd if=medicat.20.06.bin of=medicat.20.06-withoutheader.img ibs=512 skip=1 obs=4096 status=progress", and then use your distro's default program to mount the image (on Linux Mint Cinnamon is Disk Image Mounter). As already said, Medicat is no longer a single ISO that you install on the USB stick using another program to install the ISO content + a bootloader, Medicat now has a separate ISO (or wim file) for each application and comes with its pre-installed bootloader (Ventoy)

 

[Ruxos]

If you can positively identify the problematic driver's, I'll remove them going forward.

Yes, I'll notify you about it. Right now the current winpe has it too. Also, not sure if you've ever come across this project, aioboot by nguyentumine (project is open sourced on github), it is quite a cool product. I heard that there are ways to make it work from within linux, not sure how but probably with wine. It's not the same as vintoy but more advanced than it. The project might be abandoned at this point though but the last version he posted is seriously off the charts already, yeah it could take some more polishing fixing some minor stuff here and there, a new gui maybe and adding more improvements but even at this point you could do a lot more than ventoy and is a lot user friendly.

It supports booting from a multitude of options, from iso to wim to vhd and whatnot. When I saw ventoy in your work I was excited to see another software like yumi/aioboot but yumi has always been finicky for me. You should give that option a try. With that it might even be possible that you won't have to share a huge ass file to everyone and instead just create iso/wim files (which is what you're currently using) and just integrate them with aioboot. (You only have to give instructions within on how to do that, if you're lukcy enough it might support all of the products you have in medicat)

I love how many tools it has now, and for a full-time forensics guy/girl or someone working in the IT somewhere, all of those tools or the majority of those could come in handy. But they aren't for everyone. Pretty sure most were fine with the windows version of it, linux was a nice addition but everyone might prefer a separate download for each extra addon for what they might need. I saw some of the posts on how to reduce the size of the image(bin) file, but really don't think everyone needs all of those tools. I myself just ripped the content out and keeping the stuff I need and removing everything up, created a traditional bootable winpe iso like before, kept the linux one which booted really well with aioboot. If you see that it might work for you a little better, you could give it a shot and get all of the isos/wims compatible with it and host them separately.

(Although that's only one or two gimmicks with the software. One of which it needs all the files on both partitons if you want a uefi/legacy support. Which sometimes work and sometimes don't as it doesn't have full uefi drivers. For that I used the UEFI:NTFS project, which one can easily use in conjunction with rufus. My process is to create a UEFI:NTFS bootable usb from rufus and then use aioboot extractor to extract the files in the ntfs portion of it. Works really well.)

EDIT: Also, your malwarebytes google drive link is for the outdated version.

 

[Chansm]

Ho shit, i have the same issue with the same usb key....

I think 64G USB drive (depending on brand) may not be enough as the image itself is already close to 61G.
(That's excluding the EFI partition)

 

[Jayro]

Also, your malwarebytes google drive link is for the outdated version.

Thank you, I'll fix that link when I get home tonight in a few hours. What I've been doing is downloading the driverpacks, deleting ALL the drivers inside that aren't Win10x64, then I use RED2.exe to remove all the empty folders, and repack the driverpacks. Then I added my minimalized LAN and WLAN driverpacks into boot.wim, but I had no idea some drivers were causing people problems.

And thank you all for the helpful suggestions, but most of all, for helping one another. I can't always be here to help since I work full-time. So thanks again!

 

[aelfwine88]

So would I use KaMyKaSii's method to backup the drive to an image, and this dd command to flash it back?

I think you should ditch the image method and distribute the content of the 2 partition as 2 compressed archives.
Having an automated script for partition creation can be a solution but I already see the posts like:
"I ran your tool and now all my personal data is missing"

So I think you should just go with a simple guide like:
1. Create 2 partitions on your USB drive (at least 32GB exFAT then a 32MB FAT16)
2. Download and install Ventoy onto the USB drive
3. Extract the 2 compressed archive to the 2 partitions you just created

Frankly, who is unable to understand/follow this 3 simple steps shouldn't be even playing around with a multiUSB like this.
You would save everyone a lot of space (bandwidth and disk) and time (extracting multiple times, resizing and possible error tracking) including yourself.

 

[EgyptianRaptor]

My Method for Burning 20.06 on my 128 GBs Flash Drive.



First I got my Flash Drive and Removed all partitions then created at the end an Empty 32 MBs Exactly partition.

I mounted the bin Image using OSFMount then cloned the EUFI partition from the image to the 32 MBs partition on my Flash.

I Cloned the Main partition from the image to my first Flash partition and after the cloning using DiskGenius I have resized it to occupy the full size of my partition and was able then to fill the extra space with my 80 GBs if Portable Apps and some other ISO and WIM files that I needed to add.



Sure hope this would help you and best of luck.

 

[pallass]

Hello,

First, thanks for your job Jayro, you did it verry well

Next, one of PortableApps's soft is named "NTFS Permission Tool" but due to the exFat format of Medicat, I can't use it, I still got a message or error saying that it's not working on other than NTFS.

There is a trick for this or I missed something ?

Thanks again !

 

[Jayro]

Hello,

First, thanks for your job Jayro, you did it verry well

Next, one of PortableApps's soft is named "NTFS Permission Tool" but due to the exFat format of Medicat, I can't use it, I still got a message or error saying that it's not working on other than NTFS.

There is a trick for this or I missed something ?

Thanks again !

Probably just an oversized on my part. I'll be using NTFS going forward.

 

[Ruxos]

Alright. @Jayro here's the faulting driver. Apparently, I think it's also present in all of the wim files you've created.

Published Name : oem19.inf
Original File Name : netathrx.inf
Inbox : No
Class Name : Net
Provider Name : Atheros Communications Inc.
Date : 11/13/2010
Version : 9.2.0.113​

That's the one that gives issues for me on my Atheros card. Not on my desktop right now but if you want I can post the make/model of it too. Removing that makes my wifi works properly. Now, this is just on my side apparently. One of my friend, whom I give occasional online support via teamviewer, I got her to test the same iso. Unmodified 19.10 one. Apparently, in her case something weird happens. She too has a qualcomm atheros card, albeit a different make and model from mine, since hers is a laptop card while mine is a desktop one. Regardless, in her case, no wifi drivers are installed at all. For which, I downloaded the drivers from her laptop's manufacturer thinking that they should work, and they do as far as the installation goes. Device is active in her device manager, throws no error at all either. But, still no wifi at all. Not sure what's happening on her side. But for now I have given up on it, and my instinct tells me to make a live version of medicat winpe and try that out. In her case this is the driver

netathr10x.inf
Version : 12.0.0.709​

(Well, that is the driver from the manufacturer's side. Doesn't work. But in the drivers list I saw that there are 2 different versions of the same driver, but why doesn't the windows load them then instead? Because when I removed the manufacturer's drivers from /System/Drivers folder, I couldn't even see the network adapter now at all). Which also got me to notice, that how there were many drivers having multiple (2 or more) versions of them. I wonder how you're removing the default microsoft drivers and integrating the new ones.

Other than that, there's one more thing. I tried aioboot on your images. Aside from the winpe and lubuntu, both of them which work fine, I got all of the images/isos to work fine with it too. Easily integrated into the menu. Except from spinrite, which I couldn't get to load. And the fact that it can only load linux iso files or boot wim files via wimboot only, whereas ventoy can easily load them up even from within a iso file. The perks vary in both, although from a security point of view I'd say ventoy seems better as it can easily boot from iso/wim files which can help to keep the data within virus free, if you were plugging that usb in a heavily infected system. Aioboot has a lot of tools which helps to weed out singular problems. If it were me, I'd still keep a copy of aioboot on the side with the ventoy as the main driver. What keeps me away from ventoy is the fact that I can't boot my usb on uefi mode at all. It keeps booting into legacy mode. Whereas both aioboot and uefi:ntfs got my usb into uefi mode. Have to look into it more perhaps.

One more thing, does ventoy need some extra configuration files for the images you've put on the exfat partition? I can see on their github that all ventoy needs the iso/wim files to be is just ventoy compatible. And if that's the case, wouldn't it be better for you to host the images as is instead of making a partition image? When all people have to do is just copy/paste the files into the ntfs folder in whatever order/folder hierarchy they want? Please think about it if it's possible. That way you also don't have to go the extra mile of creating a full disk like before and the users can have the choice on what they want. Win-Win situation for everyone.

 

[Abdo-kh]

I have a serious problem
When I engrave the image on my 128 GB key, I have an unallocated space of 57 GB that I cannot use.
I wanted to copy in this space my iso tools and a driverpacks but it's boring to lose half of space for nothing

 

[KaMyKaSii]

The project might be abandoned at this point though but the last version he posted is seriously off the charts already, yeah it could take some more polishing fixing some minor stuff here and there, a new gui maybe and adding more improvements but even at this point you could do a lot more than ventoy and is a lot user friendly.

It supports booting from a multitude of options, from iso to wim to vhd and whatnot.

As you said, the AIO Boot project is abandoned. If you want the possibility to boot directly from .vhd or .img disk copies (like the current Medicat itself), you can use the Grub2 File Manager. You just need to add the multiarch iso to Medicat (Ventoy bootloader) and use it to boot into the Grub2 File Manager, and then boot anything you want.

Probably just an oversized on my part. I'll be using NTFS going forward.

Don't forget to include the new Ventoy update, it fixed the problems I was having with low system resolution when booting wim files directly, maybe it will also fix the problem of other users

 

[Abdo-kh]

I have a serious problem
When I engrave the image on my 128 GB key, I have an unallocated space of 57 GB that I cannot use.
I wanted to copy in this space my iso tools and a driverpacks but it's boring to lose half of space for nothing

 

[KaMyKaSii]

I have a serious problem
When I engrave the image on my 128 GB key, I have an unallocated space of 57 GB that I cannot use.
I wanted to copy in this space my iso tools and a driverpacks but it's boring to lose half of space for nothing

You need to read the forum first.
Move all files of the ExFAT partition to another drive and then use some partition program to delete the ExFAT partition and create a NTFS partition using all the avaliable space. Then just move the files back

 

[Ruxos]

As you said, the AIO Boot project is abandoned. If you want the possibility to boot directly from .vhd or .img disk copies (like the current Medicat itself), you can use the Grub2 File Manager. You just need to add the multiarch iso to Medicat (Ventoy bootloader) and then use it to boot into the Grub2 File Manager, and then boot anything you want.

Ay, it's not just the ability to boot from img or vhd disks, but the vast array of tools it packs within itself. Of course, I could go ahead and get most of those extra tools separately, and even updated ones, but that's going a hard way around. I am not saying ventoy is bad, even I like the current changes within it that it can boot directly from wim/iso files. That in itself is something. Aioboot can do the same but with some additional steps, it's not a one click setup like ventoy. Yes the project is abandoned, although I don't think it would provide the same functionality as ventoy, in which case even the current version is a good option for some users. It just comes to the preferences too.

 

[Romano2K]

Hi!

Thank you Jayro for your work!

I've downloaded MediCat 20.06 via BitTorrent, which is suited for this kind of download, thanks for offering this option!

But why put the actual files in a multipart compressed file? As far as I know this isn't common practice for torrents, it's even forbidden on many torrenting communities.

One good reason is that you need twice the storage space to download then uncompress the files. Also you'd have to keep both the compressed files to keep seeding and the uncompressed files to flash them. That's 70GB in this case, which is a lot, too much for my laptop's 500GB SSD. ;-)

Would you consider sharing the actual files directly via BitTorrent? You can put a disclaimer regarding antiviruses if that's your reasoning.

 

[Jayro]

Hi!

Thank you Jayro for your work!

I've downloaded MediCat 20.06 via BitTorrent, which is suited for this kind of download, thanks for offering this option!

But why put the actual files in a multipart compressed file? As far as I know this isn't common practice for torrents, it's even forbidden on many torrenting communities.

One good reason is that you need twice the storage space to download then uncompress the files. Also you'd have to keep both the compressed files to keep seeding and the uncompressed files to flash them. That's 70GB in this case, which is a lot, too much for my laptop's 500GB SSD. ;-)

Would you consider sharing the actual files directly via BitTorrent? You can put a disclaimer regarding antiviruses if that's your reasoning.

They are compressed because my upload speeds are absolute shit. (40Mb/s upload)
They are split into 4GB chunks so if the download gets corrupted somewhere, you can just download the chunk again instead of re-downloading the entire thing.
I just uploaded a new torrent of MediCat v20.06.1, which is only 22.8GB zipped AND uncompressed. It's much slimmer and uses NTFS so you can resize the partitions easier.

 

[Romano2K]

They are compressed because my upload speeds are absolute shit. (40Mb/s upload)
They are split into 4GB chunks so if the download gets corrupted somewhere, you can just download the chunk again instead of re-downloading the entire thing.
I just uploaded a new torrent of MediCat v20.06.1, which is only 22.8GB zipped AND uncompressed. It's much slimmer and uses NTFS so you can resize the partitions easier.

I can understand why you split them for Google Drive or Mega, but as far as I know the BitTorrent protocol has algorithms preventing a download to become corrupted. I may be an exception, but I have never had any torrent download corrupted.

Also, if the file is the same size zipped and uncompressed, than why bother compressing it? ;-) At least for the torrent download anyway!

There are my 2 cents, I let other users say what they think about that! :-)

I guess you can ask someone else with good upload speeds to make a torrent with the plain files. The beauty of BitTorrent is that you Jayro don't need to share it, it'll live on its own!

 

[Jayro]

Also, if the file is the same size zipped and uncompressed, than why bother compressing it?

I'm basically using 7-zip as a file splitter, because it's easy.