XORer and InnoBF

[bobby]

I've just released two tools that I've coded a long time ago.

XORer is command line for (de)XORing files. I've used it to decode some logs made by some trojan downloaders.

InnoBF is brute force password finder for InnoSetup packages. This one needs maintainer (anyone interested?) as it is based on rather old Innounp 0.17, thus not supporting newer versions of InnoSetup installers.
The speed is almost equal to the speed of MD5 brute forcing on the same PC.

Both tools are released on Malzilla's SourceForge page:
http://sourceforge.net/project/showfiles.php?group_id=203466

[sowhat-x]

Thanks,bobby! 

...for the record,I had recently seen,
that an Inno bruteforcer was released in chinese rce boards...
people that had tested it though complained that it didn't work...
here are the relevant threads:
http://www.unpack.cn/viewthread.php?tid=16594
http://www.unpack.cn/viewthread.php?tid=17808

[bobby]

Well, they probably did not studied InnoSetup good enough.

There are two kind of pass-protections in Inno:
- one just to let you to continue the installation (the Chinese BFer probably tries to crack this one)
- one that encrypt the files in archive

First one is trivial, and Innounp can deal with it without a problem - it will just ignore it.
The 2nd kind of protection does need the real password to decrypt the files.

Now on the structure of one InnoSetup installer with encrypted data:
- the MD5 of the pass + salt is stored in the header of the installer !!!

So, you do not need to try unpacking for every possible password combination - you only need to calculate the MD5 of the password, apply the salt (can be read from header) and see if that match the MD5 stored in the header. If do - you have the MD5 and the salt for decrypting the files (now take original Innounp with appropriate switch and supply the password to switch - done, the Innounp will do the rest of unpacking).


Now, as I didn't bother to write the Inno headers reader etc. (neither I would know how to do it), I have just modified Innounp code to check passwords for me and report back if it was successful (unpacking code is not used, just the header reading code).
As I've modified rather old Innounp (the latest one at the moment of writing the BFer), one would need to apply my hacks to newer version of Innounp if we want the headers of newer versions of InnoSetup installers to be recognized and processed.

Maybe I'll do it myself if I get some spare time for this, but this task at the very bottom of my ToDo list.

[sowhat-x]

...he-he,seems quite a few people enjoy the idea...
Note that this one is completely untested... 

InnoCry 1.2.4 Public
===============
InnoCry removes the password from <NON-ArchFour> password protected setups.
Supported InnoSetup Engines:
-InnoSetup 1.3.26
-InnoSetup 2.0.19
-InnoSetup 3.0.7
-Version 4.x
-Version 5.x up to 5.2.2

hxxp://thedutchjewel.defcon5.biz/tools/InnoCry%20v1.2.4.rar

[sowhat-x]

And a 'bugfix' release for InnoCry...
* Fixed ARCFOUR detection for the latest InnoSetup engine (ver. 5.2.2)

hxxp://thedutchjewel.defcon5.biz/tools/InnoCry%20v1.2.5.rar

[proletsearch]

Don't know if InnoBF works correct or not, but what bobby says is quite correct. MD5 + salt they are just at one location: first the 128 Bit MD5 hash and then just after it comes the 64 bit salt value. So, you will know that this is the case, if you compile your own InnoSetup example program and put some password to protect it, then compile the same program with a different password and compare both setups to each other. The result will be 24 different bytes (if we speak in bytes). So, if you copy those 24 bytes and replace the 24  bytes in another password protected Installation, that don't uses ArcFour encryption, you actually will set as password the one you have picked up in your example project and replace so the original one. Common sense   I have created such memory patches in the past. Innounp is a great tool. I like it very much, but I have decided to code InnoCry in case I want to use the original setup untouched with all code embedded by the author, because I have experienced, that Innounp can restore above 90% of the code but not everything, so in case of repacking a target program, you will need to figure out the rest by yourself.

Replacing the mentioned 24 bytes in a crypted InnoSetup will result in bypassing the password dialog, but at the end you will get a bunch of
empty folders extracted and file CRC errors. None of the program files will be extracted correctly! To beat such protection, only bruteforcing can help you - like the idea of InnoBF by bobby. I can't code in Delphi, but I will understand the code.

Another thing - > There are innosetup compiled projects with custom password scripts. There is no MD5 + salt there. That was the reason why I have updated InnoCry to the latest version 1.2.6. Someone maybe will post it here. I am not at home right now...However
such custom password scripts can be very simple, like a member of another forum, Kindly, already pointed, you can have scripts like

Code: [Select]

[Setup]
AppName=My Program
AppVerName=My Program v.1.2
DefaultDirName={pf}\My Program
Encryption=no

[Files]
Source: Files\*; DestDir: {app}

[Code]
function CheckPassword(Password: String): Boolean;
begin
if Password = 'aaa' then Result:= True;
end;

Code: [Select]

function CheckPassword(Password: String): Boolean;
begin
if Password = 'aaa' then Result:= True;
end;


and you can have more complex scripts like:

[Code]
var
 pass,pass2,pass3,mySerial:String;
 myChrArray: Array[0..9] of String;
 myIndex:Integer;
 myOffset:Integer;

//The serial is: 6574ccf410d93d4b7fb635ed5c594a8c
procedure GenerateSerial;
begin
  myChrArray[0]  := '0';
  myChrArray[1]  := '1';
myChrArray[2]  := '2';
myChrArray[3]  := '3';
myChrArray[4]  := '4';
myChrArray[5]  := '5';
myChrArray[6]  := '6';
myChrArray[7]  := '7';
myChrArray[8]  := '8';
myChrArray[9]  := '9';

myIndex := 9;
myOffset := 0;
mySerial := myChrArray[(myIndex/2*1)+myOffset]+myChrArray[(myIndex-5/2)+myOffset];
mySerial := myChrArray[(myIndex-8/2+3-0)+myOffset]+mySerial;

pass:= GetMD5OfString('
'+'`'+'
`

'+''+'``'+'');
pass2:= pass+mySerial;
pass3:=GetMD5OfString(pass2+pass);
end;
function CheckPassword(Password: String): Boolean;
begin
GenerateSerial;
  if Password = pass3 then Result:= True;
end;
By the first example, the password is in plain text and can be located with a software like WinHex (in memory)
By the second example, the password procedure is more complex, the password function is located at other place and to bruteforce it can be made only if you know how this password function is structured.

Best regards,
proletsearch[/code][/code]

[sowhat-x]

InnoCry 1.2.6

http://www.woodmann.com/collaborative/tools/index.php/InnoCry

Welcome on board,proletsearch 
And besides the app itself of course,thanks for such a detailed analysis;
excuse me for not having replied earlier,I've been working like nuts these latest days,poof...
Along with bobby,you've pretty much revealed most of the...'secrets of the trade'!

[bobby]

Hi proletsearch,
Nice to meet you

A question: are you sure Innounp will not unpack these setup files protected with custom scripts?
As far as I know, Innounp does not care about anything, only about crypted files. All other kind of protection is useless as Innounp will unpack the files anyway if the compression method and the beginning/end of the files is known from the headers.

So, only problem is with crypted files, and files packed with modified versions of InnoSetup (changed magic numbers, modified compression algorithms etc.)

One more kind of protection I saw is using unrar.exe to unpack the files one more time after extraction. RAR-ed files are password protected, and the password is inside InnoSetups script. Thats why is important to see the script.
So, if you se unrar.exe between extracted files, always check the script for password for unraring the files.

One more time, nice to meet you. Will be glad to hear more from you here.

btw. do you have any solution for unpacking NSIS archives? I'm not good with C++ good enough to understand NSIS sources, and also not willing to translate all to Delphi/Pascal.

[proletsearch]

Thanks sowhat-x! 

Hi bobby,
You are right - innounp will take care of custom scripts and if the "Password=" option is not specified in the project file, InnoSetup can not actually apply the option "Encryption=yes". So bruteforcing via MD5 hash + salt is the only thing required.
What I would suggest you, if you don't mind, is to take a look at the extracted InoSetup .tmp file in memory and read the MD5 + salt from there. This extracted *.tmp file, which I call 'engine' may be different for different InnoSetup versions but works in general the same way.Version 4.1.8 and below don't hash the password, but that's another story. As for the latest versions, the MD5 hash + salt are placed at a fixed address for every engine and you can read the data from memory. I guess you are familiar with OllyDBG. I will write you a pm these days and I will give you a detailed info about what I know.

As for the rar-ed files. I haven't seen such scripts. If you have such an example, please share it.

As for NSIS - I have never investigated it. I know pretty much about InstallShield in general and InnoSetup.

[sowhat-x]

...bobby,7-zip can extract statically the files from NSIS-based installers,but it's c++ though...
Have a look at 7z440.tar.bz2 at SourceForge if interested in sources,or later versions also...
http://sourceforge.net/project/showfiles.php?group_id=14481

I've mentioned v4.40 specifically,because this version could also extract the compiled 'script',
ie.someone could also get an idea what instructions take place during the install process:
NSIS users complained though that this behavior supposedly bypasses their...'protection',
(...huh?What protection?Haven't they ever heard of Filemon and similar?),
so he removed that ability...only files' unpacking in later versions,no script extraction.

[bobby]

Hi proletsearch, hi sowhat-x,

@proletsearch

I'm not a reverser, so I'm not familiar with OllyDBG. I've coded InnoBF for one particular purpose: a malware cleaning program of one of my friends was plagiarized, and plagiarized version was pass-protected (the plagiarist sent the pass over email at request). We needed this as evidence for complaining to the ISP and hosting company.
We didn't succeed as he was smart enough to use very long password containing letters, numbers and symbols.
So, InnoBF was just a try to get evidence for particular case, and I didn't bothered anymore about it.

As I'm mostly interested in malware, there is not a lot of pass-protected malware. Logically, it can't silent install if it needs password to unpack it self. There is rare cases like BSPlayer, where you need to know the pass to get the adware files without running the installer. BSPlayer installer uses silent decrypting, it does not ask the user anything. The script is the one who will enter the pass for decrypting.

@sowhat-x
Yup, I know about 7-zip, and also know about plugins for Total Commander, but...
I have a loooot of files that 7-zip can't unpack (probably not using bz2 for compression, or other magic numbers for the beginning of bz2 streams inside the archive).
InstallExplorer for Total Commander is a dead project (no development in last 2-3 years), and it crashes Total Commander at some 20% of NSIS archives, although it unpacks a lot of files that 7-zip does not (probably the archives compressed with zlib, I can't recall now for sure).

Thats why I asking if someone have some better NSIS unpacker.

[sowhat-x]

...Now that's what I call a man that certainly likes to keep a very low profile:
claiming he's not a reverser...while at the same he's coding unpackers!! 

Yes,you're right about it,older NSIS don't get correctly unpacked via InstallExplorer:
either it results in corrupted files or more usually,TotalCommander gets crashed...
I've been using 'cmdTotal' in order to avoid both these crashes,
and/or accidental execution from inside TC...it's happened to me once or twice... 
http://www.kakeeware.com/i_cmdtotal.php

But you've probably already been aware of this small tool...to be honest,
I haven't encountered older non-extractable NSIS installers,since quite a lot of time...
and it's development seems to be moving quite fast.

There's not much code around for these tasks unfortunately,
except maybe from your Ripper,which has saved my butt a couple of times,lol...
Few days ago,I saw a (...very primitive) extractor for zip/rar/cab etc.,
from the author of ARiD,called 'fe',it's included in his 'trash' archive:
http://patkov-site.narod.ru/eng/programs.html
At first,I was thinking of attempting to mod it at some moment,
say adding extra 'magic bytes' for more types,whatever...but as said,it's primitive...
ie.for the fun of it,I ran it over an Inno,and it detected there was a...
.uha archive embedded in it,he-he...it needs quite a bit of work to actually be of use...

By the way,speaking of unpackers and similar,these 'BInstall' and 'Exe-Package',
as named by Kaspersky and that you've worked with...do they give some kind of sig?
Wanted to ask you since the moment that you released the unpackers for them,
but with that many malware packers and exe modifiers that I've been checking here...
Both Google and Kaspersky's site returned any useful details about them...
Would it be much asking you to describe them a bit,
upload possibly a few of these exes/archives,whatever suits you?

[bobby]

http://rapidshare.com/files/83393446/samples.rar.html

Here I have uploaded the samples that I've used to write the unpackers.

Exe-package is simple archive with the following structure:
- size of the next file
- the file
- size of the next file
- the file
- etc

BInstall is a bit more "advanced":
- something that can be a magic number, but I already saw that more than one combo is used, probably differs between BInstall versions
- size of the name of the first file
- the name of the file
- size of the name of the 2nd file
- the name of the 2nd file
- etc
- the size of the first file
- the first file
- etc

I do not know where are these archive comes from, but I saw such samples in my collection (the ones I've uploaded).
As I do not like to keep redundant files (clean files) in my malware collection, I always tend to unpack every kind of archives.

So sowhat-x, you see I'm not a reverser. at least not one who knows how to use OllyDBG.
"Reversing tools" used here were: pen, paper, calculator and Hex editor (XVI32) and a bit of knowledge about different ways of writing long values like WORD and DWORD (knowledge from the days of having good old C64, where 16bit values were written in reverse order, low byte first and high byte after that).
Yup, good old C64... that was the last time I've take a look and understood some ASM code.
I have had difficulties to understand ASM for 16bit and 32bit CPUs, so I even have had problems to pass some test at my studies.
No ASM here. Bad ASM, bad ASM..

Hehe, you would not believe which languages I've studied (long time a go, in a communist land):
- GW Basic
- Turbo Pascal 5.5
- Fortran 77

At my 2nd studies in Vienna I've learned Java and C#, but Pascal remained my best friend for ever.

[bobby]

@proletsearch

I didn't forgot the rar-ed files you asked for. I'll upload some as soon as I get some of them. I already have unpacked all the samples I got earlier, and I didn't keep the packed samples.

[sowhat-x]

Once again,a deep thanks bobby,I really appreciate it...
you've already offered too much to the community/end-users,
makes me feel obligated somehow...this was more than kind of you! 

Hehe,you would not believe which languages I've studied (long time a go,in a communist land)

He,I've always thought that,even if there were obviously lots of daily social life,
and political issues to be discussed/criticized etc.,
that education was one of the 'really strong' points in ex-Eastern block countries...
at least when compared to smaller European countries like Greece here.

I've had lots of relatives who migrated in eastern countries,
way back after the civil war ended,as they where hunted for their ideas/actions...
my grandfathers and such,obviously most of them not in life anymore...
While most of them were simple and un-educated farmers back here,
they all returned back with high degrees of knowledge and diplomas...
But then again,all of this happened,
way before the cold war supposedly ended and the 'fall' took place:
they got allowed to return back in the mid 70s,almost 30 years after the civil war...

At my 2nd studies in Vienna I've learned Java and C#,but Pascal remained my best friend for ever.

Mainly perl here,a basic grasp of C,and that's all...I really need to advance though.
Asm is simply...he-he,'bad asm,bad asm':
a pain in the...head...needs way too much patience,damn it...
but I guess that's what makes it so powerful...