I am reverse-engineering an Android app as part of a security project. My first step is to discover the protocol exchanged between the app and server. I have found that the protocol being used is protocol buffers. Given the nature of protobuf, the original .proto file is needed to be able to unserialize the protobuf-encoded message. Since I don't have that, I used protod to disassemble the Android app and recover out any .proto files used.
I have the Android app in a form where it is a bunch of .smali and .so files. Running protod against the .so files yields only one .proto file -- google/protobuf/descriptor.proto.
I was under the impression that users of protocol buffers write their own .proto files, which might reference google/protobuf/descriptor.proto, but according to protod google/protobuf/descriptor.proto is the only protofile used by the app. Could this actually be possible and google/protobuf/descriptor.proto is enough for me to unserialize the messages between the app and server?
When you write a .proto file you can set an option optimize_for to LITE_RUNTIME (see here) and this will omit the descriptors from the generated code to reduce the size of the binary. I believe this is a common practice for mobile development since code size is a scarce resource in that environment. This may explain why you found only a single .proto file. It is unlikely that the app is actually transferring any data using descriptor.proto since that is mostly an implementation detail of the protocol buffers library.
If you cannot find any other descriptors, your best bet might be to try to interpret the protocol buffers without them. You can read about the protocol buffers wire format here. An easy way to get started would be to create a proto2 message type containing no fields and attempt to parse the data as that type. You can then use the reflection API to examine what are known as the "unknown fields" in the message and try to figure out what they represent.
Related
I'm writing data to a JSON file in Processing with the saveJSONObject command. I would like to access that JSON file with another program (MAX/MSP) while my sketch is still open. The problem is, MAX is unable to read from the file while my sketch is running. Only after I close the sketch is MAX able to import data from my file.
Is Processing keeping that file open somehow while the sketch is running? Is there any way I can get around this problem?
It might be easier to stream your data straight to MaxMSP using the OSC protocol. On the Processing side, have a look at the oscP5 library and on the Max side at the udpreceive object.
You could send your JSON object as a string and unpack that in Max (maybe using the JavaScript support already present in Max), but it might be simpler to mimic the structure of your JSON object as the arguments of the OSC message object which you simply umpack in Max directly.
Probably, because I/O is usually buffered (notably for performance reasons, ans also because the hardware is doing I/O by blocks).
Try to flush the output channel, perhaps using PrintWriter::flush or something similar.
Details are implementation specific (and might be operating system specific).
Mashery IOdocs is a really a great tools for documenting API.
I'm using it for a quite big project with more then 50 methods and complex structures sent to this API, so that my json config file is more than 4000 lines long.
I self-host IOdocs on a VPS along with other stuff and the doc is awfully slow because of my long json file.
Any idea to cope with this latency ? Except obviously split my json config file into several.
I have a fork of IO Docs with some performance improvements which may help. In this instance they involve stripping out json-minify (which is only used to allow comments in the source specifications), server-side cacheing of the specifications and not having to load the specification via a synchronous AJAX call on the client.
I am working on a file system for the RTEMS OS. My question is how can I have the opendir, readdir, and closedir functions found in the unistd.h library redirect to my own opendir, readdir, and closedir functions for my file system? i.e. How can I hook them into RTEMS?
Thanks,
You would have gotten a quicker response from the rtema mailing list. The answer is that each filesystem has to provide a structure with a set of entry points which largely correspond to POSIX file I/O system calls. There are multiple filesystem types already in RTEMS and you should just follow the same pattern.
So look in cpukit/libfs and ask more on rtems.org
I have a ".pcapng" binary file, created by Wireshark.
How to detect the beginning of every new package in it?
Is there any specific bytes sequence?
Alternatively, how to detect the end of a package?
(I've seen people whose native language isn't English speak of "packages" rather than "packets" - both words come from the same word "pack", and the same word may be used for both concepts in other languages - so I'm assuming you're referring to network packets; "packages" is generally not used in that sense in English.)
The pcap-NG file format is described in the PCAP Next Generation Dump File Format document. A pcap-NG file is a sequence of blocks; each block has a length field at the beginning (and at the end, to simplify scanning backwards through a file). Not all blocks contain packets; the blocks that do are the Packet Block, Extended Packet Block, and Simple Packet Block.
Note that libpcap 1.1 and later can read pcap-NG files, so any program that uses libpcap to read capture files can, if dynamically liked with libpcap and running on a system where the libpcap shared library is 1.1 or later, or statically linked with libpcap 1.1 or later, can read some pcap-NG files using the same APIs that are used to read pcap files, without any change to the program. (pcap-NG files containing multiple interfaces where not all of them have the same link-layer header type or snapshot length cannot be read, as the current libpcap APIs don't support that.) There is no version of WinPcap based on libpcap 1.1 or later, so WinPcap cannot currently be used to read pcap-NG files.
Another library that can read pcap-NG files is the NTAR library. It, however, can only read pcap-NG files, not pcap files.
At my place of work we have a legacy document management system that for various reasons is now unsupported by the developers. I have been asked to look into extracting the documents contained in this system to eventually be imported into a new 3rd party system.
From tracing and process monitoring I have determined that the document images (mainly tiff files) are stored in a number of 1.5GB files. These files seem to be read from a specific offset and then written to a tmp file that is then served via a web app to the client, and then deleted.
I guess I am looking for suggestions as to how I can inspect these large files that contain the tiff images, and eventually extract and write them to individual files.
Are the TIFFs compressed in some way? If not, then your job may be pretty easy: stitch the TIFFs together from the 1.5G files.
Can you see the output of a particular 1.5G file (or series of them)? If so, then you should be able to piece together what the bytes should look like for that TIFF if it were uncompressed.
If the bytes don't appear to be there, then try some standard compressions (zip, tar, etc.) to see if you get a match.
I'd open a file, seek to the required offset, and then stream into a tiff object (ideally one that supports streaming from memory or file). Then you've got it. Poke around at some of the other bits, as there's likely metadata about the document that may be useful to the next system.