EvilZone

I have a crappy iron from a local electronics store, but I look after it well, so it continues to work.
Just remember a couple of things when soldering:

1. A chisel tip is often better than a fine point, even for surface mount soldering.
2. Drag soldering is your friend.
3. Flux is your BEST friend.
4. Tin your tip after you use it, no.. really. If you don't, even a $300 iron wont work well.
5. DO NOT BUY COMPONENT BAGS / BINS. Unless you're looking for a bunch of crap to practice solder. You will not get any use out of most of the components.
6. Have an idea in your head of what you want to make, buy the components just for that project. Sure it might be nice having a parts bin sometimes, but you end up having a bunch of stuff you don't know how to use, or what to do with.
7. Salvaging is not worth your time unless you want to practice desoldering. If the chip is in a removable socket, go for it, that's a few seconds for a potentially useful 555 timer or RS232 chip.
8. If you are doing resoldering (reseating / replacing a component), a hot air gun is your friend.
9. Solder from smallest to largest component to avoid them getting in your way.

-- xor

They created a file mapping called WhatTheFile.
You can take advantage of any language and map to that same file to read or write what's in it.

The function that you're probably trying to cause an exception in is itoa(v3, DstBuf, 10);
This puts the number in v3 (1) into DstBuf and converts it to a string in Base 10 format.

The file mapping to CreateFileMapping is only accessing 256 bytes.
If you map to the file and write past this, you will overwrite the value of v3, which means you can put a string in it and make it crash on itoa.

I originally placed the serial into the clipboard, then thought better than to include WinForms stuff in a Console project.
So I then put it on the console, and figured that people wouldn't want to manually type it in.
I could have left it and let people use file redirects to output it to a file, but I figured most people wouldn't know how to do that.

So debug window it is. Yes, I overlooked that it only runs in Debug mode, but it does allow copy and paste.

Also, thanks for that write up 0E 800, although you could strip the Form1 out of the project, seeing as you are not using it.

For anyone wondering, I have decompiled the executable and can confirm that it is NOT trojanized.
This is the MD5 Hash of the version I checked: CFB63FD02FCC3938AD8D879D0FC5627C
PLEASE CHECK THE MD5 AFTER DOWNLOADING, BE SAFE!

http://onlinemd5.com/

-- xor.

UDP was never made to be reliable. If you want reliability, use TCP, reliability is built in.
That said, if you want to make your own bloated version of UDP that has reliability you may want to code some of the following features:

 - Packet numbering / sequencing - UDP packets arrive out of order, so you can either hard code only sending the next packet when you receive an acknowledgement that it has arrived, or you can put a sequence number and have the receiver rebuild the packets.

 - Delivery acknowledgement (ACK) - server sends an ACK that the message was received. Also remember that the server may send an ACK, but the client may not get it, so you could be stuck receiving a packet that you already have because the client doesn't get your message saying that you received it.

 - Resend timeout - resend the packet if you didn't receive an ACK for it after a while, you'll obviously want to limit this otherwise your protocol would be vulnerable to being abused in a DDoS attack.

 - Packet checksums - make sure the data integrity is kept, otherwise don't ACK the packet and wait for it to be sent again.

 - Packet length prefixes - easier for the server to determine how much data you sent.


Easily said... just use TCP for reliability.

First, you can use a packet sniffer such as wireshark to see what a particular protocol packet looks like.
This will show you the entirety of the packets structure.

Then you want to learn how to write packets using the RAW format.

http://www.tenouk.com/Module43a.html
http://www.binarytides.com/raw-socket-programming-in-python-linux/
https://msdn.microsoft.com/en-us/library/windows/desktop/ms740548(v=vs.85).aspx
http://www.winsocketdotnetworkprogramming.com/clientserversocketnetworkcommunication8h.html

Protocols in the lower layers of the OSI Model as shown in the link below, have very well defined structures.

TCP for example has certain flags which are set depending on the point in the three way handshake. Applications such as nmap take advantage of this to perform SYN scans, RST scans, etc.

You can modify an IP header to spoof the source IP address of a packet.
You can give a packet an invalid checksum so see how a receiving device handles it.
You can say the size of the packet is really large, but only send them a small amount of data, or vice versa.
You can even fuzz these structures to find weaknesses in the layers themselves that you might be able to take advantage of.

There's a lot to learn by learning networking as well.

Reference:
http://f.tqn.com/y/compnetworking/1/S/g/basics_osimodel.jpg

Not on all implementations. It's easy to find out by trying.