https://wiki.skullsecurity.org/api.php?action=feedcontributions&user=68.144.105.148&feedformat=atomSkullSecurity - User contributions [en]2024-03-29T07:08:43ZUser contributionsMediaWiki 1.36.1https://wiki.skullsecurity.org/index.php?title=Example_8&diff=310Example 82007-03-17T17:55:44Z<p>68.144.105.148: </p>
<hr />
<div>{{Construction}}<br />
{{Infobox assembly}}<br />
[[Category: Assembly Examples]]<br />
<br />
This is going to be a fairly short tutorial, but it will explain how to grab The IX86...dll files used by Starcraft (and other games) to perform version checking. This will be done on the latest version of Starcraft, since it's the only one that can authenticate to the server. <br />
<br />
The most common way to get the files is by downloading them directly from the Battle.net FTP server, but that involves either an external program or reverse engineering. This method will let the game download them for us! <br />
<br />
== Finding the Deletion ==<br />
First, load battle.snp in IDA. battle.snp is the library that takes care of battle.net connectivity. Click on the "Names" window and search for "LoadLibraryA". Double-click it, the press ctrl-x to view cross references. <br />
<br />
Go through each of the cross references and look for one that loads a variable dll name. <br />
<br />
I found the proper one on the fifth cross reference. The code is pretty obvious (although IDA makes some mistakes in this function, we'll talk about that at another time):<br />
.text:19021A02 push edx ; lpLibFileName<br />
.text:19021A03 call ds:LoadLibraryA<br />
.text:19021A09 mov esi, eax<br />
.text:19021A0B cmp esi, ebx<br />
.text:19021A0D mov [ebp+hLibModule], esi<br />
.text:19021A10 jz loc_19021AEE<br />
.text:19021A16 push offset aCheckrevision ; "CheckRevision"<br />
.text:19021A1B push esi ; hModule<br />
.text:19021A1C call ds:GetProcAddress<br />
A variable library is loaded (edx), then the address for a function called CheckRevision is found. <br />
<br />
So at this point, the physical file exists. One option is to load this into a debugger and break here, then make a copy of the .dll. But that's no fun, I'd prefer to stop it from being deleted altogether! <br />
<br />
Scroll down for awhile, and eventually you'll see this:<br />
.text:19021AFB push 32h ; dwMilliseconds<br />
.text:19021AFD call ds:Sleep<br />
.text:19021B03 mov esi, ds:DeleteFileA<br />
.text:19021B09 push offset byte_1903C108 ; lpFileName<br />
.text:19021B0E call esi ; DeleteFileA<br />
.text:19021B10 cmp [ebp+NumberOfBytesWritten], bl<br />
.text:19021B16 jz short loc_19021B21<br />
.text:19021B18 lea ecx, [ebp+NumberOfBytesWritten]<br />
.text:19021B1E push ecx ; lpFileName<br />
.text:19021B1F call esi ; DeleteFileA<br />
<br />
Two files are being deleted here. Presumably, one of them is the .mpq and the other is the .dll. We're going to want to skip over both of those calls. <br />
<br />
So here's what we have to do:<br />
* Remove those calls (''including the push, otherwise the stack will break'')<br />
* Connect to Battle.net<br />
<br />
== Removing the Calls ==<br />
Run Starcraft, and open it in a debugger (I've found that TSearch can't find this version of Starcraft in memory). Search for the address 0x19021b09. <br />
<br />
Not there? Uh oh! <br />
<br />
The problem we've run into is that battle.snp isn't loaded until Starcraft connects to Battle.net. Loading it with the "Injector" program doesn't even work -- Blizzard's tried hard to break hacks! <br />
<br />
But that's fine, we can go one step further and just disable DeleteFileA altogether. It's not like Starcraft really needs to be deleting my files anyways! <br />
<br />
Ensuring the game's execution is stopped, go to the disassembly window on your debugger and type "DeleteFileA". It should show you a kernel32 function. Open the memory window and do the same. In the memory window, replace the first three bytes with C2 04 00 (which is "ret 4"). Add 90's to pad it if you end up with weird instructions, although it doesn't really matter. <br />
<br />
Once the DeleteFileA call has been removed, go back to the game, and log into Battle.net. The login should succeed (since our patch wasn't in any of the actual Starcraft files). Alt-tab and go into Starcraft's folder. The .mpq and .dll file should be there! <br />
<br />
In theory, it's possible to force Starcraft to download the .dll file of your choice, by editing incoming traffic or getting a breakpoint in Battle.snp, but just connecting to Battle.net until you have them all is probably the easiest way. <br />
<br />
== Removing Protection == <br />
I was disassembling Starcraft.exe for the purposes of demonstration. While waiting, I figured I'd check out the main function:<br />
.text:004DF940 ; int __stdcall WinMain(HINSTANCE hInstance,HINSTANCE hPrevInstance,LPSTR lpCmdLine,int nShowCmd)<br />
.text:004DF940 _WinMain@16: ; CODE XREF: start+17F�p<br />
.text:004DF940 55 push ebp<br />
.text:004DF941 8B EC mov ebp, esp<br />
.text:004DF943 56 push esi<br />
.text:004DF944 8B 75 08 mov esi, [ebp+8]<br />
.text:004DF947 89 35 8C AF 51 00 mov dword_51AF8C, esi<br />
.text:004DF94D E8 3E 00 FF FF call sub_4CF990<br />
.text:004DF952 FF 15 F8 D1 4F 00 call ds:GetCurrentThreadId<br />
.text:004DF958 68 AC E8 4F 00 push offset aSwarclass ; "SWarClass"<br />
.text:004DF95D A3 B8 B9 6C 00 mov dword_6CB9B8, eax<br />
.text:004DF962 E8 A9 F8 FF FF call sub_4DF210<br />
.text:004DF967 E8 C4 9E FF FF call sub_4D9830<br />
.text:004DF96C E8 5F F9 FF FF call sub_4DF2D0<br />
.text:004DF971 E8 0A D6 00 00 call sub_4ECF80<br />
.text:004DF976 E8 15 F7 FF FF call sub_4DF090<br />
.text:004DF97B E8 30 FD FF FF call loc_4DF6B0<br />
<br />
I thought I'd kill time by checking what each of those calls do. The first few are boring, they make sure you can't run more than one Starcraft, and they check system requirements, and other boring stuff. <br />
<br />
When I got to checking sub_4DF090, however, my interest was piqued. It was a bunch of different ACL (access control list) functions, and setting authorizations, culminating in a call to SetSecurityInfo! So I had a hunch, and disabled SetSecurityInfo:<br />
* Run Starcraft through a debugger (you have to do this before Starcraft loads)<br />
* Search for the function "advapi32!SetSecurityInfo"<br />
* Disable it by setting the first three bytes to "c2 1c 00" (you can find the number of bytes to pop, 0x1c, by scrolling to the bottom of the function)<br />
* "Run" the program, and test it. TSearch can now find/modify data, and you can still log onto Battle.net! <br />
<br />
Presumably, a loader could take care of this in an automated fashion, but I'm not sure how I would go about writing one.</div>68.144.105.148https://wiki.skullsecurity.org/index.php?title=Example_8&diff=306Example 82007-03-17T16:04:38Z<p>68.144.105.148: /* Finding the Delete */</p>
<hr />
<div>{{Construction}}<br />
{{Infobox assembly}}<br />
[[Category: Assembly Examples]]<br />
<br />
This is going to be a fairly short tutorial, but it will explain how to grab The IX86...dll files used by Starcraft (and other games) to perform version checking. This will be done on the latest version of Starcraft, since it's the only one that can authenticate to the server. <br />
<br />
The most common way to get the files is by downloading them directly from the Battle.net FTP server, but that involves either an external program or reverse engineering. This method will let the game download them for us! <br />
<br />
== Finding the Deletion ==<br />
First, load battle.snp in IDA. battle.snp is the library that takes care of battle.net connectivity. Click on the "Names" window and search for "LoadLibraryA". Double-click it, the press ctrl-x to view cross references. <br />
<br />
Go through each of the cross references and look for one that loads a variable dll name. <br />
<br />
I found the proper one on the fifth cross reference. The code is pretty obvious (although IDA makes some mistakes in this function, we'll talk about that at another time):<br />
.text:19021A02 push edx ; lpLibFileName<br />
.text:19021A03 call ds:LoadLibraryA<br />
.text:19021A09 mov esi, eax<br />
.text:19021A0B cmp esi, ebx<br />
.text:19021A0D mov [ebp+hLibModule], esi<br />
.text:19021A10 jz loc_19021AEE<br />
.text:19021A16 push offset aCheckrevision ; "CheckRevision"<br />
.text:19021A1B push esi ; hModule<br />
.text:19021A1C call ds:GetProcAddress<br />
A variable library is loaded (edx), then the address for a function called CheckRevision is found. <br />
<br />
So at this point, the physical file exists. One option is to load this into a debugger and break here, then make a copy of the .dll. But that's no fun, I'd prefer to stop it from being deleted altogether! <br />
<br />
Scroll down for awhile, and eventually you'll see this:<br />
.text:19021AFB push 32h ; dwMilliseconds<br />
.text:19021AFD call ds:Sleep<br />
.text:19021B03 mov esi, ds:DeleteFileA<br />
.text:19021B09 push offset byte_1903C108 ; lpFileName<br />
.text:19021B0E call esi ; DeleteFileA<br />
.text:19021B10 cmp [ebp+NumberOfBytesWritten], bl<br />
.text:19021B16 jz short loc_19021B21<br />
.text:19021B18 lea ecx, [ebp+NumberOfBytesWritten]<br />
.text:19021B1E push ecx ; lpFileName<br />
.text:19021B1F call esi ; DeleteFileA<br />
<br />
Two files are being deleted here. Presumably, one of them is the .mpq and the other is the .dll. We're going to want to skip over both of those calls. <br />
<br />
So here's what we have to do:<br />
* Remove those calls (''including the push, otherwise the stack will break'')<br />
* Connect to Battle.net<br />
<br />
== Removing the Calls ==<br />
Run Starcraft, and open it in a debugger (I've found that TSearch can't find this version of Starcraft in memory). Search for the address 0x19021b09. <br />
<br />
Not there? Uh oh! <br />
<br />
The problem we've run into is that battle.snp isn't loaded until Starcraft connects to Battle.net. Loading it with the "Injector" program doesn't even work -- Blizzard's tried hard to break hacks! <br />
<br />
But that's fine, we can go one step further and just disable DeleteFileA altogether. It's not like Starcraft really needs to be deleting my files anyways! <br />
<br />
Ensuring the game's execution is stopped, go to the disassembly window on your debugger and type "DeleteFileA". It should show you a kernel32 function. Open the memory window and do the same. In the memory window, replace the first three bytes with C2 04 00 (which is "ret 4"). Add 90's to pad it if you end up with weird instructions, although it doesn't really matter. <br />
<br />
Once the DeleteFileA call has been removed, go back to the game, and log into Battle.net. The login should succeed (since our patch wasn't in any of the actual Starcraft files). Alt-tab and go into Starcraft's folder. The .mpq and .dll file should be there! <br />
<br />
In theory, it's possible to force Starcraft to download the .dll file of your choice, by editing incoming traffic or getting a breakpoint in Battle.snp, but just connecting to Battle.net until you have them all is probably the easiest way. <br />
<br />
== Removing Protection == <br />
I was disassembling Starcraft.exe for the purposes of demonstration. While waiting, I figured I'd check out the main function:<br />
.text:004DF940 ; int __stdcall WinMain(HINSTANCE hInstance,HINSTANCE hPrevInstance,LPSTR lpCmdLine,int nShowCmd)<br />
.text:004DF940 _WinMain@16: ; CODE XREF: start+17F�p<br />
.text:004DF940 55 push ebp<br />
.text:004DF941 8B EC mov ebp, esp<br />
.text:004DF943 56 push esi<br />
.text:004DF944 8B 75 08 mov esi, [ebp+8]<br />
.text:004DF947 89 35 8C AF 51 00 mov dword_51AF8C, esi<br />
.text:004DF94D E8 3E 00 FF FF call sub_4CF990<br />
.text:004DF952 FF 15 F8 D1 4F 00 call ds:GetCurrentThreadId<br />
.text:004DF958 68 AC E8 4F 00 push offset aSwarclass ; "SWarClass"<br />
.text:004DF95D A3 B8 B9 6C 00 mov dword_6CB9B8, eax<br />
.text:004DF962 E8 A9 F8 FF FF call sub_4DF210<br />
.text:004DF967 E8 C4 9E FF FF call sub_4D9830<br />
.text:004DF96C E8 5F F9 FF FF call sub_4DF2D0<br />
.text:004DF971 E8 0A D6 00 00 call sub_4ECF80<br />
.text:004DF976 E8 15 F7 FF FF call sub_4DF090<br />
.text:004DF97B E8 30 FD FF FF call loc_4DF6B0<br />
<br />
I thought I'd kill time by checking what each of those calls do. The first few are boring, they make sure you can't run more than one Starcraft, and they check system requirements, and other boring stuff. <br />
<br />
When I got to checking sub_4DF090, however, my interest was piqued. It was a bunch of different ACL (access control list) functions, and setting authorizations, culminating in a call to SetSecurityInfo! So I had a hunch, and disabled SetSecurityInfo:<br />
* Run Starcraft through a debugger (you have to do this before Starcraft loads)<br />
* Search for the function "advapi32!SetSecurityInfo"<br />
* Disable it by setting the first three bytes to "c2 1c 00" (you can find the number of bytes to pop, 0x1c, by scrolling to the bottom of the function)<br />
* "Run" the program, and test it. TSearch can now find/modify data, and you can still log onto Battle.net! <br />
<br />
Presumably, a loader could take care of this in an automated fashion, but I'm not sure how I would go about writing one.</div>68.144.105.148https://wiki.skullsecurity.org/index.php?title=Example_8&diff=305Example 82007-03-17T16:04:21Z<p>68.144.105.148: </p>
<hr />
<div>{{Construction}}<br />
{{Infobox assembly}}<br />
[[Category: Assembly Examples]]<br />
<br />
This is going to be a fairly short tutorial, but it will explain how to grab The IX86...dll files used by Starcraft (and other games) to perform version checking. This will be done on the latest version of Starcraft, since it's the only one that can authenticate to the server. <br />
<br />
The most common way to get the files is by downloading them directly from the Battle.net FTP server, but that involves either an external program or reverse engineering. This method will let the game download them for us! <br />
<br />
== Finding the Delete ==<br />
First, load battle.snp in IDA. battle.snp is the library that takes care of battle.net connectivity. Click on the "Names" window and search for "LoadLibraryA". Double-click it, the press ctrl-x to view cross references. <br />
<br />
Go through each of the cross references and look for one that loads a variable dll name. <br />
<br />
I found the proper one on the fifth cross reference. The code is pretty obvious (although IDA makes some mistakes in this function, we'll talk about that at another time):<br />
.text:19021A02 push edx ; lpLibFileName<br />
.text:19021A03 call ds:LoadLibraryA<br />
.text:19021A09 mov esi, eax<br />
.text:19021A0B cmp esi, ebx<br />
.text:19021A0D mov [ebp+hLibModule], esi<br />
.text:19021A10 jz loc_19021AEE<br />
.text:19021A16 push offset aCheckrevision ; "CheckRevision"<br />
.text:19021A1B push esi ; hModule<br />
.text:19021A1C call ds:GetProcAddress<br />
A variable library is loaded (edx), then the address for a function called CheckRevision is found. <br />
<br />
So at this point, the physical file exists. One option is to load this into a debugger and break here, then make a copy of the .dll. But that's no fun, I'd prefer to stop it from being deleted altogether! <br />
<br />
Scroll down for awhile, and eventually you'll see this:<br />
.text:19021AFB push 32h ; dwMilliseconds<br />
.text:19021AFD call ds:Sleep<br />
.text:19021B03 mov esi, ds:DeleteFileA<br />
.text:19021B09 push offset byte_1903C108 ; lpFileName<br />
.text:19021B0E call esi ; DeleteFileA<br />
.text:19021B10 cmp [ebp+NumberOfBytesWritten], bl<br />
.text:19021B16 jz short loc_19021B21<br />
.text:19021B18 lea ecx, [ebp+NumberOfBytesWritten]<br />
.text:19021B1E push ecx ; lpFileName<br />
.text:19021B1F call esi ; DeleteFileA<br />
<br />
Two files are being deleted here. Presumably, one of them is the .mpq and the other is the .dll. We're going to want to skip over both of those calls. <br />
<br />
So here's what we have to do:<br />
* Remove those calls (''including the push, otherwise the stack will break'')<br />
* Connect to Battle.net<br />
<br />
== Removing the Calls ==<br />
Run Starcraft, and open it in a debugger (I've found that TSearch can't find this version of Starcraft in memory). Search for the address 0x19021b09. <br />
<br />
Not there? Uh oh! <br />
<br />
The problem we've run into is that battle.snp isn't loaded until Starcraft connects to Battle.net. Loading it with the "Injector" program doesn't even work -- Blizzard's tried hard to break hacks! <br />
<br />
But that's fine, we can go one step further and just disable DeleteFileA altogether. It's not like Starcraft really needs to be deleting my files anyways! <br />
<br />
Ensuring the game's execution is stopped, go to the disassembly window on your debugger and type "DeleteFileA". It should show you a kernel32 function. Open the memory window and do the same. In the memory window, replace the first three bytes with C2 04 00 (which is "ret 4"). Add 90's to pad it if you end up with weird instructions, although it doesn't really matter. <br />
<br />
Once the DeleteFileA call has been removed, go back to the game, and log into Battle.net. The login should succeed (since our patch wasn't in any of the actual Starcraft files). Alt-tab and go into Starcraft's folder. The .mpq and .dll file should be there! <br />
<br />
In theory, it's possible to force Starcraft to download the .dll file of your choice, by editing incoming traffic or getting a breakpoint in Battle.snp, but just connecting to Battle.net until you have them all is probably the easiest way. <br />
<br />
== Removing Protection == <br />
I was disassembling Starcraft.exe for the purposes of demonstration. While waiting, I figured I'd check out the main function:<br />
.text:004DF940 ; int __stdcall WinMain(HINSTANCE hInstance,HINSTANCE hPrevInstance,LPSTR lpCmdLine,int nShowCmd)<br />
.text:004DF940 _WinMain@16: ; CODE XREF: start+17F�p<br />
.text:004DF940 55 push ebp<br />
.text:004DF941 8B EC mov ebp, esp<br />
.text:004DF943 56 push esi<br />
.text:004DF944 8B 75 08 mov esi, [ebp+8]<br />
.text:004DF947 89 35 8C AF 51 00 mov dword_51AF8C, esi<br />
.text:004DF94D E8 3E 00 FF FF call sub_4CF990<br />
.text:004DF952 FF 15 F8 D1 4F 00 call ds:GetCurrentThreadId<br />
.text:004DF958 68 AC E8 4F 00 push offset aSwarclass ; "SWarClass"<br />
.text:004DF95D A3 B8 B9 6C 00 mov dword_6CB9B8, eax<br />
.text:004DF962 E8 A9 F8 FF FF call sub_4DF210<br />
.text:004DF967 E8 C4 9E FF FF call sub_4D9830<br />
.text:004DF96C E8 5F F9 FF FF call sub_4DF2D0<br />
.text:004DF971 E8 0A D6 00 00 call sub_4ECF80<br />
.text:004DF976 E8 15 F7 FF FF call sub_4DF090<br />
.text:004DF97B E8 30 FD FF FF call loc_4DF6B0<br />
<br />
I thought I'd kill time by checking what each of those calls do. The first few are boring, they make sure you can't run more than one Starcraft, and they check system requirements, and other boring stuff. <br />
<br />
When I got to checking sub_4DF090, however, my interest was piqued. It was a bunch of different ACL (access control list) functions, and setting authorizations, culminating in a call to SetSecurityInfo! So I had a hunch, and disabled SetSecurityInfo:<br />
* Run Starcraft through a debugger (you have to do this before Starcraft loads)<br />
* Search for the function "advapi32!SetSecurityInfo"<br />
* Disable it by setting the first three bytes to "c2 1c 00" (you can find the number of bytes to pop, 0x1c, by scrolling to the bottom of the function)<br />
* "Run" the program, and test it. TSearch can now find/modify data, and you can still log onto Battle.net! <br />
<br />
Presumably, a loader could take care of this in an automated fashion, but I'm not sure how I would go about writing one.</div>68.144.105.148https://wiki.skullsecurity.org/index.php?title=Example_9&diff=304Example 92007-03-17T15:04:40Z<p>68.144.105.148: New page: {{Construction}}
{{Infobox assembly}}
Category: Assembly Examples
As usual, I won't name the game here. Contact me if you would like!</p>
<hr />
<div>{{Construction}}<br />
{{Infobox assembly}}<br />
[[Category: Assembly Examples]]<br />
<br />
As usual, I won't name the game here. Contact me if you would like!</div>68.144.105.148https://wiki.skullsecurity.org/index.php?title=Template:Infobox_assembly&diff=303Template:Infobox assembly2007-03-17T15:04:24Z<p>68.144.105.148: </p>
<hr />
<div>{| class="infobox" style="font-size:95%;width:24em;text-align:left;"<br />
|- <br />
! colspan="2" style="background:#808080;font-size:larger;text-align:center;" | Assembly Language Tutorial<br />
|- <br />
| Please choose a tutorial page:<br />
* [[Fundamentals]] -- Information about C<br />
* [[Tools]]<br />
* [[Registers]]<br />
* [[Simple Instructions]]<br />
* [[Example 1]] -- Starcraft CDKey Verification<br />
* [[Example 2]] -- Starcraft CDKey Shuffle<br />
* [[The Stack]]<br />
** [[Stack Example]]<br />
* [[Functions]]<br />
* [[Example 3]] -- Storm.dll SStrChr<br />
* [[Assembly Summary]]<br />
<hr><br />
* [[Machine Code]]<br />
* [[Example 4]] -- Smashing the Stack<br />
* [[Cracking a Game]]<br />
* [[Example 5]] -- Cracking a game<br />
* [[Example 6]] -- Writing a keygen<br />
* [[.dll Injection and Patching]]<br />
* [[Memory Searching]]<br />
* [[Example 7]] -- Writing a cheat for Starcraft (1.05)<br />
** [[Example 7 Step 1]] -- Displaying Messages<br />
** [[Example 7 Step 1b]] -- Above, w/ func ptrs<br />
** [[Example 7 Final]]<br />
* [[Example 8]] -- Getting IX86.dll files<br />
* [[16-bit Assembly]]<br />
* [[Example 9]] -- Keygen for a 16-bit game<br />
|}<includeonly>[[Category:Assembly Guide]]</includeonly><noinclude><br />
<br />
==Usage==<br />
{| style="background: transparent;"<br />
|<pre>{{Infobox assembly}}</pre><br />
<br />
[[Category:Infobox templates]]<br />
[[Category:templates]]<br />
</noinclude></div>68.144.105.148https://wiki.skullsecurity.org/index.php?title=Example_7_Step_1b&diff=267Example 7 Step 1b2007-03-16T16:18:38Z<p>68.144.105.148: New page:
#include <stdio.h>
#include <windows.h>
typedef void (__fastcall *fcnShowMessage) (const char* message, int unk, int intDisplayUntil, int unk0);
static const fcnShowMessage ShowMessage =...</p>
<hr />
<div><br />
#include <stdio.h><br />
#include <windows.h><br />
<br />
typedef void (__fastcall *fcnShowMessage) (const char* message, int unk, int intDisplayUntil, int unk0);<br />
static const fcnShowMessage ShowMessage = (fcnShowMessage) 0x00469380;<br />
<br />
BOOL APIENTRY DllMain(HMODULE hModule, DWORD ul_reason_for_call, LPVOID lpReserved)<br />
{<br />
switch(ul_reason_for_call)<br />
{<br />
case DLL_PROCESS_ATTACH:<br />
ShowMessage("\x03Loading test plugin v2", 0, GetTickCount() + 30000, 0);<br />
break;<br />
<br />
case DLL_PROCESS_DETACH:<br />
ShowMessage("\x03Loading test plugin v2", 0, GetTickCount() + 30000, 0);<br />
break;<br />
}<br />
<br />
return TRUE;<br />
}</div>68.144.105.148https://wiki.skullsecurity.org/index.php?title=Sandbox&diff=258Sandbox2007-03-16T15:34:58Z<p>68.144.105.148: </p>
<hr />
<div><br />
#include <stdio.h><br />
#include <windows.h><br />
<br />
void __stdcall DisplayMessage(char *strMessage, int intDurationInSeconds)<br />
{<br />
int intDisplayUntil = GetTickCount() + (intDurationInSeconds * 1000);<br />
int fcnDisplayMessage = 0x469380;<br />
<br />
__asm<br />
{<br />
push 0<br />
push intDisplayUntil<br />
mov edx, 0<br />
mov ecx, strMessage<br />
call fcnDisplayMessage<br />
}<br />
}<br />
<br />
BOOL APIENTRY DllMain(HMODULE hModule, DWORD ul_reason_for_call, LPVOID lpReserved)<br />
{<br />
switch(ul_reason_for_call)<br />
{<br />
case DLL_PROCESS_ATTACH:<br />
DisplayMessage("\x03Loading test plugin", 30);<br />
break;<br />
<br />
case DLL_PROCESS_DETACH:<br />
DisplayMessage("\x03Unloading test plugin", 30);<br />
break;<br />
}<br />
<br />
return TRUE;<br />
}</div>68.144.105.148https://wiki.skullsecurity.org/index.php?title=Example_5&diff=213Example 52007-03-15T18:09:23Z<p>68.144.105.148: /* Step 4 */</p>
<hr />
<div>{{Infobox assembly}}<br />
[[Category: Assembly Examples]]<br />
<br />
This example is going to cover the steps I took to crack a not-very-popular computer game. Rather than showing all the trial-and-error, I'm going to demonstrate the strategy that worked. Note that there are probably many ways to go about this, the way I'll demonstrate is only one way. <br />
<br />
== The Game == <br />
For fear of legal issues, I'm not going to name the game I use in this thread. If you wish to know which game, talk to me privately. <br />
<br />
The reason I chose this game is twofold:<br />
# Its protection is fairly simple, providing a useful tutorial.<br />
# It's a really good game made by a fantastic company that I like a lot. So encouraging people who've never heard of it to try it can only be positive. <br />
<br />
In other words, if you think this game is interesting, buy it! This demonstration is for educational purposes only. <br />
<br />
If you believe this is your game, and you don't wish this information to be here, please send me an email and I will remove this page (if indeed it is yours). <br />
<br />
== Tools ==<br />
All you need for this is IDA and TSearch. They can be found on the tools page. A hex editor can be substituted for TSearch to permanently patch the game instead of patching it in memory. <br />
<br />
== Getting Started ==<br />
If this is your first time using IDA, you might want to take some time getting used to it. I'm going to be using IDA 5 for this demonstration, but any version technically works. <br />
<br />
First, you'll probably want to run the game to familiarize yourself with the protection scheme. In the bottom-right corner you'll see a "registration code", and if you press "register" you'll be prompted for a registration key. Try a couple keys, maybe you'll get lucky. Hint: all codes are integers between 10000 and 19999. <br />
<br />
When you get bored, load up IDA and load the game's .exe file. At the bottom left, you'll see the analysis status. You can look around all you want while it's analyzing, but once it says "idle" we can start poking around. <br />
<br />
If this is your first time in IDA, take some time to familiarize yourself with it. I won't pretend that IDA is an easy program to use, I haven't even scratched the surface of what I know it is capable of. But some of the commands you might want to try are:<br />
* Renaming variables/arguments/addresses (click on a variable and press 'n').<br />
* Setting a prototype for a function (click on the function header and press 'y' -- note that you can define a __cdecl, __stdcall, or __fastcall function this way).<br />
* Adding a comment to a function (click on the function header and press ';'). <br />
* Adding a comment to a line (click on the line and press ':'). <br />
* Finding function cross references (click on the function header and press 'ctrl x')<br />
* Following cross references (double click on a variable, function, address, etc)<br />
* Experiment with highlighting (whenever you click or highlight something, everything that matches highlights)<br />
<br />
Those are the features I use most frequently. They can all be accessed via menus, so you don't have to memorize those hotkeys, but knowing the hotkeys will speed things up a lot. <br />
<br />
== Finding the Validation ==<br />
Finding the validation is the most difficult part, but if you follow these steps it shouldn't be terribly difficult. This section will cover the steps used to find the proper address. I'm omitting any trial-and-error steps from this. <br />
<br />
If you have any ideas of your own, feel free to try this on your own! If you find another way to crack this game, I'll include it here. <br />
<br />
=== Step 1 ===<br />
In the "Strings" window of IDA, search for "Unregistered". Do this by bringing up the strings tab/window, and typing the word. You should see a string that will warn the user that the game is unregistered, which is the string that is used on the main window. Double-click it. <br />
<br />
=== Step 2 ===<br />
You will see the string in the data section now. Press ctrl-x to bring up the cross references (ie, where the string is used). <br />
<br />
<br />
=== Step 3 ===<br />
There should only be one. Double-click it. You should see the following code (addresses removed to protect the innocent (me)):<br />
<br />
cmp ds:byte_AAAAAA, 0<br />
jnz short loc_BBBBBB<br />
mov edx, ds:dword_CCCCCC<br />
push edx ; HGDIOBJ<br />
mov eax, ds:dword_DDDDDD<br />
push eax ; HDC<br />
call ds:SelectObject<br />
movsx eax, word_EEEEEE<br />
push eax<br />
push offset aUnregisteredCo ; "Unregistered Copy...<br />
lea eax, [ebp+var_188]<br />
push eax<br />
call sub_FFFFFF<br />
<br />
Let's look at the steps:<br />
* byte_AAAAAA is being compared to 0<br />
* If it's non-zero, a jump away from here is made<br />
* Otherwise, call a function, sub_FFFFFF, where one of the parameters is "Unregistered Copy..."<br />
<br />
It seems like a good theory that byte_AAAAAA is the variable, "IsRegistered", so click on it, press 'n', and give it that name. Then double-click on it. <br />
<br />
=== Step 4 ===<br />
Press ctrl-x on the variable to get a list of cross references. IsRegistered is used all over the place! <br />
<br />
Luckily, our goal is to find out where the registration code is accepted. There are only three lines with "mov IsRegistered, 1" so those are probably good places to start. Funnily enough, all three functions are identical. Apparently, the developers copied/pasted code? <br />
<br />
On the plus side, we can look at one of the functions and apply the same logic to the other two, if it doesn't work. So take a guess and double-click on the first function that does "mov IsRegistered, 1"<br />
<br />
<br />
=== Step 5 ===<br />
.text:push ebp<br />
.text:mov ebp, esp<br />
.text:movsx eax, word_111111<br />
.text:push eax<br />
.text:call sub_222222<br />
.text:pop ecx<br />
.text:cmp word_333333, ax<br />
.text:jnz short registerfail<br />
.text:mov ds:IsRegistered, 1<br />
.text:jmp short endfunction<br />
.text:; ---------------------------------------------------------------------------<br />
.text:<br />
.text:registerfail:<br />
.text:mov ds:IsRegistered, 0<br />
.text:endfunction:<br />
.text:mov esp, ebp<br />
.text:pop ebp<br />
.text:retn<br />
<br />
=== Step xxx ===<br />
<br />
== Cracking the game ==<br />
Now that you know the address of the verification, we can test it. Do the following to crack it (again, if you think you can do this on your own, please do!):<br />
* Run the game<br />
* Minimize it<br />
* Run TSearch<br />
* Use "Open Process" in TSearch to open the game<br />
* Enable TSearch's "Hex Editor"<br />
* Click on the left-most icon on the hex editor, and type in the address of the '''''jnz/jz???''''' instruction<br />
* Change the instruction to '''''jmp/nop???'''''<br />
* Go back to the game, enter any registration code<br />
* Any code should now be accepted! <br />
<br />
== Questions ==<br />
Feel free to edit this section and post questions, I'll do my best to answer them. But you may need to contact me to let me know that a question exists.</div>68.144.105.148https://wiki.skullsecurity.org/index.php?title=Example_5&diff=211Example 52007-03-15T17:54:53Z<p>68.144.105.148: /* Finding the Validation */</p>
<hr />
<div>{{Infobox assembly}}<br />
[[Category: Assembly Examples]]<br />
<br />
This example is going to cover the steps I took to crack a not-very-popular computer game. Rather than showing all the trial-and-error, I'm going to demonstrate the strategy that worked. Note that there are probably many ways to go about this, the way I'll demonstrate is only one way. <br />
<br />
== The Game == <br />
For fear of legal issues, I'm not going to name the game I use in this thread. If you wish to know which game, talk to me privately. <br />
<br />
The reason I chose this game is twofold:<br />
# Its protection is fairly simple, providing a useful tutorial.<br />
# It's a really good game made by a fantastic company that I like a lot. So encouraging people who've never heard of it to try it can only be positive. <br />
<br />
In other words, if you think this game is interesting, buy it! This demonstration is for educational purposes only. <br />
<br />
If you believe this is your game, and you don't wish this information to be here, please send me an email and I will remove this page (if indeed it is yours). <br />
<br />
== Tools ==<br />
All you need for this is IDA and TSearch. They can be found on the tools page. A hex editor can be substituted for TSearch to permanently patch the game instead of patching it in memory. <br />
<br />
== Getting Started ==<br />
If this is your first time using IDA, you might want to take some time getting used to it. I'm going to be using IDA 5 for this demonstration, but any version technically works. <br />
<br />
First, you'll probably want to run the game to familiarize yourself with the protection scheme. In the bottom-right corner you'll see a "registration code", and if you press "register" you'll be prompted for a registration key. Try a couple keys, maybe you'll get lucky. Hint: all codes are integers between 10000 and 19999. <br />
<br />
When you get bored, load up IDA and load the game's .exe file. At the bottom left, you'll see the analysis status. You can look around all you want while it's analyzing, but once it says "idle" we can start poking around. <br />
<br />
If this is your first time in IDA, take some time to familiarize yourself with it. I won't pretend that IDA is an easy program to use, I haven't even scratched the surface of what I know it is capable of. But some of the commands you might want to try are:<br />
* Renaming variables/arguments/addresses (click on a variable and press 'n').<br />
* Setting a prototype for a function (click on the function header and press 'y' -- note that you can define a __cdecl, __stdcall, or __fastcall function this way).<br />
* Adding a comment to a function (click on the function header and press ';'). <br />
* Adding a comment to a line (click on the line and press ':'). <br />
* Finding function cross references (click on the function header and press 'ctrl x')<br />
* Following cross references (double click on a variable, function, address, etc)<br />
* Experiment with highlighting (whenever you click or highlight something, everything that matches highlights)<br />
<br />
Those are the features I use most frequently. They can all be accessed via menus, so you don't have to memorize those hotkeys, but knowing the hotkeys will speed things up a lot. <br />
<br />
== Finding the Validation ==<br />
Finding the validation is the most difficult part, but if you follow these steps it shouldn't be terribly difficult. This section will cover the steps used to find the proper address. I'm omitting any trial-and-error steps from this. <br />
<br />
If you have any ideas of your own, feel free to try this on your own! If you find another way to crack this game, I'll include it here. <br />
<br />
=== Step 1 ===<br />
In the "Strings" window of IDA, search for "Unregistered". Do this by bringing up the strings tab/window, and typing the word. You should see a string that will warn the user that the game is unregistered, which is the string that is used on the main window. Double-click it. <br />
<br />
=== Step 2 ===<br />
You will see the string in the data section now. Press ctrl-x to bring up the cross references (ie, where the string is used). There should only be one. Double-click it. You should see the following code (addresses removed to protect the innocent (me)):<br />
<br />
cmp ds:byte_AAAAAA, 0<br />
jnz short loc_BBBBBB<br />
mov edx, ds:dword_CCCCCC<br />
push edx ; HGDIOBJ<br />
mov eax, ds:dword_DDDDDD<br />
push eax ; HDC<br />
call ds:SelectObject<br />
movsx eax, word_EEEEEE<br />
push eax<br />
push offset aUnregisteredCo ; "Unregistered Copy...<br />
lea eax, [ebp+var_188]<br />
push eax<br />
call sub_FFFFFF<br />
<br />
<br />
=== Step xxx ===<br />
<br />
== Cracking the game ==<br />
Now that you know the address of the verification, we can test it. Do the following to crack it (again, if you think you can do this on your own, please do!):<br />
* Run the game<br />
* Minimize it<br />
* Run TSearch<br />
* Use "Open Process" in TSearch to open the game<br />
* Enable TSearch's "Hex Editor"<br />
* Click on the left-most icon on the hex editor, and type in the address of the '''''jnz/jz???''''' instruction<br />
* Change the instruction to '''''jmp/nop???'''''<br />
* Go back to the game, enter any registration code<br />
* Any code should now be accepted! <br />
<br />
== Questions ==<br />
Feel free to edit this section and post questions, I'll do my best to answer them. But you may need to contact me to let me know that a question exists.</div>68.144.105.148https://wiki.skullsecurity.org/index.php?title=Sandbox&diff=195Sandbox2007-03-14T17:07:14Z<p>68.144.105.148: </p>
<hr />
<div>This page is for playing or testing!<br />
<br />
<br />
<pre>53 push ebx<br />
8B 54 24 08 mov edx, [esp+arg_0] ; edx gets the reg code<br />
31 DB xor ebx, ebx ; Clear ebx<br />
89 D3 mov ebx, edx ; Move the reg code into ebx<br />
8D 42 07 lea eax, [edx+7] ; Add 7 to the code and put it in eax<br />
<br />
</pre></div>68.144.105.148https://wiki.skullsecurity.org/index.php?title=Fundamentals&diff=22Fundamentals2007-03-11T19:34:25Z<p>68.144.105.148: </p>
<hr />
<div>This page is going to be about the fundamentals that you have to understand before you can make any sense out of assembly. Most of this stuff you'll learn if you learn to program in C. If this is old or boring stuff to you, feel free to skip this section entirely. <br />
<br />
The topics here are going to be a short overview of each section. If you want a more complete explanation, you should find an actual reference, or look it up on the Internet. This is only meant to be a quick and dirty primer. <br />
<br />
== Hexadecimal ==<br />
To work in assembly, you have to be able to read hexadecimal fairly comfortably. Converting to decimal in your mind isn't necessary, but being able to do some simple arithmetic is. <br />
<br />
Hex can be denoted in a number of ways, but the two most common are:<br />
* Prefixed with a 0x, eg. 0x1ef7<br />
* Postfixed with a h, eg. 1ef7h<br />
<br />
The characters 0 - f represent the decimal numbers 0 - 15:<br />
* 0 = 0<br />
* 1 = 1<br />
* ...<br />
* 9 = 9<br />
* a = 10<br />
* b = 11<br />
* c = 12<br />
* d = 13<br />
* e = 14<br />
* f = 15<br />
<br />
To convert from hex to decimal, multiply each digit, starting with the right-most, with 16<sup>0</sup>, 16<sup>1</sup>, 16<sup>2</sup>, etc. So in the example of 0x1ef7, the conversion is this:<br />
* (7 * 16<sup>0</sup>) + (f * 16<sup>1</sup>) + (e * 16<sup>2</sup>) + (1 * 16<sup>3</sup>)<br />
* = (7 * 16<sup>0</sup>) + (15 * 16<sup>1</sup>) + (14 * 16<sup>2</sup>) + (1 * 16<sup>3</sup>)<br />
* = (7 * 1) + (15 * 16) + (14 * 256) + (1 * 4096)<br />
* = 7 + 240 + 3584 + 4096<br />
* = 7927<br />
<br />
It isn't necessary to do that constantly, that's why we have calculators. But you should be fairly familiar with the numbers 00 - FF (0 - 255), they will come up often and you will spend a lot of time looking them up. <br />
<br />
== Binary == <br />
Binary, as we all know, is a number system using only 0's and 1's. The usage is basically the same as hex, but change powers of 16 to powers of 2. <br />
<br />
1011 to decimal:<br />
* (1 * 2<sup>0</sup>) + (1 * 2<sup>1</sup>) + (0 * 2<sup>2</sup>) + (1 * 2<sup>3</sup>)<br />
* = (1 * 1) + (1 * 2) + (0 * 4) + (1 * 8)<br />
* = 1 + 2 + 0 + 8<br />
* = 11<br />
<br />
Conversion between decimal and binary is rare, it's much more common to convert between hexadecimal and binary. This conversion is common because it's so easy: every 4 binary digits is converted to a single hex digit. So all you really need to know are the first 16 binary to hex conversions:<br />
* 0x0 = 0000<br />
* 0x1 = 0001<br />
* 0x2 = 0010<br />
* 0x3 = 0011<br />
* 0x4 = 0100<br />
* 0x5 = 0101<br />
* 0x6 = 0110<br />
* 0x7 = 0111<br />
* 0x8 = 1000<br />
* 0x9 = 1001<br />
* 0xa = 1010<br />
* 0xb = 1011<br />
* 0xc = 1100<br />
* 0xd = 1101<br />
* 0xe = 1110<br />
* 0xf = 1111<br />
<br />
So take the binary number 100101101001110, for example. <br />
# Pad the front with zeros to make its length a multiple of 4: 0100101101001110<br />
# Break it into 4-digit groups: 0100 1011 0100 1110<br />
# Look up each set of 4-digits on the table: 0x4 0xb 0x4 0xe<br />
# Put them all together 0x4b4e<br />
<br />
To go the other way is even easier, using 0x469e for example:<br />
# Separate the digits: 0x4 0x6 0x9 0xe<br />
# Convert each of them to binary, by the table: 0100 0110 1001 1110<br />
# Put them together, and leading zeros on the first group can be removed: 100011010011110<br />
<br />
== Datatypes ==<br />
<br />
A datatype basically refers to how digits in hex are partitioned off and divided into numbers. Datatypes are typically measures by two factors: the number of bits (or bytes), and whether or not negative numbers are allowed.<br />
<br />
The number of bits (or bytes) refers to the length of the number. An 8-bit (or 1-byte) number is made up of two hexadecimal digits. For example, 0x03, 0x34, and 0xFF are all 8-bit, while 0x1234, 0x0001, and 0xFFFF are 16-bit. <br />
<br />
The signed or unsigned property refers to whether or not the number can have negative values. If it can, then the maximum number is half of what it could have, with the other half being negatives. The way sign is determined is by looking at the very first bit. If the first bit is a 1, or the first hex digit is 8 - F, then it's negative and the rest of the number, inverted plus one, is used for the magnitude. <br />
<br />
For example (use a calculator to convert to binary):<br />
* 0x10 in binary ix 0001 0000, so it's positive 16<br />
* 0xFF in binary is 1111 1111, so it's negative. The rest of the number is the 7-bits, 1111111, inverted to 0000000, plus one is 0000001, or -1 in decimal. <br />
* 0x80 in binary is 1000 0000, so it's negative. The rest of the number is the 7-bits, 0000000, inverted to 1111111, plus one is 10000000, or -128 in decimal. <br />
* 0x7F in binary is 0111 1111, so it's positive 127. <br />
<br />
Although different data lengths are called different things, here are some common ones by their usual name:<br />
<br />
* 8-bit (1 byte) = char (or BYTE)<br />
** In hex, can be 0x00 to 0xFF<br />
** Signed: ranges from -128 to 127<br />
** Unsigned: ranges from 0 to 255<br />
<br />
<br />
* 16-bit (2 bytes) = short int (often referred to as a WORD)<br />
** In hex, can be 0x0000 to 0xFFFF<br />
** Signed: ranges from -32768 to 32767<br />
** Unsigned: ranges from 0 to 65535<br />
<br />
<br />
* 32-bit (4 bytes) = long int (often referred to as a DWORD or double-WORD)<br />
** In hex, can be 0x00000000 to 0xFFFFFFFF<br />
** Signed: ranges from -2147483648 - 2147483647<br />
** Unsigned: ranges from 0 - 4294967295<br />
<br />
<br />
* 64-bit (8 bytes) = long long (often referred to as a QWORD or quad-WORD)<br />
** In hex, can be from 0x0000000000000000 - 0xFFFFFFFFFFFFFFFF<br />
** Signed: -9223372036854775808 - 9223372036854775807<br />
** Unsigned: 0 - 18446744073709551615<br />
<br />
== Memory ==<br />
<br />
== Pointers == <br />
<br />
== Ascii == <br />
<br />
== Arrays == <br />
<br />
== Strings ==<br />
<br />
== Questions ==<br />
Feel free to edit this section and post questions, I'll do my best to answer them. But you may need to contact me to let me know that a question exists.</div>68.144.105.148https://wiki.skullsecurity.org/index.php?title=Fundamentals&diff=21Fundamentals2007-03-11T19:26:47Z<p>68.144.105.148: /* Datatypes */</p>
<hr />
<div>This page is going to be about the fundamentals that you have to understand before you can make any sense out of assembly. Most of this stuff you'll learn if you learn to program in C. If this is old or boring stuff to you, feel free to skip this section entirely. <br />
<br />
The topics here are going to be a short overview of each section. If you want a more complete explanation, you should find an actual reference, or look it up on the Internet. This is only meant to be a quick and dirty primer. <br />
<br />
== Hexadecimal ==<br />
To work in assembly, you have to be able to read hexadecimal fairly comfortably. Converting to decimal in your mind isn't necessary, but being able to do some simple arithmetic is. <br />
<br />
Hex can be denoted in a number of ways, but the two most common are:<br />
* Prefixed with a 0x, eg. 0x1ef7<br />
* Postfixed with a h, eg. 1ef7h<br />
<br />
The characters 0 - f represent the decimal numbers 0 - 15:<br />
* 0 = 0<br />
* 1 = 1<br />
* ...<br />
* 9 = 9<br />
* a = 10<br />
* b = 11<br />
* c = 12<br />
* d = 13<br />
* e = 14<br />
* f = 15<br />
<br />
To convert from hex to decimal, multiply each digit, starting with the right-most, with 16<sup>0</sup>, 16<sup>1</sup>, 16<sup>2</sup>, etc. So in the example of 0x1ef7, the conversion is this:<br />
* (7 * 16<sup>0</sup>) + (f * 16<sup>1</sup>) + (e * 16<sup>2</sup>) + (1 * 16<sup>3</sup>)<br />
* = (7 * 16<sup>0</sup>) + (15 * 16<sup>1</sup>) + (14 * 16<sup>2</sup>) + (1 * 16<sup>3</sup>)<br />
* = (7 * 1) + (15 * 16) + (14 * 256) + (1 * 4096)<br />
* = 7 + 240 + 3584 + 4096<br />
* = 7927<br />
<br />
It isn't necessary to do that constantly, that's why we have calculators. But you should be fairly familiar with the numbers 00 - FF (0 - 255), they will come up often and you will spend a lot of time looking them up. <br />
<br />
== Datatypes ==<br />
<br />
A datatype basically refers to how digits in hex are partitioned off and divided into numbers. Datatypes are typically measures by two factors: the number of bits (or bytes), and whether or not negative numbers are allowed.<br />
<br />
The number of bits (or bytes) refers to the length of the number. An 8-bit (or 1-byte) number is made up of two hexadecimal digits. For example, 0x03, 0x34, and 0xFF are all 8-bit, while 0x1234, 0x0001, and 0xFFFF are 16-bit. <br />
<br />
The signed or unsigned property refers to whether or not the number can have negative values. If it can, then the maximum number is half of what it could have, with the other half being negatives. The way sign is determined is by looking at the very first bit. If the first bit is a 1, or the first hex digit is 8 - F, then it's negative and the rest of the number, inverted plus one, is used for the magnitude. <br />
<br />
For example (use a calculator to convert to binary):<br />
* 0x10 in binary ix 00010000, so it's positive 16<br />
* 0xFF in binary is 11111111, so it's negative. The rest of the number is the 7-bits, 1111111, inverted to 0000000, plus one is 0000001, or -1 in decimal. <br />
* 0x80 in binary is 10000000, so it's negative. The rest of the number is the 7-bits, 0000000, inverted to 1111111, plus one is 10000000, or -128 in decimal. <br />
* 0x7F in binary is 01111111, so it's positive 127. <br />
<br />
Although different data lengths are called different things, here are some common ones by their usual name:<br />
<br />
* 8-bit (1 byte) = char (or BYTE)<br />
** In hex, can be 0x00 to 0xFF<br />
** Signed: ranges from -128 to 127<br />
** Unsigned: ranges from 0 to 255<br />
<br />
<br />
* 16-bit (2 bytes) = short int (often referred to as a WORD)<br />
** In hex, can be 0x0000 to 0xFFFF<br />
** Signed: ranges from -32768 to 32767<br />
** Unsigned: ranges from 0 to 65535<br />
<br />
<br />
* 32-bit (4 bytes) = long int (often referred to as a DWORD or double-WORD)<br />
** In hex, can be 0x00000000 to 0xFFFFFFFF<br />
** Signed: ranges from -2147483648 - 2147483647<br />
** Unsigned: ranges from 0 - 4294967295<br />
<br />
<br />
* 64-bit (8 bytes) = long long (often referred to as a QWORD or quad-WORD)<br />
** In hex, can be from 0x0000000000000000 - 0xFFFFFFFFFFFFFFFF<br />
** Signed: -9223372036854775808 - 9223372036854775807<br />
** Unsigned: 0 - 18446744073709551615<br />
<br />
== Memory ==<br />
<br />
== Pointers == <br />
<br />
== Ascii == <br />
<br />
== Arrays == <br />
<br />
== Strings ==<br />
<br />
== Questions ==<br />
Feel free to edit this section and post questions, I'll do my best to answer them. But you may need to contact me to let me know that a question exists.</div>68.144.105.148https://wiki.skullsecurity.org/index.php?title=Fundamentals&diff=20Fundamentals2007-03-11T19:09:07Z<p>68.144.105.148: /* Datatypes */</p>
<hr />
<div>This page is going to be about the fundamentals that you have to understand before you can make any sense out of assembly. Most of this stuff you'll learn if you learn to program in C. If this is old or boring stuff to you, feel free to skip this section entirely. <br />
<br />
The topics here are going to be a short overview of each section. If you want a more complete explanation, you should find an actual reference, or look it up on the Internet. This is only meant to be a quick and dirty primer. <br />
<br />
== Hexadecimal ==<br />
To work in assembly, you have to be able to read hexadecimal fairly comfortably. Converting to decimal in your mind isn't necessary, but being able to do some simple arithmetic is. <br />
<br />
Hex can be denoted in a number of ways, but the two most common are:<br />
* Prefixed with a 0x, eg. 0x1ef7<br />
* Postfixed with a h, eg. 1ef7h<br />
<br />
The characters 0 - f represent the decimal numbers 0 - 15:<br />
* 0 = 0<br />
* 1 = 1<br />
* ...<br />
* 9 = 9<br />
* a = 10<br />
* b = 11<br />
* c = 12<br />
* d = 13<br />
* e = 14<br />
* f = 15<br />
<br />
To convert from hex to decimal, multiply each digit, starting with the right-most, with 16<sup>0</sup>, 16<sup>1</sup>, 16<sup>2</sup>, etc. So in the example of 0x1ef7, the conversion is this:<br />
* (7 * 16<sup>0</sup>) + (f * 16<sup>1</sup>) + (e * 16<sup>2</sup>) + (1 * 16<sup>3</sup>)<br />
* = (7 * 16<sup>0</sup>) + (15 * 16<sup>1</sup>) + (14 * 16<sup>2</sup>) + (1 * 16<sup>3</sup>)<br />
* = (7 * 1) + (15 * 16) + (14 * 256) + (1 * 4096)<br />
* = 7 + 240 + 3584 + 4096<br />
* = 7927<br />
<br />
It isn't necessary to do that constantly, that's why we have calculators. But you should be fairly familiar with the numbers 00 - FF (0 - 255), they will come up often and you will spend a lot of time looking them up. <br />
<br />
== Datatypes ==<br />
<br />
A datatype basically refers to how digits in hex are partitioned off and divided into numbers. Datatypes are typically measures by two factors: the number of bits (or bytes), and whether or not negative numbers are allowed. <br />
<br />
Although different data lengths are called different things, here are some common ones by their usual name:<br />
<br />
* 8-bit (1 byte) = char (or BYTE)<br />
** In hex, can be 0x00 to 0xFF<br />
** Signed: ranges from -128 to 127<br />
** Unsigned: ranges from 0 to 255<br />
<br />
<br />
* 16-bit (2 bytes) = short int (often referred to as a WORD)<br />
** In hex, can be 0x0000 to 0xFFFF<br />
** Signed: ranges from -32768 to 32767<br />
** Unsigned: ranges from 0 to 65535<br />
<br />
<br />
* 32-bit (4 bytes) = long int (often referred to as a DWORD or double-WORD)<br />
** In hex, can be 0x00000000 to 0xFFFFFFFF<br />
** Signed: ranges from -2147483648 - 2147483647<br />
** Unsigned: ranges from 0 - 4294967295<br />
<br />
* 64-bit (8 bytes) = long long (often referred to as a QWORD or quad-WORD)<br />
<br />
== Memory ==<br />
<br />
== Pointers == <br />
<br />
== Ascii == <br />
<br />
== Arrays == <br />
<br />
== Strings ==<br />
<br />
== Questions ==<br />
Feel free to edit this section and post questions, I'll do my best to answer them. But you may need to contact me to let me know that a question exists.</div>68.144.105.148https://wiki.skullsecurity.org/index.php?title=Fundamentals&diff=19Fundamentals2007-03-11T19:08:54Z<p>68.144.105.148: /* Datatypes */</p>
<hr />
<div>This page is going to be about the fundamentals that you have to understand before you can make any sense out of assembly. Most of this stuff you'll learn if you learn to program in C. If this is old or boring stuff to you, feel free to skip this section entirely. <br />
<br />
The topics here are going to be a short overview of each section. If you want a more complete explanation, you should find an actual reference, or look it up on the Internet. This is only meant to be a quick and dirty primer. <br />
<br />
== Hexadecimal ==<br />
To work in assembly, you have to be able to read hexadecimal fairly comfortably. Converting to decimal in your mind isn't necessary, but being able to do some simple arithmetic is. <br />
<br />
Hex can be denoted in a number of ways, but the two most common are:<br />
* Prefixed with a 0x, eg. 0x1ef7<br />
* Postfixed with a h, eg. 1ef7h<br />
<br />
The characters 0 - f represent the decimal numbers 0 - 15:<br />
* 0 = 0<br />
* 1 = 1<br />
* ...<br />
* 9 = 9<br />
* a = 10<br />
* b = 11<br />
* c = 12<br />
* d = 13<br />
* e = 14<br />
* f = 15<br />
<br />
To convert from hex to decimal, multiply each digit, starting with the right-most, with 16<sup>0</sup>, 16<sup>1</sup>, 16<sup>2</sup>, etc. So in the example of 0x1ef7, the conversion is this:<br />
* (7 * 16<sup>0</sup>) + (f * 16<sup>1</sup>) + (e * 16<sup>2</sup>) + (1 * 16<sup>3</sup>)<br />
* = (7 * 16<sup>0</sup>) + (15 * 16<sup>1</sup>) + (14 * 16<sup>2</sup>) + (1 * 16<sup>3</sup>)<br />
* = (7 * 1) + (15 * 16) + (14 * 256) + (1 * 4096)<br />
* = 7 + 240 + 3584 + 4096<br />
* = 7927<br />
<br />
It isn't necessary to do that constantly, that's why we have calculators. But you should be fairly familiar with the numbers 00 - FF (0 - 255), they will come up often and you will spend a lot of time looking them up. <br />
<br />
== Datatypes ==<br />
<br />
A datatype basically refers to how digits in hex are partitioned off and divided into numbers. Datatypes are typically measures by two factors: the number of bits (or bytes), and whether or not negative numbers are allowed. <br />
<br />
Although different data lengths are called different things, here are some common ones by their usual name:<br />
<br />
* 8-bit (1 byte) = char (or BYTE)<br />
** In hex, can be 0x00 to 0xFF<br />
** Signed: ranges from -128 to 127<br />
** Unsigned: ranges from 0 to 255<br />
<br />
* 16-bit (2 bytes) = short int (often referred to as a WORD)<br />
** In hex, can be 0x0000 to 0xFFFF<br />
** Signed: ranges from -32768 to 32767<br />
** Unsigned: ranges from 0 to 65535<br />
<br />
* 32-bit (4 bytes) = long int (often referred to as a DWORD or double-WORD)<br />
** In hex, can be 0x00000000 to 0xFFFFFFFF<br />
** Signed: ranges from -2147483648 - 2147483647<br />
** Unsigned: ranges from 0 - 4294967295<br />
<br />
* 64-bit (8 bytes) = long long (often referred to as a QWORD or quad-WORD)<br />
<br />
== Memory ==<br />
<br />
== Pointers == <br />
<br />
== Ascii == <br />
<br />
== Arrays == <br />
<br />
== Strings ==<br />
<br />
== Questions ==<br />
Feel free to edit this section and post questions, I'll do my best to answer them. But you may need to contact me to let me know that a question exists.</div>68.144.105.148https://wiki.skullsecurity.org/index.php?title=Fundamentals&diff=18Fundamentals2007-03-11T19:07:23Z<p>68.144.105.148: /* Datatypes */</p>
<hr />
<div>This page is going to be about the fundamentals that you have to understand before you can make any sense out of assembly. Most of this stuff you'll learn if you learn to program in C. If this is old or boring stuff to you, feel free to skip this section entirely. <br />
<br />
The topics here are going to be a short overview of each section. If you want a more complete explanation, you should find an actual reference, or look it up on the Internet. This is only meant to be a quick and dirty primer. <br />
<br />
== Hexadecimal ==<br />
To work in assembly, you have to be able to read hexadecimal fairly comfortably. Converting to decimal in your mind isn't necessary, but being able to do some simple arithmetic is. <br />
<br />
Hex can be denoted in a number of ways, but the two most common are:<br />
* Prefixed with a 0x, eg. 0x1ef7<br />
* Postfixed with a h, eg. 1ef7h<br />
<br />
The characters 0 - f represent the decimal numbers 0 - 15:<br />
* 0 = 0<br />
* 1 = 1<br />
* ...<br />
* 9 = 9<br />
* a = 10<br />
* b = 11<br />
* c = 12<br />
* d = 13<br />
* e = 14<br />
* f = 15<br />
<br />
To convert from hex to decimal, multiply each digit, starting with the right-most, with 16<sup>0</sup>, 16<sup>1</sup>, 16<sup>2</sup>, etc. So in the example of 0x1ef7, the conversion is this:<br />
* (7 * 16<sup>0</sup>) + (f * 16<sup>1</sup>) + (e * 16<sup>2</sup>) + (1 * 16<sup>3</sup>)<br />
* = (7 * 16<sup>0</sup>) + (15 * 16<sup>1</sup>) + (14 * 16<sup>2</sup>) + (1 * 16<sup>3</sup>)<br />
* = (7 * 1) + (15 * 16) + (14 * 256) + (1 * 4096)<br />
* = 7 + 240 + 3584 + 4096<br />
* = 7927<br />
<br />
It isn't necessary to do that constantly, that's why we have calculators. But you should be fairly familiar with the numbers 00 - FF (0 - 255), they will come up often and you will spend a lot of time looking them up. <br />
<br />
== Datatypes ==<br />
<br />
A datatype basically refers to how digits in hex are partitioned off and divided into numbers. Datatypes are typically measures by two factors: the number of bits (or bytes), and whether or not negative numbers are allowed. <br />
<br />
Although different data lengths are called different things, here are some common ones by their usual name:<br />
<br />
{|<br />
|+ Datatypes<br />
|| '''Common Name''' || '''Bits''' || '''Bytes''' || '''Hex Range''' || '''Signed Range''' || '''Unsigned Range'''<br />
|-<br />
| '''char (or BYTE)''' || 8 || 1 || 0x00 - 0xFF || -128 - 127 || 0 - 255<br />
|-<br />
|| '''short int (or WORD)''' || 16 || 2 || 0x0000 - 0xFFFF || -32768 - 32767 || 0 - 65535<br />
|-<br />
|| '''long int (or DWORD, Double WORD)''' || 32 || 4 || 0x00000000 - 0xFFFFFFFF || -2147483648 - 2147483647 || 0 - 4294967295<br />
|}<br />
<br />
* 8-bit (1 byte) = char (or BYTE)<br />
** In hex, can be 0x00 to 0xFF<br />
** Signed: ranges from -128 to 127<br />
** Unsigned: ranges from 0 to 255<br />
<br />
* 16-bit (2 bytes) = short int (often referred to as a WORD)<br />
** In hex, can be 0x0000 to 0xFFFF<br />
** Signed: ranges from -32768 to 32767<br />
** Unsigned: ranges from 0 to 65535<br />
<br />
* 32-bit (4 bytes) = long int (often referred to as a DWORD or double-WORD)<br />
** In hex, can be 0x00000000 to 0xFFFFFFFF<br />
** Signed: ranges from <br />
* 64-bit (8 bytes) = long long (often referred to as a QWORD or quad-WORD)<br />
<br />
== Memory ==<br />
<br />
== Pointers == <br />
<br />
== Ascii == <br />
<br />
== Arrays == <br />
<br />
== Strings ==<br />
<br />
== Questions ==<br />
Feel free to edit this section and post questions, I'll do my best to answer them. But you may need to contact me to let me know that a question exists.</div>68.144.105.148https://wiki.skullsecurity.org/index.php?title=Fundamentals&diff=17Fundamentals2007-03-11T19:05:52Z<p>68.144.105.148: /* Datatypes */</p>
<hr />
<div>This page is going to be about the fundamentals that you have to understand before you can make any sense out of assembly. Most of this stuff you'll learn if you learn to program in C. If this is old or boring stuff to you, feel free to skip this section entirely. <br />
<br />
The topics here are going to be a short overview of each section. If you want a more complete explanation, you should find an actual reference, or look it up on the Internet. This is only meant to be a quick and dirty primer. <br />
<br />
== Hexadecimal ==<br />
To work in assembly, you have to be able to read hexadecimal fairly comfortably. Converting to decimal in your mind isn't necessary, but being able to do some simple arithmetic is. <br />
<br />
Hex can be denoted in a number of ways, but the two most common are:<br />
* Prefixed with a 0x, eg. 0x1ef7<br />
* Postfixed with a h, eg. 1ef7h<br />
<br />
The characters 0 - f represent the decimal numbers 0 - 15:<br />
* 0 = 0<br />
* 1 = 1<br />
* ...<br />
* 9 = 9<br />
* a = 10<br />
* b = 11<br />
* c = 12<br />
* d = 13<br />
* e = 14<br />
* f = 15<br />
<br />
To convert from hex to decimal, multiply each digit, starting with the right-most, with 16<sup>0</sup>, 16<sup>1</sup>, 16<sup>2</sup>, etc. So in the example of 0x1ef7, the conversion is this:<br />
* (7 * 16<sup>0</sup>) + (f * 16<sup>1</sup>) + (e * 16<sup>2</sup>) + (1 * 16<sup>3</sup>)<br />
* = (7 * 16<sup>0</sup>) + (15 * 16<sup>1</sup>) + (14 * 16<sup>2</sup>) + (1 * 16<sup>3</sup>)<br />
* = (7 * 1) + (15 * 16) + (14 * 256) + (1 * 4096)<br />
* = 7 + 240 + 3584 + 4096<br />
* = 7927<br />
<br />
It isn't necessary to do that constantly, that's why we have calculators. But you should be fairly familiar with the numbers 00 - FF (0 - 255), they will come up often and you will spend a lot of time looking them up. <br />
<br />
== Datatypes ==<br />
<br />
A datatype basically refers to how digits in hex are partitioned off and divided into numbers. Datatypes are typically measures by two factors: the number of bits (or bytes), and whether or not negative numbers are allowed. <br />
<br />
Although different data lengths are called different things, here are some common ones by their usual name:<br />
<br />
{|<br />
|+ Datatypes<br />
| Common Name !! Bits !! Bytes !! Hex Range !! Signed Range !! Unsigned Range<br />
|-<br />
| char (or BYTE) || 8 || 1 || 0x00 - 0xFF || -128 - 127 || 0 - 255<br />
|-<br />
|| short int (or WORD) || 16 || 2 || 0x0000 - 0xFFFF || -32768 - 32767 || 0 - 65535<br />
|-<br />
|| long int (or DWORD, Double WORD) || 32 || 4 || 0x00000000 - 0xFFFFFFFF || -2147483648 - 2147483647 || 0 - 4294967295<br />
|}<br />
<br />
* 8-bit (1 byte) = char (or BYTE)<br />
** In hex, can be 0x00 to 0xFF<br />
** Signed: ranges from -128 to 127<br />
** Unsigned: ranges from 0 to 255<br />
<br />
* 16-bit (2 bytes) = short int (often referred to as a WORD)<br />
** In hex, can be 0x0000 to 0xFFFF<br />
** Signed: ranges from -32768 to 32767<br />
** Unsigned: ranges from 0 to 65535<br />
<br />
* 32-bit (4 bytes) = long int (often referred to as a DWORD or double-WORD)<br />
** In hex, can be 0x00000000 to 0xFFFFFFFF<br />
** Signed: ranges from <br />
* 64-bit (8 bytes) = long long (often referred to as a QWORD or quad-WORD)<br />
<br />
== Memory ==<br />
<br />
== Pointers == <br />
<br />
== Ascii == <br />
<br />
== Arrays == <br />
<br />
== Strings ==<br />
<br />
== Questions ==<br />
Feel free to edit this section and post questions, I'll do my best to answer them. But you may need to contact me to let me know that a question exists.</div>68.144.105.148https://wiki.skullsecurity.org/index.php?title=Fundamentals&diff=16Fundamentals2007-03-11T19:05:06Z<p>68.144.105.148: /* Datatypes */</p>
<hr />
<div>This page is going to be about the fundamentals that you have to understand before you can make any sense out of assembly. Most of this stuff you'll learn if you learn to program in C. If this is old or boring stuff to you, feel free to skip this section entirely. <br />
<br />
The topics here are going to be a short overview of each section. If you want a more complete explanation, you should find an actual reference, or look it up on the Internet. This is only meant to be a quick and dirty primer. <br />
<br />
== Hexadecimal ==<br />
To work in assembly, you have to be able to read hexadecimal fairly comfortably. Converting to decimal in your mind isn't necessary, but being able to do some simple arithmetic is. <br />
<br />
Hex can be denoted in a number of ways, but the two most common are:<br />
* Prefixed with a 0x, eg. 0x1ef7<br />
* Postfixed with a h, eg. 1ef7h<br />
<br />
The characters 0 - f represent the decimal numbers 0 - 15:<br />
* 0 = 0<br />
* 1 = 1<br />
* ...<br />
* 9 = 9<br />
* a = 10<br />
* b = 11<br />
* c = 12<br />
* d = 13<br />
* e = 14<br />
* f = 15<br />
<br />
To convert from hex to decimal, multiply each digit, starting with the right-most, with 16<sup>0</sup>, 16<sup>1</sup>, 16<sup>2</sup>, etc. So in the example of 0x1ef7, the conversion is this:<br />
* (7 * 16<sup>0</sup>) + (f * 16<sup>1</sup>) + (e * 16<sup>2</sup>) + (1 * 16<sup>3</sup>)<br />
* = (7 * 16<sup>0</sup>) + (15 * 16<sup>1</sup>) + (14 * 16<sup>2</sup>) + (1 * 16<sup>3</sup>)<br />
* = (7 * 1) + (15 * 16) + (14 * 256) + (1 * 4096)<br />
* = 7 + 240 + 3584 + 4096<br />
* = 7927<br />
<br />
It isn't necessary to do that constantly, that's why we have calculators. But you should be fairly familiar with the numbers 00 - FF (0 - 255), they will come up often and you will spend a lot of time looking them up. <br />
<br />
== Datatypes ==<br />
<br />
A datatype basically refers to how digits in hex are partitioned off and divided into numbers. Datatypes are typically measures by two factors: the number of bits (or bytes), and whether or not negative numbers are allowed. <br />
<br />
Although different data lengths are called different things, here are some common ones by their usual name:<br />
<br />
{|<br />
|+ Datatypes<br />
! Common Name !! Bits !! Bytes !! Hex Range !! Signed Range !! Unsigned Range<br />
|-<br />
! char (or BYTE)<br />
|8 || 1 || 0x00 - 0xFF || -128 - 127 || 0 - 255<br />
|-<br />
! short int (or WORD)<br />
|16 || 2 || 0x0000 - 0xFFFF || -32768 - 32767 || 0 - 65535<br />
|-<br />
! long int (or DWORD, Double WORD)<br />
|32 || 4 || 0x00000000 - 0xFFFFFFFF || -2147483648 - 2147483647 || 0 - 4294967295<br />
|}<br />
<br />
* 8-bit (1 byte) = char (or BYTE)<br />
** In hex, can be 0x00 to 0xFF<br />
** Signed: ranges from -128 to 127<br />
** Unsigned: ranges from 0 to 255<br />
<br />
* 16-bit (2 bytes) = short int (often referred to as a WORD)<br />
** In hex, can be 0x0000 to 0xFFFF<br />
** Signed: ranges from -32768 to 32767<br />
** Unsigned: ranges from 0 to 65535<br />
<br />
* 32-bit (4 bytes) = long int (often referred to as a DWORD or double-WORD)<br />
** In hex, can be 0x00000000 to 0xFFFFFFFF<br />
** Signed: ranges from <br />
* 64-bit (8 bytes) = long long (often referred to as a QWORD or quad-WORD)<br />
<br />
== Memory ==<br />
<br />
== Pointers == <br />
<br />
== Ascii == <br />
<br />
== Arrays == <br />
<br />
== Strings ==<br />
<br />
== Questions ==<br />
Feel free to edit this section and post questions, I'll do my best to answer them. But you may need to contact me to let me know that a question exists.</div>68.144.105.148https://wiki.skullsecurity.org/index.php?title=Fundamentals&diff=15Fundamentals2007-03-11T18:47:41Z<p>68.144.105.148: </p>
<hr />
<div>This page is going to be about the fundamentals that you have to understand before you can make any sense out of assembly. Most of this stuff you'll learn if you learn to program in C. If this is old or boring stuff to you, feel free to skip this section entirely. <br />
<br />
The topics here are going to be a short overview of each section. If you want a more complete explanation, you should find an actual reference, or look it up on the Internet. This is only meant to be a quick and dirty primer. <br />
<br />
== Hexadecimal ==<br />
To work in assembly, you have to be able to read hexadecimal fairly comfortably. Converting to decimal in your mind isn't necessary, but being able to do some simple arithmetic is. <br />
<br />
Hex can be denoted in a number of ways, but the two most common are:<br />
* Prefixed with a 0x, eg. 0x1ef7<br />
* Postfixed with a h, eg. 1ef7h<br />
<br />
The characters 0 - f represent the decimal numbers 0 - 15:<br />
* 0 = 0<br />
* 1 = 1<br />
* ...<br />
* 9 = 9<br />
* a = 10<br />
* b = 11<br />
* c = 12<br />
* d = 13<br />
* e = 14<br />
* f = 15<br />
<br />
To convert from hex to decimal, multiply each digit, starting with the right-most, with 16<sup>0</sup>, 16<sup>1</sup>, 16<sup>2</sup>, etc. So in the example of 0x1ef7, the conversion is this:<br />
* (7 * 16<sup>0</sup>) + (f * 16<sup>1</sup>) + (e * 16<sup>2</sup>) + (1 * 16<sup>3</sup>)<br />
* = (7 * 16<sup>0</sup>) + (15 * 16<sup>1</sup>) + (14 * 16<sup>2</sup>) + (1 * 16<sup>3</sup>)<br />
* = (7 * 1) + (15 * 16) + (14 * 256) + (1 * 4096)<br />
* = 7 + 240 + 3584 + 4096<br />
* = 7927<br />
<br />
It isn't necessary to do that constantly, that's why we have calculators. But you should be fairly familiar with the numbers 00 - FF (0 - 255), they will come up often and you will spend a lot of time looking them up. <br />
<br />
== Datatypes ==<br />
- Bits<br />
<br />
== Memory ==<br />
<br />
== Pointers == <br />
<br />
== Ascii == <br />
<br />
== Arrays == <br />
<br />
== Strings ==<br />
<br />
== Questions ==<br />
Feel free to edit this section and post questions, I'll do my best to answer them. But you may need to contact me to let me know that a question exists.</div>68.144.105.148https://wiki.skullsecurity.org/index.php?title=Fundamentals&diff=14Fundamentals2007-03-11T18:38:07Z<p>68.144.105.148: New page: This page is going to be about the fundamentals that you have to understand before you can make any sense out of assembly. Most of this stuff you'll learn if you learn to program in C. If ...</p>
<hr />
<div>This page is going to be about the fundamentals that you have to understand before you can make any sense out of assembly. Most of this stuff you'll learn if you learn to program in C. If this is old or boring stuff to you, feel free to skip this section entirely. <br />
<br />
== Hexadecimal ==<br />
<br />
== Datatypes ==<br />
- Bits<br />
<br />
== Memory ==<br />
<br />
== Pointers == <br />
<br />
== Ascii == <br />
<br />
== Arrays == <br />
<br />
== Strings ==<br />
<br />
== Questions ==<br />
Feel free to edit this section and post questions, I'll do my best to answer them. But you may need to contact me to let me know that a question exists.</div>68.144.105.148https://wiki.skullsecurity.org/index.php?title=Sandbox&diff=7Sandbox2007-03-11T02:17:42Z<p>68.144.105.148: New page: This page is for playing or testing!</p>
<hr />
<div>This page is for playing or testing!</div>68.144.105.148https://wiki.skullsecurity.org/index.php?title=Main_Page&diff=6Main Page2007-03-11T02:16:06Z<p>68.144.105.148: </p>
<hr />
<div><big>'''Welcome to the Skull Security Wiki!'''</big><br />
<br />
This wiki was started by Ron (also known as iago[x86]), and is dedicated to anything that I find interesting, feel like writing about, or want to share knowledge about. Since this is a wiki, you are free to make changes, if you want to. But keep in mind that this is designed to be mine, so keep that in mind if you intend to change anything. <br />
<br />
== Getting started ==<br />
<br />
Here are the categories where I've written something:<br />
* [[Assembly]]<br />
<br />
== Format ==<br />
Although this is technically a personal site, I have opted to do it as a wiki. I did it for a few reasons:<br />
* Looks nice<br />
* Easy to update<br />
* To spite Blaze<br />
<br />
At the top of sections, I am planning on having a policy on editing clearly visible. Generally, minor edits (to fix small mistakes like spelling/grammar) that don't change the content or meaning are okay, and any other edits should be run by me first. This policy may vary section to section, so check if I've written a policy before making any changes. <br />
<br />
Note that I'm generally happy to have people help out, as long as you let me know first! <br />
<br />
If you don't know how to reach me, send an email to ron@skullsecurity.com. <br />
<br />
== Wiki Stuff ==<br />
* [[Sandbox]]<br />
* [[:Special:Specialpages|Special Pages]]<br />
* [[:Special:Categories|Categories]]<br />
* [http://meta.wikimedia.org/wiki/Help:Contents User's Guide]</div>68.144.105.148https://wiki.skullsecurity.org/index.php?title=Assembly&diff=5Assembly2007-03-11T02:09:49Z<p>68.144.105.148: </p>
<hr />
<div>Welcome to the assembly page! <br />
<br />
Here you will find various tutorials on assembly (which may include cracking and hacking). <br />
<br />
In general, I've tried to start with the basics, and work up to more complicated stuff. I'm going to be writing these in my free time, so check back later to see if more have appeared! <br />
<br />
== Edit Policy ==<br />
If you intend to edit anything on these pages, unless it's a minor change (spelling or grammar, for instance), please let me know first! <br />
<br />
== Basics ==<br />
* [[Fundamental Requirements]] -- Mostly information about C, which you have to be comfortable with(datatypes, memory, pointers, ascii, array, strings, etc)<br />
* [[Tools]]<br />
* [[Registers]]<br />
* [[Simple Operations]]<br />
* [[Example 1]] -- Starcraft CDKey Verification<br />
* [[Example 2]] -- Starcraft CDKey Shuffle<br />
* [[Comparisons and Jumps]]<br />
* [[The Stack]]<br />
* [[Functions]]<br />
* [[Example 3]] -- Storm.dll SStrChr<br />
* [[Machine Code]]<br />
* [[Example 4]] -- Cracking a game<br />
* [[Writing a hack]]</div>68.144.105.148https://wiki.skullsecurity.org/index.php?title=Assembly&diff=4Assembly2007-03-11T01:26:01Z<p>68.144.105.148: New page: Welcome to the assembly page!
Here you will find various tutorials on assembly (which may include cracking and hacking).
In general, I've tried to start with the basics, and work up to...</p>
<hr />
<div>Welcome to the assembly page! <br />
<br />
Here you will find various tutorials on assembly (which may include cracking and hacking). <br />
<br />
In general, I've tried to start with the basics, and work up to more complicated stuff. I'm going to be writing these in my free time, so check back later to see if more have appeared! <br />
<br />
== Basics ==<br />
* [[Fundamental Requirements]] -- Mostly information about C, which you have to be comfortable with(datatypes, memory, pointers, ascii, array, strings, etc)<br />
* [[Tools]]<br />
* [[Registers]]<br />
* [[Simple Operations]]<br />
* [[Example 1]] -- Starcraft CDKey Verification<br />
* [[Example 2]] -- Starcraft CDKey Shuffle<br />
* [[Comparisons and Jumps]]<br />
* [[The Stack]]<br />
* [[Functions]]<br />
* [[Example 3]] -- Storm.dll SStrChr<br />
* [[Machine Code]]<br />
* [[Example 4]] -- Cracking a game<br />
* [[Writing a hack]]</div>68.144.105.148https://wiki.skullsecurity.org/index.php?title=Main_Page&diff=3Main Page2007-03-11T01:19:22Z<p>68.144.105.148: /* Getting started */</p>
<hr />
<div><big>'''Welcome to the Skull Security Wiki!'''</big><br />
<br />
This wiki was started by Ron (also known as iago[x86]), and is dedicated to anything that I find interesting, feel like writing about, or want to share knowledge about. Since this is a wiki, you are free to make changes, if you want to. But keep in mind that this is designed to be mine, so keep that in mind if you intend to change anything. <br />
<br />
== Getting started ==<br />
<br />
Here are the categories where I've written something:<br />
* [[Assembly]]<br />
<br />
== Wiki Stuff ==<br />
* [[Sandbox]]<br />
* [[:Special:Specialpages|Special Pages]]<br />
* [[:Special:Categories|Categories]]<br />
* [http://meta.wikimedia.org/wiki/Help:Contents User's Guide]</div>68.144.105.148https://wiki.skullsecurity.org/index.php?title=Main_Page&diff=2Main Page2007-03-11T01:19:09Z<p>68.144.105.148: </p>
<hr />
<div><big>'''Welcome to the Skull Security Wiki!'''</big><br />
<br />
This wiki was started by Ron (also known as iago[x86]), and is dedicated to anything that I find interesting, feel like writing about, or want to share knowledge about. Since this is a wiki, you are free to make changes, if you want to. But keep in mind that this is designed to be mine, so keep that in mind if you intend to change anything. <br />
<br />
== Getting started ==<br />
<br />
Here are the categories where I've written something:<br />
* [Assembly]<br />
<br />
== Wiki Stuff ==<br />
* [[Sandbox]]<br />
* [[:Special:Specialpages|Special Pages]]<br />
* [[:Special:Categories|Categories]]<br />
* [http://meta.wikimedia.org/wiki/Help:Contents User's Guide]</div>68.144.105.148