I'm using compression_encode_buffer with COMPRESSION_ZLIB to zlib-compress data in an iOS app, but the result is missing the zlib header.
For example:
size = compression_encode_buffer(
destinationBuffer, destinationBufferSize,
sourceBuffer, sourceBufferSize, nil,
COMPRESSION_ZLIB
)
Will return the bytes:
AD 53 C1 8E 9B 30 …
While using, for example, Python's data.encode("zlib") on the same data will return:
78 9C AD 53 C1 8E 9B 30 …
^^ ^^ correct zlib header
What's up with that? Why isn't the header being included? And is there a "correct" way to add it?
The two bytes are a zlib header, not a magic number. Most likely you are missing the final 4 bytes of the stream (the ADLER32 checksum) as well, and only have the "deflate" datastream that you expected to be wrapped in a zlib datatstream. The iOS documentation says as much:
ZLIB
The encoded format is the raw DEFLATE format as described
in IETF RFC 1951 Using the ZLIB library
They should have called the compression method "DEFLATE" not "ZLIB".
See this related question about dealing with ZLIB vs DEFLATE data.
Related
I am developing a VPN (iOS Network Extension), and using C/C++ to read file-descriptor directly (instead of Swift), currently it successfully captures device's request Packets, but I don't know how to parse iOS's packets, I could not even find what network layer or protocol the packets are formatted in.
I converted Packet's binary into Hex to be able to decode with online tools; below are samples of what I need to parse:
000000024500003B5461000040110C390A07000208080808FA2D0035002739B4DE790100000100000000000003777777056170706C6503636F6D0000010001
000000024500003CBAE200004011A5B60A07000208080808E48A0035002892DAE43B01000001000000000000037777770669636C6F756403636F6D0000010001
00000002450000375324000040110D7A0A07000208080808DD7F003500232BBA841801000001000000000000056170706C6503636F6D0000010001
But when tried parsing with online decoder, they fail saying invalid packet.
What network layer or protocol is above?
Note that above are 3 packet samples (not one splitted by me).
It's tun-layer protocol with 4 bytes prefix:
1. Once we use C/C++ to read file-descriptor, in NEPacketTunnelProvider like:
let tunFd = self.packetFlow.value(forKeyPath: "socket.fileDescriptor") as! Int32
// ... pass above to C/C++ backend
Instead of using Swift like:
self.packetFlow.readPackets { [weak self] (packets: [Data], protocols: [NSNumber]) in
// Handle packets here...
}
2. There are 4 additional bytes prefixed to the tun-layer packet (e.g. 00 00 00 02), each time we read packets.
3. To allow most online-tools to understand the packet, remove those starting 4 bytes, and instead prefix it with Mac-Header-Hex like:
01 00 5E 00 00 09 C2 01 17 23 00 00 08 00
Note that by doing above, we convert initial tun-layer packet to a tap-layer packet.
Also, remember to prefix again those 4 bytes, once writing a packet into the file-descriptor (after removing Mac-Header).
Update 2021; Apple discourages accessing file-descriptor directly (and it may be removed in future iOS releases).
This is not a programming related question. It's a question about where to find the right documentation.
If this is not the right place to ask, please let me know and I'll move the question
I'm working on a C++-Deamon for parsing recieved BLE Advertising Packages (like hcidump from bleuz). For this I'm focusing on parsing only LE Advertising Report events (Bluetooth Core Specification 7.7.65.2, S. 2382 ff)
E. g: I need to extract the local name and the 16-bit UUID. This information can be found (if broadcasted) in the field "data".
I can extract the data part from the Advertising Event Packet (since it's described in the Core Specification how these packages are arranged) but I can't parse the data. I wasn't able to find a description of the codes used in this data frame.
I also went through the Core Specification Supplement, but I couldn’t find the corresponding codes. I only found some examples:
See Site 26: Apparently the byte 0x09 indicates that the following n bytes are the broadcasted name of the BLE-Device.
Or Site 25: 0x03 seems to indicate that a "Complete list of 16-bit Service UUIDs" is following.
So far I gained my knowledge about this by just going throught these (incomplete) list of examples I found and from looking at the source code of hcidump.c.
Now the question is: Where can I find the official complete list to those bytes/codes?
Just an example of the package content I revieve:
Respone: 04 3E 1C 02 01 04 01 55 19 19 E4 8D FE 10 0F 09 54 65 73 74
20 49 50 53 50 20 6E 6F 64 65 C5
It should be able to extract the following data
HCI Event: LE Meta Event (0x3e) plen 28
LE Advertising Report
SCAN_RSP - Scan Response (4)
bdaddr FE:8D:E4:19:19:55 (Random)
Complete local name: 'Test IPSP node'
RSSI: -61
After going throught the whole Bluetooth SIG, I finally found the site where these codes are described:
https://www.bluetooth.com/specifications/assigned-numbers/generic-access-profile/
This question is unlikely to help any future visitors; it is only relevant to a small geographic area, a specific moment in time, or an extraordinarily narrow situation that is not generally applicable to the worldwide audience of the internet. For help making this question more broadly applicable, visit the help center.
Closed 10 years ago.
I'm trying to figure out what data an iPhone game app is sending. It uses the GKTurnBasedMatch framework.
I've captured some of its packets and I found a promising XML message with this string as the value for a game-state key:
eyJHYW1lR3VpZCI6ImJkMTIwYWZiLTNjNjQtNGU3Ni05MzdhLWZlMTYyOGUxZGI1NyIsIkdhbWVEYXRhIjoiQWdFVXdxbHA4aUxSdlZ3UWZXK1d0T0hpbkZXalVheHQ1MXlsM01MQ04ydytMZ2Q5aVNPeGJSRnZ2dzZnMnVTcjJSZ1hUY3lxYzlZWHVmZFZGZTFndVM0QjEwZXZcLzRCRXBPNGZQUHFlR0RadDk4WkxKdG83SXZQQkFQVGcyNmh0ZmRMTFB2cm1uM0o0b3NFWmtcL1lkeXNYeDBnMmtMNUdVZWtYXC9US24rYURVTlpJbzk4MGZLTkRwVnU0ays5cDdPOER3RVRCUU8rOVZhdEhPSUh1eDBFR0dUaUtwVGRSS0tEWUFkb3c1bmtnZ2FOakwrYVU4Q1FudXJIajZcLzNXSzZPbzNvVVpRR3o4VU50RFB2QzFvYm90TTNnRHBjdDNaZ250WDZlWkxweDVvc3VpUnN4OFNWcWFpR29hTTg5VE8xeG84ZXRXb0hXQXFmYU13eG5mblJ2TFprVTVxRkZnTGljS0U5dUZDZUg5UCs0cDlXMFFQejg5TXlzaGF5dFdDdFJxOEZHYkg1c3dJeW85UmZ2Q1Y0V1daTE9CWDF1OWVZTXZGVHFkMStmMFwvdm5VSVJRUFp0NlNGY3pHaXhPWGtGaWpPeXNPMEtHT2F2M2JWK1F4UXEzSG95SUwrVjVBQTIyRmExWjB0Mjhub2F4ME1vUUF2T2ZaejZWSlwvY0dyNFNneWZQeCtEdnVVQU9lOFJycDNrK3YxZTlhXC94Vk43WGdKRG1vNzRBUkxcL1wveU5hMGx1MWxqRXN2NnVrVUJcLzZRdkJnZGdsSG1tOGhQa0VLTzJ0M0NveXBHM0FBaEUzVlVHcmNpbm9mTE11OTI0MDFpWmFXWUV5MTJOXC9XOXFKcFNtR2lsaXVYVmNITnA5Wm15U1hIQ05lOEVwNVhqSk1jZ3h4ZnRFRkEwaXlEQkM3b2tJVjdXNmc4ZHZDNGdNcVFnMXNSRjlXTGJxU0l3S3BKM1BGYm51QlZNb2xodDQzSTJLXC9tU2JWRU1VRnhyME5mNitDZnlNYm5PZ2ZOMG9wblFXXC9rNm5RQitkXC8yeVVWY2poVXBxb0RpR05IRFIydldcL09CZXJiQ3JUSmtZK3V3aFZWcDVSNlBqWHdPVXRNek1BenduU0tETGFNK1BIMitvZTY1WXRVZmNRM0p6Wkc5bUNpNk50ZmhZWUNscWtJcHpsNVYrRE1MUXdLR294eXhJVnhcL1F3U094Q3lvTjNGdm90RlhBU0ZEWXVGb1R0ckdHSHlrWlFIYzljYks4K2REUXAycVhHK3VoYSt5VEhseElRSjJUcTNmMU5zY3cyQXlcL3dncitVekdEV0lseVdiYWQzWXNTTVhOVUJucFNpaHYydkxEbEF3MFArUnVsOTMyUzFMeEttSzRKWnRvY08zVlp0UXlpUUpIcklhNVdzUTRvb3JnVHQrc0ZFemxqQytOeXRGQ3h1dlpcL042ZUVTUFROTDZsMFJHZnk4c0RuSnBiR1VvS0lsXC9zMFdnTFRxelp6cXY5bXJGTkpcL2c2WXYwNTNzc1BhSWJkbW1JVG4rcnpmeUhwTnJrVkFKN0NPdGFxd2VnbmRnN3FuMDhidGJjMHF5Mm5rZU5wVkRtejBINGY0eFVXMDROSjYrR0R3QnNoTVNqNUV4YVJVWXBza3F0XC9mQmZcL2t0cGFkTk9nWkt2dmNoOGJUTXBcL2J2TTVtdnptc0NOUUxsalM1cEZwRFI0RDVHQzk3RzZzMnMxNExiNE1Sd05oaXpKMCs1cEc0M1BId29tK1Vna1ZTcG9Td083Qk9HeGQ4VVhGZENCV0hmbmhpanY1SEptajJLcm84N3Fhc0tNT00xS3NOWEtEREduXC9DQmRJUDBqVFJ4a0p5MjFUYUswT2ptYktFbU43RHNWRjF0U09DTU1rU2FXRlJqNWNVZ3lzVzhSbzNvcnRzOEltQW1HWWVoVzNCTHZYbUdVcUljdXNHSUxVbzhuOW5vK2tjQnlSSzhIU3poVXlPclpBQndPcW5wd1FzZ084YVBjc2hyQW1zZWtqSmpLb2N1NkMxUEluWGhqMzJ4aWhhTVJnVGxwNFVnTjlkNXA2WGVwZ1A4SkZLOURmdjUrRDN2RnBsRFJvZnpLTmVucEVsV3QyM2xKTGg1NzlLUmtCWnpBdlJwOSthWDVEdHh1bDR4NnhZR2pBR04xUUk0Q2hNbXl3SVR3clJqQUNwSHlkK0tsQmNMQWpUNmNZZFhsUldkTW52SEpyV1RFMVUzaTZISkRZakNlbXhGMVg1MWVqR1BVSzZLOE9UKzJzYzNcL2tmQmJjM0I4VUJZMitJSWNGYTd1YWVFMFc1RWJDZnA0c004UzVWZ1dUM3VsdUI2aUJOQ2UyRFJrYnF2VU9IWmVJbVNmODd5VktnSysxMW5OVUNXNmtnMjhVTTdIdysyU1E3T1NXeEI3dXV3Q2tKejc0M0I4cVBlOVJQejJxWGxodGdMTmZTSGpCaWJXSytVVTVcL0UzU1l1dDIrdnJLSDNWS0NvMTNTbCtEQlBMVGFhSHhkUEhLR0pQdEdUMVZobERnMmRlTGlLZVkwaEdPMGhzSUFGWTVEYVJuU0xwWWd5Qmw1cEI3Mmt6MVJmXC9IWGhvRkE4bU04aHhLY3JSKzM4eXZ6YmwzeXZmRzdOTzFFeitSamF3ZVBaT1J1VWRBYkVIMmdUK01Gb3BPSStZR1lYV1BGVjhLVG1JbW5wYzBlNGo3NiszT3c0eGFhQ3dONGd0c3JSbnNiNEdpU2I2TVRoNDJwR2JpOEtMbk53bXJTRVM2NCtWMFoyVkQ1bFwvUUNIV1o2QnppVFhsdUZhYUdCMGVBeUxPWlQzMXF6bTZGMDBhNnVPNEY4M0c4dWUwa1poT2RBNlRIdXU0TVpDVHF0VEpkM3p2WmU4bTdtaG5SNlFhM2tOd3BNZW9lcjY4ZGxiaGRUYmtpVFNYODh1Z3VvNVlcL1IyemRhQ0NYTERuZUFjZWRmNmlDWGFuXC9ONFZsekRhYVRLdUxoY2hnM2NFMllFWGtieGxSN29INWN1Y3hWUnhQTG1VZEo1TFFrdVwvZ0Nwc3pGVExTUUJnVUdkQjdzams4cE1hZUthOGl4K0RXYWVoTjE1ZFBVd1c3NEJVWG5ucTMxdG1NdnJ6M2xUTXF5OGF6NFM5ajRDd1pubjI0QzR5XC9RNTI1emN3djM2RFJyMVpcL2ZyTWl1Zk9tVGNSSjFlYzJ0XC85NU1HWDZITERqUW5waytoajBEaG5xNGw5WHAyblRtZElYUktMM2p1bTNJZFwva21EbkkwTFptQzBTRStsU1doQWI4aXFIaXl2MWxQTGJpYkkrUm15TlVNdXpcL0lxMStiMCtiTlNVRXpYTXg1MDJHK2hJcHhyNWFYQ0ZOYktTWEpXZDlIdGpHNHBFQU94RENQc1BMTjF4bjhkZWZLQkdkcytuV3ZBa3EyZXlOM2NxM0sxU3ByaHZLWXd4enJcL0FEVTlYTXMyVDVkS3F1bzdlclBHaHp2NU5BTUVSUWNnWGNkRjRaZ2NOZ3pmYTBLOGd3aEpsOGR4ZU02cjl5VEROcWQ0YkpQNEgyXC8rczI2eXlwVkRnaUhQVWRxMGxUanFlN1NtbTREWG41VWthV0JHSnBJRDdNWDk5d29hN2N0YnNhOXM4OGVFSWJ0YmRHWDAzMkRxS1wvcUZrSXdRU0I4RXZhTzNJcVlnQ0I5YXBSQlp4ck5mVk9kMGlUNVNYckFseFF6QW1Jd0dxaGtRZVpkVm92M3BJREk4QkxpdCs4eVNQUGMyejQrTjJvM3F2VlJneVk4WmY5clNtdHM1M0tURmxNVzZTM0tIQ2pDc3FWN1poVkZGNDdwN0F4NWV5R05rVFFWUFROZ2xlRWNyeEVXRWszYUQ1SzlLTjM0UEQ1dGd6eDd5dGM0TUdvb0hmTEpWTDQ1ekJYYTJCVXdKbHVZUGltaXM1TXh6ZUt6NzNHKytJSzllV3haMERoSkV2bnFubUlES29wS1B0S0orbFpYMlFNcEtXNVBObjdLc0FiN2hjQzFrb1oxQjhrcnhvQnFVejZZNnVBYTY5akpjUmhOZlNNbG8rMzA3MG5hbFpST1p3NHRTVVpJclwvYXNUc25nVWZ0XC9JRUNcL3FtSTRvZ0NjNGxLZ0VjXC94K0tzV1p3K0g3Qk4zODVGXC9qaCtVcG9sTGVEU3lTV3BLbXY1Mll1eDRpOHlkaVNNcFc2Y0RNNmFrT2ZUZWhkclNRTlAxd3BnR0NoZGM5NHloWmx2NmZJYVN5T3dFQXRvc3FQQ1RKTmg1UFI4ZVBram5FakR6dXlNRmhcL2pYSEhiWEpFdWkyd2kzSmZWYlNYWWpyTDlNeUd1SFYxXC9YSnZrZ0ZOU1FHZ2RSWllCSjhIckhmWGdraWt6WEFJNzVLc2twYzlud2RzTFNNRHhpVitVRlwvVFo3R2REMFQ2QkxKSHlCSitUTGdtZDZOZUZtR0cyRVZjb0dBRjY0ZThkOUdmS3BcL1pwRlh5N0dnamtRZjNrR0c1MjdlV3FiUkJhNWtldW0xUzd0RE00M0NBRlBqT0hEbnVYang5RUVsanJXbTErck1mWng4bWtzV3h4cmVFczBXUXBPaHZiT1JIcjZcL2RVSGdKY1l3SFk0bkQ3UWdGdlJpTXdndnRtR25tMXB6QzVZU3U3TEt2YWVEVGtyakZMVGhaTFBDZFQreStJRnNsXC9RdzRTaFJlSGN2bWdRT2NBSnlJVnlhNnY0T2RUSEwwSk95Z3F2SGthdWdQeFFjekEwRDV4bXl2XC9zOHhWb2F2M2xjOFwvRjhvWm5JMlB0b2xzMjdESVBsTkhOMkt2aXp1NDdKSmh2VW9WT1lqWlV3bEZ2RzUrbXB2c0hIckhld21zM1FLRVwvN3V1RklxOXlid2J6NFwvUzVrdE5XQ29OUnh3RDNhMVhvSmlSSjdUcVh2V2M1U1ZuUVJ5M3h3Z0lvV0VtbFNaTjREU3JidHFOVzh2UFFpYUV0SlF0azRKeFBvNVwvajlXblFiUjJMeTFJbWRSVldXNEZERG02WGtkSEx3b05KZ0ZIYXQ1RUh1NDJRZGJjcytXclFTTExBdmVsZGJkWHdSMkJHR1FCa2JidkVtTTBqMHhXR2lcL2hKVFg3aFFxWXNiWkpnR3dXeHVheTd4dE00dWw1Q1NWQ1ArZU9NdDJPcHEzQVU0aEJLSnJnRUN3R1FDM3lhM3ZlVENXZnk0M2lEQ3N2dTlcL0Qyanh1bGdRR1pJWTZObDU4c3A4SVFlaGxDTk5scnNQN3haZ0ZxVVZxS3ViblF0R2tLeENvM01nSUtCSVQxQzB6OHpDd3ZHTFNKelBCaEFYOWNENU10djg0bGZXdmpRSFczNWdpNHJmdkc4cUZ3SGw4RlVjWjdcL05udk15U2l3K0pZRlU2S3pMMFVXdnRaVTZrMWtVWmZnaWNNSDdUWlRkTWhodU9ZTzVrMDlSbDNrbHVYNGdzV3hSUTRNVWtkMTJsN1FiajlnUGVhejRTOTRwMXdzNUhqQ1lhUVZEMzhuc1dqb1VsXC9xQVVlWDMrR2FcL1RzRXFkN1NocFYxT3dYOTRzaDYzb3lKb1gzXC9tZmlxRGlMZUdMSEhtQWhqdXZwNFJYUlwvTmJheU01WUdhUzFNaURMYzgrRzczZEtwa1JtM2xTNDRGT0lISHdcL1wvSjlvbXFJaXV2YkM0aGxHTUVcL3lPMW82NVFCOXlPSDEyV0VFSktCbGFDQlFUZzRmTjlMRlFxMU9jVjJkRkd6UDdTZ2hHb0VUMHRTTjhkc2toVWhnUUJvaWpicGlxVWRyNEprOU8rbkI0UXZcL2xFM29BNFwvWG8rblU1eDBFamgzRWFoampSQ1ZzU3RHUzdqTzVuUE9ua2hCUjROV3Q0Sm9Ca2dOK0lMOHJDb2xUekVXUUFrVFkyTzBoQjB1bldCaHVUR0JHbk9wUHl3amV6ckZ5Wlg3M1hcL3NISGpRYXBYdndSZGJKMm5Wdm05bVc0amZ1b2VlQnpsdVE4Z0NXU1FwOW1TK2VrUHg5ZVNwM2ZhMUFTeVl1V2V3TU5SM3ViUENIUU0yTkw2aFIrdmRvWCtoY2h1dzN2UnpLaDhBZzhaXC9HbEI5cENWYUpIK1QzaHpUMHowSTdJT1dxXC9PWG9JNEIyV1hPa1lMM0ZNRm5FUk9cL2I2bzA4Q0puWU52S1h0YW9lTEtBVnFEWUFmdFFKSTlmV0ZkazZCTDg0c2xXR2F4bVZ1cDF3Vk50NDBxV1wveVI5dmJnSHFrbVwvWmtcL3loTm9cL1ZLaWR6M2JiWVNHcVhoQzJzajFMTGpJS29WZDNKMHV5TDFJZjViZVNYM28yQkhSYmkwWmZMbnR3enNubGFQZmF3MHQ5bkZYbWdMRUVVaDBnR1wvZmk0RU9wQ2hDNDNUNFc0K2hLZDQzSTc2ekQzQzhZOTdlK01icnloekdJWGF4Qmd4NUdPR1FnWlZPNFdlU241VG40WXMyQ01vSkpnVEpudmgwUVE3WTk2MnBwSDF4Y0FjdGdQTG51eFhwVzQ5QnR2MG5NNUljZkwxZ0N5RUNvblo1R2ZuQW9FeUk5amM3UzFXMjF0RUpsdEZ5d3lzVmVBQktxamZjeGlBR0lhNU9rOTJXUkFcL2kzb2V6aHl6NHBvcGNlelcybysrTUgzSUF4RmVOV1JnVm1hXC9FMDRWK05JTlE1RU4rTXpSd1lGVjdzREVJaDlkanBuenJ5cEZycE1IclBlXC9qOGFuYkc4aE1tajZFN0JoN3dvdENTZno0aDhGekxhMTF6am9keUVtNG5SSThLZXZTOHpkYzdqNDFKZ0xhTmRaV1VvdzJ6RnpPY3FiWUNVZDlxaEh1MXQ3eWNlNWR4dkJTMk0wZVZ0eEw4cGRUZnFYTFhNb0diSldWYlIyWWREVTFtRzdlaGtcLzVFVStibUZRWExPNWpnUWp4OVwvRHhzK2EwZFJYRnE4WHlvVEdQd1FTaVRZa3RuVGE4NzhIQlBBN2Y4R1JkUVRlaU8wb08xNGVNWHBNYlZ4RHZcL0lBZnU1QTlFZ1FTQjNjS0xNeEFrSVkyb2UyK01INEdkQkhadDQ4Y1NXRHpLdUtqREFHa3MwMTZHVWFYMHJ5VnhoejQ1blFaa0gxNmFlTGFDS0F1MUs5VVwveFdRMDB6eDBSdWFLOCtCK1wvKzFnUHkwVHh5VkhtOEZ3UWpPYVZxM0lhbEdBV0hodnBjYWtRNk54T3gyaFZzSkN4bEl4TVVCZ3B4djF2VlN3aXA2T2RhVHV4cENYeTZhTEFabUlSeGNINlNRWWVmNERiNzhqT1hCc1NFRWJ5bkJ0OEp6OFRtcmhvWHRPUVwveDhsTlwvM0s0T0k1ZEpBbStLZHN3TzBlVUdMdz09In0=
Base64, of course! So I decoded it and got:
{"GameGuid":"bd120afb-3c64-4e76-937a-fe1628e1db57","GameData":"AgEUwqlp8iLRvVwQfW+WtOHinFWjUaxt51yl3MLCN2w+Lgd9iSOxbRFvvw6g2uSr2RgXTcyqc9YXufdVFe1guS4B10ev\/4BEpO4fPPqeGDZt98ZLJto7IvPBAPTg26htfdLLPvrmn3J4osEZk\/YdysXx0g2kL5GUekX\/TKn+aDUNZIo980fKNDpVu4k+9p7O8DwETBQO+9VatHOIHux0EGGTiKpTdRKKDYAdow5nkggaNjL+aU8CQnurHj6\/3WK6Oo3oUZQGz8UNtDPvC1obotM3gDpct3ZgntX6eZLpx5osuiRsx8SVqaiGoaM89TO1xo8etWoHWAqfaMwxnfnRvLZkU5qFFgLicKE9uFCeH9P+4p9W0QPz89MyshaytWCtRq8FGbH5swIyo9RfvCV4WWZLOBX1u9eYMvFTqd1+f0\/vnUIRQPZt6SFczGixOXkFijOysO0KGOav3bV+QxQq3HoyIL+V5AA22Fa1Z0t28noax0MoQAvOfZz6VJ\/cGr4SgyfPx+DvuUAOe8Rrp3k+v1e9a\/xVN7XgJDmo74ARL\/\/yNa0lu1ljEsv6ukUB\/6QvBgdglHmm8hPkEKO2t3CoypG3AAhE3VUGrcinofLMu92401iZaWYEy12N\/W9qJpSmGiliuXVcHNp9ZmySXHCNe8Ep5XjJMcgxxftEFA0iyDBC7okIV7W6g8dvC4gMqQg1sRF9WLbqSIwKpJ3PFbnuBVMolht43I2K\/mSbVEMUFxr0Nf6+CfyMbnOgfN0opnQW\/k6nQB+d\/2yUVcjhUpqoDiGNHDR2vW\/OBerbCrTJkY+uwhVVp5R6PjXwOUtMzMAzwnSKDLaM+PH2+oe65YtUfcQ3JzZG9mCi6NtfhYYClqkIpzl5V+DMLQwKGoxyxIVx\/QwSOxCyoN3FvotFXASFDYuFoTtrGGHykZQHc9cbK8+dDQp2qXG+uha+yTHlxIQJ2Tq3f1Nscw2Ay\/wgr+UzGDWIlyWbad3YsSMXNUBnpSihv2vLDlAw0P+Rul932S1LxKmK4JZtocO3VZtQyiQJHrIa5WsQ4oorgTt+sFEzljC+NytFCxuvZ\/N6eESPTNL6l0RGfy8sDnJpbGUoKIl\/s0WgLTqzZzqv9mrFNJ\/g6Yv053ssPaIbdmmITn+rzfyHpNrkVAJ7COtaqwegndg7qn08btbc0qy2nkeNpVDmz0H4f4xUW04NJ6+GDwBshMSj5ExaRUYpskqt\/fBf\/ktpadNOgZKvvch8bTMp\/bvM5mvzmsCNQLljS5pFpDR4D5GC97G6s2s14Lb4MRwNhizJ0+5pG43PHwom+UgkVSpoSwO7BOGxd8UXFdCBWHfnhijv5HJmj2Kro87qasKMOM1KsNXKDDGn\/CBdIP0jTRxkJy21TaK0OjmbKEmN7DsVF1tSOCMMkSaWFRj5cUgysW8Ro3orts8ImAmGYehW3BLvXmGUqIcusGILUo8n9no+kcByRK8HSzhUyOrZABwOqnpwQsgO8aPcshrAmsekjJjKocu6C1PInXhj32xihaMRgTlp4UgN9d5p6XepgP8JFK9Dfv5+D3vFplDRofzKNenpElWt23lJLh579KRkBZzAvRp9+aX5Dtxul4x6xYGjAGN1QI4ChMmywITwrRjACpHyd+KlBcLAjT6cYdXlRWdMnvHJrWTE1U3i6HJDYjCemxF1X51ejGPUK6K8OT+2sc3\/kfBbc3B8UBY2+IIcFa7uaeE0W5EbCfp4sM8S5VgWT3uluB6iBNCe2DRkbqvUOHZeImSf87yVKgK+11nNUCW6kg28UM7Hw+2SQ7OSWxB7uuwCkJz743B8qPe9RPz2qXlhtgLNfSHjBibWK+UU5\/E3SYut2+vrKH3VKCo13Sl+DBPLTaaHxdPHKGJPtGT1VhlDg2deLiKeY0hGO0hsIAFY5DaRnSLpYgyBl5pB72kz1Rf\/HXhoFA8mM8hxKcrR+38yvzbl3yvfG7NO1Ez+RjawePZORuUdAbEH2gT+MFopOI+YGYXWPFV8KTmImnpc0e4j76+3Ow4xaaCwN4gtsrRnsb4GiSb6MTh42pGbi8KLnNwmrSES64+V0Z2VD5l\/QCHWZ6BziTXluFaaGB0eAyLOZT31qzm6F00a6uO4F83G8ue0kZhOdA6THuu4MZCTqtTJd3zvZe8m7mhnR6Qa3kNwpMeoer68dlbhdTbkiTSX88uguo5Y\/R2zdaCCXLDneAcedf6iCXan\/N4VlzDaaTKuLhchg3cE2YEXkbxlR7oH5cucxVRxPLmUdJ5LQku\/gCpszFTLSQBgUGdB7sjk8pMaeKa8ix+DWaehN15dPUwW74BUXnnq31tmMvrz3lTMqy8az4S9j4CwZnn24C4y\/Q525zcwv36DRr1Z\/frMiufOmTcRJ1ec2t\/95MGX6HLDjQnpk+hj0Dhnq4l9Xp2nTmdIXRKL3jum3Id\/kmDnI0LZmC0SE+lSWhAb8iqHiyv1lPLbibI+RmyNUMuz\/Iq1+b0+bNSUEzXMx502G+hIpxr5aXCFNbKSXJWd9HtjG4pEAOxDCPsPLN1xn8defKBGds+nWvAkq2eyN3cq3K1SprhvKYwxzr\/ADU9XMs2T5dKquo7erPGhzv5NAMERQcgXcdF4ZgcNgzfa0K8gwhJl8dxeM6r9yTDNqd4bJP4H2\/+s26yypVDgiHPUdq0lTjqe7Smm4DXn5UkaWBGJpID7MX99woa7ctbsa9s88eEIbtbdGX032DqK\/qFkIwQSB8EvaO3IqYgCB9apRBZxrNfVOd0iT5SXrAlxQzAmIwGqhkQeZdVov3pIDI8BLit+8ySPPc2z4+N2o3qvVRgyY8Zf9rSmts53KTFlMW6S3KHCjCsqV7ZhVFF47p7Ax5eyGNkTQVPTNgleEcrxEWEk3aD5K9KN34PD5tgzx7ytc4MGooHfLJVL45zBXa2BUwJluYPimis5MxzeKz73G++IK9eWxZ0DhJEvnqnmIDKopKPtKJ+lZX2QMpKW5PNn7KsAb7hcC1koZ1B8krxoBqUz6Y6uAa69jJcRhNfSMlo+3070nalZROZw4tSUZIr\/asTsngUft\/IEC\/qmI4ogCc4lKgEc\/x+KsWZw+H7BN385F\/jh+UpolLeDSySWpKmv52Yux4i8ydiSMpW6cDM6akOfTehdrSQNP1wpgGChdc94yhZlv6fIaSyOwEAtosqPCTJNh5PR8ePkjnEjDzuyMFh\/jXHHbXJEui2wi3JfVbSXYjrL9MyGuHV1\/XJvkgFNSQGgdRZYBJ8HrHfXgkikzXAI75Kskpc9nwdsLSMDxiV+UF\/TZ7GdD0T6BLJHyBJ+TLgmd6NeFmGG2EVcoGAF64e8d9GfKp\/ZpFXy7GgjkQf3kGG527eWqbRBa5keum1S7tDM43CAFPjOHDnuXjx9EEljrWm1+rMfZx8mksWxxreEs0WQpOhvbORHr6\/dUHgJcYwHY4nD7QgFvRiMwgvtmGnm1pzC5YSu7LKvaeDTkrjFLThZLPCdT+y+IFsl\/Qw4ShReHcvmgQOcAJyIVya6v4OdTHL0JOygqvHkaugPxQczA0D5xmyv\/s8xVoav3lc8\/F8oZnI2Ptols27DIPlNHN2Kvizu47JJhvUoVOYjZUwlFvG5+mpvsHHrHewms3QKE\/7uuFIq9ybwbz4\/S5ktNWCoNRxwD3a1XoJiRJ7TqXvWc5SVnQRy3xwgIoWEmlSZN4DSrbtqNW8vPQiaEtJQtk4JxPo5\/j9WnQbR2Ly1ImdRVWW4FDDm6XkdHLwoNJgFHat5EHu42Qdbcs+WrQSLLAveldbdXwR2BGGQBkbbvEmM0j0xWGi\/hJTX7hQqYsbZJgGwWxuay7xtM4ul5CSVCP+eOMt2Opq3AU4hBKJrgECwGQC3ya3veTCWfy43iDCsvu9\/D2jxulgQGZIY6Nl58sp8IQehlCNNlrsP7xZgFqUVqKubnQtGkKxCo3MgIKBIT1C0z8zCwvGLSJzPBhAX9cD5Mtv84lfWvjQHW35gi4rfvG8qFwHl8FUcZ7\/NnvMySiw+JYFU6KzL0UWvtZU6k1kUZfgicMH7TZTdMhhuOYO5k09Rl3kluX4gsWxRQ4MUkd12l7Qbj9gPeaz4S94p1ws5HjCYaQVD38nsWjoUl\/qAUeX3+Ga\/TsEqd7ShpV1OwX94sh63oyJoX3\/mfiqDiLeGLHHmAhjuvp4RXR\/NbayM5YGaS1MiDLc8+G73dKpkRm3lS44FOIHHw\/\/J9omqIiuvbC4hlGME\/yO1o65QB9yOH12WEEJKBlaCBQTg4fN9LFQq1OcV2dFGzP7SghGoET0tSN8dskhUhgQBoijbpiqUdr4Jk9O+nB4Qv\/lE3oA4\/Xo+nU5x0Ejh3EahjjRCVsStGS7jO5nPOnkhBR4NWt4JoBkgN+IL8rColTzEWQAkTY2O0hB0unWBhuTGBGnOpPywjezrFyZX73X\/sHHjQapXvwRdbJ2nVvm9mW4jfuoeeBzluQ8gCWSQp9mS+ekPx9eSp3fa1ASyYuWewMNR3ubPCHQM2NL6hR+vdoX+hchuw3vRzKh8Ag8Z\/GlB9pCVaJH+T3hzT0z0I7IOWq\/OXoI4B2WXOkYL3FMFnERO\/b6o08CJnYNvKXtaoeLKAVqDYAftQJI9fWFdk6BL84slWGaxmVup1wVNt40qW\/yR9vbgHqkm\/Zk\/yhNo\/VKidz3bbYSGqXhC2sj1LLjIKoVd3J0uyL1If5beSX3o2BHRbi0ZfLntwzsnlaPfaw0t9nFXmgLEEUh0gG\/fi4EOpChC43T4W4+hKd43I76zD3C8Y97e+MbryhzGIXaxBgx5GOGQgZVO4WeSn5Tn4Ys2CMoJJgTJnvh0QQ7Y962ppH1xcActgPLnuxXpW49Btv0nM5IcfL1gCyEConZ5GfnAoEyI9jc7S1W21tEJltFywysVeABKqjfcxiAGIa5Ok92WRA\/i3oezhyz4popcezW2o++MH3IAxFeNWRgVma\/E04V+NINQ5EN+MzRwYFV7sDEIh9djpnzrypFrpMHrPe\/j8anbG8hMmj6E7Bh7wotCSfz4h8FzLa11zjodyEm4nRI8KevS8zdc7j41JgLaNdZWUow2zFzOcqbYCUd9qhHu1t7yce5dxvBS2M0eVtxL8pdTfqXLXMoGbJWVbR2YdDU1mG7ehk\/5EU+bmFQXLO5jgQjx9\/Dxs+a0dRXFq8XyoTGPwQSiTYktnTa878HBPA7f8GRdQTeiO0oO14eMXpMbVxDv\/IAfu5A9EgQSB3cKLMxAkIY2oe2+MH4GdBHZt48cSWDzKuKjDAGks016GUaX0ryVxhz45nQZkH16aeLaCKAu1K9U\/xWQ00zx0RuaK8+B+\/+1gPy0TxyVHm8FwQjOaVq3IalGAWHhvpcakQ6NxOx2hVsJCxlIxMUBgpxv1vVSwip6OdaTuxpCXy6aLAZmIRxcH6SQYef4Db78jOXBsSEEbynBt8Jz8TmrhoXtOQ\/x8lN\/3K4OI5dJAm+KdswO0eUGLw=="}
Looks like a dict with another Base64 string in the GameData key. However, Base64 decoding that gives me a bunch of binary data:
02 01 14 c2 a9 69 f2 22 d1 bd 5c 10 7d 6f 96 b4 .....i."..\.}o..
e1 e2 9c 55 a3 51 ac 6d e7 5c a5 dc c2 c2 37 6c ...U.Q.m.\....7l
3e 2e 07 7d 89 23 b1 6d 11 6f bf 0e a0 da e4 ab >..}.#.m.o......
d9 18 17 4d cc aa 73 d6 17 b9 f7 55 15 ed 60 b9 ...M..s....U..`.
which is uncompressible:
>>> len(game_data)
4114
>>> len(game_data.encode("zlib"))
4125
It's not zlib-encoded:
>>> game_data.decode("zlib")
Traceback (most recent call last):
File "<pyshell#126>", line 1, in <module>
game_data.decode("zlib")
File "C:\Python27\lib\encodings\zlib_codec.py", line 43, in zlib_decode
output = zlib.decompress(input)
error: Error -3 while decompressing data: incorrect header check
And it's not even zlib without the header:
>>> def inflate(data):
import zlib
decompress = zlib.decompressobj(
-zlib.MAX_WBITS # see above
)
inflated = decompress.decompress(data)
inflated += decompress.flush()
return inflated
>>> inflate("roflcopters".encode("zlib")[2:])
'roflcopters'
>>> inflate(game_data)
Traceback (most recent call last):
File "<pyshell#130>", line 1, in <module>
inflate(game_data)
File "<pyshell#128>", line 6, in inflate
inflated = decompress.decompress(data)
error: Error -3 while decompressing: invalid distance too far back
I've tried using this online Objective-C compiler along with various classes like NSUnarchiver, NSKeyedUnarchiver, and NSPropertyListSerialization, but no luck, yet. Those all seem to produce output which at least has recognizable strings in it so even if they are used, something else must be going on as well.
The only similarity between different batches has been that they all start with 0x0201. Everything else seems totally different, even for subsequent updates for the same match, which makes me wonder if there's some obfuscation/encryption going on...
Any tips on where I can go from here?
It's almost certainly some proprietary structure from within the game, serialized out to bytes. 0x0201 could well be versioning for a struct, or just a set of flags that doesn't change across blobs you've seen.
There's no need to assume this is intentionally obfuscated or encrypted data. Standard textual (JSON, XML) and binary (bplist) containers are increasingly ubiquitous and often make one's life easier, but there's nothing nefarious about representing data in a more raw binary format if it's convenient. (See below re: encryption)
To really reverse engineer this in any more detail may be a Sisyphean task: figure out what the values in the binary blob are, numerically or otherwise. Match up the game state data with known (or unknown) values for the game. Do reverse engineering on the code to see what it's writing. That's some varsity stuff, but it's possible.
Re: encryption: encryption, or at least signing, is common in some parts of online gaming to prevent tampering with game state by bots to gain advantage. Whether that's happening here or not is anyone's guess. A bunch of floating point numbers that represent world positions could look similarly random.
Is there a way I can Convert my Lockbox 2 Cipher text to LockBox 3 Cipher text.
We are migrating our application built on Delphi 2007 to Delphi xe2, we used the Lockbox 2 RSA Encryption algorithm in Delphi 2007 and we intend to use lockbox 3 in Delphi xe2 to support Unicode data. since the cipher text generated by both of them differs as Xe2 supports Unicode data we face a problem . So we would like to convert the cipher text that is generated by Lockbox 2 to LockBox 3 somehow.
Since your cipher text by definition is unrecognizable, there is no easy way to tell if the underlying plaintext data was Ansi or Unicode....so you likely need to manage a new associated property.
It obviously depends on the layout of your application and where this data is stored and how the clients are going to be upgraded, but there could be a new version flag of some sort associated with the stored ciphertext. If it's in a local table say, add a new column for PlainTextVersion and set the version to some value to flag that the ciphertext was saved from Unicode plaintext. When reading the ciphertext and this new field doesn't match the Unicdoe flag, you could upgrade the ciphertext by decrypting, and encrypting using Unicode plaintext, and then re-save the ciphertext and set the new flag (or simply put-off the ciphertext version upgrade until the plaintext has changed and needs to be updated.)
Or, better yet, auto-upgrade all current ciphertext at one time if feasible.
To convert, it would be easiest to use Lockbox 2 to decrypt your cypher text and use Lockbox 3 to reencrypt it.
The reason is that from what I can tell, Lockbox 2 stuffed up the implementation of the RSA block type 2 padding which means that Lockbox 2's RSA encryption is not compatible with anybody else's RSA decryption.
Lockbox 2's RSA encryption pads out the message incorrectly as follows (found by placing a breakpoint and inspecting the memory at biBlock.Fi.IntBuf.pBuf):
message-bytes 0x00 random-padding-bytes 0x02 0x00
e.g. 'test' was padded to:
$01C883AC 74 65 73 74 00 D4 50 50 test..PP
$01C883B4 A7 BO E5 51 7A 4C C2 BC ...QzL..
$01C883BC 8C B8 69 8A 97 DF AA 1D ..I.....
$01C883C4 78 67 1E OE 8B AB 02 00 xg......
But it should be padded out to (e.g. look at this worked example):
0x00 0x02 random-padding-bytes 0x00 message-bytes
Lockbox 2 isn't just storing the bytes in reverse (otherwise the message "test" would also be reversed) or reversed 32 bit little endian (otherwise the 02 00 would be swapped too). Everything works so long as you use Lockbox 2 for both encryption and decryption.
Also I noticed another bug where Lockbox 2 calls e.RandomSimplePrime() to generate the public exponent e but it generates an even number i.e. a fairly noteworthy bug in RandomSimplePrime() eh? I only looked at Lockbox 2.07. Lockbox 3 was a complete rewrite, so it won't have these bugs.
I'm having troubles decoding/encoding a base64 string because of the CRLF on it.
I've tried this lib Base64.h and this one NSData+Base64.h but both do not handle well the CRLF.
Anyone had this problem before?
Anyone has an advice on how to avoid these CRLF? I think Android's Java lib is replacing this with a '0', am I correct?
public static final int CRLF = 4;
Base64 encodes 64 characters, namely 'A-Za-z0-9+/' with a possible trailing '=' to indicate a non mod 3 length. CR+LF may be used as a line separator, generally decode each line separately.
See Wikipedia Base64 for more information on CR+LF variants.
"+vqbiP7s3oe7/puJ8v2a3fOYnf3vmpap"
decoded is:
"FA FA 9B 88 FE EC DE 87 BB FE 9B 89 F2 FD 9A DD F3 98 9D FD EF 9A 96 A9"
The last character is not 0.