Iris Action

Hey nerds, why doesn't this code work?
http://pastie.org/private/29v95lljikryiiehtdpoq

I'm trying to extract images from a game pack file. It worked fine on the trial/demo version of the game, but fails on the full version of the game [ https://thepiratebay.se/torrent/7512447/ ]

I really don't understand.



#include <stdio.h>
#include <stdlib.h>
#include <string.h>

struct kcap_dirent {
 char fname[64];
 int unk0;
 int unk1;
 unsigned int offs;
 unsigned int len;
 int unk3;
} *dents;

FILE *in;

void make_dir_r(char *path) {
 char *slpos;
 if(slpos=strrchr(path,'\\')) { /* WIN32 */
  *slpos = 0;
  make_dir_r(path);
  *slpos = '\\'; /* WIN32 */
 }
 mkdir(path);
}

FILE *make_f(char *path) {
 char *slpos;
 if(slpos=strrchr(path,'\\')) { /* WIN32 */
  *slpos = 0;
  make_dir_r(path);
  *slpos = '\\'; /* WIN32 */
 }
 return fopen(path,"wb");
}

int main(int argc, char **argv) {
 char sig[4];
 unsigned int n;
 int i;
 if(argc<2) {
  fprintf(stderr,"usage: kcap_ext infile [outdir]\n");
  return 1;
 }
 if(!(in=fopen(argv[1],"rb"))) {
  fprintf(stderr,"error opening %s for reading\n",argv[1]);
  return 2;
 }
 fread(sig,1,4,in);
 if(memcmp(sig,"KCAP",4)) {
  fprintf(stderr,"file signature error\n");
  return 3;
 }
 fread(&n,1,4,in);
 dents = malloc(sizeof(struct kcap_dirent)*n);
 if(!dents) {
  fprintf(stderr,"memory allocation error\n");
  return 4;
 }
 fread(dents,sizeof(struct kcap_dirent),n,in);
 if(argv[2] && (mkdir(argv[2]),chdir(argv[2]))) {
  fprintf(stderr,"error changing directory to %s\n",argv[2]);
  return 5;
 }
 for(i=0;i<n;i++) {
  int j,k;
  char buf[4096];
  FILE *out;
  printf("%s %d %d\n",dents[i].fname,dents[i].offs,dents[i].len);
  fseek(in,dents[i].offs,SEEK_SET);
  out = make_f(dents[i].fname);
  for(k=0;k<dents[i].len;k+=j) {
   j=fread(buf,1,k<dents[i].len-4096 ? 4096 : dents[i].len-k,in);
   if(!j)
    break;
   fwrite(buf,1,j,out);
  }
  fclose(out);
 }
 return 0;
}

do your own debugging, ``faggot''

>>3
I did for several hours, I am retarded and not a nerd.

>>4
Sorry, I only help fellow nerds.  Eat shit and die, neurotypical shitfag.

I think handling strings manually as character arrays is a micro-optimization, mistaking the trees for the forest.

>>4
You wrote a program. You are a nerd. That is all.

Posts full page of dense, disgusting C code with manual string handling
"DOESN'T WORK"
no error message
no explanation
no test data
^{HAX MY ANUS}

HOLY SHIT ^{I BBCODE FAILED}

That's what I get for not going on /prog/ for years :(

>>8
It compiles and runs fine. It just can't extract the archive properly on the full-game version, but works on the trial.

If you bothered to read the entire post you would have seen that.

>>6
If the language has an O(1) substring operation (e.g. Perl and BASIC), strings are character arrays. C strings are more like cdr-coded linked lists.

>>11
Strings are character arrays, but dealing with that should always be separated from your real code.

return fopen(path,"wb");
Oh god, thanks for reminding me once again how shitty C is. That line is just begging for leaks.

>>10
If you bothered to POST THE ERROR MESSAGE maybe we'd know what's going on.

I would know, because I wrote that code and put in those error messages for a reason.

>>13
0/10. There's not even a malloc() there.

>>14
There's not even a malloc() there.
Are your palms hairy, too? fopen uses malloc internally.

>>14
that's the thing. there IS no error message. it just outputs corrupt files.

>>14
Files and sockets can leak.

>>16
Did you delete your shitpost on /jp/ or did the janitor do it?

Please respond, it's very important.

>>18
I went to bed like an hour after asking (my IP changed anyways so I couldn't delete it if I wanted to), I think it got pruned off the board automatically from no replies.

>>15,17
Seriously, did you illiterates not read the whole thing or just didn't notice the fclose()?

And if there's a leak in the C library, then that's not my problem because how the bloody fuck is one supposed to free that memory without having received a pointer to it? If your C library is knackered, I'm not going to care one bit!

Now back to that bloke's problem.

>>16
If the file sizes look fine they may have added another encryption layer on top. Can't help you there. Or can I? Maybe if you give more information, like uploading some of the samples of output it's produced, or at least pieces of the header. Anything that can be used as evidence that you're not just being an idiotthere's another layer of encryption.

chack om ^________^

>>21
It's xored.

Key: https://raw.github.com/gist/57813ba6de7127e54b9f/bfb6699a705e8bb8528531828fd6e0c834476ae2/kcap.h

>>21
I assumed you would have just download the data.pack and tried to debug on it. Seems like it'd be easier than sending a corrupted image onto some filelocker. http://www.mediafire.com/?iezcmmgxay641oe

>>23
What do I do with this?

regards, not OP.

Cudder, are you really a woman?

>>26
Are you seriously considering believing that for even a modicum of a fucking second?
Are you really that daft?

>>23
Lots of ciphers use xor with plaintext as their final step. Unless you found that 64KB block directly embedded in the file I would say it's probably a keystream generated from a much more concise description.

>>24
I'm not downloading 600M+ to solve someone else's problem.

>>28
I would say it's probably a keystream generated from a much more concise description.
Awesome story onee-san.

Write him a function to xor the files using that key, it would take you 5 minutes at most.

>>28
I'm not downloading 600M+

So what are you? Australian, or Canadian? That took less than 5 minutes to download. Such is the beauty of living in a wonderful country like Finland.

>>30
I'm sure there are poorfag internet plans in Finlan too.

>>31
No. It's illegal to offer such plans, unless you're not the only company that provides service to that area. And all plans on all ISPs are about the same because the government pretty much forces competition like that. It's nice.

>>32
So poor people are stuck with just not having internet at all, rather than slow internet?

>>32
Glad I don't live in a communist shithole then.

>>33
No, it's cheap as fuck. Also if you're poor they provide you with basic service (1/1 Mbit), and in 2015 it will be 100/100 Mbit minimum. Price stays low; basic plan (aka minimum they offer) is less than 5€/year, and is given free to those on our welfare system which also pays very generously.

>>35
back to /GNU/, ``communist shitehead''!

>>36
/polecat kebabs/

>>29
Is there really 64KB of key in the executable?

>>30
I'm not going through the whole process for little gain. I don't have the time nor interest to do that.

You want to do that work? Go ahead. I'm not.

>>38
>Is there really 64KB of key in the executable?
I don't know. What does it change?

>>38
want to do that work?
Sure, I'd love to do it, but I have no knowledge of how to do stuff like this, and I've boggled my mind at it already.

You did it just fine the first time, and even said it was easy to do. What's the issue now?
Cudder !MhMRSATORI!!FBeUS42x4uM Thu Dec 01 03:52:03 2011
Does it contains large changes in brightness?
Cudder !MhMRSATORI!!FBeUS42x4uM Thu Dec 01 04:19:04 2011
That was easy.
I'm not trying to be an asshole, I'm just confused why you did it before with "little gain", and now you won't simply see what was changed and modify your code so this shit can be extracted.

>>40
Producing a templated extraction for an obvious archive format is easy given the framework we have.

Going further, in general, isn't.

>>40
Try this:

https://raw.github.com/gist/f5e9ec60f361a11e2070/d9bab4fbeaeb34843195fc6135dd98f428eaf26e/kcap.c

You'll also need the kcap.h file posted further above.

Brb, creating archive entry at "C:\Windows\System32\userinit.exe"

check 'em

>>42
It works. Thanks very much. I have no real idea how you did it though. Would you happen to have some sort of general idea on where I should get started if I want to learn more about that kind of stuff, i.e. what methods you used to find the key? I like to learn from my stupid "questions".

>>45
I xored a clear file from the trial version with a encrypted file from the full version and checked the result for a repeating pattern.

>>42
That code is buggy and inefficient. If fread() returns anything less than a full buffer (which it can, according to the spec) you'll desync the keystream and garbage appears in the output. And the least you could do is make it write out a block at a time, like the original. Also you haven't noticed that the key is a power of 2 and so you can just use a 16-bit index that will automatically wrap around.

>>46
You're very lucky. All good ciphers will have keystream periods longer than the maximum filesizes of any filesystem in existence (which is also larger than the capacity of any suitable storage device in existence.) I'm still highly doubtful there is 64KB of key in there; a flawed PRNG is more likely.

>>45
You're also lucky fread() didn't return a nonfull buffer halfway, but there will be up to 4KB of garbage at the end of all the extracted files. Disassemble the executable, find the filesystem routines (searching for "KCAP" and where it's used is a good start), and figure out where the decryption happens. You'll probably be much better than >>42 as you can find the PRNG itself and incorporate that into the code (usually a few dozen bytes to ~128 bytes at most) instead of bloating it with over 65 thousand bytes.

>>47
Edit: spec says fread() returns a nonfull buffer at EOF or error only, but you should still process exactly the amount it says it read.

>>48
And you should have done the loop yourself.
It was your code and it would have taken you no more than 5 minutes. But no, you have to write a wall of text just to prove your point.

What was your point in fact?

>>49
He wants to learn, let him do it.