I hadn’t look at Dell’s iDRAC stuff in forever… and it appeared they’d changed some of the formatting of the iDRAC updates/etc. since then. I didn’t see anything out there, so here’s what I used.
First, grab an update – for instance, at – https://www.dell.com/support/home/en-us/drivers/driversdetails?driverid=wn31m – I grabbed “iDRAC-with-Lifecycle-Controller_Firmware_WN31M_LN64_7.20.30.50_A00.BIN”
On the windows EXE file at the same URL you can just use `binwalk`… they supply a shell script for linux, so I tossed at claude to quickly modify their script to create – “extract_files.sh” (attached). This spits out a bunch of files, but the one of interest to me was “firmimgFIT.d9”.
After a `binwalk` in the park, I get various other files, including the big one in: “extractions/firmimgFIT.d9.extracted/0/system.dtb”.
firmimgFIT.d9
———————————————————————————————————————————————-
DECIMAL HEXADECIMAL DESCRIPTION
———————————————————————————————————————————————-
0 0x0 Device tree blob (DTB), version: 17, CPU ID: 0, total size: 236314605
bytes
236314861 0xE15E0ED PEM certificate
236317109 0xE15E9B5 PEM certificate
236318951 0xE15F0E7 PEM certificate
236320444 0xE15F6BC PEM certificate
236321937 0xE15FC91 PEM certificate
———————————————————————————————————————————————-
[+] Extraction of dtb data at offset 0x0 completed successfully
[+] Extraction of pem_certificate data at offset 0xE15E0ED completed successfully
[+] Extraction of pem_certificate data at offset 0xE15E9B5 completed successfully
[+] Extraction of pem_certificate data at offset 0xE15F0E7 completed successfully
[+] Extraction of pem_certificate data at offset 0xE15F6BC completed successfully
[+] Extraction of pem_certificate data at offset 0xE15FC91 completed successfully
———————————————————————————————————————————————-
Analyzed 1 file for 85 file signatures (187 magic patterns) in 12.5 seconds
Ok, time for a 2nd program… I’d never really worked with DTDs before, and presumably due to my ignorance, what I tried failed. So off to claude again, and we (this one took a lot of beating on claude to get right, but we got there) created a simple sort-of-DTD-extractor/ripper/scalpel – “dtd-rip.py” (also attached.)
The DTB files were simply text, contain information on various bits found in the DTB, including hex-encoded image files – for instance, here’s how the file starts –
timestamp = <0x65b04580>;
description = "IDRAC multi-image firmware Container";
#address-cells = <0x01>;
SPB = "02000000000000000000FF01F97F9FA1CE1F0038E979FCC11600000000000000";
EFB = "7E00000000000000000000000000000000000000000000000000000000000000";
imageType = "1";
boardType = "DRB";
IDRACVer = "7.0a.1e.1e.00";
U-BootVer = "201510.4.6.0.6";
PDSVer = "1e";
LCVer = "00";
images {
mbr.bin@1 {
data = <0xfab80010 0x8ed0bc00 0xb0b80000 0x8ed88ec0 0xfbbe007c 0xbf0006b9 0x2f3a4 0xea210600 0xbebe07 0x3804750b 0x83c61081 0xfefe0775 0xf3eb16b4 0x2b001bb 0x7cb280 0x8a74018b 0x4c02cd13 0xea007c00 0xebfe00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x44454c4c 0x8001 0x45e88303 0xe0ff0000 0x3000000 0x8000003 0xe0ff8303 0xe0ff0000 0xb000000 0x8000003 0xe0ff8303 0xe0ff0000 0x1300cccc 0x6c000000 0x00 0x00 0x00 0x55aa>;
type = "firmware";
arch = "arm";
os = "linux";
compression = "none";
layDown = "AsIs";
destination = "eMMC,FWP,/";
load = <0x00>;
description = "Master Boot Record";
hash@1 {
value = <0xd419e2ae 0xad62f74c 0x2a055ff7 0xb30db7ca 0x14035ef2 0x9797824f 0x73475e07 0x27154a60>;
algo = "sha256";
};
};
When my script found a key/value with “data” as the key, it’d take the hex, decode it (“0x00” blows up to “0x00000000”), and saves it to a file. It also checks the hash of images with hashes found (at least, they were there for all the ones I tested.)
After running the script I had –
This in turn blew up a bunch of files – including the MBR, some squashfs filesystems, the u-boot image, etc.
configurations_config@1_signature@1.txt images_mbr.bin@1_hash@1.txt images_recovery.itb@1_hash@1.txt
configurations_config@1.txt images_mbr.bin@1.data images_recovery.itb@1.data
configurations.txt images_mbr.bin@1.txt images_recovery.itb@1.txt
dtb-rip.py images_md.itb@1_hash@1.txt images_rootfs.squashfs@1_hash@1.txt
images_fecDevice@1_hash@1.txt images_md.itb@1.txt images_rootfs.squashfs@1.data
images_fecDevice@1.data images_PDfecDevice@1_hash@1.txt images_rootfs.squashfs@1.txt
images_fecDevice@1.txt images_PDfecDevice@1.data images_rootfsHashTree@1_hash@1.txt
images_kmipclient.squashfs@1_hash@1.txt images_PDfecDevice@1.txt images_rootfsHashTree@1.data
images_kmipclient.squashfs@1.data images_PDHashTree@1_hash@1.txt images_rootfsHashTree@1.txt
images_kmipclient.squashfs@1.txt images_PDHashTree@1.data images_u-boot@1_hash@1.txt
images_KMIPfecDevice@1_hash@1.txt images_PDHashTree@1.txt images_u-boot@1.data
images_KMIPfecDevice@1.data images_pdtb.itb@1_hash@1.txt images_u-boot@1.txt
images_KMIPfecDevice@1.txt images_pdtb.itb@1.txt images.txt
images_KMIPHashTree@1_hash@1.txt images_platform_data.squashfs@1_hash@1.txt system.dtb
images_KMIPHashTree@1.data images_platform_data.squashfs@1.data
images_KMIPHashTree@1.txt images_platform_data.squashfs@1.txt
FINALLY, some filesystems unveiled! A quick unsquash on the two with data (the “kmipclient” one was empty), revealed some BMC gold.
I had to modify `unsquashfs` to ignore some errors, or it kept failing part of the way through (what could go wrong, lol.)
Parallel unsquashfs: Using 8 processors
804 inodes (5174 blocks) to write
write_xattr: could not write xattr security.selinux for file platform/Abilene/backplane/bmc_bp_config.json because you’re not superuser!
write_xattr: to avoid this error message, either specify -xattrs-include ‘^user.’, -no-xattrs, or run as superuser!
Further error messages of this type are suppressed!
[===========================================================================================================================|] 5978/5978 100%
created 804 files
created 610 directories
created 0 symlinks
created 0 devices
created 0 fifos
created 0 sockets
created 0 hardlinks
/usr/local/bin/unsquashfs -d rootfs2 ‘images_rootfs.squashfs@1.data’
Parallel unsquashfs: Using 8 processors
17674 inodes (17525 blocks) to write
write_xattr: could not write xattr security.selinux for file rootfs2/bin/AppThermalSHM because you’re not superuser!
write_xattr: to avoid this error message, either specify -xattrs-include ‘^user.’, -no-xattrs, or run as superuser!
Further error messages of this type are suppressed!
[================================- ] 8565/35199 24%create_inode: failed to create hardlink
create_inode: failed to create hardlink
create_inode: failed to create hardlink
create_inode: failed to create hardlink
create_inode: failed to create hardlink
[===========================================\ ] 11591/35199 32%write_file: file rootfs2/usr/lib/xtables/libip6t_hl.so already exists
write_file: file rootfs2/usr/lib/xtables/libipt_ttl.so already exists
write_file: file rootfs2/usr/lib/xtables/libxt_connmark.so already exists
write_file: file rootfs2/usr/lib/xtables/libxt_dscp.so already exists
write_file: file rootfs2/usr/lib/xtables/libxt_mark.so already exists
write_file: file rootfs2/usr/lib/xtables/libxt_rateest.so already exists
write_file: file rootfs2/usr/lib/xtables/libxt_set.so already exists
write_file: file rootfs2/usr/lib/xtables/libxt_tcpmss.so already exists
write_file: file rootfs2/usr/lib/xtables/libxt_tos.so already exists
[===================================================================================================================================- ] 35193/35199 99%
created 15833 files
created 880 directories
created 1744 symlinks
created 0 devices
created 0 fifos
created 0 sockets
created 91 hardlinks
And finally, after too many steps, there are the files….
2843543 0 drwxr-xr-x 24 zen wheel 768 Apr 5 2011 rootfs2/
2848428 0 dr-xr-xr-x 2 zen wheel 64 Apr 5 2011 rootfs2/proc
2847172 0 drwxr-xr-x 6 zen wheel 192 Apr 5 2011 rootfs2/home
2847176 0 drwxr-xr-x 4 zen wheel 128 Apr 5 2011 rootfs2/home/fwupdate
2847177 8 -rwx—— 1 zen wheel 410 Apr 5 2011 rootfs2/home/fwupdate/.bashrc
2847178 8 -rwx—— 1 zen wheel 241 Apr 5 2011 rootfs2/home/fwupdate/.profile
2847180 0 drwx—— 2 zen wheel 64 Apr 5 2011 rootfs2/home/root
2847179 0 drwxr-xr-x 2 zen wheel 64 Apr 5 2011 rootfs2/home/recman
2847173 0 drwxr-xr-x 4 zen wheel 128 Apr 5 2011 rootfs2/home/apache
2847174 8 -rwx—— 1 zen wheel 410 Apr 5 2011 rootfs2/home/apache/.bashrc
2847175 8 -rwx—— 1 zen wheel 241 Apr 5 2011 rootfs2/home/apache/.profile
2848560 0 drwxr-xr-x 12 zen wheel 384 Apr 5 2011 rootfs2/usr
2848561 0 drwxr-xr-x 1062 zen wheel 33984 Apr 5 2011 rootfs2/usr/bin
2849051 232 -rwx—— 1 zen wheel 115520 Apr 5 2011 rootfs2/usr/bin/jupdate
2849121 40 -rwx—— 1 zen wheel 19716 Apr 5 2011 rootfs2/usr/bin/lttctl
2849319 24 -rwx—— 1 zen wheel 11604 Apr 5 2011 rootfs2/usr/bin/rdfs_test
2848885 88 -rwx—— 1 zen wheel 43880 Apr 5 2011 rootfs2/usr/bin/flopcpldupd
2849382 144 -rwx—— 1 zen wheel 70020 Apr 5 2011 rootfs2/usr/bin/scvInventoryService
2849542 32 -rwx—— 1 zen wheel 13812 Apr 5 2011 rootfs2/usr/bin/systemd-detect-virt
2849104 48 -rwx—— 1 zen wheel 23480 Apr 5 2011 rootfs2/usr/bin/localectl
Full `find` output here.
Leave a Reply
You must be logged in to post a comment.