Related
I'm trying to hook api function "NKDbgPrintfW" from coredll.dll.
I use import table in-memory patch. It works fine for main module (exe file).
It hooks all calls from exe, but does not from dll it uses.
I think root of problem is that exe and loaded dlls use own import table and I patch only exe's one.
I use next function to hook exe api calls:
Code:
DWORD ic_PatchProcImports ( HANDLE hProc, DWORD dFind, DWORD dReplace )
{
DWORD ret = 0;
/* GODMODE ON */
BOOL bOldKMode = SetKMode ( TRUE );
DWORD dOldPerms = SetProcPermissions ( 0xFFFFFFFF );
/* get process ptr prom handle */
HDATA * hProcHD = ( HDATA * ) ( 0x80000000 | ( ( DWORD ) hProc & HANDLE_ADDRESS_MASK ) );
PROCESS * prc = ( PROCESS * ) hProcHD->pvObj;
/* get imports sections */
struct ImpHdr * blockptr, * blockstart;
blockstart = ( struct ImpHdr * ) MapPtrProc ( prc->e32.e32_vbase + prc->e32.e32_unit[IMP].rva, prc );
/* iterate thru imports sections */
for ( blockptr = blockstart; blockptr->imp_lookup; ++blockptr )
{
DWORD dOldProtect, tmp;
/* get vectors ptr */
DWORD * vectors = ( DWORD * ) MapPtrProc ( prc->e32.e32_vbase + blockptr->imp_address, prc );
/* count vectors */
DWORD * vptr = vectors;
while ( * vptr ) ++vptr;
DWORD vcnt = ( vptr - vectors );
/* try to unlock imports section memory */
if ( VirtualProtect ( vectors, vcnt * sizeof ( DWORD ), PAGE_EXECUTE_READWRITE, &dOldProtect ) )
{
/* find&replace */
for ( UINT i = 0; i < vcnt; ++i )
{
if ( vectors[i] == dFind )
{
vectors[i] = dReplace;
++ret;
}
}
/* lock back */
VirtualProtect ( vectors, vcnt * sizeof ( DWORD ), dOldProtect, &tmp );
}
}
/* GODMODE OFF */
SetProcPermissions ( dOldPerms );
SetKMode ( bOldKMode );
/* */
return ret;
}
I tried to find import table in loaded dll module but failed.
Here is the code I used:
Code:
DWORD ic_PatchModuleImports ( HANDLE hProc, Module* mod, DWORD dFind, DWORD dReplace )
{
DWORD ret = 0;
/* GODMODE ON */
BOOL bOldKMode = SetKMode ( TRUE );
DWORD dOldPerms = SetProcPermissions ( 0xFFFFFFFF );
/* get process ptr prom handle */
HDATA * hProcHD = ( HDATA * ) ( 0x80000000 | ( ( DWORD ) hProc & HANDLE_ADDRESS_MASK ) );
PROCESS * prc = ( PROCESS * ) hProcHD->pvObj;
/* get imports sections */
ImpHdr *blockptr, *blockstart;
blockstart = ( ImpHdr * ) MapPtrProc(mod->e32.e32_vbase + mod->e32.e32_unit[IMP].rva, prc);
/* iterate thru imports sections */
for ( blockptr = blockstart; blockptr->imp_lookup; ++blockptr )
{
// NKDbgPrintfW(L"%s", blockptr->imp_dllname);
//DWORD dOldProtect, tmp;
/* get vectors ptr */
DWORD * vectors = ( DWORD * ) MapPtrProc(mod->e32.e32_vbase + blockptr->imp_address, prc);
/* count vectors */
DWORD * vptr = vectors;
while ( * vptr ) ++vptr;
DWORD vcnt = ( vptr - vectors );
/* try to unlock imports section memory */
//if ( VirtualProtect ( vectors, vcnt * sizeof ( DWORD ), PAGE_EXECUTE_READWRITE, &dOldProtect ) )
{
/* find&replace */
for ( UINT i = 0; i < vcnt; ++i )
{
NKDbgPrintfW(L"Serach for: %x; Found: %x", dFind, vectors[i]);
if ( vectors[i] == dFind )
{
vectors[i] = dReplace;
++ret;
}
}
/* lock back */
// VirtualProtect ( vectors, vcnt * sizeof ( DWORD ), dOldProtect, &tmp );
}
}
/* GODMODE OFF */
SetProcPermissions ( dOldPerms );
SetKMode ( bOldKMode );
/* */
return ret;
}
I'm looking for any way to hook this function, but I prefer in-memory import table patch..
Hello!
Perhaps this will help:
http://forum.xda-developers.com/showthread.php?t=372496
I am also working on a program that needs hooks. My problem right now is that I need to create the header with all the structure definitions (PROCESS, THREAD, ect). I found this but it is most likely for an older CE version as it was written in 2003:
http://nah6.com/~itsme/cvs-xdadevtools/itsutils/old/cenk.h
Do you have these definitions for wince 5.x?
I think, you can find it in Windows Mobile Platform SDK .
MS sells that SDK, but if you google it, you'll find a place where you can download it for free
I was working on a similar problem but I decided to make a generic hook that didn't rely only on import table. Thanks to itutils I was able to hook some functions until when I found out that there two methods for making api calls, the standard one and the "speedy" one. I wasn't able to hook any function that was using the second method and after a bit I gave up. How did you overcome this problem?
Any suggestion is welcome, thank you
I still have not solved my problem. I am trying to hook calls to keybd_event in coredll from keypad.dll. I think the root of the problem is that that keypad.dll is in ROM. Therefore the thunk table that is actually inside keypad.dll is not readable or writeable at runtime. I think there is a thunk table created in RAM somewhere else where the function pointers are actually stored. I can find it by analyzing keypad.dll and finding the hex location to where the runtime thunk table is, but I cant find a way to figure it out at runtime so that my hook will work with any dll.
I use the PerformCallback4 DLL hooking and it's working with ROM files. But I'd also be interested if there's a way to inject into a process without needing to load a separate DLL.
Well process injection is not my problem. I am trying to hook calls from a service dll. All I did was add my dll as a service and I am kindly loaded at boot. Its the hooking I cant get to work. How are you accomplishing the hook? I just want to hook all calls from other services to keybd_event.
What _exactly_ do you guys want to do? I may be able to assist.
I know the answers to most questions I see here, but I will simply not give out the code to do this, because it is "dangerous" code. By that I do not mean it is not somewhat reliable, but dangerous to commercial developers as these techniques allow you to crack pretty any commercial app with minimal effort...
(see my notice about having easily bypassed the MS Marketplace "advanced protection" on various news sites for an example of how bad this can be)
Actually I'd be curious to know how to hook an API that can use the kmode speedup, that is one that's using g_pKmodeEntries. I'm not interesting into cracking anything but at this point I'm curious to know how to go ahead.
Thanx for any help.
I heard that the DLL injection hooks won't work for WinCE 6.0 (--> WM 7) but what about the mentioned "kmode speedup"?
bbbird1 said:
Actually I'd be curious to know how to hook an API that can use the kmode speedup, that is one that's using g_pKmodeEntries. I'm not interesting into cracking anything but at this point I'm curious to know how to go ahead.
Thanx for any help.
Click to expand...
Click to collapse
Well there are various ways to patch functions out. The problem is that there are several ways that a kernel function can ultimately be called. Of course there are also various ways to go about patching these functions. To name a few:
(1) Patch the apiset tables and overwrite the function address the trap jumps to. If this is the same table and address are used for the g_pKmodeEntries jump I am not sure - you would have to do some IDA'ing / testing to figure that one out
(2) Patch the import tables of the executable / dll calling this function, if you have a specific target in mind (with some small trickery this can be adapted to also patch 'dynamic imports', i.e. GetProcAddress, even after the call was made)
(3) Patch the export table of coredll (actually if this one matches your wishes, I usually use 4 instead)
(4) Patch the function inside coredll directly by (saving first and then) overwriting the first few instructions with a jump to your code
(5) Patch the actual function inside nk or the other exe server (closely related to 4)
Each method has it's own pros and cons, injection/controlled-leak/code requirements and may or may not work with certain way of calling the function. Some of these patches are much more difficult to do than others...
You'd have to figure out for your function which method might actually work. For example I usually have great results with method 4, however it will not catch some ways of kernel-internal calls, so you have to confirm first with some heavy IDA'ing to see if internal calls exist (completely bypassing coredll, for most functions they actually don't). Unfortunately that I recall I have not tried patching any g_pKmodeEntries intentionally (as in I might have patched such functions, but not knowingly).
RAMMANN said:
I heard that the DLL injection hooks won't work for WinCE 6.0 (--> WM 7) but what about the mentioned "kmode speedup"?
Click to expand...
Click to collapse
Well we'd pretty much have to start from scratch again, figuring a lot of stuff out, but I'm sure we'll find new and exciting ways of hooking kmode speedup might still be there, though, but likely in a different form.
Chainfire said:
What _exactly_ do you guys want to do? I may be able to assist.
I know the answers to most questions I see here, but I will simply not give out the code to do this, because it is "dangerous" code. By that I do not mean it is not somewhat reliable, but dangerous to commercial developers as these techniques allow you to crack pretty any commercial app with minimal effort...
(see my notice about having easily bypassed the MS Marketplace "advanced protection" on various news sites for an example of how bad this can be)
Click to expand...
Click to collapse
Hello chainfire! I am trying to hook keyboard events comming from the keypad driver. There is a service that runs to detect key interrupts and when it does detect them it calls keybd_event to broadcast the event. keybd_event is in coredll. The keypad service is loaded from keypad.dll (in most ROMs). So I want to hook calls from keypad.dll to keybd_event in coredll. The problem is that I want it to work regardless of ROM version and there are different versions of keypad.dll, and some ROMs dont have it at all. Therefore I want to hook all calls to keybd_event from services. I added my dll as a service so injection method is not a problem. Now I need to hook.
Using IDA I found the address of the IAT in keypad, but the IAT that exists in the dll itself is not readable or writeable. It seems that there is a thunk table that gets created in RAM separate from where the dll is loaded. Each process seems to create it's own RAM thunk table for loaded dlls (my guess is just those in ROM). I dont know how to programmatically find these thunk tables.
Do I make sense? This is of course targeting WM6.x (wce5). I just need some way to hook calls to keybd_event from all dlls loaded in the current process. Some of those dlls may be in ROM but they need to be hooked too.
Chainfire said:
Well there are various ways to patch functions out. The problem is that there are several ways that a kernel function can ultimately be called. Of course there are also various ways to go about patching these functions. To name a few:
(1) Patch the apiset tables and overwrite the function address the trap jumps to. If this is the same table and address are used for the g_pKmodeEntries jump I am not sure - you would have to do some IDA'ing / testing to figure that one out
(2) Patch the import tables of the executable / dll calling this function, if you have a specific target in mind (with some small trickery this can be adapted to also patch 'dynamic imports', i.e. GetProcAddress, even after the call was made)
(3) Patch the export table of coredll (actually if this one matches your wishes, I usually use 4 instead)
(4) Patch the function inside coredll directly by (saving first and then) overwriting the first few instructions with a jump to your code
(5) Patch the actual function inside nk or the other exe server (closely related to 4)
Each method has it's own pros and cons, injection/controlled-leak/code requirements and may or may not work with certain way of calling the function. Some of these patches are much more difficult to do than others...
You'd have to figure out for your function which method might actually work. For example I usually have great results with method 4, however it will not catch some ways of kernel-internal calls, so you have to confirm first with some heavy IDA'ing to see if internal calls exist (completely bypassing coredll, for most functions they actually don't). Unfortunately that I recall I have not tried patching any g_pKmodeEntries intentionally (as in I might have patched such functions, but not knowingly).
Well we'd pretty much have to start from scratch again, figuring a lot of stuff out, but I'm sure we'll find new and exciting ways of hooking kmode speedup might still be there, though, but likely in a different form.
Click to expand...
Click to collapse
I like the sound of (3). Why Use (4) instead? How do you find the export table programmatically? If I use this method, as long as my service is loaded first it should work.
Ok I just tried something and it worked. It seems that these RAM thunk tables are always loaded at 0x01bb5000 for every process. The following code worked:
Code:
coremod = GetModuleHandle(L"coredll.dll");
o_keybd_event = (_keybd_event)GetProcAddress(coremod, L"keybd_event");
my_kbe = (DWORD)(my_keybd_event);
addr = (DWORD*)(0x01bb5000);
VirtualProtect(addr, 4, PAGE_READWRITE, NULL);
while(ReadProcessMemory(GetCurrentProcess(), addr, &dat, 4, NULL))
{
if(dat == (DWORD)o_keybd_event)
{
WriteProcessMemory(GetCurrentProcess(), addr, &my_kbe, 4, NULL);
kbe_hkd = TRUE;
}
addr++;
VirtualProtect(addr, 4, PAGE_READWRITE, NULL);
}
The thunk tables seem to be back to back and ReadProcessMemory seems to always fail at the end of them, so the loop does not run too long. Chainfire, does this make sense to you?
JKingDev said:
...
Do I make sense? This is of course targeting WM6.x (wce5). I just need some way to hook calls to keybd_event from all dlls loaded in the current process. Some of those dlls may be in ROM but they need to be hooked too.
Click to expand...
Click to collapse
Using IAT patch to do this is certainly possible but a lengthy process as you'd have to keep track for all dll loads in services.exe and patch each and every dll as it loads. One of the other methods I described may fit better.
JKingDev said:
I like the sound of (3). Why Use (4) instead? How do you find the export table programmatically? If I use this method, as long as my service is loaded first it should work.
Click to expand...
Click to collapse
(3) is actually (IMHO) a very annoying patch to implement. It doesn't easily allow you to patch/unpatch at will. It doesn't cover coredll-internal jumps. The timing/load-order has to be perfect. It requires slightly more memory. And because you have to load it before anything else if you screw something up there's a good chance you'll need a hard-reset to recover (that's a real ***** with testing!). You can get the export table from the e32 structure of the module, though it isn't always easily patched
JKingDev said:
Ok I just tried something and it worked. It seems that these RAM thunk tables are always loaded at 0x01bb5000 for every process. The following code worked:
The thunk tables seem to be back to back and ReadProcessMemory seems to always fail at the end of them, so the loop does not run too long. Chainfire, does this make sense to you?
Click to expand...
Click to collapse
ROM DLLs create a seperate data section in memory for every process it is loaded into, the IAT is also stored there. Note that the addresses / virtual memory are the same across processes, but different physical memory is used for each process (same as data sections for normal DLLs, though those are located at the normal addresses). To figure out where this memory is look at the rwLow and rwHigh members of the PMODULE structure. (actually I'm surprised you found the location without this )
Chainfire said:
ROM DLLs create a seperate data section in memory for every process it is loaded into, the IAT is also stored there. Note that the addresses / virtual memory are the same across processes, but different physical memory is used for each process (same as data sections for normal DLLs, though those are located at the normal addresses). To figure out where this memory is look at the rwLow and rwHigh members of the PMODULE structure. (actually I'm surprised you found the location without this )
Click to expand...
Click to collapse
That is the vital info I needed! Quick question, do I start searching at rwLow and end at rwHigh, or start at rw Low and end at rwLow+rwHigh?
Thanks!
*edit* Answering my own question, start searching at rwLow and end at rwHigh. I was still having problems because my MODULE structure definition is incorrect, but I was able to find where the information I needed was so it doesnt really matter. Thanks so much!!
Hi @all,
i want to compile the mplayer for Android.
The only "How-To" i found is this.
Maybe someone with more experience in cross-compiling can give me some more hint.
thanks
peter
Take a look at that, can probaly be helpful
http://forum.xda-developers.com/showthread.php?t=431329
compile finished
@mopodo
thanks, i think i have done
sandmen said:
@mopodo
thanks, i think i have done
Click to expand...
Click to collapse
Did you get it to run?
mplayer run's.
But i have some trouble to set VSCREENINFO.
Maybe wrong video fromat.
So I have to check some different video's.
what about audio? looking at some posts in the MPLAYER discussion VSCREENINFO issues appear to be something to do with framebuffer of the kernel.
I've been trying to get audio working, although in a Magic 32B, but I have failed so far.
Do you Hero owners see /dev/dsp or /dev/snd0 ?
Do you get any audio at all? If so, using what device?
From the very limited information I've managed to get so far, Dream owners do get sound, though I have no idea how and why.
I've used the how-to mentioned in the first post, no success so far.
Perhaps this helps: read-write access for /dev/msm_pcm_out
So chmod this device file and use it as audio out?
I'm actually curious about how a native linux app would render video on android. There is no X so framebuffer would be the only way. But then, how do you get user in/output?
status mplayer crosscompilation
@all
follow things i have tryed:
- Crosscompiling svn-version mplayer, there i have some segmentation fault's.
doesn't work
- Crosscompiling Mplayer1.02 (old version) there i have trouble to set VSCREENINFO.
So it takes time
If anybody have some hints, about crosscompiling, feel free.
sandmen said:
@all
follow things i have tryed:
- Crosscompiling svn-version mplayer, there i have some segmentation fault's.
doesn't work
- Crosscompiling Mplayer1.02 (old version) there i have trouble to set VSCREENINFO.
So it takes time
If anybody have some hints, about crosscompiling, feel free.
Click to expand...
Click to collapse
I managed to compile a working (by working I mean no segfault ) version of SVN-r29796 with the following config:
./configure --enable-fbdev --host-cc=gcc --target=arm --cc=arm-none-linux-gnueabi-gcc --as=arm-none-linux-gnueabi --ar=arm-none-linux-gnueabi-ar --ranlib=arm-none-linux-gnueabi-ranlib --enable-static
The resulting binary can be found here:
http://www.megaupload.com/?d=142QK29B
Together we can solve this, sandmen
What we need now is a Dream user to confirm that audio works on that hardware...
@Djhg2000
you can play a video without sound?
sandmen said:
@Djhg2000
you can play a video without sound?
Click to expand...
Click to collapse
No, I get the VSCREENINFO error. It does decode video though if I use "-vo null -ao null", but what probably won't get us anywhere...
I've heard the VSCREENINFO problem is a kernel bug, can anyone confirm this?
I don't have the time to look into it now, but maybe we can make a patch to workaround the problem?
Edit:
It seems like this piece of code in libvo/vo_fbdev.c is causing the problem:
Code:
if (ioctl(fb_dev_fd, FBIOGET_VSCREENINFO, &fb_vinfo)) {
mp_msg(MSGT_VO, MSGL_ERR, "Can't get VSCREENINFO: %s\n", strerror(errno));
goto err_out;
}
These lines can be found at 685-688 in r29796.
The problem is that my C skills are very limited and I have no idea what "&fb_vinfo" should be... C coders please help?
Typing "ioctl FBIOGET_VSCREENINFO" returns "ioctl: too few arguments".
Typing "ioctl FBIOGET_VSCREENINFO 0" returns "cannot open FBIOGET_VSCREENINFO"
From the information I can gather, ioctl seems to be a tool to pass instructions directly to drivers?
Yeah, it finally seems like we're getting somewhere
us1111 said:
Perhaps this helps: read-write access for /dev/msm_pcm_out
So chmod this device file and use it as audio out?
I'm actually curious about how a native linux app would render video on android. There is no X so framebuffer would be the only way. But then, how do you get user in/output?
Click to expand...
Click to collapse
I've tried this, "-ao oss:/dev/msm_pcm_out" gives "Can't set audio device /dev/msm_pcm_out to s16le output, trying s16le...".
"-ao pcm:file=/dev/msm_pcm_out" hangs MPlayer at the "Starting playback..." message.
"-ao pcm:file=/dev/msm_pcm_out -v" hangs MPlayer with the line "Increasing filtered audio buffer size from 0 to 65536".
So yes, it might be the right device, but I can't get it to work.
Perhaps you could download the binary and see if you get different results on a Hero?
@Djhg2000
Did you get the "get VSCREENINFO" error or the "put VSCREENINFO"
sandmen said:
@Djhg2000
Did you get the "get VSCREENINFO" error or the "put VSCREENINFO"
Click to expand...
Click to collapse
Wow, do I feel stupid
Of course it's the put VSCREEN error, here is the correct code from libvo/vo_fbdev.c:
Code:
if (ioctl(fb_dev_fd, FBIOPUT_VSCREENINFO, &fb_vinfo)) {
mp_msg(MSGT_VO, MSGL_ERR, "Can't put VSCREENINFO: %s\n", strerror(errno));
if (fb_tty_fd >= 0 && ioctl(fb_tty_fd, KDSETMODE, KD_TEXT) < 0) {
mp_msg(MSGT_VO, MSGL_ERR, "Can't restore text mode: %s\n", strerror(errno));
}
return 1;
}
This is at lines 814-820 in r29796.
It seems like the problem mostly remains the same.
However, I can't debug it properly (yet!) due to my lack of skills in C .
I'm making slow progress in understanding the real problem, but at least I'm learning some C while I'm doing it
Edit:
I've looked through the sources and I just can't figure it out:
Code:
static struct fb_var_screeninfo fb_vinfo;
means that fb_vinfo should look like fb_var_screeninfo, right?
But fb_var_screeninfo itself (defined in linux/fb.h) looks like this (copied directly form android kernel git tree):
Code:
struct fb_var_screeninfo {
__u32 xres; /* visible resolution */
__u32 yres;
__u32 xres_virtual; /* virtual resolution */
__u32 yres_virtual;
__u32 xoffset; /* offset from virtual to visible */
__u32 yoffset; /* resolution */
__u32 bits_per_pixel; /* guess what */
__u32 grayscale; /* != 0 Graylevels instead of colors */
struct fb_bitfield red; /* bitfield in fb mem if true color, */
struct fb_bitfield green; /* else only length is significant */
struct fb_bitfield blue;
struct fb_bitfield transp; /* transparency */
__u32 nonstd; /* != 0 Non standard pixel format */
__u32 activate; /* see FB_ACTIVATE_* */
__u32 height; /* height of picture in mm */
__u32 width; /* width of picture in mm */
__u32 accel_flags; /* (OBSOLETE) see fb_info.flags */
/* Timing: All values in pixclocks, except pixclock (of course) */
__u32 pixclock; /* pixel clock in ps (pico seconds) */
__u32 left_margin; /* time from sync to picture */
__u32 right_margin; /* time from picture to sync */
__u32 upper_margin; /* time from sync to picture */
__u32 lower_margin;
__u32 hsync_len; /* length of horizontal sync */
__u32 vsync_len; /* length of vertical sync */
__u32 sync; /* see FB_SYNC_* */
__u32 vmode; /* see FB_VMODE_* */
__u32 rotate; /* angle we rotate counter clockwise */
__u32 reserved[5]; /* Reserved for future compatibility */
};
Which is identical to the same struct in Ubuntu's kernel tree?
My conclusion so far is that one of these parameters are unsupported by the HTC Magic's graphics driver, but not the HTC Dream graphics driver?
I have no idea why the driver would even differ between them; they both use the same graphics chip, don't they?
Djhg2000 said:
I've tried this, "-ao oss:/dev/msm_pcm_out" gives "Can't set audio device /dev/msm_pcm_out to s16le output, trying s16le...".
"-ao pcm:file=/dev/msm_pcm_out" hangs MPlayer at the "Starting playback..." message.
"-ao pcm:file=/dev/msm_pcm_out -v" hangs MPlayer with the line "Increasing filtered audio buffer size from 0 to 65536".
So yes, it might be the right device, but I can't get it to work.
Perhaps you could download the binary and see if you get different results on a Hero?
Click to expand...
Click to collapse
I assume you have root ?
try
chmod o+rw /dev/msm_pcm_out
Jesterz said:
I assume you have root ?
try
chmod o+rw /dev/msm_pcm_out
Click to expand...
Click to collapse
Already tried that, I usually use root when debugging inside of Android, but not even "chmod 777 /dev/msm_pcm_out" helps.
I noticed there might be some relevant libraries in android:
/lib//libaudio.so
/lib/libhardware.so
/lib/libhtc_acoustics.so
/lib/libmedia.so
/lib/libmm-adspsvc.so
/lib/libopencore_player.so
/lib/libsoundpool.so
/lib/bluez-plugin/audio.so
Surely at least one of these libraries can provide a way to output audio?
Except maybe that bluez thing
I want to be a beta tester. My device is HTC Dream (g1).
1: pcm is the way to go. If you run mplayer -ao help, does it list pcm?
2: you can try compiling mplayer along with support for a sound server like pulseaudio, which would mean that you would need to add that package too...
Krasimir said:
I want to be a beta tester. My device is HTC Dream (g1).
Click to expand...
Click to collapse
Great, finally a Dream user (maybe thread should be moved to the Dream Development sub forum, as that's where people look for general android discussions).
Anyway, it's publicly available here:
http://www.megaupload.com/?d=142QK29B
Version SVN-r29796 for now, will probably upgrade later and post link here.
Save it to a SD card and use 'sh mplayer mediafilegoeshere.example -ao oss:/dev/msm_pcm_out' and post the results here.
Since you have a HTC Dream, it would be great if you could confirm it working/broken without the '-ao oss:/dev/msm_pcm/out' part.
Thanks for your help
Hi, right been looking at the Hero CDMA Kernel trying to get direct access to the light sensor.
I know its part of I2C, and have found some documentation, but its completely over my head! Anyone smarter than me know what this means/how to use it?
Thanks
Usually, i2c devices are controlled by a kernel driver. But it is also
possible to access all devices on an adapter from userspace, through
the /dev interface. You need to load module i2c-dev for this.
Each registered i2c adapter gets a number, counting from 0. You can
examine /sys/class/i2c-dev/ to see what number corresponds to which adapter.
I2C device files are character device files with major device number 89
and a minor device number corresponding to the number assigned as
explained above. They should be called "i2c-%d" (i2c-0, i2c-1, ...,
i2c-10, ...). All 256 minor device numbers are reserved for i2c.
C example
=========
So let's say you want to access an i2c adapter from a C program. The
first thing to do is "#include <linux/i2c-dev.h>". Please note that
there are two files named "i2c-dev.h" out there, one is distributed
with the Linux kernel and is meant to be included from kernel
driver code, the other one is distributed with lm_sensors and is
meant to be included from user-space programs. You obviously want
the second one here.
Now, you have to decide which adapter you want to access. You should
inspect /sys/class/i2c-dev/ to decide this. Adapter numbers are assigned
somewhat dynamically, so you can not even assume /dev/i2c-0 is the
first adapter.
Next thing, open the device file, as follows:
int file;
int adapter_nr = 2; /* probably dynamically determined */
char filename[20];
sprintf(filename,"/dev/i2c-%d",adapter_nr);
if ((file = open(filename,O_RDWR)) < 0) {
/* ERROR HANDLING; you can check errno to see what went wrong */
exit(1);
}
When you have opened the device, you must specify with what device
address you want to communicate:
int addr = 0x40; /* The I2C address */
if (ioctl(file,I2C_SLAVE,addr) < 0) {
/* ERROR HANDLING; you can check errno to see what went wrong */
exit(1);
}
Well, you are all set up now. You can now use SMBus commands or plain
I2C to communicate with your device. SMBus commands are preferred if
the device supports them. Both are illustrated below.
__u8 register = 0x10; /* Device register to access */
__s32 res;
char buf[10];
/* Using SMBus commands */
res = i2c_smbus_read_word_data(file,register);
if (res < 0) {
/* ERROR HANDLING: i2c transaction failed */
} else {
/* res contains the read word */
}
/* Using I2C Write, equivalent of
i2c_smbus_write_word_data(file,register,0x6543) */
buf[0] = register;
buf[1] = 0x43;
buf[2] = 0x65;
if ( write(file,buf,3) != 3) {
/* ERROR HANDLING: i2c transaction failed */
}
/* Using I2C Read, equivalent of i2c_smbus_read_byte(file) */
if (read(file,buf,1) != 1) {
/* ERROR HANDLING: i2c transaction failed */
} else {
/* buf[0] contains the read byte */
}
IMPORTANT: because of the use of inline functions, you *have* to use
'-O' or some variation when you compile your program!
Full interface description
==========================
The following IOCTLs are defined and fully supported
(see also i2c-dev.h):
ioctl(file,I2C_SLAVE,long addr)
Change slave address. The address is passed in the 7 lower bits of the
argument (except for 10 bit addresses, passed in the 10 lower bits in this
case).
ioctl(file,I2C_TENBIT,long select)
Selects ten bit addresses if select not equals 0, selects normal 7 bit
addresses if select equals 0. Default 0. This request is only valid
if the adapter has I2C_FUNC_10BIT_ADDR.
ioctl(file,I2C_PEC,long select)
Selects SMBus PEC (packet error checking) generation and verification
if select not equals 0, disables if select equals 0. Default 0.
Used only for SMBus transactions. This request only has an effect if the
the adapter has I2C_FUNC_SMBUS_PEC; it is still safe if not, it just
doesn't have any effect.
ioctl(file,I2C_FUNCS,unsigned long *funcs)
Gets the adapter functionality and puts it in *funcs.
ioctl(file,I2C_RDWR,struct i2c_rdwr_ioctl_data *msgset)
Do combined read/write transaction without stop in between.
Only valid if the adapter has I2C_FUNC_I2C. The argument is
a pointer to a
struct i2c_rdwr_ioctl_data {
struct i2c_msg *msgs; /* ptr to array of simple messages */
int nmsgs; /* number of messages to exchange */
}
The msgs[] themselves contain further pointers into data buffers.
The function will write or read data to or from that buffers depending
on whether the I2C_M_RD flag is set in a particular message or not.
The slave address and whether to use ten bit address mode has to be
set in each message, overriding the values set with the above ioctl's.
Other values are NOT supported at this moment, except for I2C_SMBUS,
which you should never directly call; instead, use the access functions
below.
You can do plain i2c transactions by using read(2) and write(2) calls.
You do not need to pass the address byte; instead, set it through
ioctl I2C_SLAVE before you try to access the device.
You can do SMBus level transactions (see documentation file smbus-protocol
for details) through the following functions:
__s32 i2c_smbus_write_quick(int file, __u8 value);
__s32 i2c_smbus_read_byte(int file);
__s32 i2c_smbus_write_byte(int file, __u8 value);
__s32 i2c_smbus_read_byte_data(int file, __u8 command);
__s32 i2c_smbus_write_byte_data(int file, __u8 command, __u8 value);
__s32 i2c_smbus_read_word_data(int file, __u8 command);
__s32 i2c_smbus_write_word_data(int file, __u8 command, __u16 value);
__s32 i2c_smbus_process_call(int file, __u8 command, __u16 value);
__s32 i2c_smbus_read_block_data(int file, __u8 command, __u8 *values);
__s32 i2c_smbus_write_block_data(int file, __u8 command, __u8 length,
__u8 *values);
All these transactions return -1 on failure; you can read errno to see
what happened. The 'write' transactions return 0 on success; the
'read' transactions return the read value, except for read_block, which
returns the number of values read. The block buffers need not be longer
than 32 bytes.
The above functions are all macros, that resolve to calls to the
i2c_smbus_access function, that on its turn calls a specific ioctl
with the data in a specific format. Read the source code if you
want to know what happens behind the screens.
Click to expand...
Click to collapse
Surely if you want to use the light sensor in an application, the correct path is via API calls, or do you have other intentions?
Regards,
Dave
Ideally yes, but when you use the API to get the light sensor values, you get the accelerometer values instead! Interesting its similar on the Samsung Moment, asking for the light sensor values returns the compass values!
Seems neither HTC or Samsung know what they are doing!
[2012/06/03] IMPORTANT UPDATE HERE
Hi hackers,
This is meant as a little update on one of the projects I've been working on. I'm kinda stuck now. I have a suspicion of what the problem is. I thought that maybe if I write a post about it, me or someone else will have an idea on how to get this working.
The goal is to run native homebrew executables on WP7
This has not been done yet. All apps are Silverlight apps that are compiled as DLL and run by Taskhost.exe with least privileges. All other executables are signed by Microsoft. Executables that are compiled as ARM executable cannot be started.
The angle is to create a certificate that allows to sign a WP7 executable. Then add that to the appropriate certificate store. Create an executable. Sign it with the private key. Load it onto a WP7 device. Copy it to the Windows folder. Use an OEM driver to launch the executable.
First I did research on the certificate stores. I can now with certainty state that there are 4 certificate stores:
- CA
- Root
- My
- Code Integrity
After a lot of research I finally got complete read/write access to all of these stores. The Code Integrity store contains all the certificates that are used by the Loader Verifier to verify the executable that is being launched. When the device is launched for the first time, the certificates that are in \Windows\ciroots.p7b are installed to that certificate store. These certificates have these properties:
Key Usage = 0x86 = Digital Signature, Certificate Signing, Off-line CRL Signing, CRL Signing
Entended Key Usage = Code Signing (1.3.6.1.5.5.7.3.3) + Unknown key usage (1.3.6.1.4.1.311.10.3.14)
So I used OpenSSL to create such an certificate (with private key) for myself. And I installed the certificate in the Code Integrity store.
I then used VS2008 to create a completely barebone executable (ARMv4 Console app with only Sleep(-1) in the Main). I signed it with SignTool from Microsoft.
I loaded the executable to my device and I copied it to the \Windows folder (I think the policies restrict executing to only from that folder, but I'm not sure about that).
I use the Samsung driver to launch the executable, because I need at least Standard Rights to launch an executable. The Samsung driver has Elevated Rights. My own app has only Least Privileges. Using the Samsung driver does not return any success or fail codes. But looking at the Running Processes list, I don't see my Test.exe running. It should be, because the main thread is put to sleep infinitely.
So why is this not working?
Well, I have a guess. I think it's the policies that bind the certificates in the Code Integrity store to the different accounts/chambers. In the \Windows folder there are a lot of policy xml-files. On fist boot, these are merged into PolicyCommit.xml and then compiled to policydb.vol. When the Loader Verifier (lvmod.dll) loads an executable, it queries the policies to determine access rights and chamber for that executable. The policies that matter in this context are defined in 8314B832-8D03-444f-9A2A-1EF6FADCC3B8.policy.xml. It's an xml-file that basically says this:
Code:
Microsoft Mobile Device Privileged PCA - ced778d7bb4cb41d26c40328cc9c0397926b4eea - not used in this context
Microsoft Mobile Device TCB PCA - 88bcaec267ef8b366c6e6215ac4028e7a1be2deb - honored by System Identity Group
Microsoft Mobile Device Unprivileged PCA - 1c8229f5c8d6e256bdcb427cc5521ec2f8ff011a - honored by Standard Right Identity Group
Microsoft Mobile Device VSD PCA - 91b318116f8897d2860733fdf757b93345373574 - not used in this context
VeriSign Mobile Root Authority for Microsoft - 069dbcca9590d1b5ed7c73de65795348e58d4ae3 - honored by LPC Identity Group
I should find a way to add a policy with my certificate in it. Any ideas?
Ciao,
Heathcliff74
If you are able to re-sign an executable that is already in the ROM, i would try that, so you know the problem isn't within the native code, but only with the signing. Or maybe the other way round which would be awesome.
regards
Flow WP7 said:
If you are able to re-sign an executable that is already in the ROM, i would try that, so you know the problem isn't within the native code, but only with the signing. Or maybe the other way round which would be awesome.
regards
Click to expand...
Click to collapse
That's a good idea. I must say that I don't have much faith in the current RecMod tools for WP7 right now. I am able to get the binaries recmodded so that I can disassemble them correctly. But I don't think they can be easily launched. But there are executables that are on the rom as complete binaries, instead of rom-modules. To begin with, I have to select one that does not need much privileges to run and try to sign that one and then run it.
I'm really busy with work right now, so I think I won't be able to try it until the day after tomorrow. But I will try it and will let know how that went.
Thanks!
Decompiled taskhost.exe, so it gets more easy for us to see if its able to make taskhost to start another exe for us. Lots of code tho (C code).
taskhost.c (276 KB) in attachments.
edit: Oh, WOW, this really shows how to call those anonymous methods without call signature "Hello" (signature: "??z_Hello_?mze")
Hmm, pretty much about the pause part?
Code:
if ( v10 )
{
a7 = sub_178E7(v10);
if ( a7 >= 0 )
{
a7 = sub_180A5(v7, v7 + 64);
if ( a7 >= 0 )
{
a7 = ThemeInitialize(v7 + 136);
if ( a7 >= 0 )
{
v11 = sub_1862B(v13, v7);
EnableHostAutoDehydration(v11 == 3);
v16 = 0;
a7 = InitializeEmClientEx(&a2, 0, &v16);
if ( a7 >= 0 )
{
a7 = RegisterPausedHostCallback(sub_19D0D, 0);
if ( a7 >= 0 )
{
a7 = RegisterResumingHostCallback(sub_19D31, 0);
if ( a7 >= 0 )
{
if ( v11 != 3
|| (a7 = RegisterDehydrateHostCallback(sub_19D76, 0), a7 >= 0)
&& (a7 = RegisterFreezeHostCallback(sub_19D97, 0), a7 >= 0) )
{
a7 = RegisterExitHostCallback(sub_19D55, 0);
if ( a7 >= 0 )
a7 = sub_17C0A(*(_DWORD *)(v7 + 128), 0);
}
}
}
}
}
}
}
}
UIX framework entry-point (exe)
Code:
int __cdecl sub_11114(int a1, int a2, int a3)
{
int v4; // [sp+0h] [bp-38h]@1
char Dst; // [sp+4h] [bp-34h]@1
int v6; // [sp+8h] [bp-30h]@1
int v7; // [sp+Ch] [bp-2Ch]@1
int v8; // [sp+18h] [bp-20h]@1
int v9; // [sp+28h] [bp-10h]@1
v4 = 0;
memset(&Dst, 0, 0x34u);
v8 = a3;
v6 = (int)L"res://FlightModeUXDLL!FlightMode.uix";
v7 = (int)L"FMMain";
v9 = 2;
RunApplication(&v4);
return dword_12034;
}
C++ converted
Code:
UIXApplicationInfo app;
app { ... }
RunApplication(&app);
struct UIXApplicationInfo
{
int UNK_v4 = 0;
char Dst = {0};
char* uixFile;
char* uixEntryPoint;
int UNK_v8;
int UNK_v9 = 2;
}
Then just figure out the UIX part (or test the existing "res://FlightModeUXDLL!FlightMode.uix" if it launches, if so, we made it).
___
Found this in mango dump:
> Uninstall provxml
Code:
<!-- Uninstall Xbox LIVE Extras App -->
<characteristic type="AppInstall">
<nocharacteristic type="{0c17d153-b5d5-df11-a844-00237de2db9e}"/>
</characteristic>
Is there a reason you can't just use COM interop to run native code? Check out this thread for a discussion covering the technique: http://forum.xda-developers.com/showthread.php?t=820455
athompson said:
Is there a reason you can't just use COM interop to run native code? Check out this thread for a discussion covering the technique: http://forum.xda-developers.com/showthread.php?t=820455
Click to expand...
Click to collapse
Hello "co-founder of native code on WP7"
I'm fully aware of the possibility of native code through COM. I use it for example in the WP7 Root Tools. But I just wanted to take it a step further. Running native executables give a lot more freedom. Not being bound to the watchdog, getting higher privileges and running in the background for instance. But there's a whole lot more. So that's why I started research on it. Thanks anyway. You helped making native code possible on WP7.
Ciao,
Heathcliff74
The taskhost.exe is our RAM, because our app run in it, giving us full RAM access inside our "viritual ram". So that means we own all strings, int, floats etc. Then rewrite the ram to change strings in mscorlib. The checksum if an exe has been modified is only checked at startup, without checking if we modify the dll at runtime.
My purpose with this is that some function's call external apps, where we rewrite the args going in to the function. Just find an exploitable function and modify it after JIT has been there one before generating the pre ram, that we modify and call yet again but with the modified ram values behind.
Marshal.Copy, my friends, there.
[SecurityFuckingSafeCritical]
(byte[] source, IntPtr destination, int length)
> Interopservices leaked dll (\windows)
destination = our ram ptr to modify.
fiinix said:
The taskhost.exe is our RAM, because our app run in it, giving us full RAM access inside our "viritual ram". So that means we own all strings, int, floats etc. Then rewrite the ram to change strings in mscorlib. The checksum if an exe has been modified is only checked at startup, without checking if we modify the dll at runtime.
My purpose with this is that some function's call external apps, where we rewrite the args going in to the function. Just find an exploitable function and modify it after JIT has been there one before generating the pre ram, that we modify and call yet again but with the modified ram values behind.
Marshal.Copy, my friends, there.
[SecurityFuckingSafeCritical]
(byte[] source, IntPtr destination, int length)
> Interopservices leaked dll (\windows)
destination = our ram ptr to modify.
Click to expand...
Click to collapse
Hmmm. 10 Points for inventiveness But I don't think it's going to work. Even if you could find a function where the executable is passed as argument you still don't have enough privileges. Most code will have the path to the executable hardcoded instead of an argument. And you will still run under TaskHost with Least Privileges. And you need to have at least Standard Privileges or higher to launch most executables with CreateProcess() or ShellExecuteEx().
Sent from my OMNIA7 using XDA Windows Phone 7 App
Heathcliff74 said:
Hmmm. 10 Points for inventiveness But I don't think it's going to work. Even if you could find a function where the executable is passed as argument you still don't have enough privileges. Most code will have the path to the executable hardcoded instead of an argument. And you will still run under TaskHost with Least Privileges. And you need to have at least Standard Privileges or higher to launch most executables with CreateProcess() or ShellExecuteEx().
Sent from my OMNIA7 using XDA Windows Phone 7 App
Click to expand...
Click to collapse
"And you will still run under TaskHost with Least Privileges"
I know, i dont need standard rights to do it. Because i call a mscorlib function that is trusted code. I think you saw my idea wrong, let me show you.
[mscorlib, SecuritySafeCritical]
public static void example(string str)
{
string mscorlibStr = "you cant change my value ";
Debug.WriteLine(mscorlibStr + str);
}
This is where we modify "mscorlibStr" in ram and the function is still trusted code. But its doing something totally different from that it would do.
fiinix said:
"And you will still run under TaskHost with Least Privileges"
I know, i dont need standard rights to do it. Because i call a mscorlib function that is trusted code. I think you saw my idea wrong, let me show you.
[mscorlib, SecuritySafeCritical]
public static void example(string str)
{
string mscorlibStr = "you cant change my value ";
Debug.WriteLine(mscorlibStr + str);
}
This is where we modify "mscorlibStr" in ram and the function is still trusted code. But its doing something totally different from that it would do.
Click to expand...
Click to collapse
I really hate to break it for you. But the [SecuritySafeCritical] is indeed trusted code, but it will still check your privileges. All the API functions that do system modifications like that, do the security checks. Read the note under SecuritySafeCriticalAttribute here. Also read this; same problem. You are in process TaskHost.exe and it is launched in LPC (Least Privilege Chamber), so every CeImpersonateToken() to do the important stuff will fail and return an error code. I also wouldn't know how you would modify the stack-frame of a function that you call. Seems impossible to me, because at the moment you call the function, that stack-frame has not been allocated yet.
Anyway, although I don't think that is going to work in any way, I absolutely don't want to discourage you, because my experience is that when you try enough, sooner or later you will find an exploit
Ciao,
Heathcliff74
Currently installing "Windows Embeded Compact 7", because this lousy ARMv4 compiler (from WM5-6) maybe generates wrong ARM op-codes (WP7 runs ARMv7), therefore it says "Invalid program signature" (or what error it was).
Maybe ARMv7 is'nt even backwards compatibility with ARMv4.
By compiling with the ARMv7 compiler from WEM7, it will probably (hope) generate a valid exe.
Thats it..
edit:
*Research
"Armv7 is the processor instruction set used starting with the S5L8920 in the iPhone 3GS and in all subsequent devices. Processors that support Armv7 instructions are backward compatible with Armv6 instructions, but attempting to run binaries compiled for Arm7 on older, Armv6 processors will result in the error: "Bad CPU type in executable"."
Source: http://theiphonewiki.com/wiki/index.php?title=Armv7
___
"As I said in the past, the ARMv6 CTR was kept backwards compatible with
> > > earlier versions of the ARM architecture (and ARM tried to keep it like
> > > this as much as possible). With ARMv7, you have multiple levels of cache
> > > and different types (e.g. ASID-tagged VIVT I-cache). There is no way you
> > > could encode the useful information while keeping the same (and only)
> > > register, hence the the need for a new register."
Source: http://www.spinics.net/lists/arm-kernel/msg58813.html
As i see this (^), all ARMv > 6 == no backwards
ARMv6 had backwards to 4
ARMv7 >> ARMv6 compatibility, not more.
_
Problem officer even running ARMv4???
>On a non ARMv4 backwards compatibility CPU.
Profit!!
__
[ExeX.exe] (the one that i recompiled to a state: "this has to work")(ARMv4)
Decompilation:
Code:
; Attributes: bp-based frame
EXPORT start
start
var_20= -0x20
oldR4= -0x1C
oldR5= -0x18
oldR6= -0x14
oldR7= -0x10
oldR11= -0xC
oldSP= -8
oldLR= -4
MOV R12, SP
STMFD SP!, {R4-R7,R11,R12,LR}
ADD R11, SP, #0x1C
SUB SP, SP, #4
MOV R4, R3
MOV R5, R2
MOV R6, R1
MOV R7, R0
.
Next up, decompile a ARMv7 from a raw device. (how, someone has one)
fiinix said:
Next up, decompile a ARMv7 from a raw device. (how, someone has one)
Click to expand...
Click to collapse
I think you'll find what you're looking for here: http://forum.xda-developers.com/showthread.php?t=681659 in the dump of the IMAGEFS. What did you use to decompile it? IDA Pro, or a different thing?
athompson said:
I think you'll find what you're looking for here: http://forum.xda-developers.com/showthread.php?t=681659 in the dump of the IMAGEFS. What did you use to decompile it? IDA Pro, or a different thing?
Click to expand...
Click to collapse
IDA Pro, yes. Ill see if i can dump that "nbh" (used to nb0), and extract a fully operable exe that is not corrupted.
fiinix said:
IDA Pro, yes. Ill see if i can dump that "nbh" (used to nb0), and extract a fully operable exe that is not corrupted.
Click to expand...
Click to collapse
First use Andim's WP7 Rom Tools to extract the rommodules. Remember to always dump a folder, not a single file.
Then use Denomitor's version of Recmod and follow the instructions in the post. That works most of the time.
Going forward
Currently building the WP7 ARMv7 commandline, getting closer.
Current cmd (not working, no need to help):
Code:
"C:\WINCE700\sdk\bin\i386\arm\cl.exe" /Od /D "_DEBUG" /D "_WIN32_WCE=0x700" /D "UNDER_CE" /D "ZUNE_HD" /D "WINCE" /D "DEBUG" /D "_WINDOWS" /D "ARM" /D "_ARM_" /D "_UNICODE" /D "UNICODE" /D "_CRT_SECURE_NO_WARNINGS" /Gm /EHsc /MTd /Gy /fp:fast /GR- /Fo"C:\Users\Steven VM\Desktop\ARMv7\Build\Debug/" /Fd"C:\Users\Steven VM\Desktop\ARMv7\Build\Debug/vc80.pdb" /W3 /c /Zi /TP /QRfpe- /QRarch7 "C:\Users\Steven VM\Desktop\ARMv7\main.cpp"
/QRarch7 is the ARMv7.
edit:
HOORRY SHEEAT
generated:
> main.obj
> vc80.idb
> vc80.pdb
, feels soo good:
main.exe is there.
IDA Pro says "ARM AND THUMB MODE SWITCH INSTRUCTIONS", just like others.
Code:
; Input MD5 : B50E8D8395DE7CA2419464DC3CE0BC74
; File Name : C:\Users\Steven\Desktop\burn\main.exe
; Format : Portable executable for ARMI (PE)
; Imagebase : 10000
; Section 1. (virtual address 00001000)
; Virtual size : 00000018 ( 24.)
; Section size in file : 00000200 ( 512.)
; Offset to raw data for section: 00000400
; Flags 60000020: Text Executable Readable
; Alignment : default
; Processor : ARM
; Target assembler: Generic assembler for ARM
; Byte sex : Little endian
; Segment type: Pure code
AREA .text, CODE, READWRITE, ALIGN=4
; ORG 0x11000
CODE32
EXPORT start
start
var_4= -4
SUB SP, SP, #4
MOV R3, #1
STR R3, [SP,#4+var_4]
LDR R0, [SP,#4+var_4]
ADD SP, SP, #4
BX LR
; End of function start
Made an empty entry point as from above ^:
Code:
int wWinMainCRTStartup()
{
return 1;
}
PE Explorer (main.exe):
Machine: THUMB
Operating System Version: 7.0
Image Version: 7.0
Subsystem Version: 7.0
Subsystem: WinCE GUI
**** so CLOSE!
Successful copied "main.exe" and "ExeX.exe" to "\Windows", where i have the right to launch them remotely.
Method:
WP7Process p = device.LaunchEXE(@"main.exe", "");
main.exe (no signing, ARMv7):
System.UnauthorizedAccessException: Access is denied.
WP7Process p = device.LaunchEXE(@"ExeX.exe", "");
ExeX.exe (signed with CA/ROOT custom, ARMv4):
System.Runtime.InteropServices.COMException (0x800704EC): This program is blocked by group policy. For more information, contact your system administrator.
There IS different things going on! Something is missing, but what
edit:
Signed main.exe with custom XDA ROOT certificate (ARMv7):
signtool.exe sign /sha1 "[CertChomp]" "main.exe"
> Now main.exe also gets "This program is blocked by group policy. For more information, contact your system administrator."
Ill see if i can add it to startup list , if it boot from there.
edit 2:
Nope gonna hijack "fieldtestapp.exe" with my app because policy says:
Risky-mode.Activate();
Backup(fieldtestapp.exe, backupPath);
Copy(main.exe, > fieldtestapp.exe);
"LOADERVERIFIER_ROUTE_BY_NAME"
"LOADERVERIFIER_EXE_AUTHZ_INROM_ROOT"
<Rule Description="Route fieldtestapp.exe" ResourceIri="$(LOADERVERIFIER_ROUTE_BY_NAME)/PRIMARY/WINDOWS/FIELDTESTAPP.EXE" SpeakerAccountId="$(SYSTEM_USER_NAME)" PriorityCategoryId="PRIORITY_LOW">
<Authorize>
<Match AccountId="$(FIELDTESTAPP_EXE_SID)" AuthorizationIds="LV_ACCESS_EXECUTE" />
</Authorize>
</Rule>
<Rule Description="Authorize fieldtestapp.exe be loadable to $(FIELDTESTAPP_EXE_SID) and chambers" ResourceIri="$(LOADERVERIFIER_EXE_AUTHZ_INROM_ROOT)/WINDOWS/FIELDTESTAPP.EXE" SpeakerAccountId="$(SYSTEM_USER_NAME)" PriorityCategoryId="PRIORITY_STANDARD">
<Authorize>
<Match AccountId="$(FIELDTESTAPP_EXE_SID)" AuthorizationIds="LV_ACCESS_EXECUTE,LV_ACCESS_LOAD" />
</Authorize>
</Rule>
edit 3:
Seems like "fieldtestapp.exe" is ROM locked. Need to try out some other targets.
edit 4:
Target acquired "ProximitySensorDisable.exe" > "ProximitySensorDisableBackup.exe"
Successful copy == no ROM lock.
edit 5:
There exists two types of talking to the LoadVerifier (the: This program is blocked by group policy.):
Direct exe name OR special certificate
How we do:
> Direct exe (hijack exe)
How we cant do (SHA1) (Nope, ain't gonna happen):
> We certainly dont have Microsofts certificate so this way is a nodo, haha lol, no do way.
(1: direct exe name) /LOADERVERIFIER/GLOBAL/AUTHORIZATION/PE_AUTHZ/NONE/NONE/PRIMARY/WINDOWS/CFGHOST.EXE
(2: static/pre certificates) /LOADERVERIFIER/GLOBAL/CERTIFICATES/HASH/SHA1/91B318116F8897D2860733FDF757B93345373574
edit 6:
Yep, loads of edits, just for you.
Allowed exe's to run (sorted a-z) (direct exe) (pre cert removed):
Code:
ACCESSIBILITYCPL.EXE
ACCOUNTSMANAGER.EXE
ALARMS.EXE
APPCHECKERSHIM.EXE
APPPREINSTALLER.EXE
AUTODATACONFIG.EXE
AUTOSIM.EXE
AUTOTIMEUPDATE.EXE
BRIGHTNESSCPL.EXE
BTUXCPL.EXE
CALENDARAPP.EXE
CALLSETTINGSHOST.EXE
CALNOT.EXE
CALUPD.EXE
CAM_FW_UPDATE_UI.EXE
CELLUXCPL.EXE
CERTINSTALLER.EXE
CFGHOST.EXE
CFLAUNCHER.EXE
CHDIALERHOST.EXE
CIPHASE2.EXE
CLIENTSHUTDOWN3.EXE
CLOCKNOT.EXE
CMACCEPT3.EXE
COLDINIT.EXE
COMMSVC.EXE
COMPOSITOR.EXE
CONFIGDM.EXE
CONFIGXML.EXE
CONMANCLIENT3.EXE
CONTACTS.EXE
CPROG.EXE
DATETIMECPL.EXE
DCVSSWITCH.EXE
DEPOTCOPY.EXE
DEVICEFEEDBACKCPL.EXE
DEVICEREG.EXE
DIAGPORTCHANGETEST.EXE
DLLHOST.EXE
DMSCHEDULERCALLBACK.EXE
DMSRV.EXE
DMSTOOLS.EXE
DUACLIENT.EXE
DW.EXE
EDM3.EXE
EMAIL.EXE
EMAILSETUP.EXE
ENDPOINT.EXE
FCROUTERCMDTEST.EXE
FIELDTESTAPP.EXE
FLIGHTMODE.EXE
GAMESUX.EXE
IEXPLORE.EXE
INITIATEDMSESSION.EXE
INVALIDLICENSEUXLAUNCHER.EXE
KEYBOARDCPL.EXE
LASSCREDENTIALEXPIRATIONCHECK.EXE
LASSRESTARTER.EXE
LIVETOKEN.EXE
LOCKCPL.EXE
LOOPBACKTEST.EXE
MEDIAGROVEL.EXE
MEUX.EXE
MITSMAN.EXE
MMSPRPROXY.EXE
MMSTRANSHOST.EXE
MULTIMEDIALAUNCHER.EXE
MYPHONECPL.EXE
MYPHONETASKSRUNTIME.EXE
NATIVEINSTALLERHOST.EXE
OFFICEURL.EXE
OMADMCLIENT.EXE
OMADMPRC.EXE
OMHUB.EXE
ONBOOTSQM.EXE
ONENOTEMOBILE.EXE
OOBE.EXE
PACMANINSTALLER.EXE
PHOTOENT.EXE
PHOTOENTCAPTURE.EXE
PHOTOUPLOADER.EXE
PPT.EXE
PWORD.EXE
PWRLOGCTRL.EXE
PXL.EXE
RAPICONFIG.EXE
REGIONCPL.EXE
RMACTIVATE.EXE
SAPISVR.EXE
SECSIMTKIT.EXE
SERVICESD.EXE
SERVICESSTART.EXE
SETTELEPORTMODE.EXE
SETTINGS3.EXE
SHORTMSG.EXE
SICLNT.EXE
SIGNALEVENT.EXE
SIREPSERVERAPPDEV.EXE
SMSETTINGS.EXE
SMSTRANSPORT.EXE
SOUNDCPL.EXE
SPEECHCPL.EXE
SPMC.EXE
SQMEVENT.EXE
SSUPDATE.EXE
TASKHOST.EXE
TELSHELL.EXE
TESTSHOW.EXE
THEMECPL.EXE
TOGGLEBROWSERHIBERNATION.EXE
TOGGLEDOG.EXE
UDEVICE.EXE
UIF.EXE
UNIFIEDPAIR.EXE
USBMGR.EXE
WEBSEARCH.EXE
WIFIUXSPLASH.EXE
WLANEXT.EXE
WLIDSETUP.EXE
WWANDATAMGR.EXE
XDRMREMOTESERV.EXE
ZIPVIEW.EXE
ZMFTASKLAUNCH.EXE
How code (yes i know its super un-optimized, fast put together):
Code:
var doc = XDocument.Load(File.OpenRead("SamsungOmnia7_BasePolicy_webserver.xml"));
var ea = doc.Elements().ToArray()[0].Elements()
.Where(x => x.Name.LocalName == "Rule")
.Where(x => x.Attributes("ResourceIri").Count() > 0)
.Where(x =>
{
var r = x.Attribute("ResourceIri").Value;
return r.Contains("LOADERVERIFIER") && r.ToLower().Contains(".exe") && !r.Contains("CERTIFICATES");
})
.Select(x =>
{
var v = x.Attribute("ResourceIri").Value;
var l = v.LastIndexOf('/');
return v.Substring(l + 1);
})
.Distinct()
.OrderBy(x => x)
.ToArray();
edit 7:
yeah, lol i say too.
Unprotected exe (FCRouterCmdTest.exe)
> c:\Project Work\SGH-i707(Cetus)\FCRouterCmdTest\Windows Mobile 6 Professional SDK (ARMV4I)\Release\FCRouterCmdTest.pdb
mfw samsung use "Windows Mobile 6 Professional SDK (ARMV4I)"
Wow, this truly was a big step today
Done hacking today.
"After a day, there comes another day"
@fiinix,
You did a lot of testing. Good job, man.
A few comments:
0x800704ec "blocked by group policy" is THE error of the new WP7 security model. It is basically telling you to go f*ck yourself. Everything you do without enough privileges or capabilities results in this error.
The two ways of policies, exe-path and cert-hash, is result of difference between rom-modules and executables that are signed and added as a file. Rom-modules are not even normal files. You can't open and read them. They are executable sections that are mapped in rom-address-space. You can only call loadlibrary() and createprocess() on them. Since they are only executable sections, they don't have a signature, like a normal executable file would have. Therefore they are referred to with an exe-path. You may safely assume that every path to an executable in the policy files is referring to a rom-module and can't be overwritten in any way (except by cooking your own rom - who is going to unlock our bootloaders?!?) Other than that, there are a few signing certs that Microsoft has. Signing the different executables with different privileges and accordingly a different cert. Their hashes are in the policies.
Using ARMv7 isn't going to add much I'm afraid. Although it may make a difference in the exe-header. But you've seen tools that were really old, remember And they were signed to have TCB access. And they were compiled for ARMv4. So it should not make much difference.
I did some testing with certificates myself yesterday. Up until Zune totally went bezerk on it. I don't know what happened, but after removing my own cooked certs it all seems normal again. Zune started using 100% cpu on verifying certs and dropping my connection all the time. Help! So I haven't made much progress. I will try again later. Hope it will go better. And I will try to resign an existing executable, as Flow WP7 suggested.
According to policy on my omnia (webserver dumped) there seems to exist two typed of HDD, one ROM hard coded and one that points to internal sd card. It seems that all exe and dll on the sd are not "protected" and therefore can be hijacked.
Seems like ARMv4 will be enough, but to be on the safe side i compile with both, to have more chance getting it work.
Zune, hmm, did not seem to like you, maybe Microsoft DDOS'ed you lol
"Sent from my fingers on my phone", don't expect way too long text
XxXPachaXxX said:
Excuse my ignorance...I'm a noob...This hack may also work on LG devices?
Click to expand...
Click to collapse
At the moment fiinix and I are both working on Samsungs and we use a couple of Samsung-specific exploit to get deeper in the system and getting a better understanding of the system. The ultimate goal is to find exploits that will work for all devices. But we're not at that stage yet. Hacking is research, a lot of trying and being lucky sometimes. Just bear with us
Ciao,
Heathcliff74
An MTP filesystem for linux that I believe works better than anything else currently out there.
http://research.jacquette.com/jmtpfs-exchanging-files-between-android-devices-and-linux/
I tried to make the filesystem implementation robust and as complete as possible within the limits of MTP. Everything except chown, chmod, symlinks, and updating the modification time without actually changing the file should work.
I've only tested it under Fedora 16, but the code is generic enough that it should work on any linux system (and probably Mac OS X as well) with libmtp 1.1.3, fuse, and libmagic.
Give it a try, and let me know if you find any bugs or other issues.
- J
Hi. This looks great. I tried mtpfs a couple of weeks ago and found it unreliable and buggy.
I'm trying to use this on mac. I installed gcc 4.7 since xcode command line tools ship with gcc 4.2 which doesn't support C++11.
However I still get this when I run make:
Code:
Making all in src
g++ -DPACKAGE_NAME=\"jmtpfs\" -DPACKAGE_TARNAME=\"jmtpfs\" -DPACKAGE_VERSION=\"1.0\" -DPACKAGE_STRING=\"jmtpfs\ 1.0\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -DPACKAGE=\"jmtpfs\" -DVERSION=\"1.0\" -DHAVE_LIBMAGIC=1 -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_MAGIC_H=1 -I. -framework IOKit -I/usr/local/Cellar/libmtp/1.1.2/include -I/usr/local/Cellar/libusb-compat/0.1.3/include -D__DARWIN_64_BIT_INO_T=1 -D__FreeBSD__=10 -D_FILE_OFFSET_BITS=64 -I/usr/local/include/osxfuse/fuse -g -O2 -std=c++0x -MT jmtpfs-jmtpfs.o -MD -MP -MF .deps/jmtpfs-jmtpfs.Tpo -c -o jmtpfs-jmtpfs.o `test -f 'jmtpfs.cpp' || echo './'`jmtpfs.cpp
cc1plus: error: unrecognized command line option "-std=c++0x"
make[1]: *** [jmtpfs-jmtpfs.o] Error 1
make: *** [all-recursive] Error 1
Any ideas?
---------- Post added at 09:51 PM ---------- Previous post was at 09:34 PM ----------
Ok nevermind that. I had a symlink problem.
I still couldn't compile though:
Code:
jmtpfs.cpp:411:62: error: macro "fuse_main" passed 4 arguments, but takes just 3
jmtpfs.cpp: In function 'int main(int, char**)':
jmtpfs.cpp:411:15: error: 'fuse_main' was not declared in this scope
Hi,
I tested on gentoo x64, it worked very well.
Mounted my galaxy nexus as normal user, showed in nautilus as a drive. Copied some flac files to it, so far so good.
Thanks and please keep this going, since mtpfs didn't work for me either.
OSX build
With the patch below I got jmtpfs to build under Lion using libmtp, fuse4x, gcc46 (or gcc47), and file (libmagic) installed via macports. I'll include the patch in my next release.
There is still one weird issue though. If jmtpfs is run without the foreground (-f) option, you just get i/o errors when trying to access the device. It looks like something in the way fuse4x is backgrounding the process is messing up libmtp. But with -f it seems to work fine.
Index: src/jmtpfs.cpp
===================================================================
--- src/jmtpfs.cpp (revision 5445)
+++ src/jmtpfs.cpp (working copy)
@@ -22,11 +22,10 @@
#include "ConnectedMtpDevices.h"
#include "mtpFilesystemErrors.h"
#include "Mutex.h"
+#include "FuseHeader.h"
#include <MtpRoot.h>
#include <iostream>
-#include <fuse.h>
-#include <fuse_opt.h>
#include <cstddef>
#include <errno.h>
#include <sstream>
Index: src/MtpNode.h
===================================================================
--- src/MtpNode.h (revision 5445)
+++ src/MtpNode.h (working copy)
@@ -25,7 +25,7 @@
#include "MtpMetadataCache.h"
#include "MtpFilesystemPath.h"
#include "MtpDevice.h"
-#include <fuse.h>
+#include "FuseHeader.h"
#include <time.h>
#include <vector>
#include <string>
Index: src/FuseHeader.h
===================================================================
--- src/FuseHeader.h (revision 0)
+++ src/FuseHeader.h (revision 5447)
@@ -0,0 +1,30 @@
+/*
+ * FuseHeader.h
+ *
+ * Author: Jason Ferrara
+ *
+ * This software is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 3 as published by the Free Software Foundation.
+ *
+ * This software is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public
+ * License along with this library; if not, write to the
+ * Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor,
+ * Boston, MA 02111-1301, USA.
+ * [email protected]
+ */
+
+#ifndef FUSEHEADER_H_
+#define FUSEHEADER_H_
+
+#define FUSE_USE_VERSION 26
+#include <fuse.h>
+#include <fuse_opt.h>
+
+
+#endif /* FUSEHEADER_H_ */
Index: src/MtpLocalFileCopy.cpp
===================================================================
--- src/MtpLocalFileCopy.cpp (revision 5445)
+++ src/MtpLocalFileCopy.cpp (working copy)
@@ -22,6 +22,7 @@
#include "mtpFilesystemErrors.h"
#include <sys/stat.h>
#include <iostream>
+#include <unistd.h>
MtpLocalFileCopy::MtpLocalFileCopy(MtpDevice& device, uint32_t id) :
m_device(device), m_remoteId(id), m_needWriteBack(false)
I released a version that builds and runs correctly under Mac OS X.
If you follow the link in my first post you'll now see a link to download the new version at the top of the blog post.
J F said:
I released a version that builds and runs correctly under Mac OS X.
If you follow the link in my first post you'll now see a link to download the new version at the top of the blog post.
Click to expand...
Click to collapse
Awesome! I didn't expect such a quick response. I got it working with gcc 4.7 and fuse4x installed using homebrew. I still can't copy/move anything due to permission errors. I tried running with sudo but it wouldn't mount at all. I also caught a couple of crashes: http://pastebin.com/JFgc0n5s http://pastebin.com/1d8FgvVX
Great work!
I'll try it on Archlinux 64 as soon as I get home
New release 0.4 with improved Mac OS X compatibility. Follow the link in my first post.
Apparently if you don't lie to the Finder and tell it MTP supports chmod and utime, the Finder throws a fit.
I'm also using the user that started jmtpfs for the uid and gid for the files. This fixes the permissions problems in OS X. And I report the combined free space of all the storage devices as the free space of the mount point. If I report 0 (which is the truth, since the mount point is read only and only contains directory entries for the storage devices, and its each subdirectory of the mount point which is read/write and has its own free space) then the finder assumes there is no free space in any directory under the mount point and refused to copy over files.
J F said:
New release 0.4 with improved Mac OS X compatibility. Follow the link in my first post.
Apparently if you don't lie to the Finder and tell it MTP supports chmod and utime, the Finder throws a fit.
I'm also using the user that started jmtpfs for the uid and gid for the files. This fixes the permissions problems in OS X. And I report the combined free space of all the storage devices as the free space of the mount point. If I report 0 (which is the truth, since the mount point is read only and only contains directory entries for the storage devices, and its each subdirectory of the mount point which is read/write and has its own free space) then the finder assumes there is no free space in any directory under the mount point and refused to copy over files.
Click to expand...
Click to collapse
0.4 compiled with the addition of "#include <unistd.h>" to jmtpfs.cpp and it worked! I was able to send/receive files! Thanks a lot for your efforts. At last we have a viable alternative to Android File Transfer.
Here is a little toturial for less techsavvy Mac owners:
1. Get Xcode from App Store if you haven't already. Open it and go to Preferences>Downloads and install "Command Line Tools".
2. Install homebrew
3. In terminal, run "brew doctor" to check for any issues. Then run "brew update && brew upgrade" to get the latest database.
4. Run this to get gcc 4.7 with C++ support:
Code:
brew install https://raw.github.com/Homebrew/homebrew-dupes/master/gcc.rb
5. Run "brew install fuse4x libmtp libmagic".
6. Run the following to install the fuse kernel extentions:
Code:
sudo cp -rfX /usr/local/Cellar/fuse4x-kext/0.9.0/Library/Extensions/fuse4x.kext /Library/Extensions && sudo chmod +s /Library/Extensions/fuse4x.kext/Support/load_fuse4x
7. Now you should have all the pre requisites installed. Download (fixed) jmtpfs from here and extract it.
8. cd to the extracted directory and run:
Code:
CXX=g++-4.7 CXXFLAGS="-D FUSE_USE_VERSION=25" ./configure --prefix=/usr/local/Cellar/jmptfs/0.4 && make && make install && brew link jmptfs
9. Run "mkdir ~/Android" to create a directory in your homefolder.
10. Finally, run "jmtpfs ~/Android". At this point, you should see a mountpoint called "fuse4x volume 0 jmtpfs" in your home directory, which you can treat as any external harddrive.
This is very interesting, but I can't seem to get it to work on Ubuntu Precise 12.04.
This is what I get on the "make" command:
[email protected]:~/Downloads/jmtpfs$ make
Making all in src
make[1]: Entering directory `/home/betto/Downloads/jmtpfs/src'
g++ -g -O2 -std=c++0x -lmagic -o jmtpfs jmtpfs-jmtpfs.o jmtpfs-MtpDevice.o jmtpfs-ConnectedMtpDevices.o jmtpfs-Mutex.o jmtpfs-MtpFilesystemPath.o jmtpfs-MtpMetadataCache.o jmtpfs-MtpNode.o jmtpfs-MtpRoot.o jmtpfs-MtpLibLock.o jmtpfs-MtpStorage.o jmtpfs-MtpFolder.o jmtpfs-MtpFile.o jmtpfs-TemporaryFile.o jmtpfs-MtpLocalFileCopy.o -L/usr/local/lib -lmtp -lusb -pthread -lfuse -lrt -ldl
jmtpfs-MtpDevice.o: In function `MtpDevice':
/home/betto/Downloads/jmtpfs/src/MtpDevice.cpp:69: undefined reference to `magic_open'
/home/betto/Downloads/jmtpfs/src/MtpDevice.cpp:72: undefined reference to `magic_load'
/home/betto/Downloads/jmtpfs/src/MtpDevice.cpp:73: undefined reference to `magic_error'
jmtpfs-MtpDevice.o: In function `MtpDevice::SendFile(LIBMTP_file_struct*, int)':
/home/betto/Downloads/jmtpfs/src/MtpDevice.cpp:242: undefined reference to `magic_buffer'
collect2: ld returned 1 exit status
make[1]: *** [jmtpfs] Error 1
make[1]: Leaving directory `/home/betto/Downloads/jmtpfs/src'
make: *** [all-recursive] Error 1
Click to expand...
Click to collapse
I've installed the libmagic-dev package(or something like that. What are those undefined references? Am I missing some packages??
Hey, i have now w7, pls support for me.
Sent from my Galaxy Nexus using Tapatalk 2
Rimher said:
This is very interesting, but I can't seem to get it to work on Ubuntu Precise 12.04.
This is what I get on the "make" command:
I've installed the libmagic-dev package(or something like that. What are those undefined references? Am I missing some packages??
Click to expand...
Click to collapse
It looks like maybe you ran configure, installed libmagic-dev, and then ran make without rerunning configure.
Do "make distclean;./configure" and make sure configure doesn't report any errors. Then try make again.
If things go right at the final link command there should be a -lmagic at the end of the command line. The -lmagic you see near the beginning of the command line is because of a mistake I made in configure.ac (the LDFLAGS="$LDFLAGS -lmagic" line shouldn't be there), but it has no effect because it comes before the object files that need it.
J F said:
It looks like maybe you ran configure, installed libmagic-dev, and then ran make without rerunning configure.
Do "make distclean;./configure" and make sure configure doesn't report any errors. Then try make again.
If things go right at the final link command there should be a -lmagic at the end of the command line. The -lmagic you see near the beginning of the command line is because of a mistake I made in configure.ac (the LDFLAGS="$LDFLAGS -lmagic" line shouldn't be there), but it has no effect because it comes before the object files that need it.
Click to expand...
Click to collapse
Seems to work correctly now! Thanks a lot =)
The weird thing is that some folders that are available into my Android are not visible through the file system. How's that possible?
Ubuntu 12
Hey OP,
When I run the ./configure command I get this output
:/home/jd/Downloads/jmtpfs-0.3# ./configure
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking target system type... x86_64-unknown-linux-gnu
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking for g++... no
checking for c++... no
checking for gpp... no
checking for aCC... no
checking for CC... no
checking for cxx... no
checking for cc++... no
checking for cl.exe... no
checking for FCC... no
checking for KCC... no
checking for RCC... no
checking for xlC_r... no
checking for xlC... no
checking whether the C++ compiler works... no
configure: error: in `/home/jd/Downloads/jmtpfs-0.3':
configure: error: C++ compiler cannot create executables
See `config.log' for more details
After this when I try make and make install it says
make: *** No targets specified and no makefile found. Stop.
I also tried the latest jmtpfs package too with the same results, what am I doing wrong?
Is this because of the compiler errors above? Any help would really be great. I use Airdroid normally but I would love to try your method. Thank you.
You have to install g++
sudo apt-get install g++
I installed libmagic-dev, autoconf and automake. Before running ./configure, I ran autoreconf, and that also seemed to fix it.
You can do most operations much quicker than with mtpfs, but it's still silly-slow to do something like 'tree'. MTP really sucks in some use-cases. DON'T think of it as a filesystem!
jangutter said:
I installed libmagic-dev, autoconf and automake. Before running ./configure, I ran autoreconf, and that also seemed to fix it.
You can do most operations much quicker than with mtpfs, but it's still silly-slow to do something like 'tree'. MTP really sucks in some use-cases. DON'T think of it as a filesystem!
Click to expand...
Click to collapse
I agree. It's way slower than UMS. Granted, on mac, google's own Android File Transfer app works way faster than jmtpfs or mtpfs (it's very buggy and unreliable though)
Hey Rimher,
Thanks for that I installed g++
No when I try to run through the ./configure command I get this
checking for FUSE... no
configure: error: Package requirements (fuse >= 2.6) were not met:
No package 'fuse' found
Any ideas?
jd1001 said:
Hey Rimher,
Thanks for that I installed g++
No when I try to run through the ./configure command I get this
checking for FUSE... no
configure: error: Package requirements (fuse >= 2.6) were not met:
No package 'fuse' found
Any ideas?
Click to expand...
Click to collapse
it's pretty self explanatory. You need to install fuse, as mentioned in OP.
jd1001 said:
Hey Rimher,
Thanks for that I installed g++
No when I try to run through the ./configure command I get this
checking for FUSE... no
configure: error: Package requirements (fuse >= 2.6) were not met:
No package 'fuse' found
Any ideas?
Click to expand...
Click to collapse
sudo apt-get install libfuse-dev
sudo apt-get install libmagic-dev
you have to install a bunch of libraries, not sure if those two are enough, try it