After a long long time without anything to reverse, and no ideas to write another reme, i am back. What's today's topic ? Crudd's new reme, ForwardMe. The goal is to reconstruct an exe with only the raw sections. So the hardest thing we will need to do is to "create" a working PE. You can manage such a thing in three big steps :
1/Identify the sections
2/Put them together in the right order
3/Make the PE work
STEP ONE : Identifying the sections
We have five sections : 1_Here.hex, 2_Are.hex, 3_The.hex, 4_Five.hex, 5_Sections.hex. I'll call them 1,2,3,4,5 of course :).
Let's start with the last (we are reversers, :)).
5_Sections.hex : So .... We have here the biggest of the five. Mmmm, let's take a look at it in HIEW. Switch into asm view and scroll down some lines. YES ! It's the code of the program. Rename your file 5.hex into code.hex.
4_Five.hex : In this one we can see words in unicode format : Crudd's Forward Me, OK, Cancel. 2 seconds later, you recognize the rsrc section. 4.hex is now rsrc.hex :)
3_The.hex : This one is small : 164 bytes. A quick look into it reveals words in ASCII : Fruintcake. is a fag. Haha..Good Job!.Congrats, everything seems to be working fine. This section can only be the .data one. 3.hex changes into data.hex
2_Are.hex : This one is easily identified : Scroll some lines down and you see API names, and dll names too. Idata section of course.
1_Here.hex : Wow ! This one is the hardest. There is nothing that allow you to understand what it is. But if you tae another little pe file, you can see that there are generally only four sections. Eh-Eh, what's that intruder here ? Some small files have a fifth section called .reloc, created by windows (i think). So if that intruder is the reloc section, we don't need to care about it. If the program will not work when we'll have done everything, maybe should we worry about this one, but, for now, i've "forgot" to put it, just to see.
It's fine, we have the sections names.
Now we can jump to the next step
STEP TWO : Putting them together in the right order
So, we now know what's in the sections.
But what about their location in the memory ??? I assume that the .code
one is at 401000, because it's a "standard", but where are the others ??.
The problem is that the .data and .rsrc do not contain any hint on where
they have to be located. So i started with the 2 others : code and idata.
Assuming that .code had to be at 401000, i only had to find where idata
must be. Open it :). The first DWORD is 000040A4. As the DWORD's in the
import table are RVA's, the section must be located at 404000 :). The program's
shape looks like that now :
401000 : Code
402000 : ?
403000 : ?
404000 : Import
data
405000 : ?
The next section i'll try to locate is the data one, as we don't care about the rsrc one (it doesn't need to be at a fixed place, you just need to put the right memory address in the Ressource Table DWORD in the PE).So, we need to find the place where the data is located. But how can we do that ? There are lots of way to find it. We could find a call to an api that needs strings, and then see to where the push is made. We could simply try all the addresses. But, there's another way . We know that there are only three places where it can be, and we know that this place is refered a lot of times in the code (pushes, moves, ...). So all we need to do is search in the code file, to see wich is likely to be the one. Launch your hexeditor and search for 2040,3040,5040 (we search DWORDS).
2040 = 0
3040 = 24
5040 = 0
So ..., 403000 seems to be today's winner :). As we really don't care about .rsrc, we will put it at 402000.
401000 : Code
402000 : Ressource
403000 : Data
404000 : Import
data
Now take another pe file and paste all our sections together, padding with zeros to have "clear" addresses. On my comp it gives :
@400 : .code
@A00 : .rsrc
@D00 : .data
@E00 : .idata
All parts are together. We can jump
to step 3
STEP THREE : Making the PE "work"
We've done the hard part, and now we
can do the easy things. Run a PE editor (i use PEeditor 1.5), and start
filling :
Name | Virtual Size | Virtual Offset | Raw Size | Raw Offset | Characteristics |
.code | 800 | 1000 | 600 | 400 | E0000020 |
.rsrc | 500 | 2000 | 300 | A00 | 40000040 |
.data | 500 | 3000 | 100 | D00 | C00000C0 |
.idata | 800 | 4000 | 400 | E00 | C00000C0 |
Don't forget to change the Directory entries (Import Table = 4000, Ressource = 2000).
But now we fall on another problem
: where is the entry point ????. For now put it at 1000. Then run IDA on
the target and analyse that prog a little. Here's how i found the entry
point :
A proggie always need to run a couple
of api at the begginning : GetModuleHandleA, GetCommandLineA. As this prog
seems to be from another language than assembly, then it must follow this.
So i searched for GetCommandlineA in the dissassembly, and then i found
an reference at 40141D, and there was only one cross-reference in IDA,
to 40121D. I scrolled some lines up and found a "strange" instruction :
mov
eax, large fs:0
There was no cross-reference to that
point, and there was a jump to another place just before it. There was
another hint because there was a bit later a call to __GetMainArgs. So
i decided it was the entry-point.
But on that point, i fall on a problem
: the dialogbox weren't displayed. Hopefully i met Santmat, that told me
that ressource HAVE TO BE at a specific place. Then i tried to change the
Virtual Offset of the .rsrc section to 5000, and the ressource table too.
I launched it. WOOOOHOOOOOO ! That works this time :). So here's the final
PE
Name | Virtual Size | Virtual Offset | Raw Size | Raw Offset | Characteristics |
.code | 800 | 1000 | 600 | 400 | E0000020 |
.rsrc | 500 | 5000 | 300 | A00 | 40000040 |
.data | 500 | 3000 | 100 | D00 | C00000C0 |
.idata | 800 | 4000 | 400 | E00 | C00000C0 |
Thanks : SantMat ( wow, great great
thanks to you man), Crudd, MagicRaph,Edy,Tam,C_DKnight,ep-180,promethee,
V-Rom,analyst,amante, to everyone from
[ID], #c4n, #crack.fr