I've been able to run the debugger inside Cutter (radare2) using my native host (x86_64) libraries when reversing a x86 binary. How would I do such a thing when trying to debug an arm binary? How can I get cutter to use the libc.so for arm instead of my native host so I can debug?
ENVIRONMENT
Cutter: Version 1.10.0, Using r2-4.1.1, Based on Qt 5.12.1 (GCC 7.4.0, 64 bit)
System: Ubuntu 18.04.3 LTS
SOLUTION
Note: As of Cutter v1.10.0 debugging is still in beta, therefore these results may vary and change over time.
Option 1: Utilize the emulation features of Cutter instead of debugging.
Option 2: Connect Cutter to a remote session.
EXAMPLE
Option 1
Open Cutter with target ARM binary and seek to main function.
Select "Start emulation" from Debug menu.
Set breakpoints/step/continue as if debugging.
Option 2
Open Cutter with target ARM binary and seek to main function.
Launch remote session for target ARM binary.
user#host:~$ qemu-arm -g 5000 test.x
Select "Connect to a remote debugger" from Debug menu.
Target the remote debugger.
Set breakpoints/step/continue like normal.
Related
I've installed (OSX Mojave 10.14.6.) Eclipse CDT and GNU MCU Eclipse plugin and finaly GNU Tools for ARM. My goal is to build and debug ARM code using GDB (arm-none-eabi-gdb).
I've created a Hello World project for Arm, which builds ok - but, debugging seems not to work with GDB (that comes with the Arm package). GDB gets stuck:
I have set the proper paths in Eclipse to arm-none-eabi-gdb.
I have signed the arm-none-eabi-gdb (with the same certificate that I used to sign GDB installed via brew into /usr/local/bin/gdb the day before - and it worked!).
I have also tried running Eclipse as root from command line.
Nothing helps.
The message is "Configuring GDB Aborting configuring GDB".
What to do?
Probably what is going on here is that you built to a given target (ARM based) and you're trying to run it (with gdb) on your mac (x86).
You'll need an emulator or QEMU to properly run on your mac or maybe a real board.
I install qemu-system-arm in Ubuntu 16.04 to run firmware of dlink DIR868L. But when I use the command chroot ./squashfs-root/ /bin/sh, it just shows Illegal instruction. I get squashfs-root/from DIR868LB1_FW203b01.bin by binwalk and I am sure that /bin/sh exists in squashfs-root/.
I start qemu by sudo qemu-system-arm -M versatilepb -kernel vmlinuz-2.6.32-5-versatile -initrd initrd.img-2.6.32-5-versatile -hda debian_squeeze_armel_standard.qcow2 -append "root=/dev/sda1" -net nic -net tap and use scp to cpoy squashfs-root/ into virtual mechine. And I met the same problem when using debian_wheezy_armel_standard.qcow2
What should I do ? It has bothered me for the whole afternoon.
Or can anyone give me an example to run the arm firmware in qemu ? I only find lots of examples using firmware based on mips.
Thanks a lot !
The problem is almost certainly because whatever CPU is in the DIR868lL is newer than the ARM926 CPU that the "versatilepb" board has. If the binaries from that firmware are built to use newer instructions, then running them in an emulation of an older CPU will result in an 'illegal instruction' signal, just as if you'd run them on real older ARM hardware.
This is similar to taking binaries that were built for a Core2 Duo and trying to run them on your old Pentium system: it won't work.
I recently downloaded the v3 of the FourQlib [1], build the FourQlib and wanted to test if everything went well.
First of all, my system:
Windows 10 (host) with MinGW, ARM Toolchain, MSYS, ...
Ubuntu 16.04 LTS (Guest) (gcc, arm toolchain, ...)
VirtualBox
STM32F429ZI-Disco
The source [1] includes the directory "FourQ_ARM", when compiling you have to start the "monitor.sh" [2] file in a terminal. Since they (Longa et al.) link to "ttyUSB0" I'll checked, if there is any device registered in Ubuntu. Since my µC ist registered as "stlinkv2_2 I changed this symbolic link "/dev/ttyUSB0 -> /dev/stlinkv2_2".
If I run the monitor.sh, the beginning will turn me in an error:
stty -F /dev/stlinkv2_2
leads to the error "Vorgang nicht zulässig" which means something like "Operation not allowed"
Could someone explain me, why I get this error and how to get this shell-script work?
[1] https://github.com/Microsoft/FourQlib
[2] https://github.com/Microsoft/FourQlib/blob/master/FourQ_ARM/tests_Cortex-M4/monitor.sh
The solution is: Using extra hardware with an old driver. Using TTL to USB-converter.
If someone needs to use the FourQlib on a STM32F407, use their USART and monitoring tools. On different processors you need to choose different USART pins. Those with a display connected allready use those pins.
When I try to add it to sources as per debian install instructions I get this error. I'm guessing this means that there are no arm packages for it.
Failed to fetch https://dist.crystal-lang.org/apt/dists/crystal/InRelease Unable to find expected entry 'main/binary-armhf/Packages' in Release file (Wrong sources.list entry or malformed file)
I'm guessing I probably need to install it from source. How would I go about doing that with an arm cpu? When I check it out and run make I get the error:
You need to have a crystal executable in your path! Makefile:113:
recipe for target '.build/crystal' failed make: *** [.build/crystal]
Error 1
Any suggestions would be greatly appreciated.
EDIT: There's now a semi-official repository for crystal on raspbian, check it out here: http://public.portalier.com/raspbian
Crystal doesn't build Debian packages for ARM, and you're correct in that you'll need to build from source.
However, the Crystal compiler is written in Crystal. This presents the obvious problem of how to get a compiler to build the compiler. The answer is cross-compilation: building an arm binary on a x86 desktop computer and copying it across.
Here's a quick step-by-step based on my memory of last time I cross-compiled:
Install Crystal on a x86 desktop PC, and check it works.
Install all required libraries on the desktop and Raspberry Pi. You'll need the same LLVM version on the Raspberry Pi and desktop. This is probably the hardest and longest step. You can install llvm 3.9 from debian testing for ARM, see this stackoverflow post for how to install only LLVM from debian testing.
Check out the sources from git on both computers, and run make deps.
Cross-compile the compiler by running this command in the root of the git repository:
./bin/crystal build src/compiler/crystal.cr --cross-compile --target arm-unknown-linux-gnueabihf --release -s -D without_openssl -D without_zlib
This command will create a crystal.o file in your current directory, and also output a linker command (cc crystal.o -o crystal ...).
Copy crystal.o to the raspberry pi, and run the linker command. Be sure to edit the absolute path to llvm_ext.o so that it points to the Crystal checkout on your Raspberry Pi, not the checkout on your desktop. Also make sure that all references to llvm-config in the command are for the correct LLVM version. For example, changing /usr/local/bin/llvm-config to llvm-config-3.9 on Raspbian.
Run the crystal executable in your current directory (./crystal -v) and make sure it works.
Ensure to set CRYSTAL_PATH environment variable is set to lib:/path/to/crystal/source/checkout/src so that the compiler can find the standard library when compiling applications.
I was trying to install Sourcery G++ cross-compiler for ARM on Ubuntu 10.04 LTS from the following link ->http://www.codesourcery.com/sgpp/lite/arm/portal/release644
I did not use the graphical interface since I got java.awt error. While using the console mode of installation, I provided all the details asked by the program.(changed the default location of installation)
Some time into the installation, I got this error:
Unable to create file links
An error occurred while running an internal program.
Please remove the toolchain from "/home//cross_compiler".
EXITCODE=-1
I'm not sure what the reason is. I redid this process as a root user and I still got the same error.I am trying to install this on a 64 bit machine.
I suppose it is important to check your system requirements.
There is the possibility you are running a 64bit build of Ubuntu.
Sourcery G++ requires 32bit host libraries. Ensure those are installed.
In my mind, it may be easier to run a 32bit installation in a VM.
If that is not possible, there are installation logs in the 'uninstall' directory of your installation attempt directory. That may help you troubleshoot the issue.
You must have the 32-bit compatibility libraries installed to install Sourcery CodeBench.
From the FAQ: "What do I need to do to install and run Sourcery CodeBench on an x86 64-bit Linux host system?"
https://sourcery.mentor.com/sgpp/lite/arm/portal/kbentry62
Full FAQ here:
https://sourcery.mentor.com/sgpp/lite/arm/portal/target_arch?#action=faq&target_arch=arm
The ARM Lite edition tools have their own mailing list where you can ask such questions.
Go to sourcerytools.com and use the "arm-gnu" mailing list for ARM Lite edition questions.
Cheers!