custom file format and cracking, compiled executable and hacking ?

[RemiD]

hi ! 

i have a good understanding on how to write / read files with text or binary datas.

and from my limited understanding it is difficult to extract meaningful datas from a binary file (or even from a text file) if the file format (how datas is organized and what it means) is not known by the person who tries to extract datas from it.

but i have seen on some pirate forums (by curiosity) that some programmers have the ability to extract datas from any file in a hex editor (or something like that) and create patches to make a game / app work as they want.

i can understand how somebody can identify and modify a few variables in memory (like fastext does) to cheat / upgrade a game.

but say i want to code a simple app (like a text editor) to store logins/passwords, which would saves /loads the datas in a custom binary file. and the opening of the app would require a password.

how hard would it be for somebody to hack/crack this executable (to not have to know the password to open it), or to extract meaningful datas from the custom binary file ?

(i would use blitz3d to create the executable / file)

your thoughts ?

thanks,

[Derron]

"to not know the password"

They open your binary in a "disassembler" (IDA or so), run the program until it it does the password request - then they look for a simple "jump equal" or "jump not equal" instruction (je/jne) and switch them.
The binary would then accept every WRONG password but not the right one.


If you talked about a encrypted data file (so content of the file is "scrambled" with your password) then you cannot "hack" the program to auto-decrypt it. The user enters a password and the app decrypts the data ... it either does it blindly to not give a clue ("whatever is decrypted is then used") or it has some data in the package which it then must be able to "read" (else the password was not correct).
The binary would not contain a password to "compare" - so you cannot extract stuff.
You can only brute force the password - or steal it from a computer who enters the correct password.



@ file extraction
If files keep their "file headers" (so you just read from a "part of the data file" - without requiring the image loader to know about a "trimmed" image file format) then the ressource extractors just scan for "known" magic bytes ... to identify png, jpg, ...pdf... they then extract the data from "file to next file" or "file start to given length". Files extracted.


@ file extraction 2
Once a file is extracted into memory, you can try to dump from there. For 3D games a lot of textures can simply be extracted from the GPU ... just take one of these OpenGL/DirectX/Vulkan/... render-analyzers.
Example: http://apitrace.github.io
Download the textures... and done. Same said for 3d models. This is why stuff like "cgi porn" with famous game characters can exist so fast. Extract the data, add body morphs (this can even be done semiautomatically ... ) and done ... "game main character" with wobbling ... elements.



bye
Ron

[RemiD]

They open your binary in a "disassembler" (IDA or so), run the program until it it does the password request - then they look for a simple "jump equal" or "jump not equal" instruction (je/jne) and switch them.
The binary would then accept every WRONG password but not the right one.

it sounds easy, but is it so easy in reality ?

If you talked about a encrypted data file (so content of the file is "scrambled" with your password) then you cannot "hack" the program to auto-decrypt it. The user enters a password and the app decrypts the data ... it either does it blindly to not give a clue ("whatever is decrypted is then used") or it has some data in the package which it then must be able to "read" (else the password was not correct).
The binary would not contain a password to "compare" - so you cannot extract stuff.

so this password would be in the encrypted file, and the algorithm to encrypt/decrypt the file would be in the executable ?

what if the password is not stored in the executable but is also encrypted in the binary file, and the executable only contains the algorithm to encrypt/decrypt the password (and the datas) ?

about files headers to describe the format of a file, yes i am aware of that, especially useful to recover deleted files on a hard drive. ("recuva")

( thanks for the infos! )

[Derron]

it sounds easy, but is it so easy in reality ?

Yes ... except the binary has checks against being tampered. But these simple je/jne things were what... people... used in the 90s or early 00s used to crack stuff or to at least "bypass" stuff.
Similar things were done to remove "nag screens" of shareware / about trial periods ...

what if the password is not stored in the executable but is also encrypted in the binary file, and the executable only contains the algorithm to encrypt/decrypt the password (and the datas) ?

No ... this would make it insecure. If the application contained the password "somehow" it can be extracted:
- hardcoded : the binary contains the password
- hardcoded and "scrambled/encoded": somewhere the password is made "original" and this is then where you extract it
- password in data file: the decoding algorithm for the password is in the binary ... so you could read the password right when it decodes the stuff

This is why you would always need to ENTER (or load from a file, usb stick/dongle, ... remote internet thing, ...) the password - albeit you can also find workarounds for this. As soon as you store the password in a file or so, there will be a way to read the password. And if they do not use "passwords" but hashes -- your task is to create a hash collision. This means you do not need to know the password itself, but you "simply" need to find a text which creates the same hash (eg for the old "md5" there are multiple texts resulting in the same hash - which results in a <100% security of having unique "hashes" when doing a "hash map" based on md5. Same said for some "integer based" algorithms - eg. BlitzMax NG now uses "hashes" for strings to ease comparison - number vs number ... instead of bunch of characters vs bunch of characters)


bye
Ron

[RemiD]

As soon as you store the password in a file or so, there will be a way to read the password.

of course there will be a way to read it, but if the password is obfuscated with a custom algorithm, the person who tries to use it to open the program won't know what is the normal password (not obfuscated)

and i don't see how somebody can extract a custom algorithm from an executable...

maybe there are some hackers / crackers who can do that, but i doubt that they would someday target me. (the program and binary file will stay offline)

my goal is only to protect my logins / passwords better than in a text file, and not have to rely on a software which i can't verify if i can trust or not...

[Derron]

of course there will be a way to read it, but if the password is obfuscated with a custom algorithm, the person who tries to use it to open the program won't know what is the normal password (not obfuscated)

and i don't see how somebody can extract a custom algorithm from an executable...

File: 654321
your app:
- "read file"
- mighty algorithm: reverse content: newVariable = 123456

"hacker":
- hmm file content gets read? what happens with it?
- oh... content gets processed into a new variable
- variable content is "1235456"


So as soon as your application processes something the hacker does not have to enter ("manually entered password") they will be able to read it out.



BTW you did not ask for "how to avoid average joe to steal my assets / read my data". If you want to protect your multiple passwords from others (who might steal your computer!) then use one of the password managers (single password to store multiple ones).
I would be more afraid of being attacked with some trojan software simply keylogging my passwords...


bye
Ron

[RemiD]

So as soon as your application processes something the hacker does not have to enter ("manually entered password") they will be able to read it out.

i see... thanks for the clarification


i don't trust a password manager app...


and yes i am aware of malwares, this is a complex issue : how do you know that you can trust an anti malwares company (who provides an anti malwares app)

i do use one and i chose to trust a company (malwares bytes), but i don't know what the updates really do !!!


next step : code my own OS