I am trying to duplicate the solution shown here but no luck.
Basically Ivan Kuckir managed to decompress a PDF1.6 xref stream by first decrypting it and then decompressing. This stream like mine belongs to an encrypted PDF file.
One issue here however, is that the PDF 1.6 spec states on p.83 that "The cross-reference stream must NOT be encrypted, nor may any strings appearing in the cross-reference stream dictionary. It must not have a Filter entry that specifies a Crypt filter (see 3.3.9, “Crypt Filter”)." What I understand from this is that, like cross ref tables before them, xref streams must not be encrypted.
When I try to inflate the stream the zlib dll crashes. It also crashes when I decrypt first and then inflate... Has anyone managed to duplicate Ivan Kuckir's solution? Thanks.
P.S. I tried to ask the question in the above thread but for some reason it was deleted by the admin...
This is the link to the object: https://drive.google.com/file/d/1DwOf3zarg9p_B8DNZ2gZdaBr43NKDWR3/view?usp=sharing
I replaced the stream charecters with a hex string for unrisky pasting
So, as you read in the spec, xref streams are not encrypted. So you don't need to decrypt any strings in the xref stream dictionary nor the stream itself. What you need to take into account are the /Filter and /DecodeParams entries when decoding the stream.
Most of the time an xref stream uses a /Flate decode filter together with parameters that allow for better compression due to the way an xref stream is structured. So have a look at sections 7.4.4.1 and 7.4.4.4 of the PDF specification.
Related
I have an API endpoint for uploading large files, streaming then directly to DB. I use ASP.NET Core's IFormFeature to do this, calling IFormFile.OpenReadStream() to get a Stream that I pass to SqlClient for streaming.
I want to enforce a a maximum file size to avoid abuse. I know IFormFile has a Length property, but I assume that is based on Content-Length or similar and can not be trusted (please correct me if I'm wrong, but AFAIK the only way to be 100% sure about the file size is to actually read the data; the client could send an incorrect Content-Length.)
I must therefore ensure that when the stream is read, it does not read more than what is specified in IFormFile.Length (ideally it should throw if it encounters additional bytes). I have not found a way to do this. Is this possible, or is there perhaps a better way to ensure the server doesn't read enormous amounts of data from clients sending incorrect Content-Length headers?
(It should go without saying that this must not entail reading the entire file into memory.)
I am trying to get the contents stream out of a PDFs internal structure using xCode.
I have managed to get to the array of contents using:
CGPDFDictionaryGetArray(str, "Contents", &val)
Then counting the amount of objects within the array, its returning 8 which is far less than shown in Acrobat Pro.
The objects with in the array seem to be of type kCGPDFObjectTypeStream, not sure what I can do with this.
Any help would be much appreciated, many
thanks,
Jacob
The page /Contents entry can be a stream object or an array of stream objects. When you have an array of stream objects you get the complete page content by merging these streams in a single one (append one stream after another).
I'm working in Xcode 4.3.2 + building for an app in iOS 5.
I've decided to use SBJson to parse streams of data from our server. I've verified that I'm receiving a valid JSON response from the server. My question concerns the design behind the classes SBJsonStreamParser and the SBJsonParser.
It appears that in SBJsonParser the method "objectWithData" takes the data received from the JSON response and uses the SBJsonStreamParserAccumulator to append the stream of data into a single JSON document. Once the data stream is gathered into one object, it is then parsed by the "parse" method in SBJsonStreamParser.
I've run into several issues when requesting larger JSON documents. The size of the responses seem to be reasonable (specially 9.4 KB response). It appears that the SBJsonStreamParser breaks when getting a data stream greater than a certain size. The parser succeeds when the response is small (~3KB), but fails when the response is larger (~10KB).
I used NSLog to verify that in both cases, pulling a small & large stream, the methods are successfully receiving the full json document - because it looks like [{"id": .... 123}]. I'm convinced that the issue is that the data stream is too long.
I'm wondering if I'm using SBJson incorrectly or is this simply a limitation of the parser? Is there anything that I can configure that allows SBJsonStreamParser to not throw an error for larger (but reasonable) data streams & continue to parse the full response?
Thanks in advance!
Actually you have the workings of objectWithData: backwards. SBJsonStreamParserAccumulator is used to accumulate the parsed output, not the unparsed data stream.
I consuming Web-Services that streams a pdf file to my iOS device. I used SOAP message to interact with web-services and using NSXMLParser:foundCharacters() after the stream is complete and I want to get the content of pdf file from my streamed xml file which was created in first step. The data I get is encoded in base64 and I have the methods to decode the content back.For small file the easiest approach is reading/collect all content with NSXMLParser:foundCharacters from first streamed file and call the decoding base64 method when I get whole data from parse:didEndElement
(the above approach works fine I tested for this case and I made the right pdf file out of it).
Now my question is what is the best approach(optimizing memory/speed) to read/decode/write to make the final pdf from a big streamed files.
Is there any code available or any thought to accomplish this in objective-C
I am curious to know how webservers handle file uploads.
Is the entire file sent as a single chunk? Or is it streamed into the webserver - which puts it together and saves it in a temp folder for PHP etc. to use?
It's just a matter of following the encoding rules so that one can easily decode (parse) it. Read on the specification about multipart-form/data encoding (the one which is required in HTML based file uploads using input type="file").
Generally the parsing is done by the server side application itself. The webserver only takes care about streaming the bytes from the one to the other side.
It's streamed to answer that question, but see this RFC 1867 for more information.
RFC 1867 describes the mechanism.