This same example runs with no problem in my older Ubuntu 10.10 with DirectFB 1.4.11 and shows a yellow line in the center of the black screen:
#include <iostream>
#include <stdio.h>
#include <unistd.h>
#include <directfb.h>
using namespace std;
static IDirectFB *dfb = NULL;
static IDirectFBSurface *primary = NULL;
static int screen_width = 0;
static int screen_height = 0;
#define DFBCHECK(x...) \
{ \
DFBResult err = x; \
\
if (err != DFB_OK) \
{ \
fprintf( stderr, "%s <%d>:\n\t", __FILE__, __LINE__ ); \
DirectFBErrorFatal( #x, err ); \
} \
}
int main(int argc, char **argv) {
DFBSurfaceDescription dsc;
DFBCHECK(DirectFBInit (&argc, &argv));
DFBCHECK(DirectFBCreate (&dfb));
DFBCHECK(dfb->SetCooperativeLevel (dfb, DFSCL_FULLSCREEN));
dsc.flags = DSDESC_CAPS;
dsc.caps = DFBSurfaceCapabilities(DSCAPS_PRIMARY | DSCAPS_FLIPPING);
DFBCHECK(dfb->CreateSurface( dfb, &dsc, &primary ));
DFBCHECK(primary->GetSize (primary, &screen_width, &screen_height));
DFBCHECK(primary->FillRectangle (primary, 0, 0, screen_width, screen_height));
DFBCHECK(primary->SetColor (primary, 0xFF, 0xFF, 0x00, 0xff));
DFBCHECK(primary->SetSrcColorKey(primary, 0xFF, 0xFF, 0x00));
DFBCHECK(primary->SetBlittingFlags(primary, (DFBSurfaceBlittingFlags) ( DSBLIT_BLEND_ALPHACHANNEL | DSBLIT_SRC_COLORKEY)));
DFBCHECK(primary->DrawLine (primary, 0, screen_height / 2, screen_width - 1, screen_height / 2));
primary->Flip(primary, NULL, DFBSurfaceFlipFlags(0));
sleep(3);
primary->Release(primary);
dfb->Release(dfb);
cout << "DONE!\n";
return 23;
}
But this same example will only show a black screen, with no line, in Ubuntu 12.04, using DirectFB 6.3.
The console output is:
# ./a.out
~~~~~~~~~~~~~~~~~~~~~~~~~~| DirectFB 1.6.3 |~~~~~~~~~~~~~~~~~~~~~~~~~~
(c) 2012-2013 DirectFB integrated media GmbH
(c) 2001-2013 The world wide DirectFB Open Source Community
(c) 2000-2004 Convergence (integrated media) GmbH
----------------------------------------------------------------
(*) DirectFB/Core: Single Application Core. (2013-02-07 11:05)
(*) Direct/Memcpy: Using libc memcpy()
(*) Direct/Thread: Started 'Fusion Dispatch' (-1) [MESSAGING OTHER/OTHER 0/0] <8388608>...
(*) Direct/Thread: Started 'VT Switcher' (-1) [CRITICAL OTHER/OTHER 0/0] <8388608>...
(*) Direct/Thread: Started 'VT Flusher' (-1) [DEFAULT OTHER/OTHER 0/0] <8388608>...
(*) DirectFB/FBDev: Found 'svgadrmfb' (ID 0) with frame buffer at 0x00000000, 15360k (MMIO 0x00000000, 0k)
(*) Direct/Thread: Started 'PS/2 Input' (-1) [INPUT OTHER/OTHER 0/0] <8388608>...
(*) DirectFB/Input: IMPS/2 Mouse (1) 1.0 (directfb.org)
(*) Direct/Thread: Started 'PS/2 Input' (-1) [INPUT OTHER/OTHER 0/0] <8388608>...
(*) DirectFB/Input: IMPS/2 Mouse (2) 1.0 (directfb.org)
(*) Direct/Thread: Started 'Linux Input' (-1) [INPUT OTHER/OTHER 0/0] <8388608>...
(*) DirectFB/Input: Power Button (1) 0.1 (directfb.org)
(*) Direct/Thread: Started 'Linux Input' (-1) [INPUT OTHER/OTHER 0/0] <8388608>...
(*) DirectFB/Input: AT Translated Set 2 keyboard (2) 0.1 (directfb.org)
(*) Direct/Thread: Started 'Linux Input' (-1) [INPUT OTHER/OTHER 0/0] <8388608>...
(*) DirectFB/Input: VMware VMware Virtual USB Mouse (3) 0.1 (directfb.org)
(*) Direct/Thread: Started 'Linux Input' (-1) [INPUT OTHER/OTHER 0/0] <8388608>...
(*) DirectFB/Input: VMware VMware Virtual USB Mouse (4) 0.1 (directfb.org)
(*) Direct/Thread: Started 'Linux Input' (-1) [INPUT OTHER/OTHER 0/0] <8388608>...
(*) DirectFB/Input: ImPS/2 Generic Wheel Mouse (5) 0.1 (directfb.org)
(*) Direct/Thread: Started 'Hotplug with Linux Input' (-1) [INPUT OTHER/OTHER 0/0] <8388608>...
(*) DirectFB/Input: Hot-plug detection enabled with Linux Input Driver
(*) Direct/Thread: Started 'Joystick Input' (-1) [INPUT OTHER/OTHER 0/0] <8388608>...
(*) DirectFB/Input: Joystick 0.9 (directfb.org)
(*) DirectFB/Input: Hot-plug detection enabled with Input Hub Driver
(*) Direct/Thread: Started 'Keyboard Input' (-1) [INPUT OTHER/OTHER 0/0] <8388608>...
(!!!) *** ONCE [Joystick sends JS_EVENT_INIT events, make sure it has been calibrated using 'jscal -c'
] *** [joystick.c:99 in joystick_handle_event()]
(*) DirectFB/Input: Keyboard 0.9 (directfb.org)
(*) DirectFB/Genefx: MMX detected and enabled
(*) DirectFB/Graphics: MMX Software Rasterizer 0.7 (directfb.org)
(*) DirectFB/Core/WM: Default 0.3 (directfb.org)
(*) FBDev/Mode: Setting 800x600 RGB32
(*) FBDev/Mode: Switched to 800x600 (virtual 800x600) at 32 bit (RGB32), pitch 8192
(*) FBDev/Mode: Setting 800x600 RGB32
(*) FBDev/Mode: Switched to 800x600 (virtual 800x600) at 32 bit (RGB32), pitch 8192
(*) FBDev/Mode: Setting 800x600 RGB32
(*) FBDev/Mode: Switched to 800x600 (virtual 800x1200) at 32 bit (RGB32), pitch 8192
(*) FBDev/Mode: Setting 800x600 RGB32
(*) FBDev/Mode: Switched to 800x600 (virtual 800x600) at 32 bit (RGB32), pitch 8192
DONE!
Any idea why the line is not drawn? I wonder if it's a problem with the 64-bit system?
You meant 1.6.3 version. I dont know about your configure options. For example MMX Support.
You can reconfigure and reinstall it with --enable-debug and/or --enable-trace then run the programs with --dfb:debug for more info.
Also DirectFB does a lot of system call while running so you can see them by strace.
This is an old question but lately these are my suggested methods to find related problems to run directfb apps.
Goog luck.
Related
I have following c++ code
int myvar=1;
void test1( int j)
{
int b=j+1;
}
void main()
{
myvar=2;
test1(50);
myvar=3;
test1(100);
myvar=6;
test1(200);
}
I'm trying to set a breakpoint that stops if myvar is greater than 4 when running function test1.
Here is my breakpoint:
bp test!test1 ".if ( poi(myvar)>0n4) {} .else {gc} "
however, it stops every time test1 is executed...
The executable file is called test.exe, a 64 bit application.
Any suggestion would be appreciated.
A little bit of debugging in the breakpoint reveals what is happening:
0 e Disable Clear 00007ff6`77e11410 [f:\projects\windbg_help\main.cpp # 4] 0001 (0001) 0:**** windbg_help!test1 "?? myvar; r $t1=myvar; ?? #$t1; r $t2=poi(myvar); ?? #$t2; .if (dwo(myvar) > 0n4) {.echo yes; gc} .else {.echo no; gc} "
I set the t1 temp register to myvar, and t2 temp register to the contents of myvar, then display them:
0:000> g
int 0n2
unsigned int64 0x00007ff6`77e1c000
unsigned int64 0xffffffff`00000002
no
int 0n3
unsigned int64 0x00007ff6`77e1c000
unsigned int64 0xffffffff`00000003
no
int 0n6
unsigned int64 0x00007ff6`77e1c000
unsigned int64 0xffffffff`00000006
yes
ModLoad: 00007ff9`c8520000 00007ff9`c8531000 C:\WINDOWS\System32\kernel.appcore.dll
ModLoad: 00007ff9`c9da0000 00007ff9`c9e3e000 C:\WINDOWS\System32\msvcrt.dll
ModLoad: 00007ff9`c9aa0000 00007ff9`c9bc2000 C:\WINDOWS\System32\RPCRT4.dll
ntdll!NtTerminateProcess+0x14:
00007ff9`cc5cfcd4 c3 ret
Notice how poi(myvar) is returning a 64bit value, and the upper 32bits are set. You poi(myvar) > 0n4 comparison is saying:
if (0xffffffff0000000? > 4) then { always true }
use dwo(myvar) instead to read only the 32bit contents
Trying to set breakpoint to class member, but I get syntax error or error saying "could not resolve".
Target variable is abc of class pointer xyz.
0:000> ??##c++(xyz->abc)
short 0n812
0:000> dt xyz
Local var # rbx Type Prop*
+0x000 __VFN_table : 0x00007ffd`b9229510
+0x058 abc : 0n0147
Attempts:
0:000> bu ***!***::function+0x56 ".if (##c++(xyz->abc))==147) {.echo 'hit'} .else {gc}"
^ Syntax error in '.if ....'
I want to set breakpoint when pProp->ydu value is equal to 147.
source
#include <iostream>
using namespace std;
class Rectangle {
int width, height;
public:
Rectangle (int x ,int y) : width(x) , height(y) {}
int area (void) {return (width*height);}
};
void CalcArea(int i,int j,Rectangle *rect) {
cout << "Area for Rect("<<i<<","<<j<<") = "<<rect->area()<< endl;
}
int main () {
int i,j;
for(i=10,j=10; (i<100 && j<100); i+=5,j+=10){
Rectangle rect (i,j);
CalcArea(i,j,&rect);
}
return 0;
}
compiled with vs 2017 community cmd prompt
cl /EHsc /W4 /analyze /Zi /Od classy.cpp /link /release
executed
classy.exe
Area for Rect(10,10) = 100
Area for Rect(15,20) = 300
Area for Rect(20,30) = 600
Area for Rect(25,40) = 1000
Area for Rect(30,50) = 1500
Area for Rect(35,60) = 2100
Area for Rect(40,70) = 2800
Area for Rect(45,80) = 3600
Area for Rect(50,90) = 4500
loaded in windbg and set a conditional break point and run
:\>cdb classy.exe
Microsoft (R) Windows Debugger Version 10.0.16299.15 X86
0:000> bu classy!CalcArea ".if(((##c++(rect->width))==0n40)){ .echo \"hit\" } .else{gc}"
0:000> bl
0 e 00841100 0001 (0001) 0:****
classy!CalcArea ".if( ((##c++(rect->width))==0n40) ) { .echo \"hit\" } .else {gc}"
0:000> g
Area for Rect(10,10) = 100
Area for Rect(15,20) = 300
Area for Rect(20,30) = 600
Area for Rect(25,40) = 1000
Area for Rect(30,50) = 1500
Area for Rect(35,60) = 2100
hit <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
eax=00000028 ebx=7ffdf000 ecx=002dff08 edx=00000046 esi=008c9bf0 edi=000d8b28
eip=00841100 esp=002dfef8 ebp=002dff18 iopl=0 nv up ei ng nz na pe cy
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000287
classy!CalcArea:
00841100 55 push ebp
0:000> ?? rect
class Rectangle * 0x002dff08
+0x000 width : 0n40 <<<<<<<<<<<<<<<
+0x004 height : 0n70
0:000>
sorry if this question sounds dumb but I am very new to shellcoding and I was trying to get a hello world example to work on a 32 bit linux machine.
As this is shellcoding, I used a few tricks to remove null bytes and shorten the code. Here it is:
section .data
section .text
global _start
_start:
;Instead of xor eax,eax
;mov al,0x4
push byte 0x4
pop eax
;xor ebx,ebx
push byte 0x1
pop ebx
;xor ecx,ecx
cdq ; instead of xor edx,edx
;mov al, 0x4
;mov bl, 0x1
mov dl, 0x8
push 0x65726568
push 0x74206948
;mov ecx, esp
push esp
pop ecx
int 0x80
mov al, 0x1
xor ebx,ebx
int 0x80
This code works fine when I compile and link it with the following commands:
$ nasm -f elf print4.asm
$ ld -o print4 -m elf_i386 print4.o
However, I tried running it within the following C code:
$ cat shellcodetest.c
#include
#include
char *shellcode = "\x04\x6a\x58\x66\x01\x6a\x5b\x66\x99\x66\x08\xb2\x68\x68\x68\x65\x69\x48\x54\x66\x59\x66\x80\xcd\x01\xb0\x31\x66\xcd\xdb\x80";
int main(void) {
( *( void(*)() ) shellcode)();
}
$ gcc shellcodetest.c –m32 –z execstack -o shellcodetest
$ ./shellcodetest
Segmentation fault (core dumped)
Could someone please explain what is happening there? I tried running the code in gdb and noticed something weird happening with esp. But as I said before, I still lack experience to really understand what is going on here.
Thanks in advance!
Your shellcode does not work, because it is not entered in the correct endianness. You did not state how you extracted the bytes from the file print4, but both objdump and xxd gives the bytes in correct order.
$ xxd print4 | grep -A1 here
0000060: 6a04 586a 015b 99b2 0868 6865 7265 6848 j.Xj.[...hherehH
0000070: 6920 7454 59cd 80b0 0131 dbcd 8000 2e73 i tTY....1.....s
$ objdump -d print4
print4: file format elf32-i386
Disassembly of section .text:
08048060 <_start>:
8048060: 6a 04 push $0x4
8048062: 58 pop %eax
8048063: 6a 01 push $0x1
...
The changes you need to do is to swap the byte order, '\x04\x6a' -> '\x6a\x04'.
When I run your code with this change, it works!
$ cat shellcodetest.c
char *shellcode = "\x6a\x04\x58\x6a\x01\x5b\x99\xb2\x08\x68\x68\x65\x72\x65\x68\x48\x69\x20\x74\x54\x59\xcd\x80\xb0\x01\x31\xdb\xcd\x80";
int main(void) {
( *( void(*)() ) shellcode)();
}
$ gcc shellcodetest.c -m32 -z execstack -o shellcodetest
$ ./shellcodetest
Hi there$
I'm having problems with analyzing a simple binary in IDA Pro.
When running a program, i dumped part of its memory (for example, unpacked code section in the memory) into a file, using WinDbg.
I would like to analyze it using IDA, but when trying to just load the binary - it will only show its raw data.
Of course the binary is not a full PE file, so I'm not expecting a deep analysis, just a nicer way to read the disassembly.
So the question is - How can i make IDA disassemble the binary?
Thanks! :)
select an appropriate address and press c
that is MakeCode(Ea); ida will convert the raw bytes to code and disassemble it
pasted below is a simple automation with an idc script but idas automation is imho subpar so you should stick with manual pressing of C in user interface
:dir /b
foo.dmp
foo.idc
:xxd foo.dmp
0000000: 6a10 6830 b780 7ce8 d86d ffff 8365 fc00 j.h0..|..m...e..
0000010: 64a1 1800 0000 8945 e081 7810 001e 0000 d......E..x.....
0000020: 750f 803d 0850 887c 0075 06ff 15f8 1280 u..=.P.|.u......
0000030: 7cff 750c ff55 0850 e8c9 0900 00 |.u..U.P.....
:type foo.idc
#include <idc.idc>
static main (void) {
auto len,temp,fhand;
len = -1; temp = 0;
while (temp < 0x3d && len != 0 ) {
len = MakeCode(temp);
temp = temp+len;
}
fhand = fopen("foo.asm","wb");
GenerateFile(OFILE_LST,fhand,0,0x3d,0x1F);
fclose(fhand);
Wait();
Exit(0);
}
:f:\IDA_FRE_5\idag.exe -c -B -S.\foo.idc foo.dmp
:head -n 30 foo.asm | tail
seg000:00000000 ; Segment type: Pure code
seg000:00000000 seg000 segment byte public 'CODE' use32
seg000:00000000 assume cs:seg000
seg000:00000000 assume es:nothing, ss:nothing, ds:nothing, fs:no thing, gs:nothing
seg000:00000000 push 10h
seg000:00000002 push 7C80B730h
seg000:00000007 call near ptr 0FFFF6DE4h
seg000:0000000C and dword ptr [ebp-4], 0
with windbg you can get the disassembly right from command line like this
:cdb -c ".dvalloc /b 60000000 2000;.readmem foo.dmp 60001000 l?0n61;u 60001000 60001040;q" calc
0:000> cdb: Reading initial command '.dvalloc /b 60000000 2000;.readmem foo.dmp 60001000 l?0n61;u 60001000 60001040;q'
Allocated 2000 bytes starting at 60000000
Reading 3d bytes.
60001000 6a10 push 10h
60001002 6830b7807c push offset kernel32!`string'+0x88 (7c80b730)
60001007 e8d86dffff call 5fff7de4
6000100c 8365fc00 and dword ptr [ebp-4],0
60001010 64a118000000 mov eax,dword ptr fs:[00000018h]
60001016 8945e0 mov dword ptr [ebp-20h],eax
60001019 817810001e0000 cmp dword ptr [eax+10h],1E00h
60001020 750f jne 60001031
60001022 803d0850887c00 cmp byte ptr [kernel32!BaseRunningInServerProcess (7c885008)],0
60001029 7506 jne 60001031
6000102b ff15f812807c call dword ptr [kernel32!_imp__CsrNewThread (7c8012f8)]
60001031 ff750c push dword ptr [ebp+0Ch]
60001034 ff5508 call dword ptr [ebp+8]
60001037 50 push eax
60001038 e8c9090000 call 60001a06
6000103d 0000 add byte ptr [eax],al
6000103f 0000 add byte ptr [eax],al
quit:
ollydbg 1.10 view-> file-> (mask any file) -> foo.dmp -> rightclick -> disassemble
[root# test]$ cat return10.c
#include <stdio.h>
int main(int argc, char *argv[]){
return 10;
}
[root# test]$ perl -e 'print system("/path_to_return10")'
2560
I was expecting 10 but got 2560,why?
See $? in perldoc perlvar.
You got 10 * 256 (return value = 10) + 0 * 128 (there was no core dump) + 0 (process wasn't killed by signal).
as specified in the documentation for the system call in perl (http://perldoc.perl.org/functions/system.html):
The return value is the exit status of the program as returned by the
wait call. To get the actual exit value, shift right by eight (see
below).
indeed: 2560 >> 8 = 10