Does anyone understand which system call belong I/O component (WiFi, SDcard or GSP etc.)?
I am using strace to trace application, and now, I have A application (A application just have wifi on/off functions, A's PID=999), and I use cmd to key command
./strace -p 999 -t -v
if I use this command ./strace -p 999 -t -v -e trace=open,close,read,write output for example:
04:18:11.473383 read(52, "D", 1) = 1
04:18:11.476191 write(39, "W", 1) = 1
04:18:11.477198 write(53, "u", 1) = 1
04:18:11.478114 read(38, "W", 16) = 1
04:18:11.583430 read(52, "D", 1) = 1
04:18:11.584315 write(39, "W", 1) = 1
04:18:11.586787 write(53, "u", 1) = 1
04:18:11.587824 read(38, "W", 16) = 1
04:18:11.794337 read(38, "W", 16) = 1
04:18:11.800227 read(38, "W", 16) = 1
04:18:11.802210 syscall_983042(0x4e1d5428, 0x4e1d542c, 0, 0xfff, 0x408e54d8, 0x4e1d5428, 0x4e1d8469, 0xf0002, 0, 0x4e1d542c, 0xf81ef003, 0x14, 0, 0xbee5c738, 0x408b6093, 0x4006c8fc, 0x40000010, 0x4e1d5428, 0, 0, 0xc764, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0) =
But output have so many...I can't explain then...
So, I want to know
What system call name is belong component (belong wifi or belong SDcard)
How can I use component to get component's system call(What command should I ues?)
How should using "strace" to trace SDcard? Should I have B application (B application just have open SDcard or close SDcard?) I don't know what experiment I can do.
All this calls belong to file-system component. Which are then routed through the kernel to the actual hardware drives. So there is no way to know just by looking at system calls.
What you need to do is to look for the open calls to see what file is being opened. The call will return a number, called file handle. This number is later used as a first argument to read / write / close calls.
Things are even tricker for WIFI, since you will have to monitor a whole bunch of socket calls as well as things like sendto. Plus you'll need to cross reference the routing map.
Basically, what you are trying to do is really hard to do on syscall level. I used to do such things in the past by going a level deeper, to the kernel and drivers. There you are
much closer to actual hardware to see the context.
Note that to get a bit more visibility on what the file descriptors are (if you continue to play with strace), you can use the -y option of recent strace versions (at least 4.8 has it). -y will decode the the file descriptors to a path.
Related
I am trying to read and write the DACR on an ARM device running Linux (Android on nexus 5 :)). I have a kernel module. The relevant instructions are as follows:
MRC p15, 0, <Rd>, c3, c0, 0 ; Read DACR
MCR p15, 0, <Rd>, c3, c0, 0 ; Write DACR
I am using C code in the module with assembly inside. I wrote the following to read the current DACR value:
unsigned int x = 0;
__asm__("MRC p15, 0, r1, c3, c0, 0;" : "=r" (x));
printk(KERN_INFO "DACR read - value = %u", x);
The above didn't crash the kernel, and the value read out was 3920437248.
I am not able to write the instruction for DACR write correctly. I was trying to follow from this question and did the following (to write all 1's to DACR to test), but the device crashed and rebooted:
__asm__("MVN r1, #0;");
__asm__("MCR p15, 0, r1, c3, c0, 0;");
Can anyone advice how to write to DACR correctly ?
Also how to parameterize the above instruction - e.g. for using value of x to initialize DACR, would the following be correct:
__asm__("MCR p15, 0, %0, c3, c0, 0;" :: "r" (x));
Oh, you're writing the register correctly alright.
The trouble is, the question is like this:
I am trying to engage reverse gear on my car driving on the motorway. I was trying to follow the directions in the handbook and moved the gear lever firmly into the "R" position, but my gearbox is now in bits all over the road. Can anyone advise how to engage reverse gear correctly?
You're on a live system. The kernel is already using domains. It needs access permissions to work correctly. If you declare open season by marking everything as Manager and removing all permission checks, copy-on-write no longer works; every process starts trashing the zero page via their initial mappings instead of triggering the allocation of real backing pages; cats and dogs live together; chaos.
I've downloaded NFC parts from AOSP and I'm looking for the method used by Android to generate the random UID used by card emulation. My goal is to fix the UID instead of having a different one each time there is a communication with the target. I found inside "libnfc-nci" module the file "nfa_ce_act.c" containing this:
void nfa_ce_t3t_generate_rand_nfcid (UINT8 nfcid2[NCI_RF_F_UID_LEN])
{
UINT32 rand_seed = GKI_get_tick_count ();
/* For Type-3 tag, nfcid2 starts witn 02:fe */
nfcid2[0] = 0x02;
nfcid2[1] = 0xFE;
/* The remaining 6 bytes are random */
nfcid2[2] = (UINT8) (rand_seed & 0xFF);
nfcid2[3] = (UINT8) (rand_seed>>8 & 0xFF);
rand_seed>>=(rand_seed&3);
nfcid2[4] = (UINT8) (rand_seed & 0xFF);
nfcid2[5] = (UINT8) (rand_seed>>8 & 0xFF);
rand_seed>>=(rand_seed&3);
nfcid2[6] = (UINT8) (rand_seed & 0xFF);
nfcid2[7] = (UINT8) (rand_seed>>8 & 0xFF);
}
This method generate an UID for FeliCa tags. I'm not able to find the one for ISO14443 cards (MIFARE) which generate an UID beginning with 0x08 by default. According to Martijn Coenen, as explained in his G+ Post, it's something possible.
Sorry, I realize many people wanted this, but it's not possible in the official version. (You could of course do it with some AOSP hacking). The reason is that HCE is designed around background operation. If we allow apps to set the UID, every app possibly wants to set their own UID, and there's no way to resolve the conflict. We hope that with HCE, NFC infrastructure will move to higher levels of the protocol stack to do authentication instead of relying on the UID (which is easily cloned anyway).
https://plus.google.com/+MartijnCoenen/posts/iX6LLoQmZLZ
Is anyone know how to achieve it?
Thanks
One important thing to know is that the UID transfered at a very low level of the nfc protocol. This means that it is done independently by the nfc firmware and not within the android operating system.
We had the same problem in our NFCGate project and found a solution for Broadcom BCM20793 chips like the ones in the Nexus4/5 and others by writing the UID with NFC_SetConfig directly into the chip firmware.
You can see a working version in our repository on github. Here is a non-tested version to show the principle:
uint8_t cfg[] = {
CFG_TYPE_UID, // config type
3, // uid length
0x0A, // uid byte 1
0x0B, // uid byte 2
0x0C // uid byte 3
};
NFC_SetConfig(sizeof(cfg), cfg);
Our tests revealed that android sometimes sets the UID back to random (length=0 if I recall correctly), so you need to find a good place to set it when you need it or do something similar as we did and intercept NFC_SetConfig calls from android to re-set our own UID.
I am working on Android platform, and I wonder if it is possible to start an Android app from the kernel source code. For example, at certain point along the linux kernel resume path, I want to start a specific app, say my custom lock screen app. Is that possible?
Edit:
the call_usermodehelper does not work with the "am" utility.
I have code like this in a kernel module:
int result = 0;
char *argv[] = { "/system/bin/am", "start", "-n", "com.twitter.android/com.twitter.applib.HomeTabActivity", NULL};
char *argv[] = {"/system/bin/ls", NULL};
static char *envp[] = {"HOME=/", "PATH=/sbin:/system/sbin:/system/bin:/system/xbin", NULL };
result = call_usermodehelper(argv[0], argv, envp, 1);
but when I insmod, the nothing happens, and result = -8
anyone can help?
I can't speak for certain about Android, but in vanilla Linux, there's a bunch of API's in kmod.h which can do what you want. See this article for details.
I have been trying to capture audio, within a native linux program running on an Android device via adb shell.
Since I seemed to be getting only (very quiet) noise, i.e. no actual signal (interestingly, an Android/Java program doing similar did show there was a signal on that input),
I executed alsa_amixer, which had one entry that looked like the right one:
Simple mixer control 'Capture',0
Capabilities: cvolume cswitch penum
Capture channels: Front Left - Front Right
Limits: Capture 0 - 63
Front Left: Capture 31 [49%] [0.00dB] [off]
Front Right: Capture 31 [49%] [0.00dB] [off]
"off". That would explain the noise.
So I looked for examples of how to use alsa_amixer to unmute the channels, I found different suggestions for parameters like "49% on" or "49% unmute", or just "unmute" none of which works. (if the volume% is left out, it says "Invalid command!", otherwise, the volume is set, but the on/unmute is ignored)
I also searched how to do this programatically (which I'll ultimately need to do, although the manual approach would be helpful for now), but wasn't too lucky there.
The only ALSA lib command I found which sounds like it could do something like that was "snd_mixer_selem_set_capture_switch_all", but the docs don't day what the parameter does (1/0 is not on/off, I tried that ;) )
The manual approach to set these things via alsa_amixer does work - but only if android is built with the 'BoardConfigCommon.mk' modified, at the entry: BOARD_USES_ALSA_AUDIO := false, instead of true.
Yeah, this will probably disable ALSA for android, which is why it wouldn't meddle with the mixer settings anymore.
To you android programmers out there, note that this is a very niche use case of course, as was to be expected by my original post to begin with.
This is not what most people would want to do.
I just happen to tinker with an android device here in unusual ways ;-)
Just posting the code as question giver suggested, also don't like external links.
#include <alsa/asoundlib.h>
int main()
{
snd_mixer_t *handle;
snd_mixer_selem_id_t *sid;
snd_mixer_open(&handle, 0);
snd_mixer_attach(handle, "default");
snd_mixer_selem_register(handle, NULL, NULL);
snd_mixer_load(handle);
snd_mixer_selem_id_alloca(&sid);
snd_mixer_selem_id_set_index(sid, 0);
snd_mixer_selem_id_set_name(sid, "Capture");
snd_mixer_elem_t* elem = snd_mixer_find_selem(handle, sid);
snd_mixer_selem_set_capture_switch_all(elem, 0);
snd_mixer_selem_set_capture_dB_all(elem, 0, 0);
snd_mixer_close(handle);
}
I am coding a native application in android and I need to get the default gateway of a device on my application. Here is my current code to get the default gateway.
static int get_default_gateway(char *def_gateway, int buf_size)
{
FILE* pipe;
char buffer[128];
char result[2049];
char cmd[] = "netstat -r | grep ^default | awk '{print $2}'";
pipe = popen(cmd, "r");
if (!pipe) return 1;
memset(result, 0, sizeof(result));
while(!feof(pipe)) {
memset(buffer, 0, sizeof(buffer));
if(fgets(buffer, 128, pipe) != NULL)
{
strcat(result, buffer);
}
}
pclose(pipe);
memset(def_gateway, 0, buf_size);
strncpy (def_gateway, result, buf_size );
return 0;
}
It works on my LG p500 but on some devices it doesn't return anything.
My question is: Does popen() works on android? I read somewhere that it is not included in bionic.
And is there any other method to get the default gateway? I need it to be written in C and not java.
Thank you
Yea, probably popen() should work on any Android. But unfortunately grep and awk - not. Take a look at /proc/net/route - line where Destination equals to 00000000 is your default gateway. Also perhaps you can use NETLINK_ROUTE socket, though I never used it and can't say more.
See also this related question.