search

ufrisk / pcileech

Direct Memory Access (DMA) Attack Software
GNU Affero General Public License v3.0
5.04k stars 735 forks source link

pcileech3.0 cannot run on Nexus 5x #278

Closed whyseu closed 11 months ago

whyseu commented 11 months ago

1.I use Nexus 5x, android 7.1.2 2.I follow the steps in the Android.md of pcileech 3.0 3.I use adb from a win10 to input instructions as the image shows image How can I dump the mem of the Nexus?

ufrisk commented 11 months ago

PCILeech used to support Android on the attacker side.

I.e. you were able to use Android as the attacking computer when attacking a PC instead of a separate laptop computer.

PCILeech have never supported dumping memory from phones. It's not possible to use PCILeech to dump the memory of the nexus system.

I removed this feature a long time ago since there was no interest.

RickyCong commented 11 months ago

I recently created an Android system using a Rock5b, as detailed here: https://wiki.radxa.com/Rock5/5b. It supports PCIe interface, and I'm interested in seeing if I can get PCIeLeach to work with it. If it's not possible, can I contribute to the source code?

ufrisk commented 11 months ago

I assume you mean to attack the Android system here, not run PCILeech on the Android system which is another thing.

If you get around the SMMU it should work to attack it I guess, you could be able to view memory. On ARM memory does not usually start at address 0x0 so that may be an issue as well, just check whatever physical memory ranges exists on your system and try to read it with pcileech display -min 0x80000000 -device fpga -v -vvv to read from address 0x80000000 (or whatever you wish to read from) and then see the TLPs being transmitted / received. If its blocked by the SMMU you might see something in the dmesg log.

I'd happily accept any contributions of modules to PCILeech feely.

To contribution so the core code that would be possible as well, but ping me first in that case, and I'd need it to be contributed under a a permissive license (such as BSD 0-clause license) since I have the need to be able to dual-license PCILeech. Also it would have to be something more than re-enabling the old removed android #defines in the c-code. Android kernel injection support would be quite nice :)

RickyCong commented 11 months ago

Yes, I've just been delving into this subject and recognized the necessity to bypass the SMMU, but I'm uncertain about the initial steps to take.

I am currently rolling back my project to a version above 3.0 to evaluate whether the Android-compatible code you've authored can effectively dump the memory of an Android application. However, I encountered your remark: ”PCILeech has never supported memory dumping from mobile devices. It is not viable to use PCILeech for dumping the memory of the Nexus system.“ https://github.com/ufrisk/pcileech/issues/278

Therefore, I am still in the phase of compiling information. It would be immensely helpful if you could suggest a potential starting point or approach! It appears that some individuals may have managed to successfully bypass the SMMU. https://github.com/ufrisk/pcileech/issues/271

ufrisk commented 11 months ago

If you wish to attack your Android system best would probably to run most recent PCILeech on your x64 PC or ARM64 Linux system...

Attacking from Android is quite interesting as well I think, but it would be nice to have PCILeech Appified then, i.e. an App using the library. Just running in from command line kinda sucked when I had support around so noone was interested at the time and I'm a terrible App designer so I removed support instead :\

RickyCong commented 11 months ago

Okay, I'm going to test the latest version of PCILeech. No worries, regardless of the program's design quality, what's most important is to materialize the concept in mind, right?

If I'm aiming to bypass the SMMU now, could you provide some guidance on the direction to take? I'm not a kernel developer, so I'm uncertain about which direction to channel my efforts.

RickyCong commented 11 months ago

While Android emulators exist for x64 PCs, some applications implement emulator detection mechanisms that prevent them from running. For instance, they may detect Houdini's x86 to ARM translation technology (libhoudini.so). Consequently, the optimal strategy would be to operate an Android system on an ARM development board. Thus, I have compiled an Android 12 system and its corresponding kernel (kernel 5.10), but I am currently unsure of how to proceed. https://wiki.radxa.com/Rock5/guide/android12