[ art / civ / cult / cyb / diy / drg / feels / layer / lit / λ / q / r / sci / sec / tech / w / zzz ] archive provided by lainchan.jp

lainchan archive - /λ/ - 17463

File: 1468687055913.png (420.13 KB, 300x207, Screen-Shot-2014-05-20-at-4.51.48-PM-640x440.png)


Lainons, how do I get into Reverse Engineering? Best book suggestion?
What kind of CS background do I need?
I know some assembly and C. The drive behind this all is that I want to get more into Assembly, figuring out what does what is fun.


Also interested in this subject.

A month ago I tried to reverse engineer the network protocol of an Android game. I downloaded some proxy/VPN apps that would capture all network traffic of the game.

Sadly, only one of the tools could actually perform a MITM attack to decrypt the game communications, and it couldn't export the data in a format that wireshark could read so I wasn't able to do any serious analysis on it.

I almost started a packet capture tool project but decided it was too much effort.


There are a few books like

>Secrets of Reverse Engineering

Published by Wiley. It deals with windows binaries because, as they say, linux stuff has the source code for all to see
>Practical Malware analysis
Published by No Starch. Looks good
>Hacking, the art of exploitation
I suggest this one because it has a lot of relevant information
>Reverse Engineering for beginners
Probably the best book out there, free and almost encyclopedic
>Practical Packet Analysis
Network-oriented. It's meaningful because of the above post

At the end of the day, the best way to go about it is to
>Write something in C
>Assemble it/compile it
>look at the resulting instructions, try to figure out what parts of your code are being translated to what
>change the program a bit
And so on...

You also need to know how the stack AND the heap (as done by malloc()) operate.
Oh and get comfortable with gdb

That's about all I can tell you... Oh yeah:


File: 1468794647380.png (168.95 KB, 200x184, 1468280470726.png)

I've used the Lena tutorials, but it was many years ago. If it's just for learning assembly: grab your CPU's instruction reference and your favourite debugger or disassembler, go on crackmes.de, download some easy crackmes, play around with them and try not to get too frustrated.


I'm pretty sure you could have just put wireshark on your router.


>re thread
What are you working on?
I thought I'd test my skills by cracking a simple program, so I chose winrar because it seemed easy.

Even though I was done with a crack within 2 hours, I still can't seem to get a keygen for it. almost wasted a week and honestly feel stupid now..

How does scene do it the same day a program gets released?


They use fancy disassemblers/partial decompilers. Plus many of them are very experienced.


Most businesses don't write their own protection but buy finished solutions from companies specialized in it. If you manage to crack a software protected like this, other software using the same solution will be much easier to crack. You can even automate a great deal of it, sometimes even the whole process.


The irony.
Because the company that provides the protection service probably automates it. Charges a shitload to the client for just running a script on it and at the end of the day the protection scheme is completely useless


I'm starting on the crackmes.de right now. thanks, this is great. Any reading up I can do that you would recommend?


If it's just for assembly and having fun, I don't think you need any special material. Maybe some write-ups on how others solve crackmes using the tools that you use.


Anyone here uses radare2 for RE tasks? I'm curious if lainchan knows (and uses) that tool.


Can someone please offer help. I really want to get into cracking. I did one really easy crackmes.de but all it was was the password in a dissassembler. Even the very easy ones with keygens kill me. I don't know what I'm doing.


Same guy here, I found this http://web.textfiles.com/software/howtocrk.txt in case anyone else wanted to start.


It's a bit dated and you will need flash to follow it, but Lena's tutorial will teach you the basics:


rar is password protected


Sorry about that, "tuts4you" is the password.


I'd recommend IDA + Hexrays as debugger/decompiler as well for C/C++ based binaries. Decompiling is quite nice since you qave a quick wide view of what a subroutine is doing more or less. Of course it isn't really decompiling but it just translates the assembly to pseudo C language.


Reverse Engineering for Beginners by Dennis Yurichev


What you need is practice bro. Do some crackmes.


File: 1471629340272.png (36.94 KB, 200x158, 400735f39d3234411e39d7c358a270bf.jpg)

I'm interested in reverse engineering myself, but I am more interested in doing it for anti-virus purposes and to study program flow.

I'm thinking of making a program that decompiles another program. Anyone else have experience or interest in this?


That book was subpar.

I already had suitable knowledge of the topic, so take this advice with a grain of salt, but I wouldn't recommend it to anyone.


We should pic a crack me and do it as a collab together. Could be a fun project over IRC.


What's the usefulness of reverse engineering?


Does anyone have any tips for unlocking the Intel ME? Is there a way to read the flash too so I could maybe try and reverse it?


Ctfs are good for this also


Add the link, you schmock.


flashes are signed, so there's not much you can do unless you find a vulnerability in the RTOS or get the private key somehow.


File: 1482095362101.png (322.36 KB, 200x143, stupid.png)

Can somebody help me out with disassembling a dll? I'm still fairly new to this stuff, I've managed to pull the raw data off Arkdasm, but that's probably the most user unfriendly program I've used in a decade and searching in it seems to be impossible. I've tried x64dbg next and it's quite swell for the most part, but it only loads the dll as a database file, afterwards opens DLLLoader64_F466.exe/ntdll.dll instead and I have no idea how to access the original file.

Database file: C:\stuff\x64dbg\release\x64\db\rdx64.dll.dd64
Process Started: 000000013FF70000 C:\DLLLoader64_F466.exe
DLL Loaded: 0000000077350000 C:\Windows\System32\ntdll.dll

from the logs. Neither the website, nor manual nor Google seem to provide more insight here. Any ideas on how do I open rdx64.dll?


figure it our based on this post


Use Dependency Walker, it will show internal calls and structure of the library


File: 1482176599068.png (67.34 KB, 200x200, 1461273689345.jpg)

Does anyone have some suggestion on how to find potential bugs in a program? (also called bug hunting).
You know, some book that explains the methodologies, tools (fuzzers and so on).
Thanks in advance



I'd be curious too, I just use fuzzers and windbg but I'm not exactly proficient.


Type checking of input/response is a most common bug. If any program asks for some information, it always worth checking what will happen if you feed it: ascii, unicode chars, digits, literals, long string, very long strings and very long numbers and so forth. Same with network response - bugs occur when there is no server-side check implemented.


>really want to get into reverse engineering
>download tools / books / misc.
>start working on it hardcore for a day
>never do it again
>it's now 3 months later and have done nothing
Anyone else have this problem? I do it with everything


You'll get over it eventually and go through a burst of activity again.


Is it possible to get a job with reverse engineering skills, so to say?


20935 basically laid it down.
Long strings and exotic characters have led to many successful independent finds.
Getting the balance between static and dynamic analysis can't be stressed enough.
As for books, you need to be more specific as to what area.
One would assume binary exploitation and potentially hw hacking based on OP, or maybe attacking web apps is what you prefer?


Pirated IDA 6.95 when? This is taking too long...


I use a mix of radare2, IDA and Olly.

Yes, but then you would have to work for an anti-virus company and they are all dying.


You want someone to crack a cracking tool for you to crack software?
How about you crack it yourself?


I would if I had the binary...


I started to learn RE last month. What i do is:

>Write some code in C.

>Dissamble it.

The idea is get to know the instructions, the disassembler/debugger (i use radare2), detect patterns like a for loop or a switch/case, etc.

Once i was confident enough, i started debugging crackme's and transcribing the assembly to C code.

I'm really interested in RE IoT firmwares.


File: 1484261393734.png (225.26 KB, 134x200, 1482313507528.jpg)

Should I know a programming language before I start to learn to crack programs?


Can confirm from writing simple stuff in C. This is especially true for huge programs or stuff written by beginners/Indians: in my case, I found when writing a simple console calculator that my program fell apart when you fed it, say, a string instead of a decimal float.


Writing malware/blackhatting is generally very lucrative, and it's not going away. If you want to stay legal, bug reports for major softwares distributors can net some decent cash as well.




At the very least you'll need to learn x86 or another assembly language and a general purpose language probably C. Reversing and cracking is like transcribing Mandarin into Cantonese, or the other way around you're kinda fuarrrked if you don't know how to speak either.

Alternatively if you're looking to crack physical devices you might only need a really good electronics background, but the higher level you go you'll need to learn something like verilog, C, or a bunch of exotic assemblers along the way.


I think you should know several of them - cracking programs mostly involves relying on human mistakes made by programmers who do not understand the compiler in such SICK detail as you do. Unless you're a person who learned to read assembly the same time as the alphabet, you'll need to know your way around; and even assembly


My advice is start with assembly and then learn C. This way you start hands on with the machine and then learn how high level programs (often they're written in C or something that translates to C) relate to those machine level instructions.


or learn both at the same time, http://gcc.godbolt.org/ is especially nice for it.


I didn't know of this. Thanks!