tag:blogger.com,1999:blog-82932578327823060472011-10-25T04:32:25.701-07:00Reverse EngineeringSeanhttp://www.blogger.com/profile/06911558688467600710noreply@blogger.comBlogger81100tag:blogger.com,1999:blog-8293257832782306047.post-8497070624251311462010-01-07T12:13:00.002-07:002010-01-07T12:42:14.520-07:00

I'm always interested in found data. Little notes buried in executables and other strange places. These are usually intended to be seen only by those curious enough to fire up a hex editor, or do a little reverse engineering.Here's an example. On the 68k Macintosh, executables usually only have a resource fork. All the code is stored in CODE blocks in the resource fork. So I was curious when

Seanhttp://www.blogger.com/profile/06911558688467600710noreply@blogger.com0tag:blogger.com,1999:blog-8293257832782306047.post-74154183397523644902008-01-31T17:13:00.000-07:002008-12-10T11:19:35.931-07:00

A posting on reddit lead to a discussion on typefaces. In particular one poster asked about the kerning of a word. Surprisingly, the kerning was perfect for me. I decided to compare it across the browsers I have access to.Here's the kerning in Firefox on Linux (Stock Ubuntu Gutsy):Notice how the A and V overlap? That's correct kerning.Here's how it looks in Firefox on OSX Tiger:Aside from the

Seanhttp://www.blogger.com/profile/06911558688467600710noreply@blogger.com1tag:blogger.com,1999:blog-8293257832782306047.post-60554968886365181162007-11-02T12:56:00.000-07:002007-11-02T16:45:54.376-07:00

We ran into a malicious banner ad yesterday. People would randomly get redirected to a malicious website. You can imagine that it's a pretty tough thing to diagnose. It turned out to be a flash ad. I was able to disassemble the banner ad to see how it worked. The banner is "protected" and compressed, so hex editing the banner doesn't show any text.Using Flare to decompile the actionscript in

Seanhttp://www.blogger.com/profile/06911558688467600710noreply@blogger.com1tag:blogger.com,1999:blog-8293257832782306047.post-74241118047721827662007-09-06T10:33:00.000-07:002007-09-06T11:10:38.882-07:00

There are two basic ways to assign a string literal to a local variable.char *p = "string";char a[] = "string";I was curious to see how gcc handles the two.In both cases, "string" is put into .rodata This means that with the first method, you must not modify the contents of "string".p[3]='o'; // this causes a segfault.So technically, the first method should be:const char *p = "string";With the

Seanhttp://www.blogger.com/profile/06911558688467600710noreply@blogger.com0tag:blogger.com,1999:blog-8293257832782306047.post-63696891249857214302007-07-31T16:24:00.000-07:002007-08-01T13:30:18.460-07:00

Did you know that Gmail provides a handy, light-weight API for gmail? Google's gmail midlet uses this API.Mobile Gmail BasicsFirst thing to note, all responses from the server are in the form of UTF8 string lists. There is a 16 bit word (in network byte order) that represents the length of the string, followed by that many bytes. Then another 16 bit word for the next string, and so on. The

Seanhttp://www.blogger.com/profile/06911558688467600710noreply@blogger.com7tag:blogger.com,1999:blog-8293257832782306047.post-10785074062618613022007-05-02T14:02:00.000-07:002007-05-02T14:11:01.198-07:00

Here's my entry for the 128-bit programming challenge. Not a single lookup table in there. The resulting stripped binary is down to exactly 500 bytes.; nasm -f elf hex.asm; ld hex.osection .textglobal _start_start: mov ecx,10h mov esi,hex mov edi,bufferlp: movzx eax,byte [esi] mov ah,al and al,0fh cmp al,0ah sbb al,

Seanhttp://www.blogger.com/profile/06911558688467600710noreply@blogger.com0tag:blogger.com,1999:blog-8293257832782306047.post-53982209920892649672007-03-01T14:39:00.000-07:002007-03-01T15:32:39.296-07:00

The following describes the format of the QPS 3.5 protocol. Earlier versions of QPS are very similar, with only minor packet changes. All communication between the client and the QPS server is done via Messages.Message from Client to Server.0000 0002 Session ID0002 0002 Code0004 0004 Version (0x003f003f)0008 0002 Sequence Number000a 0004 Sub-Data Length000e 0004 Packet Length0012 **** Data****

Seanhttp://www.blogger.com/profile/06911558688467600710noreply@blogger.com0tag:blogger.com,1999:blog-8293257832782306047.post-44963404422361833482007-03-01T13:07:00.000-07:002007-03-01T15:33:05.396-07:00

This is the file format used by Quark Copydesk.The file is broken into chunks. Each chunk is exactly 256 bytes long. Chunks are identified by their ID number. Chunk 1 starts at position 0, Chunk 2 starts at position 512, and so on. The first chunk in the file contains the header followed by the TOC.Quark Header:The first thing in this file is a 26 byte Quark Header.0000 0004 File Format

Seanhttp://www.blogger.com/profile/06911558688467600710noreply@blogger.com0