Rooting the Meraki MS220-8P - Revision history

Leo: Text replacement - "Category:Tinkering{{Navbox Tinkering}}" to "{{Navbox Tinkering}}Category:Tinkering"

2020-06-15T00:42:57Z

Text replacement - "Category:Tinkering{{Navbox Tinkering}}" to "{{Navbox Tinkering}}Category:Tinkering"

← Older revision		Revision as of 00:42, 15 June 2020
Line 487:		Line 487:
	* https://wiki.dave.eu/index.php/Memory_Tecnology_Device_(MTD) - more information, including ubi/ubifs		* https://wiki.dave.eu/index.php/Memory_Tecnology_Device_(MTD) - more information, including ubi/ubifs

	[[Category:Tinkering]]~~{{Navbox Tinkering}}~~		{{Navbox Tinkering}}[[Category:Tinkering]]

Leo: Recategorize

2019-09-01T02:05:46Z

Recategorize

← Older revision		Revision as of 02:05, 1 September 2019
Line 486:		Line 486:
	* http://processors.wiki.ti.com/index.php/Mtdutils - using mtdutils, dumping, flashing, etc.		* http://processors.wiki.ti.com/index.php/Mtdutils - using mtdutils, dumping, flashing, etc.
	* https://wiki.dave.eu/index.php/Memory_Tecnology_Device_(MTD) - more information, including ubi/ubifs		* https://wiki.dave.eu/index.php/Memory_Tecnology_Device_(MTD) - more information, including ubi/ubifs

			[[Category:Tinkering]]{{Navbox Tinkering}}

Leo: Text replacement - "{\| " to "{| class="wikitable" "

2019-09-01T01:33:40Z

Text replacement - "{\| " to "{| class="wikitable" "

← Older revision		Revision as of 01:33, 1 September 2019
Line 39:		Line 39:

	The boot images must be of size 3932160 bytes (ie. MTD partition size of 0x3C0000) and containing the following header.		The boot images must be of size 3932160 bytes (ie. MTD partition size of 0x3C0000) and containing the following header.
	{\|		{\| class="wikitable"
	! colspan="4" \|		! colspan="4" \|
	Boot Image Header		Boot Image Header
Line 50:		Line 50:
	{{code\|Boot Data}}. This is of length {{code\|Payload Length}}		{{code\|Boot Data}}. This is of length {{code\|Payload Length}}
	\|}		\|}
	{\|		{\| class="wikitable"
	! colspan="4" \|		! colspan="4" \|
	Example Boot Header		Example Boot Header
Line 321:		Line 321:
	The image has another header. It looks like this time, the 32bit words are in big endian.		The image has another header. It looks like this time, the 32bit words are in big endian.

	{\|		{\| class="wikitable"
	! colspan="4" \|		! colspan="4" \|
	Boot Image Header		Boot Image Header
Line 333:		Line 333:
	\|}		\|}

	{\|		{\| class="wikitable"
	! colspan="4" \|		! colspan="4" \|
	Example Boot Header		Example Boot Header

Leo at 05:53, 22 January 2019

2019-01-22T05:53:15Z

← Older revision		Revision as of 05:53, 22 January 2019
Line 467:		Line 467:
	/ # dmesg -n 1		/ # dmesg -n 1
	}}		}}


			== See Also ==
			* https://forum.archive.openwrt.org/viewtopic.php?id=63838 - Old forum post
			* https://forum.openwrt.org/t/support-for-meraki-ms220-8p/26007 - New forum post

			=== Source ===
			Open source code can be found at:
			* https://dl.meraki.net/switch-8-10-20170825.tar.bz2
			* http://dl.meraki.net/linux/index.html

			=== OpenWRT ===
			* https://openwrt.org/docs/guide-developer/crosscompile

			=== Flash Memory ===
			* http://www.righthandtech.com/embedded-linux-managing-memory.php
			*: {{quote\|The mapping driver can either specify a hard-coded partition layout, read the partition layout from the kernel command line passed in from the boot loader (i.e. U-Boot), or read the partition layout from flash storage (i.e. Redboot boot loader).}}
			* http://processors.wiki.ti.com/index.php/Mtdutils - using mtdutils, dumping, flashing, etc.
			* https://wiki.dave.eu/index.php/Memory_Tecnology_Device_(MTD) - more information, including ubi/ubifs

Leo: /* Stage 1 */

2019-01-22T01:36:53Z

Stage 1

← Older revision		Revision as of 01:36, 22 January 2019
Line 95:		Line 95:
	Since I don't have a 32bit MIPS crosscompiler and being the lazy guy I am, I tried the simplest approach which was to patch the {{code\|bootsh}} binary so that it calls a shell instead of {{code\|kexec}} which is on the ramdisk. I am assuming that the {{code\|bootsh}} file mounts the filesystems on the empty directories in the ramdisk.		Since I don't have a 32bit MIPS crosscompiler and being the lazy guy I am, I tried the simplest approach which was to patch the {{code\|bootsh}} binary so that it calls a shell instead of {{code\|kexec}} which is on the ramdisk. I am assuming that the {{code\|bootsh}} file mounts the filesystems on the empty directories in the ramdisk.

	I hex-edited {{code\|kexec -f %s --reuse-cmdline}} to {{code\|/bin/sh}} with a bunch of nulls after and tried booting. This did not work as the boot process continued on to the second kernel, implying that the kexec call still got made.		To extract the embedded initramfs from the boot MTD partition, locate the start and end {{code\|xz}} file header and footers. In my case, the initramfs data resides at {{code\|0x339604}} with length {{code\|349124}}. Using {{code\|dd}}, it can be extracted with:
			{{highlight\|lang=terminal\|code=
			dd if=bin/boot1 of=bin/boot1-patched-pre bs=1 count=$((0x339604))
			dd if=bin/boot1 of=bin/boot-data.xz bs=1 skip=$((0x339604)) count=349124
			dd if=bin/boot1 of=bin/boot1-patched-post bs=1 skip=$((0x38e9c8))
			}}

			The {{code\|boot1-patched-pre}} contains the boot image header and the Linux Kernel. {{code\|boot1-patched-post}} contains mystery data. The exact structure of the file must remain intact which means the payload data has to be the same as the original. The extracted ramfs data is a {{code\|cpio}} compressed with {{code\|xz}} and can be extracted with {{code\|zcat boot-data.xz {{!}} cpio -i}} on an empty directory.

			After extracting the initramfs contents, I hex-edited {{code\|kexec -f %s --reuse-cmdline}} to {{code\|/bin/sh}} with a bunch of nulls after and tried booting. This did not work as the boot process continued on to the second kernel, implying that the kexec call still got made.

	I hex-edited all reference to {{code\|kexec}} to {{code\|/sh}} with {{code\|/sh}} symlinked to {{code\|/bin/sh}} but that too did not work. It just tries over and over with this error:		I hex-edited all reference to {{code\|kexec}} to {{code\|/sh}} with {{code\|/sh}} symlinked to {{code\|/bin/sh}} but that too did not work. It just tries over and over with this error:

Leo: Created page with "This article will go over what I did to gain root access on the Meraki MS220-8P switch. TLDR: I modified both stage1 and stage2 flash so that I could eventually set a root pas..."

2019-01-22T01:16:14Z

Created page with "This article will go over what I did to gain root access on the Meraki MS220-8P switch. TLDR: I modified both stage1 and stage2 flash so that I could eventually set a root pas..."

New page

This article will go over what I did to gain root access on the Meraki MS220-8P switch. TLDR: I modified both stage1 and stage2 flash so that I could eventually set a root password in {{code|/etc/passwd}} as well as change the default shell to {{code|/bin/sh}}.

For information on the switch itself, see [[Meraki MS220-8P]].

== Rooting the Switch ==
Without the ability to start a shell on the first-stage bootloader, I would need to modify the initramfs to change {{code|bootsh}}'s behavior. Getting a shell at the first-stage bootloader would allow me to dump and inspect the rest of the NAND flash.

=== Examining the Boot Image ===
The initial bootloader, the VCore-III ROM Loader that is stored in the first 256Kb of the NOR flash, loads the first-stage bootloader into memory and verifies its integrity using a CRC32 check against the checksum stored as a 32bit word 16bytes into the boot image. If the CRC check fails, it will attempt to load the next partition (by jumping to the next hard-coded memory block containing the SPIM header, see below) and try again.

You can view the VCore-III ROM Loader source at {{code|meraki-firmware/linux-2.6.32/arch/mips/vcoreiii/loader/head.S}}.

When the CRC check fails, the loader will jump execution to the second loader. Your boot logs will show the double initialization as well:
{{highlight|lang=terminal|code=
LinuxLoader built Nov 12 2014 18:01:50
init_pll ok
init_spi ok
init_memctl ok
wait_memctl ok
Training DRAM ok
init_irq ok
init_dram_uncached ok
init_icache ok
init_dcache ok
enable_caches ok
init_board ok
Low level initialization complete, exiting boot mode
LinuxLoader built Nov 12 2014 18:01:50
init_pll ok
init_spi ok
init_irq ok
init_dram_uncached ok
init_icache ok
init_dcache ok
enable_caches ok
init_board ok
Low level initialization complete, exiting boot mode
}}

The boot images must be of size 3932160 bytes (ie. MTD partition size of 0x3C0000) and containing the following header.
{|
! colspan="4" |
Boot Image Header
|-
| {{code|LOADER_MAGIC}} 32bit || {{code|Kernel Address}} 32bit || {{code|Payload Length}} 32bit || {{code|Entrypoint Address}} 32bit
|-
| {{code|CRC32 CHKSUM}} 32bit || {{code|Reserved 1}} 32bit || {{code|Reserved 2}} 32bit || {{code|Reserved 3}} 32bit
|-
| colspan="4" |
{{code|Boot Data}}. This is of length {{code|Payload Length}}
|}
{|
! colspan="4" |
Example Boot Header
|-
| {{code|53 50 49 4D}} || {{code|00 00 10 80}} || {{code|E0 F1 38 00}} || {{code|B0 16 39 80}}
|-
| {{code|XX XX XX XX}} || {{code|00 00 00 00}} || {{code|00 00 00 00}} || {{code|00 00 00 00}}
|-
| colspan="4" |
{{code|00 00 ... boot data ... 00 00}}.
|}

Note: Values are in little endian so a 32bit value of {{code|0xAABBCCDD}} is stored as {{code|0xDDCCBBAA}}.

The {{code|LOADER_MAGIC}} is {{code|0x4d495053}} in little endian looks like {{code|53 50 49 4d}} or ASCII for {{code|SPIM}}.

The {{code|CRC32 CHKSUM}} value is calculated against the entire boot image of the given {{code|Payload Length}} with the CRC32 value zeroed out.

=== Modifying The Boot Image ===
The data after the boot image headers mentioned in the previous section contains the kernel and whatever else that's embedded into the kernel including a ramdisk. The ramdisk from the stock kernel is located after byte 0x339604.

To help facilitate modifying this ramdisk to do my bidding, I will split the data portion into 3 parts: The 'pre' ramdisk portion, the ramdisk portion, and the 'post' ramdisk portion. Pre-portion can be generated with {{code|1=dd if=boot1 of=boot1-patched-pre bs=1 count=$((0x339604))}} and the post-portion with {{code|1=dd if=boot1 of=boot1-patched-post bs=1 skip=$((0x38e9c8))}}.

To make changes to the boot file:
# Extract the boot data using {{code|cat ../boot-data.xz {{!}} xz -d {{!}} cpio -i}}
# Make your changes to the ramdisk
# Recreate the cpio {{code|find . {{!}} cpio -o -c > ../modified.cpio}}
# Recompress {{code|1=cat modified.cpio {{!}} xz -c9 --check=crc32 > modified.xz}}
# If image is smaller, pad with 0's for the difference {{code|cat modified.xz zeros.bin > modified.xz}}
# If image is larger, append post data, then adjust data lengths after payload and at the start of the boot file
# Reassemble boot file {{code|cat boot1-patched-pre modified.xz boot1-patched-post > boot1-patched}}
# Zero out CRC code
# Calculate the CRC code {{code|php ../crc32.php boot1-patched}}
# Write new CRC code
# Reassemble the entire image {{code|cat loader1 boot1-patched loader2 boot2 rsvd bootubi conf stackconf syslog > dump-patched.dat}}
# Copy the dump-patched.dat file to raspberry pi
# Flash it {{code|1=flashrom -p linux_spi:dev=/dev/spidev0.0,spispeed=600 -c "MX25L12835F/MX25L12845E/MX25L12865E" -w dump-patched.dat}}.

=== The Journey to Rooting the Switch ===
This section will run on as a semi-journal on what I did in order to gain access to the switch.

==== Stage 1 ====
Since I don't have a 32bit MIPS crosscompiler and being the lazy guy I am, I tried the simplest approach which was to patch the {{code|bootsh}} binary so that it calls a shell instead of {{code|kexec}} which is on the ramdisk. I am assuming that the {{code|bootsh}} file mounts the filesystems on the empty directories in the ramdisk.

I hex-edited {{code|kexec -f %s --reuse-cmdline}} to {{code|/bin/sh}} with a bunch of nulls after and tried booting. This did not work as the boot process continued on to the second kernel, implying that the kexec call still got made.

I hex-edited all reference to {{code|kexec}} to {{code|/sh}} with {{code|/sh}} symlinked to {{code|/bin/sh}} but that too did not work. It just tries over and over with this error:
{{highlight|lang=terminal|code=
[ 3.633000] execl failed: 2
[ 3.638000] kexec died
[ 3.640000] Calling kexec for /dev/mtdblock/part1 failed!
[ 3.647000] execl failed: 2
[ 3.651000] kexec died
[ 3.654000] Calling kexec for /dev/mtdblock/part2 failed!
}}

Since I removed the {{code|kexec}} binary and replaced all {{code|kexec}} strings to {{code|/sh}} that is symlinked to {{code|/bin/sh}}, having the boot process fail in this manner implies that either the {{code|/kexec}} or the {{code|/sh}} binary is being called. Both of which are symlinked to {{code|/bin/sh}} which suggests that {{code|/bin}} isn't mounted.

I got a [https://www.mips.com/develop/tools/codescape-mips-sdk/ MIPS cross compiler] and compiled busybox without a bunch of applets so that the final binary can fit inside the size of the existing xz archive. I wasn't totally sure if busybox would like being called directly by the kernel (because it might not know which applet to run?) so I created a {{code|/init}} script that invoked {{code|/sh}} that is symlinked to busybox and then called {{code|/sh}}.

The first few times failed. The first time, the CPU architecture wasn't correct (the MIPS compiler targetted rel6, not rel2). The next few times also failed because I compiled it with the wrong endianness. All these failed attempts resulted in {{highlight|lang=terminal|code=
Starting init: /bin/sh exists but couldn't execute it (error -8)
Kernel Panic - not syncing: No working init found. Try passing init= option to Kernel. }}.

I eventually got busybox compiled for MIPS32 rel2 in little endian with these gcc flags:
{{highlight|lang=terminal|code=
root@fc:/tmp/busybox-1.30.0# make CROSS_COMPILE=mips-mti-linux-gnu- CFLAGS='-Wa,-mips32r2,-march=24kec,-mtune=24kec -mel -EL' LDFLAGS='-Wa,-mips32r2,-march=24kec,-mtune=24kec -mel -EL' ARCH=mips KBUILD_VERBOSE=1 -j 8

## The resulting binary should be like this
root@fc:/tmp/busybox-1.30.0# file busybox
busybox: ELF 32-bit LSB executable, MIPS, MIPS32 rel2 version 1 (SYSV), statically linked, for GNU/Linux 2.6.32, stripped
}}

Using this busybox executable, I rebuilt the ramdisk, repackaged the files, and reflashed it onto the switch and hoped for the best.

{{highlight|lang=terminal|code=
[ 3.057000] devtmpfs: mounted

[ 3.069000] Freeing unused kernel memory: 484K
sh: can't execute 'echo': No such file or directory

BusyBox v1.30.0 (2019-01-16 20:37:46 MST) hush - the humble shell

/ # uname -a
Linux (none) 3.18.102-meraki-elemental #1 Fri Apr 13 11:18:08 PDT 2018 mips GNU/Linux
}}

My {{code|echo "Hello world"}} inside {{code|failed}} failed since there was no {{code|echo}} in the PATH, but I got a shell!

After exploring around with my very limited busybox (which in my haste to minimize size, I apparently did not bundle {{code|cd}} into...), it turns out that {{code|/dev/mtdblock11}} contains a 640K squashfs filesystem containing a better featured busybox. To make my life easier, I mounted and copied the entire contents to the ramdisk. No other devices seem to have a filesystem I can mount. I integrated this into {{code|init}}, so that the switch comes up with a more usable system.
{{highlight|lang=terminal|code=
/ # busybox mkdir /proc /sys
/ # busybox mount -t proc none /proc
/ # busybox mount -t sysfs none /sys
/ # busybox mkdir /rootfs
/ # busybox rm /lib /sbin /usr /bin
/ # busybox mount -o ro /dev/mtdblock11 /rootfs
/ # busybox cp -r /rootfs/* /
/ # /bin/sh
}}

Unfortunately, there is no networking enabled with this first kernel. This will make copying data in and out a pain since it has to go through the serial connection.
{{highlight|lang=terminal|code=
## No networking is a bummer.
/ # ifconfig -a
lo Link encap:Local Loopback
LOOPBACK MTU:65536 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
}}

CPU information:
{{highlight|lang=terminal|code=
/ # cat /proc/cpuinfo
system type : Vitesse VCore-III VSC7425
machine : Unknown
processor : 0
cpu model : MIPS 24KEc V5.4
BogoMIPS : 276.99
wait instruction : yes
microsecond timers : yes
tlb_entries : 16
extra interrupt vector : yes
hardware watchpoint : yes, count: 4, address/irw mask: [0x0ffc, 0x0ffc, 0x0ffb, 0x0ffb]
isa : mips1 mips2 mips32r1 mips32r2
ASEs implemented : mips16 dsp
shadow register sets : 1
kscratch registers : 0
package : 0
core : 0
VCED exceptions : not available
VCEI exceptions : not available

/ # cat /proc/meminfo
MemTotal: 125548 kB
}}

Since the first 9 MTD are from the NOR flash device, everything after is from the larger NAND flash device. Since I have no ability to physically dump the contents of the NAND drive, being able to copy the data from the running kernel at this stage is extremely helpful.

The next task now is to get the contents of the flash memory and figure out how to gain root access on the second stage. Specifically, it would be nice to know if there is already a SSH account I can use, what the {{code|<MERAKI>}} console that gets brought up is (and what commands it actually takes), and if it is possible to add my own account in.

I tried to {{code|dd}} data out from the serial connection, but it seems like data randomly gets corrupted over the serial console. There are utilities that can be used to transfer files over serial such as lzrzr or kermit, but none of them exist. I figured it'd be easier to write my own shell script that chunks the data out using base64 and then sum these chunks for data integrity checks. It turns out, baud rates higher than 115200 yields a very unstable serial connection and it ends up garbling up the data that's sent across. After spending a few hours hacking a few scripts together, I am now able to send (albeit slowly, <8kb/s) files in and out of the switch.

I transferred mtd{9-21}ro out of the switch for analysis. Each MTD looks like this:
{{highlight|lang=terminal|code=
data9: ~250k Nulls, of length 0x0003dd8b
data10: 128k Switch Data (Model, Serial Number)
data11: 540k Squashfs filesystem, little endian, version 4.0, 548778 bytes, 166 inodes, blocksize: 131072 bytes, created: Fri Apr 13 18:19:18 2018
data12: 20MB data
data13: 20MB data, old copy/backup of the above?
data14: 8MB UBIfs image, sequence number 1, length 4096, CRC 0x8a351c73
data15: ELF 32-bit LSB executable, MIPS, MIPS32 version 1 (SYSV), statically linked, stripped
data16: ELF 32-bit LSB executable, MIPS, MIPS32 version 1 (SYSV), statically linked, stripped
data17: ELF 32-bit LSB executable, MIPS, MIPS32 version 1 (SYSV), statically linked, stripped
data18: ELF 32-bit LSB executable, MIPS, MIPS32 version 1 (SYSV), statically linked, stripped
data19: ELF 32-bit LSB executable, MIPS, MIPS32 version 1 (SYSV), statically linked, stripped
data20: ELF 32-bit LSB executable, MIPS, MIPS32 version 1 (SYSV), statically linked, stripped
data21: ELF 32-bit LSB executable, MIPS, MIPS32 version 1 (SYSV), statically linked, stripped
}}

The ELF binaries stored in {{code|mtdblock15}} - {{code|mtdblock21}} are all different versions of what seems to be the switch CLI management program. I later learn that these are different versions of SMBStax binaries for eCos. I'm unsure whether these actually get executed anywhere considering that they're supposed to run under eCos and not Linux.

{{code|mtdblock12}} and {{code|mtdblock13}} contains the second stage kernel as well as an embedded ramdisk image similar to the first stage boot1/boot2 partitions. The kernel that is there is slightly older at version {{code|3.18.57-meraki-elemental}}. The ramdisk image extracted out contains all the Meraki OS binaries and scripts which we'll get into soon.

{{code|mtdblock14}} is a UBIfs image that gets mapped to {{code|/dev/ubi1_4}} and gets mounted as {{code|/storage}} when the switch boots into the second stage. This partition contains some logs, core dumps, last known good configs, etc.
{{highlight|lang=terminal|code=
# mount -t ubifs /dev/ubi1_4 /mnt
# find /mnt
.
./syslogs
./syslogs/41.start
./syslogs/42.last_write
./syslogs/40.last_write
./syslogs/43.start
./syslogs/39.last_write
./syslogs/39.start
./syslogs/39.watchdog_status
./syslogs/40.start
./syslogs/43.last_write
./syslogs/42.start
./syslogs/41.last_write
./mfg_done
./dropbear
./dropbear/dropbear_rsa_host_key
./dropbear/dropbear_dss_host_key
./random_seed
./odm_test.log
./last_good_uplink_config
./lastdhcpip_wired0
./config.local
./unique_config_secret
./cores
./cores/37.switch-10-201808241214-G0a4ba17b-rel-owner.core-serial_loginche-00-00-52.tgz
./cores/37.switch-10-201808241214-G0a4ba17b-rel-owner.core-serial_loginche-00-00-53.tgz
./cores/37.switch-10-201808241214-G0a4ba17b-rel-owner.core-serial_loginche-00-00-55.tgz
./cores/37.switch-10-201808241214-G0a4ba17b-rel-owner.core-serial_loginche-00-00-56.tgz
./cores/37.switch-10-201808241214-G0a4ba17b-rel-owner.core-serial_loginche-00-01-36.tgz
./cores/37.switch-10-201808241214-G0a4ba17b-rel-owner.core-serial_loginche-00-01-49.tgz
./lists
./last_uplink_lport
./BOOT_COUNT
./BOOT_COUNT.reserve
./config
}}

To boot the next stage, you can copy the {{code|kexec}} binary from the original boot1/boot2 partition over and then run:
{{highlight|lang=terminal|code=
# ./kexec -f /dev/mtdblock12
}}

However, this will just bring you back to the locked down console.

==== Stage 2 ====

With the second stage ramfs image obtained, I can now dig through how the Meraki OS actually works. The file listing of the ramdisk can be found at https://paste.steamr.com/view/7974ba25. After extracting the image and digging around the filesystem, a few interesting points to note:
* {{code|/etc/passwd}} contains some accounts: {{highlight|lang=terminal|code=
leo@fc:/home/leo/extracted/stage2/extracted% cat etc/passwd
root:!:0:0:root:/tmp:/bin/ash
nobody:*:65534:65534:nobody:/var:/bin/false
mf:$1$$CgXoxAaejQmJWRkDiclb6/:0:0:meraki:/tmp:/usr/bin/serial_logincheck
support:x:1:1:Meraki Support:/support:/bin/ash
}}
* The 'mf' account runs {{code|/usr/bin/serial_logincheck}}, which is the same getty that gets launched on {{code|ttyS0}} in {{code|/etc/inittab}}: {{highlight|lang=terminal|code=
leo@fc:/home/leo/extracted/stage2/extracted% cat etc/inittab
::sysinit:/etc/init.d/rcS
::shutdown:/etc/init.d/shutdown
ttyS0::respawn:/usr/bin/serial_logincheck --login
}}
* There is an empty {{code|/etc/dropbear/authorized_keys}} file
* lighttpd runs with 'authorized_ips' set to 6.0.0.{2,10,11,12} and 127.0.0.1.
* Speed test script in {{code|/www}} downloads from 6.0.0.1.
* The Vitesse kernel module is at {{code|/lib/modules/jaguar/vtss_core.ko}}. Perhaps I can copy this and load it on the first stage kernel?
* {{code|usr/bin/config_updater}} writes to the NAND flash using {{code|nanddump}}, {{code|nandwrite}}, {{code|flash_erase}}, etc. This is probably the thing that phones home and interfaces with the {{code|switch_brain}}.
* {{code|/usr/bin/switch_brain}} seems to manage the switch hardware and services? Deals a lot with {{code|/click}} partition.
* The only mention of OpenWRT is the {{code|/etc/ipkg.conf}} file.
* {{code|/usr/bin/board_data_config}} gets or sets board config values. (mfg_done if set sets it to manufacturing mode).
* {{code|/usr/bin/odm}} is a script that does lots of diagnostic things including writing a new firmware.
* {{code|/usr/bin/serial_logincheck}} appears to lock the console down except if the switch is in manufacturing mode. Despite its threatening warning, it does not appear to actually log anything to the cloud.

Getting networking working in the stage1 kernel would be nice as it would allow me to easily copy files in and out of the switch. My shell scripts to copy data in/out reliably can only copy files at around 6-7kb/s. Since the kernel module for networking is probably part of the {{code|vtss_core.ko}}, I'll copy and then load the module.

Modules are loaded by the {{code|/etc/init.d/S10boot}} startup script. The type of CPU or board determines which module gets loaded. The MS220-8P board has the VSC7425 CPU which will load the {{code|luton26/vtss_core.ko}} module. The module is loaded with {{code|insmod}} provided by busybox inside a wrapper function called {{code|modload}}.

{{highlight|lang=terminal|code=
## Load vtss_core and unload the module without board_desc
insmod/lib/modules/$vtss_board/vtss_core.ko board_desc=$switch_board && modrm /lib/modules/$vtss_board/vtss_core.ko
}}

Of course, the kernel versions mismatch and there is no force option. Ugh.
{{highlight|lang=text|code=
[28928.328000] vtss_core: version magic '3.18.57-meraki-elemental mod_unload MIPS32_R2 32BIT ' should be '3.18.102-meraki-elemental mod_unload MIPS32_R2 32BIT '
}}

The next approach is just to modify the second stage initramfs so that the root account has a password set and the serial console isn't locked down.

Modifying the second stage boot image.

The image has another header. It looks like this time, the 32bit words are in big endian.

{|
! colspan="4" |
Boot Image Header
|-
| {{code|LOADER_MAGIC}} || {{code|Payload Address}} || {{code|Payload Length}} || {{code|SHA1}}
|-
| {{code|SHA1}} || {{code|SHA1}} || {{code|SHA1}} || {{code|SHA1}}
|-
| colspan="4" |
{{code|Empty Header Data}} until {{code|Payload Address}}
|}

{|
! colspan="4" |
Example Boot Header
|-
| {{code|8E 73 ED 8A}} || {{code|00 00 40 00}} || {{code|01 11 29 9C}} || {{code|6A 33 34 92}}
|-
| {{code|DA 33 DC 66 }} || {{code|36 1E C9 3C}} || {{code| FE DD D2 8C}} || {{code| EE 1E 33 ED}}
|-
| colspan="4" |
{{code|FF FF .. FF FF}} until {{code|Payload Address}}
|}

The SHA1 checksum is done against the payload only. If the hash is incorrect, {{code|kexec}} will tell you:
{{highlight|lang=terminal|code=
/ # kexec -ld /dev/mtdblock12
Try gzip decompression.
kernel: 0x76aff010 kernel_size: 0x140e800
meraki_part_mips: SHA1 doesn't match
}}

Erase and then flash the image on the NAND flash:
{{highlight|lang=terminal|code=
# flash_erase /dev/mtdchar/part1 0 0
# nandwrite -pam /dev/mtdchar/part1 firmware.bin
}}

The kernel can be loaded and executed once the SHA1 hash was fixed. My change to make the console run {{code|/bin/sh}} instead of the locked down console worked like a treat too.

{{highlight|lang=terminal|code=
[ 12.586000] UBIFS: reserved for root: 347364 bytes (339 KiB)
[ 12.592000] UBIFS: media format: w4/r0 (latest is w4/r0), UUID 2EA2ACA1-07FA-472B-BC2D-F0F2DB4314D3, small LPT model
In manufacturing: FALSE
In rma [ 12.615000] /initmode: FALSE
: reading file /storage/config: No such file or directory
init started: BusyBox v1.25.1 (2018-08-24 12:51:28 PDT)

BusyBox v1.25.1 (2018-08-24 12:51:28 PDT) built-in shell (ash)

/ # [ 13.515000] sysctl: error: 'kernel.softlockup_panic' is an unknown key
[ 13.523000] sysctl: error: 'kernel.watchdog_thresh' is an unknown key
[ 13.768000] sh: write error: Device or resource busy
[ 13.882000] vtss_core: module license '(c) Vitesse Semiconductor Inc.' taints kernel.
[ 13.890000] Disabling lock debugging due to kernel taint
[ 14.490000] switch: 'Meraki MS220-8' board detected
[ 14.837000] grep: /storage/config: No such file or directory
[ 15.446000] sysctl -w vm.panic_on_oom=2
[ 15.473000] vm.panic_on_oom = 2
[ 16.087000] click: starting router thread pid 745 (87bfca00)
[ 16.943000] Single synchronous check for reset
[ 17.252000]
[ 17.289000] boot 47 build switch-10-201808241214-G0a4ba17b-rel-owner board elemental mac 0C:8D:DB:7E:D7:76
[ 17.324000] Module: vtss_core .text=0xc1411000 .data=0xc14a90b0 .bss=0xc14a9320
[ 17.324000] Module: proclikefs .text=0xc007c000 .data= .bss=0xc007d040
[ 17.324000] Module: merakiclick .text=0xc182c000 .data=0xc197c800 .bss=0xc197ca80
[ 17.324000] Module: elts_meraki .text=0xc1f59000 .data=0xc224faa0 .bss=0xc22513d0
[ 17.324000] Module: vc_click .text=0xc23ba000 .data=0xc23ebfa0 .bss=0xc23ec130
[ 17.488000] ls -1 /sys/fs/pstore/dmesg-ramoops-* 2>/dev/null
[ 17.520000] /usr/bin/check_bootreason: reading file : No such file or directory
[ 20.336000] !!!!! {/usr/bin/switch_brain} opening /click/switch_port_table/dump_stack_info_and_reset_stack_change failed: No such file or directory
[ 22.423000] chatter: from_sw0 :: FromVitesse: initializing fdma
[ 23.566000] chatter: dhcp_tracker :: DHCPTracker: skipping undersized restore buffer (buf size: 0)
[ 24.918000] !!!!! {/usr/bin/switch_brain} failed writing /click/switch_port_table/set_port_storm_control errno 2 len 211 data: "PORT 1, ENABLED true\nPORT 2, ENABLED ..."
[ 25.884000] chatter: big_acl :: BigACL: skipping undersized restore buffer (buf size: 0)

/ #
/ #
}}

=== Other Failures ===
Here are a collection of failures when I tried various things.

==== Bad XZ Encoding ====
When building the ramdisk, you need to compress with {{code|-C crc32}} or else you will get this:
{{highlight|lang=terminal|code=
[ 0.106000] mkp_lg: Input was encoded with settings that are not supported by this XZ decoder
[ 0.106000] Kernel panic - not syncing: Input was encoded with settings that are not supported by this XZ decoder
[ 0.106000] Rebooting in 5 seconds..LinuxLoader built Nov 12 2014 18:01:50
}}

The first search result returned [https://forums.fogproject.org/topic/2819/custom-boot-image this post] which suggested compressing the archive using {{code|xz -C crc32 -z -c init > init.xz}}.

==== Misaligning Ramdisk in Boot Image ====
If you misalign the embedded ramdisk, the kernel won't be able to mount it but the kernel will print out all the block devices it sees. Fix this by making sure the ramdisk is exactly the same size as the original.

{{highlight|lang=terminal|code=
[ 2.544000] devtmpfs: error mounting -2
[ 2.548000] Warning: unable to open an initial console.
[ 2.555000] VFS: Cannot open root device "(null)" or unknown-block(0,0): error -2
[ 2.563000] Please append a correct "root=" boot option; here are the available partitions:
[ 2.571000] 1f00 131072 mtdblock0 (driver?)
[ 2.576000] 1f01 256 mtdblock1 (driver?)
[ 2.582000] 1f02 3840 mtdblock2 (driver?)
[ 2.587000] 1f03 256 mtdblock3 (driver?)
[ 2.592000] 1f04 3840 mtdblock4 (driver?)
[ 2.597000] 1f05 512 mtdblock5 (driver?)
[ 2.602000] 1f06 6144 mtdblock6 (driver?)
[ 2.607000] 1f07 256 mtdblock7 (driver?)
[ 2.613000] 1f08 1024 mtdblock8 (driver?)
[ 2.618000] 1f09 256 mtdblock9 (driver?)
[ 2.623000] 1f0a 126 mtdblock10 (driver?)
[ 2.628000] 1f0b 536 mtdblock11 (driver?)
[ 2.633000] 1f0c 20538 mtdblock12 (driver?)
[ 2.639000] 1f0d 20538 mtdblock13 (driver?)
[ 2.644000] 1f0e 8316 mtdblock14 (driver?)
[ 2.649000] 1f0f 2095 mtdblock15 (driver?)
[ 2.654000] 1f10 2632 mtdblock16 (driver?)
[ 2.660000] 1f11 2242 mtdblock17 (driver?)
[ 2.665000] 1f12 2223 mtdblock18 (driver?)
[ 2.670000] 1f13 2671 mtdblock19 (driver?)
[ 2.675000] 1f14 2681 mtdblock20 (driver?)
[ 2.681000] 1f15 2674 mtdblock21 (driver?)
[ 2.686000] mkp_lg: VFS: Unable to mount root fs on unknown-block(0,0)
[ 2.686000] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
[ 2.686000] Rebooting in 5 seconds..
}}

==== Failed Attempt at Expanding the Ramdisk ====
The smallest shell I can find is the busybox 1.20 version at 1.5MB. This will cause the archive to be larger than the original which will screw with how the archive gets loaded if I just dump the data in. The data immediately after the archive is also a concern since I have no clue what it is or what it does. My obervation is that immediately after the end of the archive data, there is a 32bit word containing the length of the archive data, followed by some data, padded by 00's to the next 16byte. So, I swapped the archive data out with the larger version with busybox, rewrote the 32bit word to the new length, updated the data length at the start of the boot image as well as the CRC32 code and tried booting it. No go, with the following error:

{{highlight|lang=terminal|code=
[ 0.106000] mkp_lg: compression method <<▒i=▒▒R;▒,▒C▒8▒C▒\▒C▒x▒C▒▒▒C▒ not configu
[ 0.106000] Kernel panic - not syncing: compression method <<▒i=▒▒R;▒,▒C▒8▒C▒\▒C▒x▒C▒▒▒C▒ not configu
[ 0.106000] Rebooting in 5 seconds..LinuxLoader built Nov 12 2014 18:01:50
}}

==== Serial Speed ====

You can raise the serial speed, but anything higher than the default 115200 baud seems to be unstable for me and it ends up corrupting data.
{{highlight|lang=terminal|code=
/ # stty -F /dev/ttyS0 921600
/ # dmesg -n 1
}}