VSAM Status code 04 - cobol

I am running one COBOL pgm which is reading one VSAM file.
Below is ithe input output section in my pgm.
FILE-CONTROL.
SELECT INPUT-FILE ASSIGN TO DDINPUT
ORGANIZATION IS INDEXED
ACCESS MODE IS RANDOM
RECORD KEY IS INPUT-KEY
FILE STATUS IS WS-INPUT-STATUS.
and FD entry is as follow.
FILE SECTION.
FD INPUT-FILE IS EXTERNAL (as this is in sub pgm)
COPY INPUTREC.
When I ran this pgm, it failed with file status code =04.
Somewhere I found that when in FD we have only one record even if the file is VB it treats it is FB. So FB should have record contains or Varying clause.
When I updated my FD to.
FILE SECTION.
FD INPUT-FILE IS EXTERNAL
RECORD VARYING IN SIZE FROM 1 TO 215.
COPY INPLAYOUT.
job ran fine.
I have one doubt Can I specify this Varying clause to maximum length, like if I write this as eg RECORD VARYING IN SIZE FROM 1 TO 2500. then will it cause any issue?

Assuming your VSAM file is properly initialized and your JCL is coded consistently with your program requirements there should be no issue.
The VARYING clause is simply telling COBOL to reserve enough space in the buffer for the maximum expected record size and indicates that the file contains records that are expected to vary in size from one I/O call to the next. If it had been FB (Fixed Block), COBOL expects the record to be a constant size and will trigger the status code 04 if the record deviates from the expected size. For VB (Variable Block) a return code 04 could still occur if your record size exceeds the maximum VARYING defined limit.
Personally I find COBOL I/O Status conditions somewhat cryptic to understand.
Here is a table of ANSI COBOL I/O Status Codes that I keep handy for file i/o debugging purposes:
0x - Successful Completion
00 - No futher information
02 - Duplicate Key detected
04 - Wrong Length Record
05 - File created when opened. With sequential VSAM 00 is returned.
07 - CLOSE with NO REWIND or REEL for non-tape dataset.
1x - End of File conditions
10 - No futher information
14 - Relative record READ outside boundry.
2x - Invalid Key condition
21 - Sequence Error
22 - Duplicate Key
23 - No Record found
24 - Key outside boundry
3x - Permanent I/O Errors
30 - No further information
34 - Record outside file boundry
35 - OPEN and required file not found.
37 - OPEN with invalid mode
38 - OPEN of file closed with a LOCK
39 - OPEN unsuccessful due to conflicting file attributes
4x - Logic Errors
41 - OPEN of file already open
42 - CLOSE of file not open
43 - READ not executed before REWRITE
44 - REWRITE of different size record
46 - READ after EOF reached
47 - READ attempted for file not opened I-O or EXTEND
48 - WRITE for file not opened OUTPUT, I-O, or EXTEND
49 - DELETE or REWRITE for file not opened I-O
9x - Specific Compiler defined exceptions
90 - No further information
91 - VSAM Password failure
92 - Logic Error
93 - VSAM Resource unavailable
94 - VSAM Sequence record not available
95 - VSAM invalid or incomplete file information
96 - VSAM no DD statement
97 - VSAM OPEN successful, file integrity verified.

The COBOL program which reads a varable record layout file gave file status code as 004. But after specifying the VARYING clause in FILE SECTION, it went fine.
Code which gave File status code as 04:
FD XXXXX-FILE
RECORDING MODE IS V
BLOCK CONTAINS 0 RECORDS
LABEL RECORDS STANDARD.
After specifying VARYING clause, file status code is 00:
FD XXXXX-FILE
RECORDING MODE IS V
RECORD IS VARYING IN SIZE FROM 01 TO 2598
BLOCK CONTAINS 0 RECORDS
LABEL RECORDS STANDARD.

Related

Finding the documentation for parsing data found in BLE Advertising Respones

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/

Passing multiple line value from JCL instream to Cobol variable 88

Example:
01 VAR1 PIC 9(05).
88 WS-VAR1 VALUE 1000 1001 1002 1003
1004 1009 2000 2002 3000 4000 4009
5000 5001 6000 7000 8000 2332 8484.
How can we pass value from JCL as instream to a Cobol program variable 88.
So, that it will be easier to modify the value without changing the program.
Two solutions which I found:
1. Using internal indexed table. So that Binary search will do the task fast.
2. Using VSAM file instead of passing data instream. (Less likely)
I think Binary search definitely be slower than 88 condition check.
I am trying to find something of equivalent efficiency as of 88 condition check.
It sounds like you want to pass a value from JCL PARM= or from SYSIN to make the COBOL program independent of a hard coded value.
This web article has a good explanation of how you can accomplish this.
JCL looks like this:
//* *******************************************************************
//* Step 2 of 4, Execute the COBOL program with a parameter. //*
//PARJ1S02 EXEC PGM=CBLPARC1,
// PARM='This is a Parameter from the EXEC and PARM= ...'
and in the COBOL program linkage section:
*****************************************************************
LINKAGE SECTION.
01 PARM-BUFFER.
05 PARM-LENGTH pic S9(4) comp.
05 PARM-DATA pic X(256).
In your case you can validate the data passed in the linkage section based on your criteria. So, once validated, you could move the value from the linkage section after converting it to a numeric value for the test.

How to use F# TypeProvider to read PowerBall csv?

The powerball schema and separators are not consistent which makes it an unusual file to read. (http://www.powerball.com/powerball/winnums-text.txt)
Sample:
Draw Date WB1 WB2 WB3 WB4 WB5 PB PP
09/24/2016 15 07 29 41 20 22 2
09/21/2016 63 67 01 69 28 17 4
09/17/2016 51 19 09 62 55 14 4
Any suggestions?
This looks like a "fixed column width" file rather than an ordinary CSV (meaning that the columns are not separated by any single character, but instead have fixed number of characters, with padding spaces).
There is some early work on supporting this in F# Data in the pull request here. We'd welcome any help getting this tested - but you'd need to get the soruce code and build F# Data from source (which is just a matter of running the build script though!)
Alternatively, you could probably do some simple pre-processing on the file before reading it as an ordinary CSV file. Looking at the sample file, using a regular expression to replace 1 or more spaces with a comma would produce regular CSV that the CSV provider can consume.

Postscript file - Image instead text

With a Postscript driver (Xerox, Canon, HP, all), when I create a PS file, for example when I print the test page in the printer properties, I get :
OK :
The view of the result is correct (with GSview for example)
Not OK :
The file size is to big, more than 4 MB.
When I edit the file, I have one big image (doNimage). I think is the reason of the big size file.
The example file : https://drive.google.com/open?id=0B9bet657DEU5alV6WFZZdDFjMmc
I'm on Windows 10, similar problem with Windows server 2012 r2.
I let the configuration of the driver by default.
Anyone has an idea ?
Thanks a lot.
Regards.
I don't understand your problem, the file you posted a link to contains text. Here's an example:
360 4485 M <202530360E0F1102381030100D100B0824152D30103102020C302A1E19181B1E1730132E28301530132D3B02230B2A2E22081308>[46 16 28 70 18 42 44 44 54 32 28 32 36 32 25 39 65 40 40 28 32 44 44 44 18 28 53 45 20 47 38 45
40 28 34 40 40 28 40 28 34 40 18 44 44 25 53 40 16 39 34 0]xS
M is a moveto and xS uses the xshow operator to draw the glyphs represented by the character codes in the hexstring, using the values in the array to modify the width of each glyph.
If you were expecting to see ASCII character codes you are going to be sadly disappointed, the files uses an incrementally downloaded subset TrueType font, so the character codes are defined as they are encountered, that is the first glyph used will be given character code 1, the second will be character code 2 and so on.
Even without that, using ASCII would limit the languages that could be supported. Back in the 1980s that maybe didn't seem like a problem, but its a long time since that was considered acceptable.
If you were expecting to be able to modify the text by editing it in a text editor, forget it. PostScript is a programming language, and the output of a PostScript printer driver is a machine-generated program. Its a lengthy process for a skilled user of the language to decipher what the program is doing. The program is not amenable to alteration, if there's a fault in the output, correct the original document and recreate the PostScript program from the original.
PostScript is not an editable format.
Thanks all for your response. I see I was not very clear in my question.
Here is the state :
With the PS driver, on a windows server 2008, I get this file :
http://expirebox.com/download/0bb511565377e8b74eead67641fe7f68.html
Inside the file I can see the text "Page de test d\222imprimante"
On a Windows server 2012 R2 :
http://expirebox.com/download/60fa957cba97c82bbcd5c0e975825b52.html
I can't see any text. It's a printer page test too.
I need to see text because I'll print document with code inside. Code for a printer to identify page type. (for example a white page for the tray n° 1, yellow page for tray 2)
KenS : I understand your point. But why the same driver give different file.
I checked if it's really the same. The only difference I see is the OS, one x86, the other x64.
Thanks.
Regards.

What format is this string in? [closed]

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.

Resources