http://stackoverflow.com/questions/11365301/how-to-simulate-android-killing-my-process
Monday, May 8, 2017
Android how to simulate Service being killed
http://stackoverflow.com/questions/11365301/how-to-simulate-android-killing-my-process
Friday, May 5, 2017
Wireshark - How to decrypt SSL streams
The SSL dissector is fully functional and even supports advanced features such as decryption of SSL if the encryption key can be provided and Wireshark is compiled against GnuTLS (rather than OpenSSL or bsafe). This works for RSA private keys.
If Wireshark is compiled with SSL decryption support there will be a new option in the preferences for SSL. If the key entry option is absent then verify if your Wireshark is linked against the required GnuTLS library. This can be done with wireshark -v . The output should include GnuTLS and GCrypt. If you see without GnuTLS, without Gcrypt, then you will need reconfigure with --with-gnutls, recompile and reinstall.
To configure a RSA private key, go to the SSL dissector preference in the Protocols tree. Then press the RSA keys list button. A new dialog windows appears showing you the currently configured RSA private keys. Press the New button to configure a new RSA private key. In the new window you have to configure the following fields:
The RSA key file can either be a PEM format private key or a PKCS#12 keystore. If the file is a PKCS#12 keystore (typically a file with a .pfx or .p12 extension), the password for the keystore must be specified in the Password field.
Starting with Wireshark 2.0, the RSA key file is automatically matched against the public key as found in the Certificate handshake message. Before Wireshark 2.0, it relied on the user to enter a valid Address and Port value. Note that only RSA key exchanges can be decrypted using this RSA private key, Diffie-Hellman key exchanges cannot be decrypted using a RSA key file! (See "SSLKEYLOGFILE" if you have such a capture.)
The fileformat needed is 'PEM'. Note that it is common practice on webservers to combine the public key (or certificate) and the private key in a single PEM file.
references:
https://ask.wireshark.org/questions/34393/how-to-decrypt-ssl-traffic-using-wireshark
If Wireshark is compiled with SSL decryption support there will be a new option in the preferences for SSL. If the key entry option is absent then verify if your Wireshark is linked against the required GnuTLS library. This can be done with wireshark -v . The output should include GnuTLS and GCrypt. If you see without GnuTLS, without Gcrypt, then you will need reconfigure with --with-gnutls, recompile and reinstall.
To configure a RSA private key, go to the SSL dissector preference in the Protocols tree. Then press the RSA keys list button. A new dialog windows appears showing you the currently configured RSA private keys. Press the New button to configure a new RSA private key. In the new window you have to configure the following fields:
The RSA key file can either be a PEM format private key or a PKCS#12 keystore. If the file is a PKCS#12 keystore (typically a file with a .pfx or .p12 extension), the password for the keystore must be specified in the Password field.
Starting with Wireshark 2.0, the RSA key file is automatically matched against the public key as found in the Certificate handshake message. Before Wireshark 2.0, it relied on the user to enter a valid Address and Port value. Note that only RSA key exchanges can be decrypted using this RSA private key, Diffie-Hellman key exchanges cannot be decrypted using a RSA key file! (See "SSLKEYLOGFILE" if you have such a capture.)
The fileformat needed is 'PEM'. Note that it is common practice on webservers to combine the public key (or certificate) and the private key in a single PEM file.
references:
https://ask.wireshark.org/questions/34393/how-to-decrypt-ssl-traffic-using-wireshark
Wednesday, May 3, 2017
WAV Storage format
The data bits for each sample should be left-justified and padded with 0s. For example, consider the case of a 10-bit sample (as samples must be multiples of 8, we need to represent it as 16 bits). The 10 bits should be left-justified so that they become bits 6 to 15 inclusive, and bits 0 to 5 should be set to zero.
As an example, here is a 10-bit sample with a value of 0100001111 left-justified as a 16-bit word.
Given the fact that the WAVE format uses Intel's little endian byte order, the LSB is stored first, as shown here:
The analogy is for mono audio, meaning that you have just one "channel." When you deal with stereo audio, 3D audio, and so forth, you are in effect dealing with multiple channels, meaning you have multiple samples describing the audio in any given moment in time. For example, for stereo audio, at any given point in time you need to know what the audio signal was for the left channel as well as the right channel. So, you will have to read and write two samples at a time.
Say you sample at 44 KHz for stereo audio; then effectively, you will have 44 K * 2 samples. If you are using 16 bits per sample, then given the duration of audio, you can calculate the total size of the wave file as:
Size in bytes = sampling rate * number of channels * (bits per sample / 8) * duration in seconds
Number of samples per second = sampling rate * number of channels
When you are dealing with such multi-channel sounds, single sample points from each channel are interleaved. Instead of storing all of the sample points for the left channel first, and then storing all of the sample points for the right channel next, you "interleave" the two channels' samples together. You would store the first sample of the left channel. Then, you would store the first sample of the right channel, and so on.
references:
http://www.codeguru.com/cpp/g-m/multimedia/audio/article.php/c8935/PCM-Audio-and-Wave-Files.htm
As an example, here is a 10-bit sample with a value of 0100001111 left-justified as a 16-bit word.
Given the fact that the WAVE format uses Intel's little endian byte order, the LSB is stored first, as shown here:
The analogy is for mono audio, meaning that you have just one "channel." When you deal with stereo audio, 3D audio, and so forth, you are in effect dealing with multiple channels, meaning you have multiple samples describing the audio in any given moment in time. For example, for stereo audio, at any given point in time you need to know what the audio signal was for the left channel as well as the right channel. So, you will have to read and write two samples at a time.
Say you sample at 44 KHz for stereo audio; then effectively, you will have 44 K * 2 samples. If you are using 16 bits per sample, then given the duration of audio, you can calculate the total size of the wave file as:
Size in bytes = sampling rate * number of channels * (bits per sample / 8) * duration in seconds
Number of samples per second = sampling rate * number of channels
When you are dealing with such multi-channel sounds, single sample points from each channel are interleaved. Instead of storing all of the sample points for the left channel first, and then storing all of the sample points for the right channel next, you "interleave" the two channels' samples together. You would store the first sample of the left channel. Then, you would store the first sample of the right channel, and so on.
references:
http://www.codeguru.com/cpp/g-m/multimedia/audio/article.php/c8935/PCM-Audio-and-Wave-Files.htm
What is PCM ?
In the digital domain, PCM (Pulse Code Modulation) is the most straightforward mechanism to store audio. The analog audio is sampled in accordance with the Nyquest theorem and the individual samples are stored sequentially in binary format. The wave file is the most common format for storing PCM data.
Interchange Format Files (IFF)
It is a "Meta" file format developed by a company named Electronic Arts. The full name of this format is ElectronicArts Interchange File Format 1985 (EA IFF 85). IFF lays down a top-level protocol on what the structure of IFF compliant files should look like. It targets issues such as versioning, compatibility, portability, and so forth. It helps specify standardized file formats that aren't tied to a particular product. The wave file format is based on the generic IFF format.
The WAVE File Format supports a variety of bit resolutions, sample rates, and channels of audio.
The WAVE file format is based on Microsoft's version of the Electronic Arts Interchange File Format method for storing data. In keeping with the dictums of IFF, data in a Wave file is stored in many different "chunks." So, if a vendor wants to store additional information in a Wave file, he just adds info to new chunks instead of trying to tweak the base file format or come up with his own proprietary file format.
There are three chunks that are required to be present in a valid wave file:
'RIFF', 'WAVE' chunk
"fmt" chunk
'data' chunk
All other chunks are optional. The Riff wave chunk is the identifier chunk that tells us that this is a wave file. The "fmt" chunk contains important parameters describing the waveform, such as its sample rate, bits per sample, and so forth. The Data chunk contains the actual waveform data.
An application that uses a WAVE file must be able to read the three required chunks although it can ignore the optional chunks. But, all applications that perform a copy operation on wave files should copy all of the chunks in the WAVE.
The Riff chunk is always the first chunk. The fmt chunk should be present before the data chunk. Apart from this, there are no restrictions upon the order of the chunks within a WAVE file.
While interpreting WAVE files, the unit of measurement used is a "sample." Literally, it is what it says. A sample represents data captured during a single sampling cycle. So, if you are sampling at 44 KHz, you will have 44 K samples. Each sample could be represented as 8 bits, 16 bits, 24 bits, or 32 bits. (There is no restriction on how many bits you use for a sample except that it has to be a multiple of 8.) To some extent, the more the number of bits in a sample, the better the quality of the audio.
One detail to note is that 8-bit samples are represented as "unsigned" values whereas 16-bit and higher are represented by "signed" values.
references:
http://www.codeguru.com/cpp/g-m/multimedia/audio/article.php/c8935/PCM-Audio-and-Wave-Files.htm
Tuesday, May 2, 2017
WebRTC Basics of FineAudioBuffer
FineAudioBuffer takes an AudioDeviceBuffer (ADB) which deals with audio data corresponding to 10ms of data. It then allows for this data to be pulled in a finer or coarser granularity. I.e. interacting with this class instead of directly with the AudioDeviceBuffer one can ask for any number of audio data samples. This class also ensures that audio data can be delivered to the ADB in 10ms chunks when the size of the provided audio buffers differs from 10ms. As an example: calling DeliverRecordedData() with 5ms buffers will deliver accumulated 10ms worth of data to the ADB every second call.
Constructor is like below.
FineAudioBuffer(AudioDeviceBuffer* device_buffer,
size_t desired_frame_size_bytes,
int sample_rate);
device_buffer => Is the buffer that provides 10 ms of audio data.
desired_frame_size_bytes => is the number of bytes of audio data GetPlayoutData() should return on success. It is also the required each recorded buffer used in DeliverRecordedData calls
sample_rate => is the sample rate of audio data. This is needed because |device_buffer| delivers 10ms of data. Given the sample rate the number of samples can be calculated.
The two main function in this class are the ones below
1. void FineAudioBuffer::GetPlayoutData(int8_t* buffer)
This method asks webrtc for data in 10 milliseconds
2. void FineAudioBuffer::DeliverRecordedData(const int8_t* buffer,
size_t size_in_bytes,
int playout_delay_ms,
int record_delay_ms)
Deliver the recorded data in in 10ms samples to the observer. Consume samples from buffer in chunks of 10ms until there is not enough data left. The number of remaining bytes in the cache is given by the new size of the buffer.
references:
https://chromium.googlesource.com/external/webrtc/+/master/webrtc/modules/audio_device/fine_audio_buffer.cc
Constructor is like below.
FineAudioBuffer(AudioDeviceBuffer* device_buffer,
size_t desired_frame_size_bytes,
int sample_rate);
device_buffer => Is the buffer that provides 10 ms of audio data.
desired_frame_size_bytes => is the number of bytes of audio data GetPlayoutData() should return on success. It is also the required each recorded buffer used in DeliverRecordedData calls
sample_rate => is the sample rate of audio data. This is needed because |device_buffer| delivers 10ms of data. Given the sample rate the number of samples can be calculated.
The two main function in this class are the ones below
1. void FineAudioBuffer::GetPlayoutData(int8_t* buffer)
This method asks webrtc for data in 10 milliseconds
2. void FineAudioBuffer::DeliverRecordedData(const int8_t* buffer,
size_t size_in_bytes,
int playout_delay_ms,
int record_delay_ms)
Deliver the recorded data in in 10ms samples to the observer. Consume samples from buffer in chunks of 10ms until there is not enough data left. The number of remaining bytes in the cache is given by the new size of the buffer.
references:
https://chromium.googlesource.com/external/webrtc/+/master/webrtc/modules/audio_device/fine_audio_buffer.cc
Monday, May 1, 2017
Assertions in C - Pre, Post, Invariants.
In C, assertions are implemented with the standard assert macro. The argument to assert must be true when the macro is executed, otherwise the program aborts and prints an error message. For example, the assertion
assert( size <= LIMIT );
will abort the program and print an error message like this:
Assertion violation: file tripe.c, line 34: size <= LIMIT
if size is greater than LIMIT.
There are 3 types of assertions
1. Preconditions : Specify conditions at the start of a function.
2. Postconditions : Specify conditions at the end of a function.
3. Invariants : Specify conditions over a defined region of a program.
An assertion violation indicates a bug in the program. Thus, assertions are an effective means of improving the reliability of programs-in other words, they are a systematic debugging tool.
Preconditions
Preconditions specify the input conditions to a function. Here is an example of a function with preconditions:
int
magic( int size, char *format )
{
int maximum;
assert( size <= LIMIT );
assert( format != NULL );
...
These pre-conditions have two consequences:
magic is only required to perform its task if the pre- conditions are satisfied. Thus, as the writer of magic, you are not required to make magic do anything sensible if size or format are not as stated in the assertions.
The caller is certain of the conditions under which magic will perform its task correctly. Thus, if your code is calling magic, you must ensure that the size or format arguments to the call are as specified by the assertions.
Postconditions
Postconditions specify the output conditions of a function. They are used much less frequently than preconditions, partly because implementing them in C can be a little awkward. Here is an example of a postcondition in magic:
...
assert( result <= LIMIT );
return result;
}
The postcondition also has two consequences:
magic guarantees that the stated condition will hold when it completes execution. As the writer of magic, you must make certain that your code never produces a value of result that is greater than LIMIT.
The caller is certain of the task that magic will perform (provided its preconditions are satisfied). If your program is calling magic, then you know that the result returned by magic can be no greater than LIMIT.
Compare this with the apple-picker analogy. Another part of your contract states that you will not bruise the apples. It is therefore your responsibility to ensure that you do not (and if you do, you have failed.) Your employer is thus relieved of the need to check that the apples are not bruised before shipping them.
Assert Writing preconditions
The simplest and most effective use of assertions is as preconditions-that is, to specify and check input conditions to functions. Two very common uses are to assert that:
Pointers are not NULL.
Indexes and size values are non-negative and less than a known limit.
Each assertion must be listed in the Asserts section of the function description comment in the corresponding header file. For example, the comment describing magic will include:
* Asserts:
* 'size' is no greater then LIMIT.
* 'format' is not NULL.
* The function result is no greater than LIMIT.
*/
If there are no assertions, write ``Nothing'':
* Asserts:
* Nothing
*/
Assertion violations
If a precondition is violated during program testing and debugging, then there is a bug in the code that called the function containing the precondition. The bug must be found and fixed.
If a postcondition is violated during program testing and debugging, then there is a bug in the function containing the precondition. The bug must be found and fixed.
Turning assertions off
By default, ANSI C compilers generate code to check assertions at run-time. Assertion-checking can be turned off by defining the NDEBUG flag to your compiler, either by inserting
#define NDEBUG
in a header file such as stdhdr.h, or by calling your compiler with the -dNDEBUG option:
cc -dNDEBUG ...
This should be done only you are confident that your program is operating correctly, and only if program run-time is a pressing concern.
If you face any error like this while compiling the code, make sure you have #include included.
references:
http://ptolemy.eecs.berkeley.edu/~johnr/tutorials/assertions.html
assert( size <= LIMIT );
will abort the program and print an error message like this:
Assertion violation: file tripe.c, line 34: size <= LIMIT
if size is greater than LIMIT.
There are 3 types of assertions
1. Preconditions : Specify conditions at the start of a function.
2. Postconditions : Specify conditions at the end of a function.
3. Invariants : Specify conditions over a defined region of a program.
An assertion violation indicates a bug in the program. Thus, assertions are an effective means of improving the reliability of programs-in other words, they are a systematic debugging tool.
Preconditions
Preconditions specify the input conditions to a function. Here is an example of a function with preconditions:
int
magic( int size, char *format )
{
int maximum;
assert( size <= LIMIT );
assert( format != NULL );
...
These pre-conditions have two consequences:
magic is only required to perform its task if the pre- conditions are satisfied. Thus, as the writer of magic, you are not required to make magic do anything sensible if size or format are not as stated in the assertions.
The caller is certain of the conditions under which magic will perform its task correctly. Thus, if your code is calling magic, you must ensure that the size or format arguments to the call are as specified by the assertions.
Postconditions
Postconditions specify the output conditions of a function. They are used much less frequently than preconditions, partly because implementing them in C can be a little awkward. Here is an example of a postcondition in magic:
...
assert( result <= LIMIT );
return result;
}
The postcondition also has two consequences:
magic guarantees that the stated condition will hold when it completes execution. As the writer of magic, you must make certain that your code never produces a value of result that is greater than LIMIT.
The caller is certain of the task that magic will perform (provided its preconditions are satisfied). If your program is calling magic, then you know that the result returned by magic can be no greater than LIMIT.
Compare this with the apple-picker analogy. Another part of your contract states that you will not bruise the apples. It is therefore your responsibility to ensure that you do not (and if you do, you have failed.) Your employer is thus relieved of the need to check that the apples are not bruised before shipping them.
Assert Writing preconditions
The simplest and most effective use of assertions is as preconditions-that is, to specify and check input conditions to functions. Two very common uses are to assert that:
Pointers are not NULL.
Indexes and size values are non-negative and less than a known limit.
Each assertion must be listed in the Asserts section of the function description comment in the corresponding header file. For example, the comment describing magic will include:
* Asserts:
* 'size' is no greater then LIMIT.
* 'format' is not NULL.
* The function result is no greater than LIMIT.
*/
If there are no assertions, write ``Nothing'':
* Asserts:
* Nothing
*/
Assertion violations
If a precondition is violated during program testing and debugging, then there is a bug in the code that called the function containing the precondition. The bug must be found and fixed.
If a postcondition is violated during program testing and debugging, then there is a bug in the function containing the precondition. The bug must be found and fixed.
Turning assertions off
By default, ANSI C compilers generate code to check assertions at run-time. Assertion-checking can be turned off by defining the NDEBUG flag to your compiler, either by inserting
#define NDEBUG
in a header file such as stdhdr.h, or by calling your compiler with the -dNDEBUG option:
cc -dNDEBUG ...
This should be done only you are confident that your program is operating correctly, and only if program run-time is a pressing concern.
If you face any error like this while compiling the code, make sure you have #include
error: implicit declaration of function 'assert' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
references:
http://ptolemy.eecs.berkeley.edu/~johnr/tutorials/assertions.html
How to convert WAV to PCM format?
Wav files are often just raw PCM data with some RIFF and Wav header information, depending on whether or not you know exactly whats in there will determine the method you use, stereo pcm data in cd quality sound is interleaved 16 bits per channel left first, often with wav files you can discard the first 44 bytes of the header and write the rest of the pcm data to your card to play or convert, but wav files can contain almost any kind of sound data, mu-law, pcm, adpcm, even mp3 wrapped in a wave file header. Another portable library is libao if you only want to open the file
for playing, very easy to use. but libsndfile does pretty much the same thing, also openal will give you a threaded write to your sound device if you making a game of some kind.
references:
http://computer-programming-forum.com/47-c-language/7c98914c3e47bd5b.htm
for playing, very easy to use. but libsndfile does pretty much the same thing, also openal will give you a threaded write to your sound device if you making a game of some kind.
references:
http://computer-programming-forum.com/47-c-language/7c98914c3e47bd5b.htm
Subscribe to:
Posts (Atom)