One Article Review
| Source |  SkullSecurity |
|---|---|
| Identifiant | 8332967 |
| Date de publication | 2023-05-02 22:37:26 (vue: 2023-05-02 23:07:15) |
| Titre | Astuces d'ingénierie inverse: identifier les protocoles de réseau opaques Reverse engineering tricks: identifying opaque network protocols |
| Texte | Lately, I\'ve been reverse engineering a reasonably complex network protocol, and I ran into a mystery - while the protocol is generally an unencrypted binary protocol, one of the messages was large and random. In an otherwise unencrypted protocol, why is one of the messages unreadable? It took me a few hours to accomplish what should have been a couple minutes of effort, and I wanted to share the trick I ultimately used! I\'m going to be intentionally vague on the software, and even modify a few things to make it harder to identify; I\'ll probably publish a lot more on my work blog once I\'m finished this project! Binary protocols Let\'s take a look at the binary protocol! If you\'re familiar with protocols and just want to see the “good stuff”, feel free to skip down to the next header. A “binary protocol” is a network protocol that uses unprintable characters (as opposed to a protocol like HTTP, which is something you can type on your keyboard). Often, you\'ll use a tool like Wireshark to grab a sample of network traffic (a “packet capture”, or “PCAP”) and, if it\'s not encrypted, you can start drawing conclusions about what the client and server expect. In a PCAP, you might see requests / responses that look like this: Outbound: 08 00 00 00 2c 00 00 00 ....,... Inbound: 40 00 00 00 2c 00 00 00 55 53 52 53 05 00 00 00 @...,... USRS.... 2c 00 00 00 02 00 00 00 55 38 f9 ed 21 59 47 f5 ,....... U8..!YG. 8f 9d 43 59 33 5c 2e 92 00 00 00 00 c4 54 f4 01 ..CY3\.. .....T.. 8d b4 43 e7 9e 9f ea db 4e 76 1a 7a 00 00 00 00 ..C..... Nv.z.... I don\'t want to get too buried in the weeds on how this protocol actually works, but when you work with unknown binary protocols a lot, certain things start to stand out. First, let\'s talk about endianness! The way integers are encoded into protocols vary based on the protocol, but a very common way to encode a 4-byte (32-bit) number is either big endian (8 => 00 00 00 08) or little endian (8 => 08 00 00 00). There are historic reasons both exist, and both are common to see, but based on the structure of those messages, we can guess that the first 4 bytes are either a big-endian integer with the value 0x08000000 or a little-endian integer with the value 0x00000008. The latter seems more likely, because that would make a great length value; speaking of lengths… Second, let\'s talk about TCP - TCP is a streaming protocol, which means there is no guarantee that if you send 100 bytes, the receiver will receive those 100 bytes all at once. You ARE guaranteed that if you received data, it\'ll be the correct bytes in the correct order; however, you might get 50 now and 50 later, or 99 now and 1 later, or maybe the next 50 bytes will be attached and you\'ll get 150 bytes all at once. As a result, TCP-based services nearly always encode a length value near the start, allowing protocols to unambiguously receive complete messages. Because of all that, one of the first things I do when approaching a new protocol is try to identify the length field. In this case, you\'ll note that the packet that starts with 0x08 is 8 bytes long, and the packet that starts with 0x40 is 0x40 bytes long. That looks promising! And, as it turns out, is correct. Once we have a length field, the next thing to consider is how the client and server multiplex messages. In an HTTP protocol, there\'s a URI, which tells the server where to direct the request. In a binary protocol, there isn\'t typical |
| Envoyé | Oui |
| Condensat | /tmp/test /tmp/test: 00000000 00000010 00000020 00000030 00007ff77741b65e 0778 0x00000008 0x08 0x08000000 0x0c 0x17ba 0x2c 0x40 0x4924924924924925 0x78 0xff7f: 100 150 1e9h 3fh 490 4924924924924925h 6074 7ff776fd0000 7ff776fd0000h 7ff77709d600 7ff777411f20 7ff77741b5e1 7ff77741b624: 7ff77741b65e 7ff77741b65e↓o 7ff77741bc23: 7ff77741d190 7ff77741d5ec 7ff7776ffe80+70↑j 7ff7777000a2: about above access accomplish actually add adminsupport after all allowing always another any appear approaching archive are around array attached authenticating avcarchiveexception avcarchiveexception@io@shared@@ awfully bandwidth based because been begin being believe big binary bit blank blob block blog body: both bottom breakpoint breaks building buried but byte bytes bzip2 c++ call calls can candidate capture” case cases certain challenges character characters chose cipher client close cmp code code: command common commonly complete complex compressed conclusion conclusions configuration confirms consider constant constants correct could couple ctf cxxthrowexception cy3 data day debug debugger debugging dec decompress decrypt def default did didn different direct disassembling does don done dove down drawing ds: easy eax edx effort either encode encoded encrypt encrypted encryption encryptiony end endian endianness engineering enormous even eventually exactly example exception excited excitedly exciting execution exist expect faced familiar feel field figure file file: finding finished first form found free from function functions generally generate get gigantic going googled googling got gotta grab great guarantee guaranteed guess gzip had handles hard harder has hashtable have head header here hex hexdump historic hoping hours how however http id+89↑j id+fe↑j id:jpt ida: identified identifier identifiers identify identify; identifying id” immediately implementing imul inbound: including incorrect initial instead instinct instruction integer integers intentionally interesting involved isn jmp jpt jump jumptable just keyboard kinda knew know knows large lately later latter lea length lengths… let like like: likely linux little loc logic long look looked looking looks lot made make matter maybe means mean… mentions message messages might mind minutes mode modify more most mov movzx msg much multiple multiplex mystery n6l names near nearly necessarily network never new next normal not note nothing noticed now number objects obvious off often ohj once one opaque openssl openssl: opposed options order; other otherwise out out: outbound: packet part passwords pcap perform pexceptionobject piece plaintext point post presumably pretty probably process program project promising protocol protocols protocol” pthrowinfo ptr publish put question: r14 r14+10h r15 r15w r8d raises ran random rax rbp+50h+str rbp+50h+var rbp+pexceptionobject rbx rcx rcx+rax rcx+rax*4 rdi rdx reached reading realized really reasonably reasons receive received receiver recv reliable remainder remember replayed request request/response requests responds response response; responses rest result returns revealed reverse reversing right rsi rsi+10h ruby run same sample sar save second see seeing seems send sends server services set settings settings” share short should shr similar since site situation size skip slst software solving some something sort speaking spent stand stands start start; starts statement streaming string strings structure stuck stuff stuff” sub super switch switches take talk talked tcp techniques tell tells text:00007ff77741b624 text:00007ff77741b628 text:00007ff77741b630 text:00007ff77741b635 text:00007ff77741b638 text:00007ff77741b63a text:00007ff77741b63f text:00007ff77741b645 text:00007ff77741b64c text:00007ff77741b654 text:00007ff77741b65b text:00007ff77741b65e text:00007ff77741bc23 text:00007ff77741bc26 text:00007ff77741bc29 text:00007ff77741bc2c text:00007ff77741bc2f text:00007ff77741bc34 text:00007ff7776ffeba text:00007ff7776ffec4 text:00007ff7776ffec8 text:00007ff7776ffece text:00007ff7776ffed1 text:00007ff7776ffed4 text:0000 |
| Tags | Tool |
| Stories | |
| Notes | ★★★ |
| Move | 
|
L'article ne semble pas avoir été repris aprés sa publication.
L'article ne semble pas avoir été repris sur un précédent.