You can use the Image File Execution Options registry key to specify a debugger which will be launched automatically when the executable starts.
You can also always do the ancient trick of patching an endless loop (EB FE) at the entry point or somewhere later. This would allow you to attach at you leisure, restore the patched bytes and resume the execution.
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 ...
It sounds like you are talking about Windows Services. In which case I am not sure how to debug those. Perhaps you can figure out how to make it revert to being a normal app but then again that may not be possible.
I think this will solve your packet monitoring problem though. It allows you to monitor packets per process unlike WireShark. SmartSniff should ...
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:
Several great answers here, and the one posted by Igor is perfect for debugging the service before it actually starts. One piece of insight I would like to contribute is looking into the malware to see if there are any threads that are created that hold the functionality you wish to review.
Oftentimes in my analysis, I've dealt with malware that runs as a ...
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 would like to separate questions here:
1. How to debug service: answer of Igor is covering it. In basic - You may use any debugger, that You familiar with.
2. How to capture network traffic of malware (that run as a service): answer of cb88 is covering it. Any network sniffer able to capture communications of services. To capture traffic from service ...
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 ...
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)
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 ...
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:
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 ...