I am building a W65C02S based computer for fun, and I try to build basically all the tools myself. Including the assembler (yes, I know they exist, I just want to make everything from scratch myself, for fun).
When working on the JSR opcode (absolute addressing mode), I find that before it puts the program counter on the stack, it reads one byte off the stack first (program counter is set to 80 2e at this point, the stack pointer is 01b6):
READ address: 80 2e data: 20 JSR ; Read the opcode
READ address: 80 2f data: 14 14 ; Read the LO byte of operand
READ address: 01 b6 data: 74 't' ; Read the stack (why?!)
WRITE address: 01 b6 data: 80 --- ; Write HI byte of PC
WRITE address: 01 b5 data: 30 '0' ; Write LO byte of PC
READ address: 80 30 data: 80 80 ; Read HI byte of operand
READ address: 80 14 data: 8d STA ; Read opcode at `80 14` (the JSR operand)
It works OK, but what it the reason it reads from the stack first?
(Update: to explain the table. This was from my own tool. I am using an Arduino to look at the data and address buses to see what is happening there. It is a hardware CPU running only my own code.)
I am by no means a 6502 expert, but I do have a conjecture. Someone with more 6502 experience can correct me if I'm wrong here...
Your output is, among other things, just indicating what's on the bus on each clock cycle. I believe the initial "stack read" you are seeing isn't really a read at all, but simply the CPU asserting the stack address onto the address bus during that clock cycle with the RWB (read/write bit) high (so as not to write to the stack unintentionally) but not for the purpose of actually reading the contents of the stack at that address at that time into an internal register. With a stable address on the address bus, on the next cycle, the CPU presents the data to be written on the data lines and lowers the RWB signal to write the value to the stack at that address.
Related
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/
I am attempting to reverse engineer an iOS app to remove jailbreak detection. When using lldb, I got this output:
* thread #1: tid = 0xe26e, 0x00000001012322f8 dyld`__abort_with_payload + 8, queue = 'com.apple.main-thread', stop reason = signal SIGABRT
I looked it up and __abort_with_payload has to do with embedded binaries or code signing or something, which gives me reason to believe it has something to do with how mobilesubstrate injects dylibs into apps.
I tried disabling mobilesubstrate, and running lldb again. This time, it gave a different issue:
Process 16662 resuming
Process 16662 exited with status = 45 (0x0000002d)
What is exit code 45? Google searching didn't help very much, but according to osstatus.com, it can mean ENOTSUP or "Operation not supported". What does "Operation not supported" mean?
It's PT_DENY_ATTACH.
Many SO answers already cover it to some extent to give you an idea: here & here . Even in more details covered in Alexander O'mara 's blog post here
To counter it in lldb before your executable runs type:
b ptrace
You should see something like this:
Breakpoint 5: where = libsystem_kernel.dylib`__ptrace, address = 0x00000001c2b17140
Giving you indication where it's actually handled.
When you hit the ptrace breakpoint type:
th r
i.e. shortened syntax for thread return
It will force exiting the ptrace function without actually doing the denying part.
After the th r you may see something like this
-> 0x100daa548 <+140>: str w0, [sp, #392]
0x100daa54c <+144>: bl 0x100b01cb8 ; ___lldb_unnamed_function1756$$prodx
0x100daa550 <+148>: bl 0x100b02538 ; ___lldb_unnamed_function1760$$prodx
0x100daa554 <+152>: bl 0x100daa470 ; ___lldb_unnamed_function29542$$prodx
The code snippet is from OP and is irrelevant. What is important is ip(i.e. instruction pointer register) is pointing to the next assembly instruction after the ptrace call. Hence to see what's going on we must disassemble preceding assembly code. Every single arm64 assembly instruction is 4 bytes hence we type:
di -s 0x100daa544
That will most likely yield:
0x100daa544 bl <some address> ; aka ptrace(PT_DENY_ATTACH, ...)
So now you can just inspect the actual bytes of the opcodes^:
x 0x100daa544 -c 4
These are the bytes to replace with the nop mentioned below.
However it may happen the ptrace is made directly instead through a syscall like this (that's what libsystem_kernel.dylib`__ptrace: actually does internally) :
mov x0, #0x1f ; this is PT_DENY_ATTACH 31 syscall argument
mov x16, #0x1a ; x0,x16 can be set in numerous ways so I skip the opcodes
01 10 00 D4 svc #0x80
This is AARCH64 (aka arm64) assembly so I'm assuming your device is iPhone5s or newer. To further obfuscate it, the instructions might be separated by some nonrelevant instructions. If you need to follow this path check the SO question here.
So replacing 01 10 00 D4 in your favourite hex editor with
1f 20 03 d5 nop
should get you going.
One could go crazy with not using 0x80 in svc for the syscall
01 00 00 d4 svc #0
21 00 00 d4 svc #1
01 02 00 d4 svc #0x10
e1 1f 00 d4 svc #0xff
Each of them would happen to work, but it might break at any point (still it hasn’t since iOS7 up to present iOS 13).
Final remarks:
If you actually modify the binary some extra protection mechanism might exist like checksum and other self integrity checks. That's definitely beyond the scope of this question.
I was playing with a shellcode example and put some code on the stack. Here is a relevant fragment from it, as seen in the memory view of VS2013:
Memory view:
0x0018FEB4 90 90 90 83 ec 28 eb 0b e8 66 2a 1a 75 50 e8 9d 80 18 75
Now, when I see the same code in the disassembly view, interpreted in x86 machine language, all goes as expected, except for the addresses( in little endian) I see for the call instructions (opcode E8):
Disassembly view:
0018FEB4 nop
0018FEB5 nop
0018FEB6 nop
0018FEB7 sub esp,28h
0018FEBA jmp 0018FEC7
0018FEBC call 75332927
0018FEC1 push eax
0018FEC2 call 75317F64
If I change the view to disassembly with code bytes, I get the same type of delta between the address that I have written to memory and the address that gets called:
Disassembly view, with code bytes as well:
0018FEBC E8 66 2A 1A 75 call 75332927
I think I may be missing some big theoretical fact with this one, but could some one explain it to me?
The addresses I wanted to call are specific function addresses from kernel32.dll, but I had to make some arithmetic on them to actually make the code execute and call the correct addresses.
I am new to the Bluetooth system and I am trying to understand the data used for the new Apple's technology : iBeacon.
There is already some nice answers which explain how it works and I have been reading everything I could find (especially the Bluetooth Specification). Still, I am missing some points and I will go for an example first : (I am using the Set Advertising Data Command, it misses here the hcitool cmd before the OGF)
0x08 0x0008 1E 02 01 1A 1A FF 4C 00 02 15 E2 C5 6D B5 DF FB 48 D2 B0 60 D0 F5 A7 10 96 E0 00 00 00 00 C5 00
I will list here what I didn't understand or find information about.
Is there any information anywhere about the OGF (here it is 0x08)? I know it stands for OpCode Group Field, but contratry to the OCF which follows the OGF, I didn't find anything.
What does the 02 01 1A 1A bytes line stand for? I know that the first byte, 1E, tells the length of the rest of the data and after that line, starting with FF, you get the manufacturer specific data. But I couldn't find anything about those 4 bytes.
How does the power byte work? Here it is C5. I know that what I get is the dBm value when ranging my iBeacon (on my iPhone for instance). And I know that the higher the value (on that power byte), the higher the power which means more accuracy but also more energy consumption. But how do you use that byte? What are the min and max values you can set? Or is there any kind of formula there? Do you get a set dBm value (at one meter from your iBeacon) for a set value on the byte?
Thank you.
Answers to the first two questions can be found in the gigantic Bluetooth 4.0 Core spec.
The OGF of 0x08 groups OCF commands for LE Controllers:
For the LE Controller Commands, the OGF code is defined as 0x08.
(Bluetooth Specification Version 4.0 [Vol 2], page 1114)
Because the 0x0008 OCF command is a controller command, you have to use the 0x08 OGF code with it. Confused? Forget it. Just know you use 0x08 0x0008 to set the advertising data using hcitool.
The byte sequence starting the advertisement is as follows:
1E Number of bytes that follow in the advertisement
02 Number of bytes that follow in first AD structure
01 Flags AD type
1A Flags value 0x1A = 000011010
bit 0 (OFF) LE Limited Discoverable Mode
bit 1 (ON) LE General Discoverable Mode
bit 2 (OFF) BR/EDR Not Supported
bit 3 (ON) Simultaneous LE and BR/EDR to Same Device Capable (controller)
bit 4 (ON) Simultaneous LE and BR/EDR to Same Device Capable (Host)
1A Number of bytes that follow in second (and last) AD structure
FF Manufacturer specific data AD type
4C Company identifier code LSB
00 Company identifier code MSB (0x004C == Apple)
02 Byte 0 of iBeacon advertisement indicator
15 Byte 1 of iBeacon advertisement indicator
-- Bluetooth Specification Version 4.0 [Vol 3], "ADVERTISING AND SCAN RESPONSE DATA FORMAT" p. 375
-- Bluetooth Specification Version 4.0 [Vol 3], Appendix C (NORMATIVE): EIR AND AD FORMATS", p. 401
The power field is simply a one byte two's complement number representing the "measured power" in RSSI at one meeter away. In simpler terms
Here is how that works:
Hold an iBeacon scanner (like Locate for iBeacon for iOS) one meter away from your iBeacon transmitter.
Read its signal strength in RSSI. It will be a number between -1 and -127. (-1 is very strong, -127 is very weak)
Convert this number into a hex using two's complement. (Add 256 then convert to hex)
Note: The power field can be 80-FF. If it is 00, iOS will not do a distance calculation at all. You can read more on how this is used here.
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.