VB Crypter wirklich Fud machen

Hallo, Ich versuche jetzt schon seit gestern mein crypter auf 0/24 zu bekommen jedoch erkennt immer av noch meine Api Funktionen:
Habs mit mehreren RunPE Modulen probiert:
LoadLibrary() wird immer detected
CopyBytes() wird immer detected
CallApibyName in allen Variationen
Sobald ich diese Teile entferne ist es wieder ud ;/
habe auch schon alles module aufrufe mit rc4 verschlüsselt.
Könnt ihr mir plx eine Methode sagen die funktioniert ;/

Meine zweite Frage: wenn ich auf meinem PC mit av scanne wird er dann iwann detected (wenn er erst mal ud ist :p)

grüße Fabi

Die erste Frage kann ich dir nicht beantworten, da ich mich mit VB6 nicht auskenne, zu der 2. Frage, wenn du den Crypter Scannst, wird er nicht detected, wenn du aber den Crypter bei Online Virenscannern insbesondere bei Virus total hochladest, wird der shcneller detected.

Gruß

Slawa

Wenn du die Funktionen nicht statisch importieren kannst, dann lade die Adresse doch on-the-fly mit GetModuleHandle und GetProcAddress.

@Slawa:
das Problem wäre bei VB.NET das gleiche und hat im Grunde weder besonders etwas mit VB6, noch mit irgendeinem VB-Dialekt zutun, sondern ist ein rein heuristisches Problem.

hmm wird getProcAdress bei heuristics net auch detected?

Dann hol dir n CONTEXT von deinem Thread, schau wo fs:[0x30] hinzeigt (Process Enviroment Block)
Struktur (musst du selber übersetzen - wird von MS momentan nur für C++ gezeigt)
http://msdn.microsoft.com/en-us/libr...8VS.85%29.aspx

Dann ab zum LDR (Adresse davon ist im PEB)
Struktur (auch hier ist wieder selber Übersetzen angesagt)
http://undocumented.ntinternals.net/..._LDR_DATA.html

Dort InLoadOrderModuleList durchlaufen und nach kernel32.dll in BaseDLLName (http://undocumented.ntinternals.net/...DR_MODULE.html) suchen.

Ist das gefunden nimmst du die BaseAddress von dem Eintrag.
Das ist das selbe wie ein HANDLE für GetProcAddress.

Wenn auch GetProcAddress in den Imports deines Programms erkannt wird musst du halt genau das selber schreiben.
Die Grundidee ist folgende:
BaseAddress sagt dir wo kernel32.dll im Speicher geladen wurde.
Dort liegt der IMAGE_DOS_HEADER (schau dir Microsoft's PE File Format Specification, oder ein Tutorial dazu an). Dieser Verweist auf IMAGE_NT_HEADERS.
IMAGE_NT_HEADERS besitzen sogenannte DataDirectories.
Das erste DataDirectory enthält die Position des Export Tables.
Dieser gibt an WO die einzelnen Funktionen der DLL im Speicher sind.

Diesen musst du also lokalisieren und parsen und nach Funktionen wie GetProcAddress durchsuchen.
Hast du GetProcAddress erstmal in kernel32.dll gefunden kannst du damit weiter machen (AV's scannen hauptsächlich nach statischen Imports - wenn du GetProcAddress on-the-fly im Speicher lokalisierst kann das nur bemerkt werden, wenn die AV's GetProcAddress gleich bei Programmstart hooken - was meines Wissens nach nicht Praktiziert wird).

Nun könntest du andere Funktionen wie GetModuleHandle laden.

So hättest du dann beide ohne einen einzigen Import zu diesen während des Programmablaufs geladen.

Anmerkung: du musst dennoch irgendeine Funktion von kernel32.dll importieren (sei es nur ExitProcess oder sowas), da sich kernel32.dll sonst nicht in der Modulliste (InLoadOrderModuleList) befände.

P.S.: ich weiß das hört sich ziemlich aufwändig und komplex an, aber niemand hat behauptet, dass es einfach sei. Außerdem ist es durchaus schaffbar, wenn man sich mit der Materie wirklich beschäftigt (hab das damals gleich in ASM gemacht - C würde aber auch gehen - bei VB wirst du wohl wegen dem Mangel an gutem Pointersupport der Sprache einige Schwierigkeiten haben, aber auch da ist es über Umwege machbar)

Und nach Blackberrys post weißt du warum nicht jeder Trottel einfach nen ordentlichen Crypter programmieren kann :lol

nimm lieber c++, damit ist es einfacher eine stub zu programmieren (glaub mir)...
außerdem, verwendest du bei deinem vb6 eof? strings verschlüsselt?

Zitat:

---

Zitat von jojoomgasd

nimm lieber c++, damit ist es einfacher eine stub zu programmieren (glaub mir)...
außerdem, verwendest du bei deinem vb6 eof? strings verschlüsselt?

---

Was redest du da ? Du schreibst in jeden Thread etwas obwohl du glaube ich garkeine Ahnung hast.In C++ ist es nicht einfacher eine Stub zu programmieren , ne Stub in VB6 ist sowas von einfach ich würde fast sagen in VB6 kann man am besten Stubs programmieren.Wie soll er in seinem VB6 EOF verwenden ? Wenn schon verwendet er bei seinem Builder - Stub Prinzip EOF.
Das man die Strings in der Stub verschlüsselt sollte klar sein denn sonst wird nix auch nur nahezu FUD.Außerdem sind bei ihm die APIs detected.

in c++ ist es einfacher, weil man da leichter die apis zur laufzeit laden und verwenden kann... (typedef's)...
in vb6 soll es deiner meinung nach am besten sein, bestimmt wegen public modulen oder? :rolleyes:

VB6 is einsteigerfreundlich, daher isses einfacher. C++ isses wenn man es kann einfacher ne Stub FUD zu bekommen aber ob man jetzt vb6 oder c++ codet is wayne. Ein VB Coder bekommt keine Stub in c++ hin und ein only c++ coder bekommt warsch keine in vb6 hin (was aber warscheinlicher ist als umgekehrt). Außerdem warum immer c++ nehmt doch einfach C. guten alten GCC ausgepackt und go da is dann auch nix mit fehlenden DLLs für die APIs usw. Was in C läuft läuft überall (solangs ANSI C is)

Warum sollte man in C mit API-Calls arbeiten? Dadurch is der Crypter doch viel schneller UD.
C ist im prinzip einfach, weil man direkten memory-zugriff hat und eben nicht über die api-krücken gehen muss.

Edith:
getProcAdress wird nicht automatisch detected, sondern nur wenn es in verbindung mit anderen apicalls genutzt wird (welche selbst einzeln auch nicht detected werden).

Schau mal in der Source Section nach hab eine Funktion gepostet welche keine GetProcAddres, CallWindowProcW, Loadlibrary nutzt mit der du Pointer callen kannst kannste ganz leicht zum CallApiByName umbasteln ;)

Da hat einer die Regeln nicht gelesen und mishandelt gerne Leichen >.>