- Forum
- General C++ Programming
- RNC Decompressor issue dumping file from
RNC Decompressor issue dumping file from input file
Hey, I have successfully compiled this code here-> https://lubiki.keeperklan.com/dk1_docs/libadikted/dernc_8c-source.html
But, when I run my executable console app it does not extract the entire input file to the output file when executing the -o param any reasons why it is not from this code?
It never dumps a output file even when it says it is doing it?
Here is my console app screenshot-> https://ibb.co/7jC8pwj
But, when I run my executable console app it does not extract the entire input file to the output file when executing the -o param any reasons why it is not from this code?
It never dumps a output file even when it says it is doing it?
Here is my console app screenshot-> https://ibb.co/7jC8pwj
> printf(" %s -o <infile> <outfile>\n", fname);
-o apparently doesn't mean output
Indeed, the text of the program also suggests with the use of the word "to" that the -o parameter is the input file.
-o apparently doesn't mean output
Indeed, the text of the program also suggests with the use of the word "to" that the -o parameter is the input file.
Then if -o is the parameter for the input file
Then, what is the parameter for the output file?
There, has to be a reason in code why it is not dumping the output file?
Then, what is the parameter for the output file?
There, has to be a reason in code why it is not dumping the output file?
some compression tools just rename the input file for the output file.
eg if you bzip2 a file, it just makes filename.bz2 and you don't specify the output name at all. It may be doing this? Or not, it seems to follow the pattern below.
All I can tell you is that code detects which parameter has the -o in it (this becomes 'mode') and then passes everything else to the decompress (the -o parameter is completely ignored, as far as I saw!). It appears that you have 3 args, one of them has a -o in it, and the other two are input and output, in that order, but the -o could be anywhere in the mix, including a screwy infile, -o, outfile ordering.
My 2 cents is this is the most messed up noobily arg parsing I have seen since college.
eg if you bzip2 a file, it just makes filename.bz2 and you don't specify the output name at all. It may be doing this? Or not, it seems to follow the pattern below.
All I can tell you is that code detects which parameter has the -o in it (this becomes 'mode') and then passes everything else to the decompress (the -o parameter is completely ignored, as far as I saw!). It appears that you have 3 args, one of them has a -o in it, and the other two are input and output, in that order, but the -o could be anywhere in the mix, including a screwy infile, -o, outfile ordering.
My 2 cents is this is the most messed up noobily arg parsing I have seen since college.
Last edited on
I agree jonnin it is very messy arg parsing lol
I see so it just takes the input file makes a file with the same name and .ext.
Which expains a lot but if that is so then the date of the input file never changes.
So it either is dumping the file somewhere else besides where the rnc decompressor.exe is located or not doing renaming or dumping the file at all?
Very, weird program indeed.
Is there an alternative way to decompressing a file archive with a start offset file signature of RNC? Without using this messy code?
I see so it just takes the input file makes a file with the same name and .ext.
Which expains a lot but if that is so then the date of the input file never changes.
So it either is dumping the file somewhere else besides where the rnc decompressor.exe is located or not doing renaming or dumping the file at all?
Very, weird program indeed.
Is there an alternative way to decompressing a file archive with a start offset file signature of RNC? Without using this messy code?
There's at least half a dozen return statements in main_unpack which go unreported, but which result in no files being produced.
You've got the code, start littering it with extra printf statements to get an idea of what it's up to.
Or "go pro" and just use the debugger with some breakpoints and step through it.
You've got the code, start littering it with extra printf statements to get an idea of what it's up to.
Or "go pro" and just use the debugger with some breakpoints and step through it.
That's an start I can do in the mean time if one person was to make a small decompressor based on this code where would one start without needing all the code specified?
The code you have is the best place to start.
Since the file is part of a package called "The libAdikted dynamic library contains all you need to load, edit and write Dungeon Keeper 1 maps", my guess is that some enterprising soul did a bit of reverse engineering and what you see in the code is the result of that.
I doubt there is a clean spec you could read, say like ZIP.
https://en.wikipedia.org/wiki/ZIP_(file_format)
It might be ZIP in disguise, I'm not into compression code to tell one from another.
Since the file is part of a package called "The libAdikted dynamic library contains all you need to load, edit and write Dungeon Keeper 1 maps", my guess is that some enterprising soul did a bit of reverse engineering and what you see in the code is the result of that.
I doubt there is a clean spec you could read, say like ZIP.
https://en.wikipedia.org/wiki/ZIP_(file_format)
It might be ZIP in disguise, I'm not into compression code to tell one from another.
Yeah, your right on that, also after doing some error checking and what not the program passes no issues at all it is doing what it is suppose to be doing but no output file or rename file after decompressing the file is generated so this code seems to be an unfinished reverse engineering process which is bad for me trying to decompress a file with RNC-001 signature.
Thanks for the help guys, if anyone has any suggestions or tips or leads on this concept I am all open to read and check it out.
Thanks for the help guys, if anyone has any suggestions or tips or leads on this concept I am all open to read and check it out.
the tool has pretty good docs for what it is, and a set of example programs as well.
Have you tried to compile and run the examples? Or opened them up to study how they are used?
The code is a bit rough, but the work put into it suggests it probably functions.
the only rnc i found was for audio, and it looks ancient to boot. Dungeonkeeper sounds ancient too.
Have you tried to compile and run the examples? Or opened them up to study how they are used?
The code is a bit rough, but the work put into it suggests it probably functions.
the only rnc i found was for audio, and it looks ancient to boot. Dungeonkeeper sounds ancient too.
Last edited on
Well, I tested the other examples they compile but the one I am interested in was the "dernc.c" example for decompression of a file archive with a RNC-001 signature.
So, for the most part the "dernc.c" example works but is not complete it never dumps or even rename's the file archive you are using with the tool to decompress.
How, the tool works is it detects the RNC signature and if it is valid it will begin to unpack the archive file and if success it begins to decompress chunks of data and if success it starts to extract the decompressed archive data to an output file once succcess it will dump the file in the directory where the generated exe resides but it never makes it to that final step so determining this from error checking and really studying the "dernc.c" code I made my conception based on my finding's. So, not sure if all the examples are complete or not?
So, for the most part the "dernc.c" example works but is not complete it never dumps or even rename's the file archive you are using with the tool to decompress.
How, the tool works is it detects the RNC signature and if it is valid it will begin to unpack the archive file and if success it begins to decompress chunks of data and if success it starts to extract the decompressed archive data to an output file once succcess it will dump the file in the directory where the generated exe resides but it never makes it to that final step so determining this from error checking and really studying the "dernc.c" code I made my conception based on my finding's. So, not sure if all the examples are complete or not?
Not sure. you can also look at the parent:
http://aluigi.altervista.org/quickbms.htm
supposedly the code you have came from there...
http://aluigi.altervista.org/quickbms.htm
supposedly the code you have came from there...
Topic archived. No new replies allowed.