Firmware Acquisition Techniques - Revision history

JPDoe: Minor edit

2020-07-02T12:19:47Z

Minor edit

← Older revision		Revision as of 12:19, 2 July 2020
Line 44:		Line 44:
	│(QEMU, IDA, Radare)│		│(QEMU, IDA, Radare)│
	╰───────────────────╯</nowiki>-->		╰───────────────────╯</nowiki>-->
	<gallery mode=packed-hover heights=500px style="text-align:~~center~~">		<gallery mode=packed-hover heights=500px style="text-align:left">
	image:Firmware_Acquisition_techniques__Attack_tree.png\|		image:Firmware_Acquisition_techniques__Attack_tree.png\|
	</gallery>		</gallery>

JPDoe: Minor edit

2020-07-02T12:19:26Z

Minor edit

← Older revision		Revision as of 12:19, 2 July 2020
Line 1:		Line 1:
	<div class="toccolours mw-collapsible mw-collapsed" style="border-color: ~~lightgrey~~; background-color: white; overflow:auto;">		<div style="max-width: 970px">

			<div class="toccolours mw-collapsible mw-collapsed" style="border-color: #eaecf0; background-color: white; overflow:auto; calc(100% - 12px);">
	<div style="font-weight: normal;line-height:1.6;">ⓘ Table of Contents</div>		<div style="font-weight: normal;line-height:1.6;">ⓘ Table of Contents</div>
	<div class="mw-collapsible-content">		<div class="mw-collapsible-content">
	__TOC__		__TOC__
	~~</div>~~
	</div>		</div>
	</div>		</div>
Line 43:		Line 44:
	│(QEMU, IDA, Radare)│		│(QEMU, IDA, Radare)│
	╰───────────────────╯</nowiki>-->		╰───────────────────╯</nowiki>-->
	<gallery mode=packed-hover heights=500px style="text-align:~~left~~">		<gallery mode=packed-hover heights=500px style="text-align:center">
	image:Firmware_Acquisition_techniques__Attack_tree.png\|		image:Firmware_Acquisition_techniques__Attack_tree.png\|
	</gallery>		</gallery>
Line 75:		Line 76:
	<p style="text-align: justify"><b>Disassembly</b> typically requires a few tools and strong nerves. A smaller Phillips screwdriver (PH0/PH3) and some plastic opening tools are generally sufficient. Furthermore, some [[#Hardware\|additional tools]] may be needed. These include UART to TTL converter (CH340G), SPI/I2C programmer (CH341H), and the appropriate clips to read SOP8 pr SOP16 package type chips without desoldering them. The last two tools will only be used in Section [[#Exploit Memory Chips\|Exploit Memory Chips]]. A common multimeter may be used to measure the pins. Alternative instruments are introduced as needed. The functions of the CH340G and CH341H can also be performed by a development board like the Raspberry Pi.</p>		<p style="text-align: justify"><b>Disassembly</b> typically requires a few tools and strong nerves. A smaller Phillips screwdriver (PH0/PH3) and some plastic opening tools are generally sufficient. Furthermore, some [[#Hardware\|additional tools]] may be needed. These include UART to TTL converter (CH340G), SPI/I2C programmer (CH341H), and the appropriate clips to read SOP8 pr SOP16 package type chips without desoldering them. The last two tools will only be used in Section [[#Exploit Memory Chips\|Exploit Memory Chips]]. A common multimeter may be used to measure the pins. Alternative instruments are introduced as needed. The functions of the CH340G and CH341H can also be performed by a development board like the Raspberry Pi.</p>

	<div class="toccolours mw-collapsible mw-collapsed" style="border-color: #~~a7d7f9~~; calc(100% - 12px)~~; overflow:auto~~;">		<div class="toccolours mw-collapsible mw-collapsed" style="border-color: #eaecf0; background-color: white; overflow:auto; calc(100% - 12px);">
	<div style="line-height:1.6;">ⓘ <b>Firmware Acquisition Toolset</b></div>		<div style="line-height:1.6;">ⓘ <b>Firmware Acquisition Toolset</b></div>
	<div class="mw-collapsible-content">		<div class="mw-collapsible-content">
Line 81:		Line 82:
	image:Firmware Acquisition toolset 1.jpg\|		image:Firmware Acquisition toolset 1.jpg\|
	</gallery>		</gallery>
	~~</div>~~
	</div>		</div>
	</div>		</div>
Line 91:		Line 91:
	<p style="text-align: justify"><b>Update Mechanisms</b> became important with the increasing number of embedded devices. Those shall provide secure and reliable firmware updates without the user having to take care of it. Updates are performed in the classic pull or in push-mode for IoT update models. In the former case, the device checks with the server whether new updates are available. With the latter, the server sends the new firmware to the device in the event of an update.<sup>[[#References\|[3]]]</sup> Therefore, the images often only appear in the Deep Web, if at all. In the case of the pull-models, the update routine is periodically initialized by the device itself or manually via the user interface. In some cases, the download link or even the firmware can be intercepted by performing an eavesdropping attack on the network when the update routine starts. If there is already an access via UART given, but there is no possibility to extract the complete firmware from there, the update mechanism, and its configuration can be searched, which should contain a link to the update server and, if available, also the URL for the firmware download. These methods are made more difficult or even impossible in push mode. Most manufacturers offer their own weakly implemented solutions, if at all. E. Baccelli et al. <sup>[[#References\|[4]]]</sup> criticizes the lack of secure and reliable update mechanisms in IoT, even though these are the key factor in eliminating serious vulnerabilities. These mechanisms should guarantee an integrated and authenticated update process from end to end. There are open standards for remote IoT device management, such as IPv6-OTA, SUIT-OTA, and LwM2M-OTA, which provide mechanisms to manage firmware updates. OTA stands for Over-The-Air firmware updates, which are pushed directly from the update server to the IoT device. Table 1 provides an overview of common threads against OTA standards and which enumerated standards have protection mechanisms against them. It can be observed that in the case of reverse engineering, there are still no sophisticated solutions to protect against eavesdropping of the firmware. Although there are approaches to protect the firmware in-flight by encryption or usage of (D)TLS. Furthermore, there are also approaches to how the blockchain can be employed for secure firmware distribution and updates <sup>[[#References\|[5]]]</sup>. These advanced update mechanisms will make the firmware download for reverse engineering difficult or even impossible in the future.</p>		<p style="text-align: justify"><b>Update Mechanisms</b> became important with the increasing number of embedded devices. Those shall provide secure and reliable firmware updates without the user having to take care of it. Updates are performed in the classic pull or in push-mode for IoT update models. In the former case, the device checks with the server whether new updates are available. With the latter, the server sends the new firmware to the device in the event of an update.<sup>[[#References\|[3]]]</sup> Therefore, the images often only appear in the Deep Web, if at all. In the case of the pull-models, the update routine is periodically initialized by the device itself or manually via the user interface. In some cases, the download link or even the firmware can be intercepted by performing an eavesdropping attack on the network when the update routine starts. If there is already an access via UART given, but there is no possibility to extract the complete firmware from there, the update mechanism, and its configuration can be searched, which should contain a link to the update server and, if available, also the URL for the firmware download. These methods are made more difficult or even impossible in push mode. Most manufacturers offer their own weakly implemented solutions, if at all. E. Baccelli et al. <sup>[[#References\|[4]]]</sup> criticizes the lack of secure and reliable update mechanisms in IoT, even though these are the key factor in eliminating serious vulnerabilities. These mechanisms should guarantee an integrated and authenticated update process from end to end. There are open standards for remote IoT device management, such as IPv6-OTA, SUIT-OTA, and LwM2M-OTA, which provide mechanisms to manage firmware updates. OTA stands for Over-The-Air firmware updates, which are pushed directly from the update server to the IoT device. Table 1 provides an overview of common threads against OTA standards and which enumerated standards have protection mechanisms against them. It can be observed that in the case of reverse engineering, there are still no sophisticated solutions to protect against eavesdropping of the firmware. Although there are approaches to protect the firmware in-flight by encryption or usage of (D)TLS. Furthermore, there are also approaches to how the blockchain can be employed for secure firmware distribution and updates <sup>[[#References\|[5]]]</sup>. These advanced update mechanisms will make the firmware download for reverse engineering difficult or even impossible in the future.</p>

	<div class="toccolours mw-collapsible mw-collapsed" style="border-color: #~~a7d7f9~~; calc(100% - 12px)~~; overflow:auto~~;">		<div class="toccolours mw-collapsible mw-collapsed" style="border-color: #eaecf0; background-color: white; overflow:auto; calc(100% - 12px);">
	<div style="line-height:1.6;">ⓘ <b>Table 1</b>: Open Standards for Remote IoT Device Management: Security Assessment <sup>[[#References\|[4]]]</sup></div>		<div style="line-height:1.6;">ⓘ <b>Table 1</b>: Open Standards for Remote IoT Device Management: Security Assessment <sup>[[#References\|[4]]]</sup></div>
	<div class="mw-collapsible-content">		<div class="mw-collapsible-content">
Line 150:		Line 150:
	</tr>		</tr>
	</table>		</table>
	~~</div>~~
	</div>		</div>
	</div>		</div>
Line 285:		Line 284:
	<p style="text-align: justify"><b>Identification</b> of the chips used is essential here, as there are a large number of different manufacturers, memory types and packages. As usual, with embedded devices, the main storage is located outside the MC. The processor can communicate and execute commands with the memory devices via a suitable protocol such as SPI (Serial Peripheral Interface). Each chip carries its model designation engraved by laser on the package, which can then be used to search for the corresponding datasheets. It should be noted that the removal of the engraving can serve as a way of obfuscation. The common memory types are listed in Table 6. NAND and NOR flash devices are the most common memory types used in embedded applications. These flash types have different architectures and characteristics. In general, NOR flash memory is directly addressable, and the ideal choice when lower capacity, fast random read access, and higher data reliability are required. NAND flash, in turn, is ideal for applications requiring higher capacity and faster write and erase operations.</p>		<p style="text-align: justify"><b>Identification</b> of the chips used is essential here, as there are a large number of different manufacturers, memory types and packages. As usual, with embedded devices, the main storage is located outside the MC. The processor can communicate and execute commands with the memory devices via a suitable protocol such as SPI (Serial Peripheral Interface). Each chip carries its model designation engraved by laser on the package, which can then be used to search for the corresponding datasheets. It should be noted that the removal of the engraving can serve as a way of obfuscation. The common memory types are listed in Table 6. NAND and NOR flash devices are the most common memory types used in embedded applications. These flash types have different architectures and characteristics. In general, NOR flash memory is directly addressable, and the ideal choice when lower capacity, fast random read access, and higher data reliability are required. NAND flash, in turn, is ideal for applications requiring higher capacity and faster write and erase operations.</p>

	<div class="toccolours mw-collapsible mw-collapsed" style="border-color: #~~a7d7f9~~; calc(100% - 12px)~~; overflow:auto~~;">		<div class="toccolours mw-collapsible mw-collapsed" style="border-color: #eaecf0; background-color: white; overflow:auto; calc(100% - 12px);">
	<div style="line-height:1.6;">ⓘ <b>Table 6</b>: Examples of common memory types <sup>[[#References\|[2]]]</sup></div>		<div style="line-height:1.6;">ⓘ <b>Table 6</b>: Examples of common memory types <sup>[[#References\|[2]]]</sup></div>
	<div class="mw-collapsible-content">		<div class="mw-collapsible-content">
Line 320:		Line 319:
	</tr>		</tr>
	</table>		</table>
	~~</div>~~
	</div>		</div>
	</div>		</div>
Line 334:		Line 332:
	<h1>Example</h1>		<h1>Example</h1>

	<div class="toccolours mw-collapsible mw-collapsed" style="border-color: #~~a7d7f9~~; calc(100% - 12px)~~; overflow:auto~~;">		<div class="toccolours mw-collapsible mw-collapsed" style="border-color: #eaecf0; background-color: white; overflow:auto; calc(100% - 12px);">
	<div style="line-height:1.6;">ⓘ <b>AVM - FRITZ!Box 7490 - Printed Circuit Board</b></div>		<div style="line-height:1.6;">ⓘ <b>AVM - FRITZ!Box 7490 - Printed Circuit Board</b></div>
	<div class="mw-collapsible-content">		<div class="mw-collapsible-content">
Line 340:		Line 338:
	image:Fritzbox7490_PCB_Example.png\|		image:Fritzbox7490_PCB_Example.png\|
	</gallery>		</gallery>
	~~</div>~~
	</div>		</div>
	</div>		</div>
Line 368:		Line 365:
	* [10] Rusolut, “Data investigation and recovery technology.” https://rusolut.com/, 2019. [Accessed 28 Dec. 2019].		* [10] Rusolut, “Data investigation and recovery technology.” https://rusolut.com/, 2019. [Accessed 28 Dec. 2019].
	* [11] E. Amir, H. CJ, and H. Khoa, “Hacking hardware with a 10 dollar sd card reader,” in Exploitee.rs, Black hat USA 2017, 2017.		* [11] E. Amir, H. CJ, and H. Khoa, “Hacking hardware with a 10 dollar sd card reader,” in Exploitee.rs, Black hat USA 2017, 2017.

			</div>

	[[Category:Basic]]		[[Category:Basic]]

JPDoe: Fix typos

2020-04-28T20:17:27Z

Fix typos

Cskallak at 11:54, 3 March 2020

2020-03-03T11:54:22Z

← Older revision		Revision as of 11:54, 3 March 2020
Line 369:		Line 369:
	* [11] E. Amir, H. CJ, and H. Khoa, “Hacking hardware with a 10 dollar sd card reader,” in Exploitee.rs, Black hat USA 2017, 2017.		* [11] E. Amir, H. CJ, and H. Khoa, “Hacking hardware with a 10 dollar sd card reader,” in Exploitee.rs, Black hat USA 2017, 2017.

	[[Category:~~Documentation~~]]		[[Category:Basic]]

JPDoe at 10:30, 24 February 2020

2020-02-24T10:30:41Z

← Older revision		Revision as of 10:30, 24 February 2020
Line 255:		Line 255:

	<h1>Exploit Memory Chips</h1>		<h1>Exploit Memory Chips</h1>

	<div style="float: right; margin-left: 20px">		<div style="float: right; margin-left: 20px">
	<table class="wikitable">		<table class="wikitable">
Line 281:		Line 280:
	<b>Table 5</b>: SPI Pinout		<b>Table 5</b>: SPI Pinout
	</div>		</div>


	<p style="text-align: justify"><b>Last resort</b>: If all previous methods fail, the data can still be extracted directly from the memory chips themselves, which allows bypassing OCD interfaces and possibly implemented security measures by inserting the chip into an artificial system to read the data. In the same way, as it was common practice in the past to insert modular EEPROM components in order to be able to remove them for reading and writing. Today the memory chips are permanently integrated on the circuit board and should not be accessed directly by the end-user. For this purpose there are basically the methods of in-circuit and chip-off data extraction. With the former, chips can be read out without having to desolder them. However, this is only possible for a few chip packages. With the second method, the chips are desoldered with a hot air station and then read with the appropriate chip programmer. Although this is theoretically possible for all chip packages, the hardware required for each package to read the data is not cheap and relatively difficult to obtain. Both methods of in-circuit and chip-off data extraction are presented and evaluated in the following.</p>		<p style="text-align: justify"><b>Last resort</b>: If all previous methods fail, the data can still be extracted directly from the memory chips themselves, which allows bypassing OCD interfaces and possibly implemented security measures by inserting the chip into an artificial system to read the data. In the same way, as it was common practice in the past to insert modular EEPROM components in order to be able to remove them for reading and writing. Today the memory chips are permanently integrated on the circuit board and should not be accessed directly by the end-user. For this purpose there are basically the methods of in-circuit and chip-off data extraction. With the former, chips can be read out without having to desolder them. However, this is only possible for a few chip packages. With the second method, the chips are desoldered with a hot air station and then read with the appropriate chip programmer. Although this is theoretically possible for all chip packages, the hardware required for each package to read the data is not cheap and relatively difficult to obtain. Both methods of in-circuit and chip-off data extraction are presented and evaluated in the following.</p>

JPDoe at 15:27, 23 February 2020

2020-02-23T15:27:22Z

← Older revision		Revision as of 15:27, 23 February 2020
Line 285:		Line 285:
	<p style="text-align: justify"><b>Last resort</b>: If all previous methods fail, the data can still be extracted directly from the memory chips themselves, which allows bypassing OCD interfaces and possibly implemented security measures by inserting the chip into an artificial system to read the data. In the same way, as it was common practice in the past to insert modular EEPROM components in order to be able to remove them for reading and writing. Today the memory chips are permanently integrated on the circuit board and should not be accessed directly by the end-user. For this purpose there are basically the methods of in-circuit and chip-off data extraction. With the former, chips can be read out without having to desolder them. However, this is only possible for a few chip packages. With the second method, the chips are desoldered with a hot air station and then read with the appropriate chip programmer. Although this is theoretically possible for all chip packages, the hardware required for each package to read the data is not cheap and relatively difficult to obtain. Both methods of in-circuit and chip-off data extraction are presented and evaluated in the following.</p>		<p style="text-align: justify"><b>Last resort</b>: If all previous methods fail, the data can still be extracted directly from the memory chips themselves, which allows bypassing OCD interfaces and possibly implemented security measures by inserting the chip into an artificial system to read the data. In the same way, as it was common practice in the past to insert modular EEPROM components in order to be able to remove them for reading and writing. Today the memory chips are permanently integrated on the circuit board and should not be accessed directly by the end-user. For this purpose there are basically the methods of in-circuit and chip-off data extraction. With the former, chips can be read out without having to desolder them. However, this is only possible for a few chip packages. With the second method, the chips are desoldered with a hot air station and then read with the appropriate chip programmer. Although this is theoretically possible for all chip packages, the hardware required for each package to read the data is not cheap and relatively difficult to obtain. Both methods of in-circuit and chip-off data extraction are presented and evaluated in the following.</p>

	<p style="text-align: justify"><b>Identification</b> of the chips used is essential here, as there are a large number of different manufacturers, memory types and packages. As usual, with embedded devices, the main storage is located outside the MC. The processor can communicate and execute commands with the memory devices via a suitable protocol such as SPI (Serial Peripheral Interface). Each chip carries its model designation engraved by laser on the package, which can then be used to search for the corresponding datasheets. It should be noted that the removal of the engraving can serve as a way of obfuscation. The common memory types are listed in Table 4.6. NAND and NOR flash devices are the most common memory types used in embedded applications. These flash types have different architectures and characteristics. In general, NOR flash memory is directly addressable, and the ideal choice when lower capacity, fast random read access, and higher data reliability are required. NAND flash, in turn, is ideal for applications requiring higher capacity and faster write and erase operations.</p>		<p style="text-align: justify"><b>Identification</b> of the chips used is essential here, as there are a large number of different manufacturers, memory types and packages. As usual, with embedded devices, the main storage is located outside the MC. The processor can communicate and execute commands with the memory devices via a suitable protocol such as SPI (Serial Peripheral Interface). Each chip carries its model designation engraved by laser on the package, which can then be used to search for the corresponding datasheets. It should be noted that the removal of the engraving can serve as a way of obfuscation. The common memory types are listed in Table 6. NAND and NOR flash devices are the most common memory types used in embedded applications. These flash types have different architectures and characteristics. In general, NOR flash memory is directly addressable, and the ideal choice when lower capacity, fast random read access, and higher data reliability are required. NAND flash, in turn, is ideal for applications requiring higher capacity and faster write and erase operations.</p>

	<div class="toccolours mw-collapsible mw-collapsed" style="border-color: #a7d7f9; calc(100% - 12px); overflow:auto;">		<div class="toccolours mw-collapsible mw-collapsed" style="border-color: #a7d7f9; calc(100% - 12px); overflow:auto;">

JPDoe: Created page with "

2020-02-23T15:11:20Z

Created page with "<div class="toccolours mw-collapsible mw-collapsed" style="border-color: lightgrey; background-color: white; overflow:auto;"> <div style="font-weight: normal;line-height:1.6;"..."
Show changes

← Older revision		Revision as of 20:17, 28 April 2020
Line 61:		Line 61:
	<p style="text-align: justify"><b>On-Chip Debug</b> (OCD) Interfaces can be multiple or none on one board. These were used during the development and testing phases of a device and are now leftover. They can be used to access the microcontroller or memory devices. In the following, the most important interfaces are introduced and are further elaborated in Chapter [[#On-chip Debug Interfaces\|On-chip Debug Interfaces]] as necessary. However, it should be noted that there are other interfaces, such as I2C and USB, but also more specific, Serial Wire Debug (SWD) for ARM and Background Debug Mode (BDM) in automotive processors. In the case of an Android-based operating system, debugging is done via the Android Debug Bridge (ADB).</p>		<p style="text-align: justify"><b>On-Chip Debug</b> (OCD) Interfaces can be multiple or none on one board. These were used during the development and testing phases of a device and are now leftover. They can be used to access the microcontroller or memory devices. In the following, the most important interfaces are introduced and are further elaborated in Chapter [[#On-chip Debug Interfaces\|On-chip Debug Interfaces]] as necessary. However, it should be noted that there are other interfaces, such as I2C and USB, but also more specific, Serial Wire Debug (SWD) for ARM and Background Debug Mode (BDM) in automotive processors. In the case of an Android-based operating system, debugging is done via the Android Debug Bridge (ADB).</p>

	<p style="text-align: justify"><b>UART</b> (Universal Asynchronous Transmitter/Receiver) is the standard serial interface for most microcontrollers. This interface is used to send and receive data via two serial data lines. Receive Data (Rx) and Transmit Data (Tx), besides multiple control lines. This serial interface is used with various other interfaces (e.g., RS-232 or EIA-485) while the UART ~~con- troller~~ performs serial-to-parallel conversion on data send and received between the processor and the peripheral device.</p>		<p style="text-align: justify"><b>UART</b> (Universal Asynchronous Transmitter/Receiver) is the standard serial interface for most microcontrollers. This interface is used to send and receive data via two serial data lines. Receive Data (Rx) and Transmit Data (Tx), besides multiple control lines. This serial interface is used with various other interfaces (e.g., RS-232 or EIA-485) while the UART controller performs serial-to-parallel conversion on data send and received between the processor and the peripheral device.</p>

	<p style="text-align: justify"><b>SPI</b> (Serial Peripheral Interface) is a serial interface similar to UART. However, it is mainly used for communication between hardware components and offers a simple and efficient alternative to parallel bus systems following a master/slave architecture, which makes it very suitable for embedded applications. The focus of this work is on the use of SPI in combination with flash chips. With certain chip packages (e.g., SOP8/16), all data of the flash chip can be retrieved using SPI without having to unsolder the flash chip.</p>		<p style="text-align: justify"><b>SPI</b> (Serial Peripheral Interface) is a serial interface similar to UART. However, it is mainly used for communication between hardware components and offers a simple and efficient alternative to parallel bus systems following a master/slave architecture, which makes it very suitable for embedded applications. The focus of this work is on the use of SPI in combination with flash chips. With certain chip packages (e.g., SOP8/16), all data of the flash chip can be retrieved using SPI without having to unsolder the flash chip.</p>
Line 243:		Line 243:

	<ol>		<ol>
	<li><b>Identification</b> of possible JTAG interfaces: JTAG can occur in multiple pin ~~arrange- ments~~. These can be connectors from 8 to 20 pins. Blocks of two times five are good JTAG candidates. In the special case of cJTAG/SWD, only two pins are searched.</li>		<li><b>Identification</b> of possible JTAG interfaces: JTAG can occur in multiple pin arrangements. These can be connectors from 8 to 20 pins. Blocks of two times five are good JTAG candidates. In the special case of cJTAG/SWD, only two pins are searched.</li>
	<li><b>Determination</b> of the pin assignment using specialized hardware like the JTAGulator.</li>		<li><b>Determination</b> of the pin assignment using specialized hardware like the JTAGulator.</li>
	<li><b>Dump</b> the internal memory using a suitable JTAG programmer.</li>		<li><b>Dump</b> the internal memory using a suitable JTAG programmer.</li>
Line 364:		Line 364:
	* [6] P. Inc., “Internet of things project.” http://www.grandideastudio.com/jtagulator/, 2019. [Accessed 27 Dec. 2019].		* [6] P. Inc., “Internet of things project.” http://www.grandideastudio.com/jtagulator/, 2019. [Accessed 27 Dec. 2019].
	* [7] J. Grand, “Jtagulator: Assisted discovery of on-chip debug interfaces,” in Grand Idea Studio, DEFCON 21, 2013.		* [7] J. Grand, “Jtagulator: Assisted discovery of on-chip debug interfaces,” in Grand Idea Studio, DEFCON 21, 2013.
	* [8] K. Rosenfeld and R. Karri, “Attacks and defenses for jtag,” IEEE Design Test of ~~Com- puters~~, vol. 27, pp. 36–47, Jan 2010.		* [8] K. Rosenfeld and R. Karri, “Attacks and defenses for jtag,” IEEE Design Test of Computers, vol. 27, pp. 36–47, Jan 2010.
	* [9] G. Vishwakarma and W. Lee, “Exploiting jtag and its mitigation in iot: A survey,” Future Internet, vol. 10, p. 121, 12 2018.		* [9] G. Vishwakarma and W. Lee, “Exploiting jtag and its mitigation in iot: A survey,” Future Internet, vol. 10, p. 121, 12 2018.
	* [10] Rusolut, “Data investigation and recovery technology.” https://rusolut.com/, 2019. [Accessed 28 Dec. 2019].		* [10] Rusolut, “Data investigation and recovery technology.” https://rusolut.com/, 2019. [Accessed 28 Dec. 2019].

Firmware Acquisition Techniques - Revision history

JPDoe: Minor edit

JPDoe: Minor edit

JPDoe: Fix typos

Cskallak at 11:54, 3 March 2020

JPDoe at 10:30, 24 February 2020

JPDoe at 15:27, 23 February 2020

JPDoe: Created page with " 2020-02-23T15:11:20Z Created page with "<div class="toccolours mw-collapsible mw-collapsed" style="border-color: lightgrey; background-color: white; overflow:auto;"> <div style="font-weight: normal;line-height:1.6;"..." Show changes

JPDoe: Created page with "

2020-02-23T15:11:20Z

Created page with "<div class="toccolours mw-collapsible mw-collapsed" style="border-color: lightgrey; background-color: white; overflow:auto;"> <div style="font-weight: normal;line-height:1.6;"..."
Show changes