After some trial and error, there are two non-obvious steps to get the installer running:

• Properly mounting the .bin live USB image in a way that’s accessible to the VM
• Setting graphics drivers to something ChromeOS Flex supports, which enables the VM to successfully boot the live USB image

Prepare

You’ll need the ChromeOS Flex USB image, which you can get from here if you don’t want to enter your contact info on the main page.

Download the ZIP and extract it to your host device somewhere.

While you wait…

To use the VirGL GPU driver, which we’ll need later:

apt-get install libgl1 libegl1

Create the VM

I used mostly default settings, with a few exceptions.

• Linux OS, with the Do not use any media option initially selected
• q35 machine type
• host CPU type
• OVMF (UEFI) BIOS type

If you’re using OVMF (UEFI) make sure you uncheck the Pre-Enroll keys option on the EFI disk, otherwise it won’t boot - I got an “Access Denied” error in the virtual BIOS.

After creation, go change the Graphic card setting under Display (inside Hardware) to VirGL GPU.

VirtIO-GPU may also work, but in my experience it was a bit laggier - more info on differences, or search yourself.

Don’t bother starting the VM yet.

Map in the live USB binary image as a disk

Set up a loop device with the extracted binary image from the earlier-downloaded from the ZIP file.

For example:

losetup --partscan /dev/loop1 chromeos_15393.58.0_reven_recovery_stable-channel_mp-v2.bin

Then, map it to your VM like you would any other block device (reference):

qm set <vm_id_here> -scsi2 /dev/loop<num>

Mine was /dev/loop1, yours may be different.

Start it up

Go back to the Proxmox VM settings (Options, not Hardware this time) and change the boot order, putting the scsi2 device first. It should be obvious which one it is, because it’s mapped to your loop device.

Finally, start the VM. If all goes well, you should be greeted with the ChromeOS Flex install screen via the console.

Complicating the matter…

• My 257GiB disks were mostly full, so I really didn’t want to download them, copy the data around, then reupload.
• I was using the max number of data disks for the VM size I had (four)
• I was using btrfs and striping the data across the data disks. So mounting a single disk and copying some data over to a larger disk couldn’t be done - all four had to be mounted at once.

Happily, the disks are in the standard VHD format. I decided to take this as a bit of a challenge and modify them using the Azure Page Blob API, but still keep them usable enough to migrate.

What? How?

⚠️ This was, and is, probably a bad idea, so follow these steps at your own risk. I didn't care much about the data but I preferred not to lose it. Standard advice of back up your data, and disclaimer that it's not my fault if you lose it. There's always the easier and safer option of just mounting more disks on a larger VM temporarily, and copying the data over!

The general idea I came up with was - as long as the disks had unallocated space at the end, the only thing I’d have to do was truncate the blobs and rewrite the VHD footer.

At first, I thought I was going to have to write my own VHD footer reading/writing code myself - but then I found someone with a similar idea which inspired my C# version.

With that in mind, I started with a few manual steps:

• btrfs balance and btrfs filesystem resize <devId>:-1G /home more than once for each “physical” drive and verified there was free space at the end
• Create a dummy disk with the desired size so the trailer is correct
  • I did this individually, for each data disk, because there’s a UUID in the footer. Unclear if this was actually necessary.
• Set the dummy disk to export mode to get a SAS URI
• Get the exact size of the dummy disk and save off its footer
• One dash of caution: take a snapshot of each pre-modification VHD so I could roll back if something went wrong.

Then, some code to:

• Resize each target disk to the exact same size as the dummy disk
• Copy over the footer from the dummy disk to the target disk so Hyper-V (Azure) is happy

And then finally finish the migration to managed disks.

So did it work?

Yep! Everything went fine. The only issue was a post-migration fsck which showed some errors like

btrfs: csum mismatch on free space cache
failed to load free space cache for block group

These were easy to fix via btrfs check --progress --clear-space-cache v1

Give me the code

using System.Text;
using Azure.Storage;
using Azure.Storage.Blobs.Specialized;

var accountName = "myStorageAccount";
var containerName = "myContainer";
var blobName = "myBlobName.vhd";
var creds = new StorageSharedKeyCredential(accountName, "myStorageAccountKey");

var dummyStorageName = "dummy4-footer.bin";
var existingBackupFooterName = "existing4-footer.bin";
var dummySasUri = "<dummy_export_URL>";

var tempSourceBlob = new PageBlobClient(new Uri(dummySasUri));
await ReadFooterAsync(tempSourceBlob, dummyStorageName);
var targetPageBlob = new PageBlobClient(new Uri($"https://{accountName}.blob.core.windows.net/{containerName}/{blobName}"), creds);
await ReadFooterAsync(targetPageBlob, existingBackupFooterName);
await ResizeAndWriteFooterAsync(targetPageBlob, dummyStorageName);

static async Task ReadFooterAsync(PageBlobClient sourceBlob, string targetBinaryFooterFileName)
{
    var footerSize = 512;
    var length = (await sourceBlob.GetPropertiesAsync()).Value.ContentLength;
    Console.WriteLine($"Dummy length: {length}");
    using var blobStream = sourceBlob.OpenRead(length - footerSize, footerSize);

    var buf = new byte[footerSize];
    int read = 0;
    while (read < footerSize && read >= 0)
    {
        read += blobStream.Read(buf, read, footerSize - read);
    }

    Console.WriteLine($"Read {read} bytes");
    Console.WriteLine($"Footer: {Encoding.UTF8.GetString(buf)}");
    using var fs = File.OpenWrite(targetBinaryFooterFileName);
    await fs.WriteAsync(buf);
}

static async Task ResizeAndWriteFooterAsync(PageBlobClient targetBlob, string sourceFooterBinaryFileName)
{
    var footerSize = 512;
    var finalSize = 273804165632; // 255GB

    var length = (await targetBlob.GetPropertiesAsync()).Value.ContentLength;
    Console.WriteLine($"Before length: {length}");
    await targetBlob.ResizeAsync(finalSize);

    using (var blobStream = await targetBlob.OpenWriteAsync(overwrite: false, finalSize - footerSize))
    using (var fs = File.OpenRead(sourceFooterBinaryFileName))
    {
        await fs.CopyToAsync(blobStream);
    }

    length = (await targetBlob.GetPropertiesAsync()).Value.ContentLength;
    Console.WriteLine($"After length: {length}");
}

If you’re not me, replace 192.168.1.223 with whatever your host machine is on your LAN.

Setup

Host

Just in case the machine I really don’t care to backup bites the dust…

• Assuming a Debian-like system, apt-get install default-jdk
  • I initially tried to do this in a Linux Container (LXC) - but nested virtualization via /dev/kvm doesn’t pass through. Oh well.
• Create or reuse a user. In my case, I did:
  • useradd -m android
  • usermod -a -G kvm android (otherwise the emulator + nested virtualization won’t work)
  • passwd android to something I could remember (needed later)
• su android, install Android Platform tools, emulator, etc. One of the links below should help.
  • If it’s been a while, sdkmanager --update to pull the latest SDK
• Add android tools to path. e.g. create .localrc and set contents to PATH=$HOME/cmdline-tools/latest/bin:$HOME/platform-tools:$HOME/emulator:$PATH
• Get the image: sdkmanager --install "system-images;android-35;google_apis;x86_64"
• Create AVD: avdmanager create avd --name pixel-android-api-35 --package "system-images;android-35;google_apis;x86_64" --tag "google_apis" --abi "x86_64" --device "pixel_6"
• Install the mitmproxy cert into the emulator after making the system partiton writable. I won’t copy those steps, follow them here.

Client

brew install scrcpy

Execute

Host

• Start screen or similar
• In one terminal of your main user with sudo: sudo docker run --rm -it -v ~/.mitmproxy:/home/kevin/.mitmproxy -p 0.0.0.0:8080:8080 -p 0.0.0.0:8081:8081 mitmproxy/mitmproxy:latest mitmweb --showhost --web-host 0.0.0.0
• (ADB_MDNS=0 can be removed if https://issuetracker.google.com/issues/382999951 is fixed)
• In another terminal: ADB_MDNS=0 emulator -avd pixel-android-api-35 -writable-system -no-window -http-proxy http://192.168.1.223:8080
• In another terminal:
  • export ADB_MDNS=0
  • adb forward tcp:1234 tcp:5555
  • adb tcpip 5555
  • ssh -Nfg -L 1234:localhost:5555 localhost

Remote

• adb connect 192.168.1.223:1234
• scrcpy -m1024
• Open http://192.168.1.223:8081
• Run your scenario and hopefully it’s captured. If not, you might have a problem with cert pinning or an app bypassing the proxy.

Unclear if this is necessary with the -http-proxy argument with the emulator (I discovered that later), but found it useful enough to document. Run on either host or remote.

adb shell settings put global http_proxy 192.168.1.223:8080
adb shell settings put global global_http_proxy_host 192.168.1.223
adb shell settings put global global_http_proxy_port 8080

Future

At some point, I think I’m going to need a packet capture for my next step in the reverse engineering journey I started down…

Resources

This terse set of instructions was compiled from:

• https://gist.github.com/mrk-han/66ac1a724456cadf1c93f4218c6060ae
• https://gist.github.com/approovm/e550374428065ff1ecafca6a0488d384
• https://dev.to/andreisfedotov/how-to-install-android-emulator-without-installing-android-studio-3lce
• https://www.reddit.com/r/Crostini/comments/hqyjir/comment/fy1l0ar/?context=3

I never did get Frida working, it just hung on my emulator device and the client timed out connecting. But for my case, that wasn’t important.

Interesting things from 2025-01-05

• Using this Frida “codeshare” was really effective: frida --codeshare akabe1/frida-multiple-unpinning -U -f <app_name>
• https://github.com/REAndroid/APKEditor - merge APKs like java -jar APKEditor.jar m -i <directory>
• Sign a recompiled APK: java -jar uber-apk-signer-1.3.0.jar -a <merged_apk>.apk
• https://apktool.org/
• https://medium.com/@vaishalinagori112/9-different-ways-to-bypass-ssl-pinning-in-android-2d8c7f81b837
• https://approov.io/blog/how-to-bypass-certificate-pinning-with-frida-on-an-android-app
• https://gist.github.com/approovm/e550374428065ff1ecafca6a0488d384#start-the-emulator-with-a-writable-file-system

Sometimes I like to screw around with my Azure resources like the VM itself, networking, sizes, etc. which necessitates deleting the VM. But I don’t want to actually lose the OS - I want my data to say safe.

My handy .txt file this is based off of told me I originally used this post, so thanks to whoever wrote that. Without further ado:

Connect-AzAccount

# RG info
$rgName = "default"
$locName = "East US 2"
$vmName = "{YOUR_VM_NAME}"
$diskBaseName = "{YOUR_DISK_BASE_NAME_MAYBE_SAME_AS_VM}"

# Networking
$vnet = Get-AzVirtualNetwork -Name "public-vnet" -ResourceGroupName $rgName
$nic = Get-AzNetworkInterface -Name "$vmName-if" -ResourceGroupName $rgName

# VM
$vm = New-AzVMConfig -VmName $vmName -VmSize "Standard_B2ms"
$vm = Add-AzVMNetworkInterface -VM $vm -Id $nic.Id

# Attach disks
$vm = Set-AzVMOSDisk -VM $vm -Name "arch_azure" -VhdUri "https://$vmName.blob.core.windows.net/os-vhd/arch_azure.vhd" -CreateOption Attach -Linux -Caching ReadWrite
$vm = Add-AzVMDataDisk -VM $vm -Name "$diskBaseName-data1" -VhdUri "https://$vmName.blob.core.windows.net/os-vhd/$diskBaseName-data1.vhd" -LUN 0 -Caching None -CreateOption Attach
$vm = Add-AzVMDataDisk -VM $vm -Name "$diskBaseName-data2" -VhdUri "https://$vmName.blob.core.windows.net/os-vhd/$diskBaseName-data2.vhd" -LUN 1 -Caching None -CreateOption Attach
$vm = Add-AzVMDataDisk -VM $vm -Name "$diskBaseName-data3" -VhdUri "https://$vmName.blob.core.windows.net/os-vhd/$diskBaseName-data3.vhd" -LUN 2 -Caching None -CreateOption Attach
$vm = Add-AzVMDataDisk -VM $vm -Name "$diskBaseName-data4" -VhdUri "https://$vmName.blob.core.windows.net/os-vhd/$diskBaseName-data4.vhd" -LUN 3 -Caching None -CreateOption Attach

# Create the VM
New-AzVM -ResourceGroupName $rgName -Location $locName -VM $vm -Verbose

In case it’s not obvious, this is using Powershell with the Azure Az module. Yes, it could probably use the fancy az CLI that exists too. No, I don’t care - it works for me 🙂

Preempting a few questions:

• This is using unmanaged disks because they are WAY cheaper per GB, and I can stripe 4 of them in RAID 0 using btrfs. While it wouldn’t be ideal, I don’t really really care about losing the data on there, plus I trust Azure to keep my data (relatively) safe.
  • Remember, I did this masochistically.
• The NIC name, as well as the storage account paths and disk names, are by convention - no real association necessary.
• I don’t remember why exactly I disabled disk caching for the “data disks” - I think some article told me to, but recommended that I keep it enabled for the OS disk. I might have perf tested it too.
• I’m using Azure because I get it for free as a work benefit. Not sure what I’d do otherwise, but dedicated servers are pretty cheap these days versus the public cloud!

For a long time, I put off setting up a blog because I felt like I had nothing unique to write about or share. Blogging seemed pretty silly and weird – still does, honestly.

But, about a year ago, I started a “new job” where asynchronous work became much more important. COVID-19 happened and put the transition from my former-office-based-self (still want to go back, BTW – but it’ll never be the same) into overdrive. So, I found myself writing a LOT more as a part of my daily job. Why not do it for fun too? (only half-kidding…)

Over the past year, I realized a few things:

• I actually enjoy writing, most of the time. Maybe there’s a pattern there…
• I’m a much better written storyteller than a verbal one. And I’m not a great writer.
• I was setting the bar WAY too high for myself, and was afraid to “put myself out there.” Don’t be me. Try the things you want to try, life is short.

So here we are! I don’t expect to put a lot on here, and I don’t expect it to be high quality¹. Mostly just a place to put the outcomes of my random quests to learn things, primarily sourced from the internet. During my relatively short time on earth, I think I’ve accumulated a fair bit of knowledge and experience (obviously paling in comparison to what I don’t know), so I might try to share some of that too.

Then again, maybe this will be the only post ever, who knows? One thing I do know - without setting this up it was going to be impossible to try.

¹A good friend of mine once told me – the key to measuring success is low expectations 😊