[{"content":"I currently own two Hikey development boards from 96boards.org. A 1GB and 2GB board, respectively. Recently I got to thinking as I was scanning through the schematics and hi6220 datasheet about the capabilities of the MMC controller. I discovered the Hikey has an DWC (Designware) MMC controller, which is very common on single-board computers, and found that the device supports eMMC up to version 4.5. The board itself supports up to HS200 mode and 150 MHz clock. As I sifted through the device tree for the board (based on my own mainline kernel, but is reflective of their current releases), the device tree was only setup for high-speed mode, and seemed to have 3.3v signaling enabled, whereas the board is capable of HS200 and 1.8v signaling, especially considering the signal lines are connected to LDO5_1V8. We can see that with the default device tree, the card is running in high-speed mode at 52 MHz. You\u0026rsquo;ll also notice that I have a 32GB eMMC chip on my Hikey, which I\u0026rsquo;ll touch on later ;) If we take a look at the device tree, we can see we are missing some important properties to reach the full potential of the eMMC and the board: Let\u0026rsquo;s take a quick peek at the device tree documentation for the MMC bindings: Here we find the missing culprits: mmc-hs200-1_8v and the paramter max-frequency (I\u0026rsquo;m not sure if this is necessary, but the hi6220 datasheet explicitly mentions the maximum frequency is 150 MHz for the controller, so I\u0026rsquo;ll be safe.) Before we add these parameters, let\u0026rsquo;s get a quick and dirty benchmark of the current mode: So we are looking at about 26 MB/s. While this isn\u0026rsquo;t a perfect or ideal benchmark, it\u0026rsquo;s good enough to get an idea of the transfer rate. Let\u0026rsquo;s give it a shot with our new parameters in the device tree, recompile the kernel, and see what happens: We can see the card was successfully detected in HS200 mode instead of the default high-speed mode. Wow! So now we\u0026rsquo;re looking at about 36 MB/s! That\u0026rsquo;s a pretty significant improvement. We can see the signal voltage is at 1.8v and the clock running at 150 MHz. I\u0026rsquo;m not sure why this hasn\u0026rsquo;t been enabled by default, but I\u0026rsquo;ve seen no issues or stability problems as a result. This is one of my favorite development boards, but I felt a little restricted by the 8GB eMMC\u0026hellip; I had an SMD rework station sitting around and a couple spare eMMC chips I had from old devices and eBay. This board came with the KLMBG1GEAC chip (8GB Samsung eMMC), and I just so happened to have a KLMBG4GEAC (32GB) sitting around, so I figured why not give it a shot\u0026hellip; As you can see, my impatience and inexperience led to damaging some of the pads. I was incredibly, lucky, as all of these pads were \u0026ldquo;NC\u0026rdquo; or not connected and not used, with the exception of two. They are in the inner square of pads in the bottom left corner. I had damaged a Vcc and Vss pad. Another stroke of luck, there are quite a few redundant grounds, and three other Vcc, which are tied together internally, which meant I could get by just fine without the damaged Vcc and Vss. Lesson learned, use tighter temperature profile, and have a little more patience in removal. After flattening the pads out with some flux and desoldering braid, then a touch up of isopropyl, I spent about 20 minutes trying to line the new eMMC chip up just perfectly (much more frustrating than you\u0026rsquo;d imagine\u0026hellip;) After a few minutes of heat (slowly working my way up from ~180c, always preheat the board, it helps) I cooked the eMMC chip at around ~260-280c. I carefully watched for the chip to \u0026ldquo;drop\u0026rdquo; into place, when the solder balls melt and attach to the pads. I kept some heat on it for about 20-30 seconds after that occurred to ensure even and thorough heating. Afterwards, I allowed the chip to cool down and gave it some time to relax. My next concern (in hindsight) was that I needed to enable HWRESET in the ExtCSD of the chip, so the Hikey could properly initialize the chip, in addition to enabling the BOOT1 partition for booting in 8-bit mode. After some careful research, I discovered that the \u0026rsquo;l-loader\u0026rsquo; used to burn the chip did this for me, which was a big relief. I made sure to backup a few of the partitions from the old chip like \u0026lsquo;vrl\u0026rsquo;, \u0026lsquo;vrl_backup\u0026rsquo;, and \u0026lsquo;mcuimage\u0026rsquo;, and was able to flash those through the l-loader fastboot. Thereafter, I flashed the UEFI/boot partition and system partition with the 16.06 Debian release, and sure enough, it booted right up. I believe that makes this the first 32GB Hikey board! I\u0026rsquo;m very pleased with this new chip and the speed I\u0026rsquo;ve been able to squeeze out of it with HS200 and hope you find this information useful too!\n","permalink":"https://movr0.com/posts/96boards-hikey-emmc-hacks/","summary":"\u003cp\u003eI currently own two Hikey development boards from 96boards.org. A 1GB and 2GB board, respectively. Recently I got to thinking as I was scanning through the schematics and hi6220 datasheet about the capabilities of the MMC controller. I discovered the Hikey has an DWC (Designware) MMC controller, which is very common on single-board computers, and found that the device supports eMMC up to version 4.5. The board itself supports up to HS200 mode and 150 MHz clock. As I sifted through the device tree for the board (based on my own mainline kernel, but is reflective of their current releases), the device tree was only setup for high-speed mode, and seemed to have 3.3v signaling enabled, whereas the board is capable of HS200 and 1.8v signaling, especially considering the signal lines are connected to LDO5_1V8. \u003ca href=\"/images/2017/09/hikey_emmc_schematic.png\"\u003e\u003cimg loading=\"lazy\" src=\"/images/2017/09/hikey_emmc_schematic.png\"\u003e\u003c/a\u003e We can see that with the default device tree, the card is running in high-speed mode at 52 MHz. You\u0026rsquo;ll also notice that I have a \u003cstrong\u003e32GB\u003c/strong\u003e eMMC chip on my Hikey, which I\u0026rsquo;ll touch on later ;) \u003ca href=\"/images/2017/09/hs_mode.png\"\u003e\u003cimg loading=\"lazy\" src=\"/images/2017/09/hs_mode.png\"\u003e\u003c/a\u003e If we take a look at the device tree, we can see we are missing some important properties to reach the full potential of the eMMC and the board: \u003ca href=\"/images/2017/09/dt_dwmmc.png\"\u003e\u003cimg loading=\"lazy\" src=\"/images/2017/09/dt_dwmmc.png\"\u003e\u003c/a\u003e Let\u0026rsquo;s take a quick peek at the device tree documentation for the MMC bindings: \u003ca href=\"/images/2017/09/mmc_bindings.png\"\u003e\u003cimg loading=\"lazy\" src=\"/images/2017/09/mmc_bindings.png\"\u003e\u003c/a\u003e Here we find the missing culprits: mmc-hs200-1_8v and the paramter max-frequency (I\u0026rsquo;m not sure if this is necessary, but the hi6220 datasheet explicitly mentions the maximum frequency is 150 MHz for the controller, so I\u0026rsquo;ll be safe.) Before we add these parameters, let\u0026rsquo;s get a quick and dirty benchmark of the current mode: \u003ca href=\"/images/2017/09/hs_info.png\"\u003e\u003cimg loading=\"lazy\" src=\"/images/2017/09/hs_info.png\"\u003e\u003c/a\u003e \u003ca href=\"/images/2017/09/old_benchmark.png\"\u003e\u003cimg loading=\"lazy\" src=\"/images/2017/09/old_benchmark.png\"\u003e\u003c/a\u003e So we are looking at about 26 MB/s. While this isn\u0026rsquo;t a perfect or ideal benchmark, it\u0026rsquo;s good enough to get an idea of the transfer rate. Let\u0026rsquo;s give it a shot with our new parameters in the device tree, recompile the kernel, and see what happens: \u003ca href=\"/images/2017/09/new_hs200_mode.png\"\u003e\u003cimg loading=\"lazy\" src=\"/images/2017/09/new_hs200_mode.png\"\u003e\u003c/a\u003e We can see the card was successfully detected in HS200 mode instead of the default high-speed mode. \u003ca href=\"/images/2017/09/hs200_info.png\"\u003e\u003cimg loading=\"lazy\" src=\"/images/2017/09/hs200_info.png\"\u003e\u003c/a\u003e \u003ca href=\"/images/2017/09/hs200_benchmark.png\"\u003e\u003cimg loading=\"lazy\" src=\"/images/2017/09/hs200_benchmark.png\"\u003e\u003c/a\u003e Wow! So now we\u0026rsquo;re looking at about 36 MB/s! That\u0026rsquo;s a pretty significant improvement. We can see the signal voltage is at 1.8v and the clock running at 150 MHz. I\u0026rsquo;m not sure why this hasn\u0026rsquo;t been enabled by default, but I\u0026rsquo;ve seen no issues or stability problems as a result. This is one of my favorite development boards, but I felt a little restricted by the 8GB eMMC\u0026hellip; I had an SMD rework station sitting around and a couple spare eMMC chips I had from old devices and eBay. This board came with the KLMBG1GEAC chip (8GB Samsung eMMC), and I just so happened to have a KLMBG4GEAC (32GB) sitting around, so I figured why not give it a shot\u0026hellip; \u003ca href=\"/images/2017/09/emmc_removal.jpg\"\u003e\u003cimg loading=\"lazy\" src=\"/images/2017/09/emmc_removal.jpg\"\u003e\u003c/a\u003e As you can see, my impatience and inexperience led to damaging some of the pads. I was incredibly, lucky, as all of these pads were \u0026ldquo;NC\u0026rdquo; or not connected and not used, with the exception of two. They are in the inner square of pads in the bottom left corner. I had damaged a Vcc and Vss pad. Another stroke of luck, there are quite a few redundant grounds, and three other Vcc, which are tied together internally, which meant I could get by just fine without the damaged Vcc and Vss. Lesson learned, use tighter temperature profile, and have a little more patience in removal. After flattening the pads out with some flux and desoldering braid, then a touch up of isopropyl, I spent about 20 minutes trying to line the new eMMC chip up just perfectly (much more frustrating than you\u0026rsquo;d imagine\u0026hellip;) \u003ca href=\"/images/2017/09/new_emmc.jpg\"\u003e\u003cimg loading=\"lazy\" src=\"/images/2017/09/new_emmc.jpg\"\u003e\u003c/a\u003e After a few minutes of heat (slowly working my way up from ~180c, always preheat the board, it helps) I cooked the eMMC chip at around ~260-280c. I carefully watched for the chip to \u0026ldquo;drop\u0026rdquo; into place, when the solder balls melt and attach to the pads. I kept some heat on it for about 20-30 seconds after that occurred to ensure even and thorough heating. Afterwards, I allowed the chip to cool down and gave it some time to relax. My next concern (in hindsight) was that I needed to enable HWRESET in the ExtCSD of the chip, so the Hikey could properly initialize the chip, in addition to enabling the BOOT1 partition for booting in 8-bit mode. After some careful research, I discovered that the \u0026rsquo;l-loader\u0026rsquo; used to burn the chip did this for me, which was a big relief. I made sure to backup a few of the partitions from the old chip like \u0026lsquo;vrl\u0026rsquo;, \u0026lsquo;vrl_backup\u0026rsquo;, and \u0026lsquo;mcuimage\u0026rsquo;, and was able to flash those through the l-loader fastboot. Thereafter, I flashed the UEFI/boot partition and system partition with the 16.06 Debian release, and sure enough, it booted right up. I believe that makes this the first 32GB Hikey board! I\u0026rsquo;m very pleased with this new chip and the speed I\u0026rsquo;ve been able to squeeze out of it with HS200 and hope you find this information useful too!\u003c/p\u003e","title":"96boards Hikey eMMC hacks!"},{"content":"Recently, I purchased an Odroid-C2. This is a great little single-board computer by Hardkernel The device has an Amlogic S905 SoC. Complete with a quad-core Cortex-A53 @ 1.5Ghz, 2GB DDR3 RAM, and gigabit ethernet. It\u0026rsquo;s quite a powerful little board with plenty of GPIO and RAM to work with. My favorite part about this board is the eMMC connector on-board, which blows away even UHS-1 MicroSD speed. This makes it a heavy competitor to the Raspberry Pi 3 in my opinion. One of the first things I do when I get a new piece of hardware is identify the debug ports. A molex UART connector is available on most/all of Hardkernel\u0026rsquo;s products. However, sometimes debugging more in-depth is required, especially since this board is still stuck on the 3.14 kernel. Progress is being made to bring it up to 4.y, but it will be some time before all the drivers are finished. I had recently been reading an article about a vulnerability and exploit on the Amlogic S905 chipset here and found the lack of any authentication for secure boot beyond a simple SHA256 hash. The author of the article was able to dump the bootrom of the chip using this vulnerability. He had written a kernel module for issuing SMC calls to their implementation of TrustZone. Upon inspecting the u-boot source for this device, I discovered a good amount of the command IDs for various trusted functions. One that stuck out to me was for enabling JTAG. All the 0x820000xx values are command IDs for TrustZone. This is only a partial list of those that exist. The command simply issues an SMC call to TrustZone to enable one of four different TAPs. Two were power domains or system fabric possibly (still haven\u0026rsquo;t figured it out.) The other two were the Cortex-A53 (the main processor) and a Cortex-M3 (possibly a secure coprocessor? System Control and Power) However, with little to nonexistent documentation, I felt it would be a good place to poke around this lesser known chip. Now, if you ask around the Odroid community, they\u0026rsquo;ll tell you that JTAG is only available through the SDIO pins using a special debug board. I had seen these before, but figured a quick look at the schematics would be worthwhile to see if there was another option rather than build this. A quick scan through the schematic revealed that TMS, TDO, TDI, and TCK were also routed to the I2S pins (which happen to have a header on this board, next to the heatsink.) I decided to connect those pins up to my JTAG adapter and give it a shot. No such luck. These are multi-function pins with a muxer, so I assumed maybe I hadn\u0026rsquo;t set the right alternative function on them. Another scan through the documentation revealed no information other than the pins exist. The documentation referred to a section that was omitted from the public datasheet. No matter, we\u0026rsquo;ll find a way. Using my UART console in u-boot, I tried using the command \u0026lsquo;jtagon apao\u0026rsquo; which according to the comments in the code, should enable the Cortex-A53 DAP. Sure enough, that did the trick, and the A53 was now exposed. I was unable to actually halt the chip or inspect the chain successfully, for reasons I am unsure of at this point (could be security related, I know it\u0026rsquo;s possible to enable a password on the TAPs to prevent debugging. issue was lack of ARMv8 support for OpenOCD and missing -ctibase since ARMv8 debugging requires CTI information for halt and resume) After repeated failed attempts to initialize the debug port on the A53, I decided to take a look at the other tap, the \u0026lsquo;SCP\u0026rsquo; chip. I rebooted back into u-boot and issued the command \u0026lsquo;jtagon scpao\u0026rsquo; and the Cortex-M3 DAP appeared. My first attempt, I was able to halt the chip! From this TAP, I could see the bootrom and I believe BL301 (this chip uses the standard ARM trusted firmware scheme.) Certain secure areas of memory were still inaccessible, which resulted in a reboot or lockup. To reiterate, all the JTAG command was doing in u-boot was issuing a simple SMC command, so I asked myself why I couldn\u0026rsquo;t enable this while the device was booted into Linux. Circling back to the S905 post about a secure boot vulnerability, the author wrote a debugfs driver that allows passing SMC calls. I realized a simple rewrite of this code would result in me being able to enable JTAG from Linux. You can see what I did here. (Inline assembly can be painful sometimes\u0026hellip;) Upon my first try with the SCP chip, I was able to connect and halt right away. Unfortunately I still haven\u0026rsquo;t been able to connect the A53, or fully understand the purpose of the \u0026lsquo;SCP\u0026rsquo; processor, but I had made some headway. When I get some free time (rare these days) I will take a look at the password checking mechanism, and if enabled, the password should be in the efuses. I\u0026rsquo;m hoping this post will serve as a resource for those looking to do JTAG debugging on this board or SoC, and possibly get it working. If you have any questions or comments, feel free to leave them in the comment section! UPDATE: I was able to start debugging the Cortex-A53 on this board using some ARMv8 patches for OpenOCD. It\u0026rsquo;s still experimental at this moment, but generally works well. The issue was related to lack of ARMv8/DAP support in OpenOCD. Since then, I can successfully halt and resume, and read memory. One side note, I\u0026rsquo;ve discovered that SCP stands for \u0026lsquo;System Control and Power\u0026rsquo; which is pretty self-explanatory.\nHere is my config for the Cortex-A53 :\n############# config ################ adapter_khz 2000 debug_level 2 reset_config none gdb_target_description disable �if { [info exists CHIPNAME] } { set _CHIPNAME $CHIPNAME } else { set _CHIPNAME aml } if { [info exists DAP_TAPID] } { set _DAP_TAPID $DAP_TAPID } else { set _DAP_TAPID 0x5ba00477 } jtag newtap $_CHIPNAME dap -irlen 4 -ircapture 0x1 -irmask 0x03 -expected-id $_DAP_TAPID set _TARGETNAME $_CHIPNAME.cpu0 target create $_TARGETNAME aarch64 -chain-position $_CHIPNAME.dap -coreid 0 -dbgbase 0x80410000 -ctibase 0x80420000 #set _TARGETNAME $_CHIPNAME.cpu1 #target create $_TARGETNAME aarch64 -chain-position $_CHIPNAME.dap -coreid 1 -dbgbase 0x80510000 -ctibase 0x80520000 #set _TARGETNAME $_CHIPNAME.cpu2 #target create $_TARGETNAME aarch64 -chain-position $_CHIPNAME.dap -coreid 2 -dbgbase 0x80610000 -ctibase 0x80620000 #set _TARGETNAME $_CHIPNAME.cpu3 #target create $_TARGETNAME aarch64 -chain-position $_CHIPNAME.dap -coreid 3 -dbgbase 0x80710000 -ctibase 0x80720000 init aarch64 dbginit And for the Cortex-M3 (System Control and Power)\n############# config ################ adapter_khz 4000 debug_level 2 reset_config none jtag newtap aml dap -irlen 4 -ircapture 0x1 -irmask 0x03 -expected-id 0x4ba00477 -enable target create aml.cpu cortex_m -chain-position aml.dap -coreid 0 ","permalink":"https://movr0.com/posts/finding-jtag-on-the-odroid-c2/","summary":"\u003cp\u003eRecently, I purchased an Odroid-C2. This is a great little single-board computer by \u003ca href=\"http://www.hardkernel.com/main/products/prdt_info.php?g_code=G145457216438\"\u003eHardkernel\u003c/a\u003e The device has an Amlogic S905 SoC. Complete with a quad-core Cortex-A53 @ 1.5Ghz, 2GB DDR3 RAM, and gigabit ethernet. It\u0026rsquo;s quite a powerful little board with plenty of GPIO and RAM to work with. My favorite part about this board is the eMMC connector on-board, which blows away even UHS-1 MicroSD speed. This makes it a heavy competitor to the Raspberry Pi 3 in my opinion. One of the first things I do when I get a new piece of hardware is identify the debug ports. A molex UART connector is available on most/all of Hardkernel\u0026rsquo;s products. However, sometimes debugging more in-depth is required, especially since this board is still stuck on the 3.14 kernel. Progress is being made to bring it up to 4.y, but it will be some time before all the drivers are finished. I had recently been reading an article about a vulnerability and exploit on the Amlogic S905 chipset \u003ca href=\"http://www.fredericb.info/2016/10/amlogic-s905-soc-bypassing-not-so.html\"\u003ehere\u003c/a\u003e and found the lack of any authentication for secure boot beyond a simple SHA256 hash. The author of the article was able to dump the bootrom of the chip using this vulnerability. He had written a kernel module for issuing SMC calls to their implementation of TrustZone. Upon inspecting the u-boot source for this device, I discovered a good amount of the command IDs for various trusted functions. One that stuck out to me was for enabling JTAG. All the 0x820000xx values are command IDs for TrustZone. This is only a partial list of those that exist. \u003ca href=\"/images/2016/12/Screenshot-5.png\"\u003e\u003cimg loading=\"lazy\" src=\"/images/2016/12/Screenshot-5.png\"\u003e\u003c/a\u003e The command simply issues an SMC call to TrustZone to enable one of four different TAPs. Two were power domains or system fabric possibly (still haven\u0026rsquo;t figured it out.) The other two were the Cortex-A53 (the main processor) and a Cortex-M3 (\u003cdel\u003epossibly a secure coprocessor?\u003c/del\u003e System Control and Power) However, with little to nonexistent documentation, I felt it would be a good place to poke around this lesser known chip. Now, if you ask around the Odroid community, they\u0026rsquo;ll tell you that JTAG is only available through the SDIO pins using a special debug board. I had seen these before, but figured a quick look at the schematics would be worthwhile to see if there was another option rather than build this. \u003ca href=\"/images/2016/12/Screenshot-2.png\"\u003e\u003cimg loading=\"lazy\" src=\"/images/2016/12/Screenshot-2.png\"\u003e\u003c/a\u003e A quick scan through the schematic revealed that TMS, TDO, TDI, and TCK were also routed to the I2S pins (which happen to have a header on this board, next to the heatsink.) \u003ca href=\"/images/2016/12/Screenshot-4.png\"\u003e\u003cimg loading=\"lazy\" src=\"/images/2016/12/Screenshot-4.png\"\u003e\u003c/a\u003e I decided to connect those pins up to my JTAG adapter and give it a shot. No such luck. These are multi-function pins with a muxer, so I assumed maybe I hadn\u0026rsquo;t set the right alternative function on them. Another scan through the documentation revealed no information other than the pins exist. The documentation referred to a section that was omitted from the public datasheet. No matter, we\u0026rsquo;ll find a way. Using my UART console in u-boot, I tried using the command \u0026lsquo;jtagon apao\u0026rsquo; which according to the comments in the code, should enable the Cortex-A53 DAP. Sure enough, that did the trick, and the A53 was now exposed. I was unable to actually halt the chip or inspect the chain successfully, for reasons I am unsure of at this point (\u003cdel\u003ecould be security related, I know it\u0026rsquo;s possible to enable a password on the TAPs to prevent debugging.\u003c/del\u003e issue was lack of ARMv8 support for OpenOCD and missing -ctibase since ARMv8 debugging requires CTI information for halt and resume) \u003ca href=\"/images/2016/12/Screenshot-3.png\"\u003e\u003cimg loading=\"lazy\" src=\"/images/2016/12/Screenshot-3.png\"\u003e\u003c/a\u003eAfter repeated failed attempts to initialize the debug port on the A53, I decided to take a look at the other tap, the \u0026lsquo;SCP\u0026rsquo; chip. I rebooted back into u-boot and issued the command \u0026lsquo;jtagon scpao\u0026rsquo; and the Cortex-M3 DAP appeared. My first attempt, I was able to halt the chip! From this TAP, I could see the bootrom and I believe BL301 (this chip uses the standard ARM trusted firmware scheme.) Certain secure areas of memory were still inaccessible, which resulted in a reboot or lockup. To reiterate, all the JTAG command was doing in u-boot was issuing a simple SMC command, so I asked myself why I couldn\u0026rsquo;t enable this while the device was booted into Linux. Circling back to the S905 post about a secure boot vulnerability, the author wrote a debugfs driver that allows passing SMC calls. I realized a simple rewrite of this code would result in me being able to enable JTAG from Linux. You can see what I did \u003ca href=\"https://github.com/oscardagrach/linux/blob/odroidc2-3.14.y/drivers/amlogic/smc_access/smc_access.c\"\u003ehere\u003c/a\u003e. (Inline assembly can be painful sometimes\u0026hellip;) Upon my first try with the SCP chip, I was able to connect and halt right away. Unfortunately I still haven\u0026rsquo;t been able to connect the A53, or \u003cdel\u003efully understand the purpose\u003c/del\u003e of the \u0026lsquo;SCP\u0026rsquo; processor, but I had made some headway. \u003ca href=\"/images/2016/12/Screenshot-6.png\"\u003e\u003cimg loading=\"lazy\" src=\"/images/2016/12/Screenshot-6.png\"\u003e\u003c/a\u003e When I get some free time (rare these days) I will take a look at the password checking mechanism, and if enabled, the password should be in the efuses. I\u0026rsquo;m hoping this post will serve as a resource for those looking to do JTAG debugging on this board or SoC, and possibly get it working. If you have any questions or comments, feel free to leave them in the comment section! \u003cstrong\u003eUPDATE:\u003c/strong\u003e I was able to start debugging the Cortex-A53 on this board using some ARMv8 patches for OpenOCD. It\u0026rsquo;s still experimental at this moment, but generally works well. The issue was related to lack of ARMv8/DAP support in OpenOCD. Since then, I can successfully halt and resume, and read memory. One side note, I\u0026rsquo;ve discovered that SCP stands for \u0026lsquo;System Control and Power\u0026rsquo; which is pretty self-explanatory.\u003c/p\u003e","title":"Finding JTAG on the Odroid-C2"},{"content":"These are some of my favorite blogs and websites. Most are security researchers in the Android world. Lots of great information. Developers of Sunshine and friends of mine (S-Off and bootloader unlock for Motorola and HTC devices): http://theroot.ninja/ My friend Gal (Now at Google Project Zero): http://bits-please.blogspot.com/ One of my favorite security researchers to follow: http://www.fredericb.info/\n","permalink":"https://movr0.com/links/","summary":"\u003cp\u003eThese are some of my favorite blogs and websites. Most are security researchers in the Android world. Lots of great information. Developers of Sunshine and friends of mine (S-Off and bootloader unlock for Motorola and HTC devices): \u003ca href=\"http://theroot.ninja/\"\u003ehttp://theroot.ninja/\u003c/a\u003e My friend Gal (Now at Google Project Zero): \u003ca href=\"http://bits-please.blogspot.com/\"\u003ehttp://bits-please.blogspot.com/\u003c/a\u003e One of my favorite security researchers to follow: \u003ca href=\"http://www.fredericb.info/\"\u003ehttp://www.fredericb.info/\u003c/a\u003e\u003c/p\u003e","title":"Links"},{"content":"My name is Ryan. I\u0026rsquo;m a Systems Administrator by trade, hobbyist security researcher and software developer by night.. I enjoy working on embedded devices and single-board computers, in addition to compiling custom kernels for various devices. Github\n","permalink":"https://movr0.com/about/","summary":"\u003cp\u003eMy name is Ryan. I\u0026rsquo;m a Systems Administrator by trade, hobbyist security researcher and software developer by night.. I enjoy working on embedded devices and single-board computers, in addition to compiling custom kernels for various devices. \u003ca href=\"https://github.com/oscardagrach\"\u003eGithub\u003c/a\u003e\u003c/p\u003e","title":"About"},{"content":"Did you know that we can use the Raspberry Pi GPIO to bitbang the JTAG/SWD protocols? We can actually use our Raspberry Pi as a JTAG adapter for programming microcontrollers, FPGAs, or another Raspberry Pi! JTAG is a protocol similar to SPI, but works a little different. It\u0026rsquo;s commonly used for board bring-up, debugging, and programming in bare-metal environments. It\u0026rsquo;s incredibly useful because you have direct low-level access to hardware and peripherals, which allows things like reading and modifying CPU registers or reading/writing memory. SWD is a newer technology developed around Cortex-based processors which boasts a reduced pin-count vs JTAG (2 vs 4) and can actually be used over JTAG pins if the device supports it. While SWD doesn\u0026rsquo;t support things like boundary-scan, it\u0026rsquo;s perfectly suited for debugging and bare-metal programming. Let\u0026rsquo;s get started!\nWe\u0026rsquo;ll need a couple of parts to get going:\nRaspberry Pi (2/3) - I will be using the Pi 3 for my example Rasbpian Jessie with latest firmware (I\u0026rsquo;m partial to Debian, sorry Red Hat guys) Female to female jumper wires (3 or 4 for SWD, and 5-7 for JTAG, more information on this later) A solid 2.5A 5V power supply (this is important always) Let\u0026rsquo;s get our repositories and packages up to date:\nsudo apt-get update sudo apt-get upgrade -y sudo apt-get dist-upgrade -y Once we\u0026rsquo;re updated, we\u0026rsquo;ll need to install some dependencies for OpenOCD:\nsudo apt-get install git autoconf libtool make pkg-config libusb-1.0-0 libusb-1.0-0-dev telnet This should provide all the pieces of the puzzle we need to compile OpenOCD. Next we\u0026rsquo;ll need to pull the latest source for OpenOCD so we can compile it:\ngit clone git://git.code.sf.net/p/openocd/code openocd This will clone the OpenOCD repository to a directory called \u0026lsquo;openocd\u0026rsquo; in your current working directory. Next we\u0026rsquo;ll need to enter this directory, and start the process of compiling from source:\ncd openocd/ ./bootstrap During this process, the scripts will download JimTCL and other dependencies for OpenOCD. Once that\u0026rsquo;s complete, we\u0026rsquo;ll move on to configuring our options for OpenOCD:\n./configure --enable-maintainer-mode --enable-bcm2835gpio --enable-sysfsgpio If all goes successfully, we\u0026rsquo;re finally ready to compile:\nmake -j4 We will use \u0026lsquo;make -j4\u0026rsquo; for the Pi 2/3 because of the four cores. This will improve the time it takes to compile OpenOCD by distributing the workload across all four cores (it\u0026rsquo;ll take a little while, so get comfortable.) If we\u0026rsquo;ve finished without errors, our next step is to finally install it:\nsudo make install At this point, we have OpenOCD configured properly for our GPIO bitbanging on the Pi, in addition to compiled binaries and scripts that are now installed. Let\u0026rsquo;s take a side-step for a moment here and take a look at the pins we\u0026rsquo;ll need:\nJTAG PINOUT: FUNC GPIO PIN # TCK GPIO11 23 TMS GPIO25 22 TDI GPIO10 19 TDO GPIO9 21 SRST* GPIO18 12 TRST* GPIO7 26 GND GND 20 NOTE : Pins are optional, I recommend using SRST and ignoring TRST. The reasons why are out of the scope of this tutorial. SWD PINOUT: FUNC GPIO PIN SWCLK GPIO25 22 SWDIO GPIO24 18 SRST GPIO18 12 GND GND 14 You\u0026rsquo;ll need to identify the pins on your target and connect them to your Raspberry Pi according to the charts above. Because target configurations are independent, you\u0026rsquo;ll need to find your configuration file for your target device in \u0026lsquo;/usr/local/share/openocd/scripts/target/\u0026rsquo; We\u0026rsquo;ll need to make some quick modifications to the Raspberry Pi 2/3 interface configuration file depending on which protocol we will be using. Here are my examples: JTAG:\n# # Config for using Raspberry Pi's expansion header # # This is best used with a fast enough buffer but also # is suitable for direct connection if the target voltage # matches RPi's 3.3V and the cable is short enough. # # Do not forget the GND connection, pin 6 of the expansion header. # interface bcm2835gpio bcm2835gpio_peripheral_base 0x3F000000 # Transition delay calculation: SPEED_COEFF/khz - SPEED_OFFSET # These depend on system clock, calibrated for stock 700MHz # bcm2835gpio_speed SPEED_COEFF SPEED_OFFSET bcm2835gpio_speed_coeffs 146203 36 # Each of the JTAG lines need a gpio number set: tck tms tdi tdo # Header pin numbers: 23 22 19 21 bcm2835gpio_jtag_nums 11 25 10 9 # or if you have both connected, # reset_config trst_and_srst srst_push_pull # Each of the SWD lines need a gpio number set: swclk swdio # Header pin numbers: 22 18 # bcm2835gpio_swd_nums 25 24 # If you define trst or srst, use appropriate reset_config # Header pin numbers: TRST - 26, SRST - 12 # bcm2835gpio_trst_num 7 # reset_config trst_only bcm2835gpio_srst_num 18 reset_config srst_only srst_push_pull # or if you have both connected, # reset_config trst_and_srst srst_push_pull SWD:\n# # Config for using Raspberry Pi's expansion header # # This is best used with a fast enough buffer but also # is suitable for direct connection if the target voltage # matches RPi's 3.3V and the cable is short enough. # # Do not forget the GND connection, pin 6 of the expansion header. # interface bcm2835gpio bcm2835gpio_peripheral_base 0x3F000000 # Transition delay calculation: SPEED_COEFF/khz - SPEED_OFFSET # These depend on system clock, calibrated for stock 700MHz # bcm2835gpio_speed SPEED_COEFF SPEED_OFFSET bcm2835gpio_speed_coeffs 146203 36 # Each of the JTAG lines need a gpio number set: tck tms tdi tdo # Header pin numbers: 23 22 19 21 # bcm2835gpio_jtag_nums 11 25 10 9 # or if you have both connected, # reset_config trst_and_srst srst_push_pull # Each of the SWD lines need a gpio number set: swclk swdio # Header pin numbers: 22 18 bcm2835gpio_swd_nums 25 24 # If you define trst or srst, use appropriate reset_config # Header pin numbers: TRST - 26, SRST - 12 # bcm2835gpio_trst_num 7 # reset_config trst_only bcm2835gpio_srst_num 18 reset_config srst_only srst_push_pull # or if you have both connected, # reset_config trst_and_srst srst_push_pull You can save either of these files in your home directory (/home/pi/) and name them whatever you want, I chose rpi_swd.cfg and rpi_jtag.cfg (Remember, you\u0026rsquo;ll need to be in the directory where your configuration files are when you execute OpenOCD, at least to make it easy.) While OpenOCD has this script already, you may have problems if you need to modify it because of permissions. It\u0026rsquo;s easier to modify it locally if you need to. I also noticed an error in the RPi2 interface configuration they provide; they state SRST is pin 18/GPIO24, but it\u0026rsquo;s actually pin 12/GPIO18. Now that our preparation is done, we can start debugging. Remember to find the target configuration file for your device first. Here\u0026rsquo;s what I would do for my STM32L476RG:\nsudo openocd -f rpi_jtag.cfg -f target/stm32l4x.cfg This launches our OpenOCD/gdb server which we\u0026rsquo;ll need to connect to using telnet. You can use netcat or the telnet client, I personally prefer the telnet client. We\u0026rsquo;ll open a new terminal window or SSH connection on the Pi and run this command to connect to OpenOCD:\ntelnet localhost 4444 That\u0026rsquo;s it! We can debug our devices using our Raspberry Pi and OpenOCD. If you have any questions or need further clarification, leave a comment.\n","permalink":"https://movr0.com/posts/use-raspberry-pi-23-as-a-jtagswd-adapter/","summary":"\u003cp\u003eDid you know that we can use the Raspberry Pi GPIO to bitbang the JTAG/SWD protocols? We can actually use our Raspberry Pi as a JTAG adapter for programming microcontrollers, FPGAs, or another Raspberry Pi! JTAG is a protocol similar to SPI, but works a little different. It\u0026rsquo;s commonly used for board bring-up, debugging, and programming in bare-metal environments. It\u0026rsquo;s incredibly useful because you have direct low-level access to hardware and peripherals, which allows things like reading and modifying CPU registers or reading/writing memory. SWD is a newer technology developed around Cortex-based processors which boasts a reduced pin-count vs JTAG (2 vs 4) and can actually be used over JTAG pins if the device supports it. While SWD doesn\u0026rsquo;t support things like boundary-scan, it\u0026rsquo;s perfectly suited for debugging and bare-metal programming. Let\u0026rsquo;s get started!\u003c/p\u003e","title":"Use Raspberry Pi (2/3) as a JTAG/SWD adapter"},{"content":"What is F2FS? From Wikipedia:\nF2FS (Flash-Friendly File System) is a flash file system initially developed by Samsung Electronics for the Linux kernel.[2] The motive for F2FS was to build a file system that, from the start, takes into account the characteristics of NAND flash memory-based storage devices (such as solid-state disks, eMMC, and SD cards), which are widely used in computer systems ranging from mobile devices to servers.\nBasically, F2FS was a file system designed from the ground up for NAND-based devices. Motorola even started using F2FS for their Android smartphones. It\u0026rsquo;s designed to help reduce wear on the device, and improve performance on this type of storage medium. Since the Raspberry Pi was designed to run off of an SD card, it makes it a perfect candidate to play around with F2FS. It\u0026rsquo;s currently supported in the 4.4.y kernel so no need to compile your own kernel this time. For this project, you will need a USB flash drive or SSD/HDD via a USB adapter (You will lose all data on your USB device, back it up!) Let\u0026rsquo;s begin. First we\u0026rsquo;ll want to upgrade our kernel and firmware to the latest available. Let\u0026rsquo;s update all of our packages first:\nsudo apt-get update\rsudo apt-get -y upgrade\rsudo apt-get -y dist-upgrade Next, we\u0026rsquo;ll use a handy script included in Raspbian (not included with minimal image.) If you do not have the rpi-update script already, we\u0026rsquo;ll install it now, otherwise you may skip to the next step.\nsudo apt-get install rpi-update So let\u0026rsquo;s pull the latest kernel and firmware to our devices:\nsudo rpi-update Allow the process to finish without errors and then reboot. Next we\u0026rsquo;ll need to grab the tools we\u0026rsquo;ll need to format or repair a drive with F2FS format:\nsudo apt-get install f2fs-tools Once installed, we\u0026rsquo;ll need to plug in our USB device. If it is the only drive plugged in besides the MicroSD, it should populate as /dev/sda, otherwise you\u0026rsquo;ll want to check which disk is associated with the proper device. We\u0026rsquo;ll assume for educational purposes that it\u0026rsquo;s /dev/sda. (Doing this on the incorrect drive will DESTROY all your data, so check carefully.) Let\u0026rsquo;s make sure our USB isn\u0026rsquo;t mounted:\nsudo umount /dev/sda1 We\u0026rsquo;ll need to format our USB to ext4. I like to start fresh and create a new partition table while I\u0026rsquo;m at it:\nsudo fdisk /dev/sda From there, the fdisk prompt will appear. We will initialize the disk with a new partition table (enter in fdisk prompt):\no Next, we\u0026rsquo;ll create a new partition:\nn You\u0026rsquo;ll be prompted for the partition type:\np We\u0026rsquo;ll choose p for Primary. Next, we\u0026rsquo;ll be prompted for the partition number, you can choose 1, or hit enter for the default (which should be 1.)\n1 Here we\u0026rsquo;ll be prompted for the first and last sector, you can hit enter to both for the default settings (It\u0026rsquo;s easier that way and it\u0026rsquo;ll use the whole disk.)\n[Enter]\r[Enter] Finally our partition has been created. Now for the last step, we\u0026rsquo;ll use the command \u0026lsquo;w\u0026rsquo; to write these changes to the disk.\nw If all is successful, fdisk will inform you that it was successful and exit. If you see any error relating to syncing the partition table, you can simply reboot at this point and continue with the steps. We\u0026rsquo;ll now format the USB with ext4:\nsudo mke2fs -t ext4 -L rootfs /dev/sda1 If you are prompted that there\u0026rsquo;s an existing filesystem, you may safely overwrite the filesystem by choosing \u0026lsquo;y\u0026rsquo;. Next we\u0026rsquo;ll need to mount our USB drive so we can back up our MicroSD root partition:\nsudo mount /dev/sda1 /mnt Next we\u0026rsquo;ll use rsync to mirror our root partition to the USB, so we can restore all of our files to the newly created F2FS partition:\nsudo rsync -axv / /mnt This process can take some time depending on how much data you have. Once it\u0026rsquo;s complete, we\u0026rsquo;ll need to boot from the USB so we can format the MicroSD partition. We\u0026rsquo;ll need to modify two files. You can use your favorite text editor to modify the files, I prefer nano (sorry vim fanboys):\nsudo nano /mnt/etc/fstab First we\u0026rsquo;ll add a # in front of the /dev/mmcblk0p2 line. Then we\u0026rsquo;ll need to add a new line at the bottom that looks like this:\n/dev/sda1 / ext4 defaults,noatime 0 1 This line tells the kernel that the root partition is on /dev/sda1. You can hit CTRL + O to save with nano, you\u0026rsquo;ll be prompted for the file name/location, leave it alone and hit enter. Then you can hit CTRL + X to quit. We\u0026rsquo;ll need to modify one more file:\nsudo nano /boot/cmdline.txt You\u0026rsquo;ll want to change from this:\ndwc_otg.lpm_enable=0 console=serial0,115200 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait To:\ndwc_otg.lpm_enable=0 console=serial0,115200 console=tty1 root=/dev/sda1 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait rootdelay=5 The only changes made were setting the root partition to \u0026lsquo;root=/dev/sda1\u0026rsquo; instead of mmcblk0p2 and added \u0026lsquo;rootdelay=5\u0026rsquo; to the end so the kernel waits a couple seconds for the USB device to be ready. In nano we can again do CTRL + O to save the file, and CTRL-X to exit. NOTE: You may use this method to use a USB device as your root partition! Pretty neat, huh? Now reboot and unmount:\nsudo umount /mnt\rsudo reboot If all went well, we should boot right up with no issues. Now that the MicroSD root partition is no longer in use, we can format it. We\u0026rsquo;ll use wipefs to remove the ext4 filesystem:\nsudo wipefs -a /dev/mmcblk0p2 Finally we can format our MicroSD root partition to f2fs:\nsudo mkfs.f2fs /dev/mmcblk0p2 If you are prompted about overwriting an existing filesystem, you may choose \u0026lsquo;y\u0026rsquo;. Once finished, we\u0026rsquo;ll need to mount the MicroSD root partition so we can copy our files back:\nsudo mount /dev/mmcblk0p2 /mnt Once again, we\u0026rsquo;ll use rsync to copy all of our data back:\nsudo rsync -axv / /mnt This should take a little bit. Once it\u0026rsquo;s done, we\u0026rsquo;ll need to edit /boot/cmdline.txt and /mnt/etc/fstab again. We\u0026rsquo;ll start with /mnt/etc/fstab:\nsudo nano /mnt/etc/fstab Here we can delete or comment out the /dev/sda1 line, and uncomment the /dev/mmcblk0p2 line by deleting the #. Then you\u0026rsquo;ll want your /dev/mmcblk0p2 line to reflect these values:\n/dev/mmcblk0p2 / f2fs defaults,noatime,discard\t0 1 If your device is does not support TRIM, you can remove the discard option. Typically, most SD cards/eMMC/SSD will support this command, while USB flash drives may not. You\u0026rsquo;ll know during the mkfs.f2fs process as it will tell you whether your device does or not. Close and save the file once the changes are complete and accurate. Only one more file to modify and then we\u0026rsquo;re set:\nsudo nano /boot/cmdline.txt We\u0026rsquo;ll change \u0026lsquo;root=/dev/sda1\u0026rsquo; to \u0026lsquo;root=/dev/mmcblk0p2\u0026rsquo;, \u0026lsquo;rootfstype=ext4\u0026rsquo; to \u0026lsquo;rootfstype=f2fs\u0026rsquo; and finally remove \u0026lsquo;rootdelay=5\u0026rsquo; since we are no longer booting from a USB device. It should look similar to this:\ndwc_otg.lpm_enable=0 console=serial0,115200 console=tty1 root=/dev/mmcblk0p2 rootfstype=f2fs elevator=deadline fsck.repair=yes rootwait Now we\u0026rsquo;ll unmount the SD and reboot using our new F2FS root partition:\nsudo umount /mnt\rsudo reboot And we\u0026rsquo;re done! Enjoy F2FS on your Pi! Question/Comments? Leave feedback in the comments.\n","permalink":"https://movr0.com/posts/convert-raspberry-pi-123-to-f2fs/","summary":"\u003cp\u003e\u003cstrong\u003eWhat is F2FS?\u003c/strong\u003e From \u003ca href=\"https://en.wikipedia.org/wiki/F2FS\"\u003eWikipedia\u003c/a\u003e:\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003e\u003cstrong\u003eF2FS\u003c/strong\u003e (\u003cstrong\u003eFlash-Friendly File System\u003c/strong\u003e) is a \u003ca href=\"https://en.wikipedia.org/wiki/Flash_file_system\" title=\"Flash file system\"\u003eflash file system\u003c/a\u003e initially developed by \u003ca href=\"https://en.wikipedia.org/wiki/Samsung_Electronics\" title=\"Samsung Electronics\"\u003eSamsung Electronics\u003c/a\u003e for the \u003ca href=\"https://en.wikipedia.org/wiki/Linux_kernel\" title=\"Linux kernel\"\u003eLinux kernel\u003c/a\u003e.\u003ca href=\"https://en.wikipedia.org/wiki/F2FS#cite_note-lwn-f2fs-2\"\u003e[2]\u003c/a\u003e The motive for F2FS was to build a \u003ca href=\"https://en.wikipedia.org/wiki/File_system\" title=\"File system\"\u003efile system\u003c/a\u003e that, from the start, takes into account the characteristics of \u003ca href=\"https://en.wikipedia.org/wiki/NAND_flash_memory\" title=\"NAND flash memory\"\u003eNAND flash memory\u003c/a\u003e-based storage devices (such as \u003ca href=\"https://en.wikipedia.org/wiki/Solid-state_disk\" title=\"Solid-state disk\"\u003esolid-state disks\u003c/a\u003e, \u003ca href=\"https://en.wikipedia.org/wiki/MultiMediaCard#eMMC\" title=\"MultiMediaCard\"\u003eeMMC\u003c/a\u003e, and \u003ca href=\"https://en.wikipedia.org/wiki/Secure_Digital\" title=\"Secure Digital\"\u003eSD\u003c/a\u003e cards), which are widely used in computer systems ranging from mobile devices to servers.\u003c/p\u003e\u003c/blockquote\u003e\n\u003cp\u003eBasically, F2FS was a file system designed from the ground up for NAND-based devices. Motorola even started using F2FS for their Android smartphones. It\u0026rsquo;s designed to help reduce wear on the device, and improve performance on this type of storage medium. Since the Raspberry Pi was designed to run off of an SD card, it makes it a perfect candidate to play around with F2FS. It\u0026rsquo;s currently supported in the 4.4.y kernel so no need to compile your own kernel this time. For this project, you will need a USB flash drive or SSD/HDD via a USB adapter (You will lose all data on your USB device, back it up!) Let\u0026rsquo;s begin. First we\u0026rsquo;ll want to upgrade our kernel and firmware to the latest available. Let\u0026rsquo;s update all of our packages first:\u003c/p\u003e","title":"Convert Raspberry Pi (1/2/3) to F2FS"},{"content":"Today we are going to learn how to compile the Raspberry Pi (2/3 only) kernel from source and then patch the kernel with BFQ IO scheduler support. As of today (8/18/16) the latest kernel is 4.4.17. I am using the latest (Jessie) Raspbian release. So what is BFQ?�More about BFQ\nBFQ is a proportional-share storage-I/O scheduler that also supports hierarchical scheduling with a cgroups interface.\nBFQ provides low latency for interactive and soft real-time applications, high throughput, and strong fairness guarantees. The code is fairly mature�and it has been around for awhile. I especially�prefer BFQ on mobile and embedded devices. Let\u0026rsquo;s dive in. (Note that this guide only covers native compiling, if you are cross-compiling from another arch, check out�this�article for more information.)\nWe\u0026rsquo;ll need to grab the latest kernel sources from the Raspberry Pi github:\ngit clone --depth=1 https://github.com/raspberrypi/linux This will clone only the latest source from the default branch (which is currently 4.4.y) We\u0026rsquo;ll need to install bc also.\nsudo apt-get install bc Now that we have our sources and dependencies met, we\u0026rsquo;ll want to grab our BFQ patches and apply them to our source:\ncd linux/ VERSION=4.4.0-v7r11 wget -nd --no-parent --level 1 -r -R \u0026quot;*.html*\u0026quot; --reject $VERSION \\\\\rhttp://algogroup.unimore.it/people/paolo/disk_sched/patches/$VERSION git am *BFQ*.patch You will see the patches applied, and if successful, no errors. Next we\u0026rsquo;ll need to modify the kernel configuration to enable BFQ and set it as the default IO scheduler.\nKERNEL=kernel7\rmake bcm2709_defconfig To modify the kernel configuration, there\u0026rsquo;s a number of options available. You can simply use your favorite text editor to edit the .config file, or you can use a tool like \u0026lsquo;make menuconfig\u0026rsquo; (ncurses.) I\u0026rsquo;ll be using \u0026lsquo;make menuconfig\u0026rsquo; which requires that libncurses5-dev is installed.\nsudo apt-get install libncurses5-dev and then I\u0026rsquo;ll run:\nmake menuconfig We\u0026rsquo;ll need to navigate to \u0026lsquo;Enable the block layer\u0026rsquo; and hit enter: From there, we\u0026rsquo;ll go down to \u0026lsquo;IO Schedulers\u0026rsquo; and hit enter again: Here, we\u0026rsquo;ll highlight \u0026lsquo;BFQ I/O scheduler\u0026rsquo; and hit space twice. We want an asterisk \u0026lsquo;\u0026lt;*\u0026gt;\u0026rsquo; next to the BFQ option, and not an \u0026lsquo;\u0026rsquo;. This means we are compiling BFQ into the kernel, instead of a module to be loaded separately. Next we\u0026rsquo;ll choose the \u0026lsquo;Default I/O scheduler\u0026rsquo; option and hit enter: This will set BFQ as our default I/O scheduler.�After choosing BFQ, we can hit \u0026lsquo;ESC\u0026rsquo; to back up until we get back to the main menu from the first picture. We\u0026rsquo;re going to modify the local version to append to the kernel release. I do this on Raspberry Pis to prevent us from overwriting the original kernel modules in /lib. We\u0026rsquo;ll choose \u0026lsquo;General setup\u0026rsquo; and hit enter: Then we\u0026rsquo;ll select \u0026lsquo;Local version - append to kernel release\u0026rsquo; and hit enter: You can set this to whatever you like, here\u0026rsquo;s what I did: We can now use our arrow keys to scroll over to Save (we\u0026rsquo;ll leave the filename as .config) and then we\u0026rsquo;ll scroll over to exit (you might have to hit exit twice.) We\u0026rsquo;ve successfully modified our kernel configuration. We now have our kernel sources patched and our configuration updated for BFQ. We\u0026rsquo;ll now compile the kernel (Note: Doing this on the Raspberry Pi will take a LONG time.)\nmake -j4 zImage modules dtbs Once that is done, we\u0026rsquo;ll need to copy over our freshly compiled files to /boot/ and install our modules.\nsudo make modules_install\rsudo cp arch/arm/boot/dts/*.dtb /boot/\rsudo cp arch/arm/boot/dts/overlays/*.dtb* /boot/overlays/\rsudo cp arch/arm/boot/dts/overlays/README /boot/overlays/ And finally, we\u0026rsquo;ll create our kernel image and copy it to /boot. To be safe, I like to backup the original kernel image first:\nsudo cp /boot/kernel7.img /boot/kernel7.bak Then make the kernel image:\nsudo scripts/mkknlimg arch/arm/boot/zImage /boot/$KERNEL.img This will generate the kernel image and copy it to /boot/ with the filename kernel7.img and replace the old kernel. You can change \u0026lsquo;$KERNEL.img\u0026rsquo; to anything you\u0026rsquo;d like, for example \u0026lsquo;movr0.img\u0026rsquo; to avoid overwriting the original kernel and add a simple line to your /boot/config.txt\nkernel=movr0.img There\u0026rsquo;s one more thing we need to fix before rebooting, we\u0026rsquo;ll need to modify /boot/cmdline.txt by changing:\nelevator=deadline to\nelevator=bfq and that\u0026rsquo;s it! You\u0026rsquo;re done, enjoy!\n","permalink":"https://movr0.com/posts/compile-raspberry-pi-23-kernel-from-source-with-bfq/","summary":"\u003cp\u003eToday we are going to learn how to compile the Raspberry Pi (2/3 only) kernel from source and then patch the kernel with BFQ IO scheduler support. As of today (8/18/16) the latest kernel is 4.4.17. I am using the latest (Jessie) Raspbian release. So what is BFQ?�\u003ca href=\"http://algo.ing.unimo.it/people/paolo/disk_sched/\"\u003eMore about BFQ\u003c/a\u003e\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003eBFQ is a proportional-share storage-I/O scheduler that also supports hierarchical scheduling with a cgroups interface.\u003c/p\u003e\u003c/blockquote\u003e\n\u003cp\u003eBFQ provides low latency for interactive and soft real-time applications, high throughput, and strong fairness guarantees. The code is fairly mature�and it has been around for awhile. I especially�prefer BFQ on mobile and embedded devices. Let\u0026rsquo;s dive in. (Note that this guide only covers native compiling, if you are cross-compiling from another arch, check out�\u003ca href=\"https://www.raspberrypi.org/documentation/linux/kernel/building.md\"\u003ethis\u003c/a\u003e�article for more information.)\u003c/p\u003e","title":"Compile Raspberry Pi (2/3) kernel from source with BFQ"},{"content":"SHA256 is a cryptographic hash function, commonly used to verify data integrity, such as its use in digital signatures. Passwords are frequently hashed and saved, without needing to store a password in plaintext. This provides an extra layer of security as a hash is not �reversible.� It�s a one-way function, and each hash is unique (with the exception of collisions, but that�s out-of-scope for this tutorial.) For this instance, let�s say we�re trying to recover a password (Apples123) that�s been hashed with SHA256 (a5fca64a1ecdce7bbf5cd75d59e302776cfea0c202ed82d6ef42e37ef3d34479). We want to recover that password because we forgot it. There�s many different types of attacks we can use against a hash, namely dictionary attacks and bruteforce. Let�s say that we have a rough idea of how long the password was, and we know that there are no special characters (!@#$^*). If we wanted to run a plain bruteforce attack, this would take ages. Because of the data that we know, we are able to optimize a much more efficient attack at calculating the original value of the hash. We are able to set a custom character set, and set a specified range of possible lengths of our password. Using a mask attack (when applicable) can significantly improve your odds at recovering the password. We can reduce the cracking time from thousands of years to a couple hours. Enter Hashcat/OclHashcat (Ocl is the CUDA/OpenCL implementation of hashcat, accelerated by a GPU to utilize it�s parallel processing ability and hundreds-to-thousands of cores.) Hashcat is also able to utilize multi-threading, in addition to certain instruction sets that are advantageous to this type of operation (Intel: AVX/2 and AMD: XOP.) Let�s start out by grabbing a copy of Hashcat from their website here. I�ll start out by running a benchmark to get a ballpark idea of how fast we can crack our hashes. Benchmarking CPU with Hashcat I used the following command (I chose the AVX2 binary because of my i5 processor, and you may use the standard hashcat or the XOP for AMD):\n./hashcat-cliAVX2.bin -b Using the -b option, hashcat will run a benchmark for various hashing algorithms. We�re only interested in SHA256, which comes out to about 24M attempts a second. In the real world, there are many factors that will slow us down, so realistically, we should not expect this speed. So we have our hash, we have some limited information about our password, and have our tool ready for work. Let�s begin. Inside the directory you extracted hashcat too, we�ll create a simple plaintext document. I�ll name it hash.txt. I�ll add our hash value calculated earlier to this text file. The hash of our target password Okay, we�ve got our target hash saved, let�s get to work. Hashcat can crack dozens of different types of hashes from WPA to NTLM/LM. It can also handle salted hashes, passwords, etc� Again out of scope but relevant to know. We�ll need to find the option for SHA256. Various hash types that are supported As you can see, we�ll be using 1400 for plain SHA256. Remember that mask attack I was talking about? That�s attack type �3�. We know our password starts with a capital letter, is 9 characters in length, and has 3 numeric characters. In a real world scenario, we might not know any information, but when we do, we can use it to our advantage is massively reduce the time needed to crack the hash. Here�s what our attack will look like:\n./hashcat-cliAVX2.bin -m 1400 -a 3 --pw-min 9 --pw-max 9 hash.txt -o cracked.txt \u0026quot;?u?l?l?l?l?l?d?d?d\u0026quot; We �-m� for hash type (1400 = SHA256), �-a� for attack mode (3 = bruteforce/mask), �pw-min and max for our specified length, hash.txt for our hash to be cracked, �-o� will output the hash when cracked to cracked.txt, and finally our mask. ?u is the character set for capital letters, ?l is lowercase letters, and ?d is numbers. Cracking the hash We�ve cut our time down to about three and a half hours to crack our hash. We can optimize our attack even more if you know that specific characters will be in a certain place. Let�s say a password only uses the letters �A-F�. We can create a custom character set by using -1 ABCDEF and then using ?1. We can also throw numbers in there too with -1 ABCDEF?d. Do you see what I�m doing here? Let�s say we want to do a second custom character set with lowercase and uppercase letters, we�d do -2 ?u?l and ?2. Since we already used -1, we�ll used -2. Now you can really see the power of this attack. In order to save a bit of time, I optimized my character set to only use �pples� (I�m cheating, but doing so to demonstrate the power of a mask attack.) The end result will look like this: Result of hash cracking And finally, our cracked hash: ????????\nProfit And we�re done! If we were to use a GPU like an AMD7970, we could crack this in mere minutes, as GPU cracking is magnitudes faster. (This article will be undergoing significant improvements in the next couple of days to organize the information and present it in a better format, along with some better examples and definitions.)\n","permalink":"https://movr0.com/posts/sha256-hash-cracking-with-hashcat-and-mask-attack/","summary":"\u003cp\u003eSHA256 is a cryptographic hash function, commonly used to verify data integrity, such as its use in digital signatures. Passwords are frequently hashed and saved, without needing to store a password in plaintext. This provides an extra layer of security as a hash is not �reversible.� It�s a one-way function, and each hash is unique (with the exception of collisions, but that�s out-of-scope for this tutorial.) For this instance, let�s say we�re trying to recover a password (Apples123) that�s been hashed with SHA256 (a5fca64a1ecdce7bbf5cd75d59e302776cfea0c202ed82d6ef42e37ef3d34479). We want to recover that password because we forgot it. There�s many different types of attacks we can use against a hash, namely dictionary attacks and bruteforce. Let�s say that we have a rough idea of how long the password was, and we know that there are no special characters (!@#$^*). If we wanted to run a plain bruteforce attack, this would take ages. Because of the data that we know, we are able to optimize a much more efficient attack at calculating the original value of the hash. We are able to set a custom character set, and set a specified range of possible lengths of our password. Using a mask attack (when applicable) can significantly improve your odds at recovering the password. We can reduce the cracking time from thousands of years to a couple hours. Enter Hashcat/OclHashcat (Ocl is the CUDA/OpenCL implementation of hashcat, accelerated by a GPU to utilize it�s parallel processing ability and hundreds-to-thousands of cores.) Hashcat is also able to utilize multi-threading, in addition to certain instruction sets that are advantageous to this type of operation (Intel: AVX/2 and AMD: XOP.) Let�s start out by grabbing a copy of Hashcat from their website \u003ca href=\"http://hashcat.net/hashcat/\"\u003ehere\u003c/a\u003e. I�ll start out by running a benchmark to get a ballpark idea of how fast we can crack our hashes. \u003ca href=\"/images/2015/11/Screenshot-1.png\"\u003e\u003cimg alt=\"Benchmarking CPU with Hashcat\" loading=\"lazy\" src=\"/images/2015/11/Screenshot-1.png\"\u003e\u003c/a\u003e Benchmarking CPU with Hashcat I used the following command (I chose the AVX2 binary because of my i5 processor, and you may use the standard hashcat or the XOP for AMD):\u003c/p\u003e","title":"SHA256 Hash Cracking with Hashcat and Mask Attack"},{"content":"Welcome to MOV r0, and my first blog post. The goal of this article is to teach you how to JTAG the Raspberry Pi 2 without having to compile a custom kernel to enable the GPIOs to do JTAG. Let\u0026rsquo;s begin! The tools and equipment I\u0026rsquo;ll be using today are as follows:\nTIAO USB Multi-protocol JTAG adapter. This device is like a BusPirate on steroids. It\u0026rsquo;ll do everything. It\u0026rsquo;s got an FT2232H chip inside, and supports dual-MPSSE. That means we can use UART/JTAG simultaneously, or SPI1/SPI2, or SWD. It\u0026rsquo;s really an amazing device at a great price. You can find it here (Link) Raspberry Pi 2 running Raspbian (Jessie) Female-to-female jumper wires (Can\u0026rsquo;t ever have enough of these) Host system is using Ubuntu Mate 15.04, with latest OpenOCD and FTDI support Grab the latest build of OpenOCD (On your host machine, not your Raspberry Pi, these directions are specific to an FTDI JTAG adapter)\ngit clone git://git.code.sf.net/p/openocd/code sudo apt-get install libtool autoconf texinfo libusb-dev libftdi-dev libusb-1.0.0 libusb-1.0.0-dev pkg-config cd code\r./bootstrap\r./configure --enable-maintainer-mode --enable-ftdi\rmake\rsudo make install Next we\u0026rsquo;re going to compile a small binary written by the guys over at SysProgs (Link). This will be done on the Raspberry Pi 2 itself.I\u0026rsquo;ve modified the original source to change the peripheral base address to support the Raspberry Pi 2. (Working on some server stuff.) The peripheral base went from 0x20000000 to 0x3F000000. NOTE: Before we compile this, we must edit the peripheral base and change it to 0x3F000000. I use nano since it\u0026rsquo;s my favorite editor.\nwget http://sysprogs.com/VisualKernel/tutorials/raspberry/jtagsetup/JtagEnabler.cpp\rnano JtagEnabler.cpp\r(Replace 0x20000000 with 0x3F000000)\rg++ -o JtagEnabler JtagEnabler.cpp Remember the location of this binary on your RPi2, we\u0026rsquo;ll need it later. This binary simply changes the GPIOs to ALT functions (i.e, routes these specific GPIO pins to an alternative function, which in this case is routed to the ARM JTAG pins.) 3. At this point, we\u0026rsquo;ll need to create a configuration file for OpenOCD to interface with the RPi2. We\u0026rsquo;ll use the configuration file found from Jitomesky\u0026rsquo;s GitHub (Link).\nwget http://movr0.com/files/rpi2.cfg Finally, we\u0026rsquo;re ready to connect to the Pi\u0026rsquo;s JTAG pins. JTAG RPi2 GPIO VREF* Pin 1 nTRST Pin 15 GND Pin 9 TDI Pin 7 TMS Pin 13 TCK Pin 22 TDO Pin 18 *Note: Pin 1 is optional, but useful for verifying voltage level. �With our Pi wired up and ready to go, we\u0026rsquo;ll start by activating the JTAG pins using the binary we compiled earlier:\nsudo ./JtagEnabler JtagEnabler executing Next we\u0026rsquo;ll fire up OpenOCD and attempt to connect! (You may need to use a different configuration file for your interface depending on which device you are using. FTDI devices are cheap and work very well) Since I have the TUMPA, I am using the TUMPA configuration file in the FTDI devices folder.\nsudo openocd -f interface/ftdi/tumpa.cfg -f rpi2.cfg Raspberry Pi 2 connected to OpenOCD Halting the four cores If all goes well, we should see the four cores halt, and we\u0026rsquo;re ready to debug. If you have any questions or comments, please post in the comment section below! Thanks for reading. (Note: I\u0026rsquo;m hoping to put together a SWD tutorial soon, so c\u0026rsquo;mon back in the near future.)\n","permalink":"https://movr0.com/posts/how-to-jtag-raspberry-pi-2-without-custom-kernel/","summary":"\u003cp\u003eWelcome to MOV r0, and my first blog post. The goal of this article is to teach you how to JTAG the Raspberry Pi 2 without having to compile a custom kernel to enable the GPIOs to do JTAG. Let\u0026rsquo;s begin! The tools and equipment I\u0026rsquo;ll be using today are as follows:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eTIAO USB Multi-protocol JTAG adapter. This device is like a BusPirate on steroids. It\u0026rsquo;ll do everything. It\u0026rsquo;s got an FT2232H chip inside, and supports dual-MPSSE. That means we can use UART/JTAG simultaneously, or SPI1/SPI2, or SWD. It\u0026rsquo;s really an amazing device at a great price. You can find it here (\u003ca href=\"http://www.diygadget.com/tiao-usb-multi-protocol-adapter-jtag-spi-i2c-serial.html\"\u003eLink\u003c/a\u003e)\u003c/li\u003e\n\u003cli\u003eRaspberry Pi 2 running Raspbian (Jessie)\u003c/li\u003e\n\u003cli\u003eFemale-to-female jumper wires (Can\u0026rsquo;t ever have enough of these)\u003c/li\u003e\n\u003cli\u003eHost system is using Ubuntu Mate 15.04, with latest OpenOCD and FTDI support\u003c/li\u003e\n\u003c/ul\u003e\n\u003col\u003e\n\u003cli\u003e\n\u003cp\u003eGrab the latest build of OpenOCD (On your host machine, not your Raspberry Pi, these directions are specific to an FTDI JTAG adapter)\u003c/p\u003e","title":"How To JTAG Raspberry Pi 2 (Without custom kernel)"}]