Got it. Here's how to calculate, using your first string as a simple example:
First, we rearrange the packet, omitting the checksum.
Then prepend the values A3 02:
a3 02 1f 01
Then calculate the checksum by starting with a sum of 0, multiplying the sum by 33 (decimal) each time and adding the value of the next byte.
Here it is in C ...
Writing your example, aaa b in binary, and as well the encoded string, 0xb0 0xb0 0x30 0x10 0x31:
a a a ' ' b
01100001 01100001 01100001 00100000 01100010
10110000 10110000 00110000 00010000 00110001
it looks like every byte of the encoded string being the original byte shift right by one bit, with the last bit of the next ...
I'd assume the first byte is a message type ID, the 2nd and 3rd bytes are checksum, and the rest is payload. As the game is probably an i386 game, the payload ought to be little-endian. Now, if we compare your first 4 examples, with bytes 2 and 3 written as a 16-bit-int, we have:
1f 6e45 01
1f 6e46 02
1f 6e49 05
1f 6e4b 07
1f 6e4c 08
in these cases the ...
The checksum is very simple, as can be seen from the minimal difference in checksum between 11111111111111111111111111111 and 11111111111111111111111111112, the difference is 0x21 (33 in decimal).
Then, difference between 11111111111111111111111111121 and 11111111111111111111111111111 is 0x441, that is 0x21^2.
The checksum (I'll call it y) is clearly a ...
I know of no collection of malware samples, focusing specifically on DGAs.
However, there are some resources that generally concentrate on DGAs and may provide you enough pointers to identify a reasonable number of different samples yourself.
There is Johannes Bader's github repository which features several reimplementations of DGAs found in malware, along ...
The checksum algorithm is simple indeed. It adds all the payload bytes modulo 0xFF and then adds 26.
I wrote a script to test it:
payload = data[3:-1]
checksum = 26
for c in payload:
checksum += c
checksum &= 0xFF
with open("input.txt","r") as f:
Is it possible to identify a protocol in a pcap file?
Yes, but this appears to be a proprietary protocol over TCP/IP.
The first four bytes of every message is a 32-bit big-endian value that specifies the length of the following bytes in the message.
The messages aren't encrypted, so you might be able to do some data carving. But if you really want to know ...
The command you need is chsh (change shell) - this is part of the
shadow or shadow-utils package.
You can also manually edit /etc/password to change the shell from
/bin/ash to something else:
BUT => be very careful that the new shell exists or you will lock yourself out !!!
You will need to be root to do either of the above.
It depends on the bootloader. Many will allow you to edit the kernel options, which should allow you to drop into single user mode. This is usually done by setting an environment variable in the bootloader ("bootargs" or something similar).
If you know the bootloader being used, you can look up any documentation that might be available (U-Boot, for example)...
I'm quite sure this isn't a pcap file at all, despite what file says, and the D8 doesn't seem to be a network type at all.
First, because D8 (216) isn't a valid link type according to http://www.tcpdump.org/linktypes.html.
Second, because hexdumping a bit more of the file yields this:
00000000 d4 c3 b2 a1 02 00 04 00 00 00 00 00 00 00 00 00 ...............
I would start by tracing all the traffic coming in and out of your application. A good summary of ways to do that are well documented in this stack overflow answer ().
Once you capture the traffic, examine it, what type of protocol does it use? Chances are, it's something wireshark will recognize, like http.
The next step I'd try is to examine what traffic ...
The algorithm is a CRC with the following parameters, stored in those two bytes as a big-endian short:
Xor In Value: 0
Xor Out Value: 0
Reflect Input: True
Reflect Out: True
To figure it out, I used my packet capture data, CRC RevEng, and some shell scripting to glue it together. I then used pycrc to calculate the check values ...
BusyBox is mainly focused on size-optimizing and commands could be excluded/included during compile time. So, without providing additional informations, it seems to be a very limited set of installed components.
However, it should be clear, that this doesn't mean that the firmware of the device doesn't support specific utilities per se. If this is not ...
open procmon from sysinternals
add a filter with your process name
and take a look at stack trace
if you have configured symbols then you get a pretty good overview
a small python server and client (mod from wiki.python)
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
This isn't a complete answer but is a bit more than fits in a comment.
There's definitely a pattern in the powers of 2. They all have exactly 4 bits set. The high bit is always 1 and the lower 15 bits seem to be the same bit pattern (11001) but rotated to different positions. Try filling in the gaps (32, 64, 128, 1024) and show in binary without spaces to ...
Depending on the calling convention, the indirect call you NOPped out might end in "RET nn". IIRC this is in fact the case in Microsoft's variant of the x86 thiscall convention. If you NOP the call out, ESP is wrong after the call. This is harmless if ESP is no longer used in that function, and it ends in a standard epilog that uses LEAVE or MOV ESP, EBP, ...
Connect a machine to the network / router. Run wireshark or tcpdump to capture packets. Look at captured packets to see what addresses and subnets are used.
Try going in on serial: reset instructions. Docs say it'll come up on 192.168.1.1:
The answer to my question is that my particular sample uses it's own custom protocol that it sends over SSL. I can't go into further detail without mentioning the particular sample family I was working on.
I didn't need to decrypt SSL traffic or anything, my previous steps actually did expose the web traffic the way I wanted it.
Also, I was ...
There's a huge variary of windows API functions that let a program send TCP packets. Non of those (as far as I recall) contain the strings tcp or send buffer in their name.
to reverse engineer network communication, you should start by gaining some knowledge on how packets are sent my programs, what are the relevant APIs and how they're used. This will most ...
So the problem was, the network application was using GetQueuedCompletionStatus instead of WSAGetOverlappedResult. It is explained here: https://support.microsoft.com/cs-cz/help/181611/socket-overlapped-i-o-versus-blocking-nonblocking-mode. I just somehow missed this article.
If you're asking how i found it out, well i had to do it the hard way. I started ...
This isn't a complete answer but I don't have enough rep to comment yet.
First off, giving us binary data with all the non-printable characters presented as ? doesn't help. Try piping it through xxd (like nc -l 8883 | xxd) to get a hex dump which would be far more useful.
When you ran mitmproxy were you using the real device? This is unclear from your ...
This is possible using the APIs available in the FlexNet Publisher SDK. I suggest you to consult the SDK documentation and contact Flexera support in case of problems.
In theory you could also observe the traffic between the client and the license server and deduce the packet format (this is known as "French Café technique" and was used to develop the Samba ...
One of the ways to block unauthorized internet access in similar kiosks is by implementing a DNS redirection. Responding to any DNS request with the same server, and having that server redirect you to the "exceeded data plan" with 302 Moved Temporarily HTTP response.
This can be validated by accessing an IP directly instead of a domain name, and might be ...
There are two possibilities:
The League of Legends client uses an embedded algorithm to injectively map a club name to a club UUID.
The League of Legends client sends the club name to the server and receives the club UUID in response.
Either way, you'd be able to see what UUID-channel is eventually joined by the League of Legends client by sniffing the ...
You may want to have a look at mitmproxy. This allows you to intercept and modify http(s) traffic, which may or may not be what you need, but it also has tools like mitmdump that just dump what's going over the connection.
Mitmproxy also has instructions about setting up the linux tcp stack using iptables to redirect connections. I guess this is the main ...